> ## 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 resolution at the federal dial gate

> How the outbound-voice lane resolver decides whether a call is transactional or marketing before the one platform-wide TCPA federal gate evaluates it — the resolution precedence, the anti-laundering ratchet, the tenant-owned self-classification control, and per-dispatcher defaults.

# Voice traffic-lane resolution at the federal dial gate

The US TCPA federal dialing window (8 AM–9 PM recipient-local) is the one
voice gate that is on for every account, with no account-level switch —
the statutory exposure behind it is not something an account setting can
waive. Before that gate looks at the recipient's local hour, Orbit decides
whether the gate even applies to this call. That decision is the
**traffic-lane resolution**, and it is the difference between "when is my
call a marketing call" being a policy you read once and being an error you
trip.

The resolver assigns every outbound voice call one of two lanes:

| Lane | What it covers | Federal window |
| - | - | - |
| **transactional** | A call the recipient's own activity prompted — a returned call, an account or delivery notification, a live agent dialling one number by hand from a softphone or the dashboard dialler | Not evaluated — the statute restricts telephone *solicitations* (47 U.S.C. § 227(b)(1)(B), 47 C.F.R. § 64.1200(c)(1)), so this traffic dials 24/7 |
| **marketing** | Campaign, journey, dialer and broadcast calls, plus anything carried by an artificial or prerecorded voice (AI voice agent, text-to-speech) | Fully governed — outside 8 AM–9 PM recipient-local the dial is refused with `TCPA_FEDERAL_DIALING_WINDOW_BLOCKED` |

Every voice dispatch point resolves a lane **before** it checks the window:
the voice-gateway outbound-call route, the webhook-worker's dial-pacer and
callback schedulers, and the API-side gate all run the same resolution.
Because the resolution happens upstream, the gate itself is deliberately
conservative about a missing lane: if a dispatch path resolves nothing and
says nothing, the gate treats the call as marketing. An exemption from the
federal window exists only when a dispatch path actively resolved and
carried it — silence is never an exemption.

## Resolution precedence

The resolver reads the call metadata your dispatch path forwarded and
applies these rules in order — the first one that matches settles the lane:

1. **The dispatcher itself signals an artificial voice** → **marketing**.
   A dial route that is about to synthesise speech (its own TTS-payload
   extractor found a payload) says so directly rather than hoping a key
   spelling is recognised.
2. **`metadata.traffic_lane: "marketing"` set by you** → **marketing**.
   Your own self-classification, honoured in the more-restrictive
   direction (see below).
3. **Campaign attribution** — any of `campaign_id`, `journey_campaign_id`,
   `dialer_campaign_id`, `broadcast_id`, or `flow_execution_id` present in
   metadata → **marketing**.
4. **Unattended origination** — `amd_requested` (you asked for
   answering-machine detection) or a per-lead `dynamic_variables`
   substitution map → **marketing**. Both mean nobody is waiting on your
   end of the answered call.
5. **Artificial or prerecorded voice in metadata** — `voice_agent_id`,
   `agent_id`, `tts_text`, `tts_body`, `message_body`,
   `voice_cloned_model_id`, or an explicit `voice_content_type` of
   `"synthetic"` or `"cloned"` → **marketing**. The statute names
   "artificial or prerecorded voice" directly, so it stays governed even
   with no campaign attached.
6. **None of the above** → **transactional**. A direct API dial or a
   softphone call with no campaign attribution: one number, one operator,
   on purpose.

## The anti-laundering rule: you can move a call onto the marketing lane, never off it

Only the `"marketing"` value of `metadata.traffic_lane` is honoured. An
explicit `metadata.traffic_lane: "transactional"` is **ignored** — the
resolver falls through to rules 3–6 anyway. Call metadata is
caller-supplied and unauthenticated: it travels from your request body
into the gateway untouched. If a transactional claim typed into that blob
were accepted, any SDK consumer, campaign-config blob, or webhook handler
could sidestep a federal statutory gate by typing one string — the same
bypass class as the `skip_tcpa` flag the voice path removed.

This is the compliance version of a one-way ratchet: your request can make
a call **more** governed, never less. The practical consequence is worth
stating plainly, because re-rerouting a campaign through the direct-dial
path is the failure shape here: stripping campaign attribution does not
make a call transactional. If any of rules 1–5 still apply — an AI voice,
a TTS payload, AMD requested, a flow origin — the call is marketing-lane
with or without a `campaign_id`, and the attribution you deleted only
removes your audit trail, not the gate.

If a dispatch path genuinely is transactional, the assertion has to arrive
on a typed, server-side field set after authenticated resolution — not a
metadata key.

## Tenant-owned self-classification

`metadata.traffic_lane: "marketing"` is a **tenant-owned control**, in the
same sense as the rest of your compliance configuration: you opt into more
governance, the platform never opts you into less. Set it when you know
traffic that would otherwise resolve transactional should walk the federal
window — the canonical case is a dial-your-own-list workflow you run
through a direct API integration, where you treat the calls as outreach
and want them governed exactly as your campaign traffic is.

```json theme={null}
{
  "to": "+14155552671",
  "from": "+14155551234",
  "metadata": {
    "traffic_lane": "marketing"
  }
}
```

Setting the flag never removes any other gate. Do-not-call lists,
suppression lists, cross-channel STOP, and your own voice quiet-hours
window (when you have enabled one) are evaluated on **every** call
regardless of lane. The lane decides only whether the federal dialing
window is asked at all.

## Per-dispatcher lane defaults

| Dispatcher | Surface | Lane behavior |
| - | - | - |
| Voice-gateway outbound call | `POST /api/v1/outbound-call` | **Resolves** the lane from the request (metadata, `agent_id`, `amd`, `dynamic_variables`, TTS payload) and passes it to the gate. A plain direct dial with no signals lands transactional |
| Dialer pacer | webhook-worker campaign dial pacing | **Pins `"marketing"`** — this dispatcher only ever feeds predictive, progressive and preview campaign dials, so the window always governs |
| Callback dispatch | webhook-worker callback scheduling | **Does not resolve a lane** — campaign callback traffic reaches the gate through its campaign attribution (rule 3), which the gateway stamps when the call is placed |

The pattern to copy: a dispatcher whose callers are **always** campaign
traffic should pin `"marketing"` rather than rely on inference — the
pacer's callers do not reliably stamp campaign metadata, and inferring a
lane from what such a dispatcher happens to pass would be the laundering
rule arriving through the front door: a missing `campaign_id` would exempt
a campaign dial. A dispatcher with **mixed** callers (the outbound-call
route: campaign blasts, AI-voice legs and hand-dialled softphone calls
alike) resolves per call instead.

## Worked examples

**Returned call, softphone.** A customer called in and hung up; an agent
dials them back one number at a time from the dashboard. No campaign
attribution, no TTS, no AMD requested → rules 1–5 miss → **transactional
lane**. The federal window is not evaluated; the call dials at any hour.
DNC and suppression checks still apply to it.

**Campaign dial through webhook-worker.** The dialer pacer picks the next
lead for a predictive campaign and dispatches. The pacer pins the lane:
`"marketing"`. The gate resolves the recipient's timezone, finds the local
hour outside 8 AM–9 PM, and refuses with
`TCPA_FEDERAL_DIALING_WINDOW_BLOCKED` and a `next_allowed_at` — the pacer
defers to that timestamp.

**Hand-dialled call with a TTS greeting.** An agent clicks to dial one
number from the dashboard, but the answered leg hands to a text-to-speech
payload (`tts_text` or `message_body`). "By hand" means a live voice on
your end, not a click: the TTS payload matches rule 1 (the route knows it
is about to synthesise speech) and rule 5 → **marketing lane**. The
federal window governs it even though no campaign is attached.

<Note>
  The federal gate is the one platform-level voice control with no account
  switch. Which lane a call lands on, and whether you self-classify upward
  into more governance, stays **tenant-owned** — your compliance
  configuration, your audit trail.
</Note>

## See also

* [Voice Guard: the federal dialing-window decision check](/compliance/voice-guard) — the gate the lanes feed, its inputs and error reasons
* [TCPA-window blocked calls](/troubleshooting/tcpa-window-blocked-calls) — triage when a dial is refused, including which lane it resolved to
* [US state calling windows](/compliance/state-calling-windows) — the state overlays that intersect the federal window
* [Message priority and traffic lanes](/concepts/message-priority-traffic-lanes) — the messaging counterpart, where the same two lanes shape throughput instead