> ## Documentation Index > Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt > Use this file to discover all available pages before exploring further. # Voice Traffic-Lane and Voice-Classification FAQ > The most-asked questions about the outbound-voice guard's decision inputs — when a call resolves marketing vs transactional and how to claim marketing from your metadata, why a +1 recipient lookup fails on a call that is nothing like the blocked-call runbook, the exact stamping order that runs before the guard, and where the decision ledger records every verdict. # Voice Traffic-Lane and Voice-Classification FAQ The [voice guard runbook](/compliance/voice-guard) documents the federal dialing-window gate end to end, and the [blocked-call troubleshooting page](/troubleshooting/tcpa-window-blocked-calls) walks a call that is already on the floor. Support volume around the guard is not "why was this call denied" — it is the questions **upstream of the denial**: which lane your call resolved, why a destination lookup failed, what ran before the guard saw your call, and where the verdict landed afterward. This page answers those four. Tenant-owned controls, not legal advice. Which laws apply to your traffic depends on your jurisdiction, your recipients, and what you send — confirm with qualified counsel before you rely on the wording here. ## 1. When is my call marketing vs transactional? The lane-resolution question. Every outbound voice dispatch — API dial, softphone click-to-call, campaign, dialer, callback, Flow Builder `make _call` — resolves to a lane of `marketing` or `transactional` **before** the federal window is evaluated. `transactional` dials 24/7; `marketing` is governed by the recipient-local 8 AM–9 PM window the moment recovery is time-based. The federal window answers *time*; the lane answers *whether time applies*. The resolution rules, in precedence order: 1. **Artificial or prerecorded voice** → `marketing`. Any of these on the call metadata resolves marketing no matter what else is there: a TTS payload (`tts_text`, `tts_body`, `message_body`), a routed agent (`voice_agent_id`), a cloned-voice model (`voice_cloned_model_id`, `agent_id`), or an explicit `voice_content_type` of `"synthetic"` or `"cloned"`. The statute names precisely this — the TCPA federal window restricts "artificial or prerecorded voice" — so this step is evaluated before anything else. 2. **An explicit claim you made** — `"traffic_lane": "marketing"` on the request metadata → `marketing`. 3. **Campaign / journey / dialer / broadcast origin** → `marketing`. Any of these metadata keys resolves marketing: `campaign_id`, `journey_campaign_id`, `dialer_campaign_id`, `broadcast_id`, `flow_execution_id`. A Flow Builder `make_call` node dials on an event, a schedule, or a webhook with no operator on the line, so flow-origin traffic is governed by default. 4. **Unattended origination** → `marketing`. `amd_requested` (answering- machine detection) or `dynamic_variables` (per-recipient substitution) on the metadata: a dial nobody is attending is an outbound blast, not a hand-placed one. 5. **Otherwise** → `transactional`. A direct API dial or a softphone click-to-call with none of the above resolves transactional and dials 24/7. **The one-way ratchet.** Only `traffic_lane: "marketing"` is honored. An explicit `traffic_lane: "transactional"` claim is *ignored* and the inference above runs — a caller can make its own call more governed, never less. Your metadata blob travels unauthenticated from your request body through the dispatch path, and honoring a transactional claim off it would type around the federal gate. If a server-side dispatcher (verified origin) needs a transactional lane, the platform stamps it on a trusted internal field — never the caller-supplied `metadata` bag. **How to claim marketing.** When you genuinely want your call governed — a dialer you run socially but not legally, a campaign where the metadata shaped by the dispatcher did not yet hit the origin keys — pass `"traffic_lane": "marketing"` in the request `metadata` bag and Orbit enforces the window. This is the only way a voice caller can opt a call into governance; the messaging `traffic_lane` override (see [Message priority traffic lanes](/concepts/message-priority-traffic-lanes)) uses the same name there, but voice rejects the reverse direction on purpose. ## 2. Why did the +1 recipient lookup fail and how do I fix it? The [blocked-call troubleshooting page](/troubleshooting/tcpa-window-blocked-calls) walks a call that evaluated the guard and lost — this is the *lookup* question: your call returned with no federal verdict at all because the recipient could not be resolved. The lookup sits before the gate: recipient E.164 → area-code → IANA timezone (for +1), or country-code prefix for non-+1. When none of that resolves, the voice guard fails closed by design and returns the dial `timezone_unresolved`, not a warning. The split is described on [Number timezone and state resolution](/compliance/number-timezone-resolution); the voice-specific handling is what this section answers. **Fix: pass an explicit `recipientTimezone` hint.** The lookup chain runs an explicit-per-request hint first, then the area-code inventory, then the prefix fallback. If your recipient's actual timezone is known — you hold it against your contact's verified address, or your CRM passes it forward — set `recipientTimezone` on the call and the guard honors it verbatim. That is the only resolution path the platform cannot infer and you must; an area code says where the number was assigned, not where the subscriber now lives. Common resolutions, in order of how often each is the answer: * **Toll-free or non-geographic +1** (800, 888, N11 codes). These carry no geographic signal and are deliberately unmapped — the dial returns `timezone_unresolved` until you pass `recipientTimezone`. * **New or overlay US area codes.** When NANPA assigns a fresh NPA, the platform's area-code inventory resolves it within a release cycle, but until then the area code is unmapped and the dial fails closed. Same fix — pass the hint. * **Canadian recipients.** Canada is in the +1 inventory but it is not a US jurisdiction; the country resolves and the state reads `null`. The federal window does not apply — the guard allows immediately. * **Non-NANP (+44, +33, …).** The guard skips the US federal wire entirely (`non_us_recipient`), and tenant quiet-hours or state overlays may still apply downstream. The lookup failure is not on the federal rail; it is on whatever tenant policy layer follows. If the hint is not available and the recipient and you are both in coverage, the failure is an **inventory update** — the code is new and mapping lands with the next cycle — not a posture the guard needs from you. Field-specific support for a missing inventory entry is the platform's own ticket, not yours. ## 3. What runs BEFORE the guard? The dispatcher stamps metadata before the guard ever reads it, and the order matters: every voice dispatch assigns the class the classifier names and the lane the guard recovers, in this fixed sequence, at the dispatch-entry point (the API `POST /voice/calls/place` route or the voice-gateway `/api/v1/outbound-call` handler, whichever ingress your caller reaches): 1. **Ingress metadata bag assembled.** Your request body and any server-side dispatch hints (e.g. an `agent_id` the route folds into the bag) compose the metadata the classifier and resolver read. 2. **Voice-content class stamped.** The classifier resolves the `voice_content_type` from the metadata in precedence order: explicit `voice_content_type` (verbatim) → `voice_cloned_model_id` → `voice_agent_id` (campaigns canonical key) → `agent_id` (fallback) → `tts_text` / `tts_body` → `message_body` → otherwise `human`. The class is stamped on the audit row and forwarded downstream with the verdict. 3. **Lane resolved.** The traffic-lane resolver sees the same metadata and the classifier's voice-content class as its `artificialVoice` signal. The verdict chain above (step 1–5) returns `marketing` or `transactional`. 4. **Voice-compliance gates, then the federal window.** The lane and class settle first, and then the voice-compliance gates run in sequence: DNC-suppression, STOP-suppression, FCC 24-17 written- consent gate, **then** the federal TCPA window check on `marketing` traffic only. A blocked call never loops back to the window math; each gate is short-circuited and returns its own reason. The read-yourverdict consequence: a dial recorded as `human` + `transactional` skips the federal window entirely; the same metadata bag carrying a TTS payload resolves `synthetic` and the window is checked. The class is stamped *before* the window check runs — the guard does not infer speech type mid-gate. ## 4. Where do I read the decision ledger? Every voice dispatch evaluation — allowed or blocked — lands in your tenant's audit chain with the same shape: resolved lane, resolved local hour, the `reason` the gate returned, and the resolved `voice_content_type`. Read it back with the [audit export](/compliance/audit-export) route (filter on `event_type = 'voice_dial_guard_decision'`) or the dashboard compliance ledger (Compliance → Audit ledger, the `voice` scope). Blocks report with the recipient number masked. Roll those events up over a reporting window and you get a posture history — the SOC 2 evidence-binder convention described on [Audit ledger posture rollup](/compliance/audit-ledger-posture-rollup) — with `federal-only`, `federal+state`, and `federal+state+tenant` bands set per period so a reviewer can attest what gate was active when. Only the lane and posture bands appear there; the full `reason` enum a blocked call returned is on the runbook and the federal window check. ## See also * [Voice guard](/compliance/voice-guard) — the federal gate's wire-up and decision chain. * [TCPA window blocked calls](/troubleshooting/tcpa-window-blocked-calls) — post-block recovery runbook. * [Quiet hours FAQ](/compliance/quiet-hours-faq) — the org gate, campaign fallback, and preview layering. * [Number timezone and state resolution](/compliance/number-timezone-resolution) — the lookup chain section 2 derives. * [Compliance posture FAQ](/compliance/posture-faq) — the broader operator index. * [Message priority traffic lanes](/concepts/message-priority-traffic-lanes) — the messaging-side lane override.