Documentation Index
Fetch the complete documentation index at: https://orbit-docs.devotel.io/llms.txt
Use this file to discover all available pages before exploring further.
AI Voice Agents via sip_forward
You can point an Orbit DID at any third-party AI voice platform that
exposes a SIP endpoint — callers.ai, Retell, Vapi, and most other
agent providers do. Orbit handles the carrier termination, billing,
and recording; the AI provider runs the conversation logic.
This guide walks through wiring up an inbound sip_forward route end
to end. The same shape works for self-hosted PBX targets — see the
SIP trunk reference for the trunk-mode alternative.
How it works
- Orbit owns the DID and accepts the inbound INVITE from the carrier.
- Orbit’s SBC (Jambonz) re-INVITEs the call to the AI provider’s SIP URI on your behalf, terminating TLS at our edge.
- RTP media is bridged through RTPengine — the AI provider never sees the carrier directly, and the carrier never sees the AI provider.
- Hangup, DTMF, and recording are surfaced over the same Orbit webhook contract regardless of which AI vendor terminates the call.
Step 1 — Buy a number
Pick a number for the agent. Toll-free numbers tend to work better for contact-center scenarios because A2P 10-DLC restrictions don’t apply to inbound voice.number_id you’ll use in the next step.
Step 2 — Configure inbound routing → sip_forward
sipUsername / sipPassword if the AI provider doesn’t
require digest auth on the inbound INVITE — most do not.
Provider URI examples
Each AI provider publishes a slightly different SIP URI shape. Use the example for your vendor verbatim — only the token / agent ID changes.callers.ai
<token> is the agent token from your callers.ai dashboard
(Settings → Phone → SIP).
Retell
<retell-sip-host> is the host published in your Retell dashboard
under “Phone Numbers → BYO SIP” — it’s region-specific
(5t4n6j0wnrl.sip.livekit.cloud is one current example, but check
your dashboard).
Vapi
<assistant_id> is the assistant’s ID from the Vapi dashboard
(Assistants → ID → Copy). Vapi’s SIP endpoint accepts unauthenticated
INVITEs by default; configure an inbound credential under “SIP
Trunks” if your security posture requires digest auth.
DTMF
Orbit forwards DTMF events to the AI provider as RFC 4733 in-band RTP. All three providers above support this out of the box — no extra configuration needed. SIP INFO DTMF is not forwarded; if your agent only supports SIP INFO, contact support and we’ll enable the DTMF translator on your account.Audio codec compatibility
Orbit’s SBC re-negotiates codecs on the way out, so the AI provider sees only the codec it’s comfortable with even if the carrier offered something exotic.| Codec | Orbit ↔ Carrier | Orbit ↔ AI Provider | Notes |
|---|---|---|---|
| G.711 µ-law | ✅ | ✅ | Default for US carriers, all AI providers |
| G.711 A-law | ✅ | ✅ | EU carriers; transcoded only when AI requires µ-law |
| Opus | ✅ | ✅ (Vapi, Retell) | Lowest latency; not all carriers offer it |
| G.729 | ✅ | ❌ | Transcoded to G.711 — adds ~10ms latency |
Troubleshooting
Signature 401 on inbound INVITE
The AI provider’s SIP gateway rejected your INVITE with a401 Unauthorized and you don’t see the call in your provider dashboard.
The two common causes:
- Wrong token / agent_id. Re-copy from the provider dashboard; tokens are case-sensitive.
- Trunk auth required. Some providers (Retell on production
tier, Vapi if “Allow only authorized SIP origins” is on) need
digest auth. Set
sipUsernameandsipPasswordon the route config to credentials issued by the provider — Orbit stores them encrypted at rest.
Audio one-way
You can hear the caller, but the caller can’t hear the agent (or vice versa). This is almost always a codec mismatch on the AI provider side — the AI is sending Opus but Orbit re-INVITEd as G.711. Open a ticket with the provider and ask them to advertise G.711 µ-law in their SDP answer; Orbit will negotiate down to whatever both ends agree on.Calls drop at exactly 32 seconds
Classic NAT keep-alive timeout: the carrier or RTPengine isn’t seeing media in one direction, so the SBC tears the call down at the 32s default. The fix lives on the AI provider’s side — they need to send RTP keep-alives during periods of silence (e.g. while waiting on the LLM). All three providers above support this; check their “send RTP during silence” setting. If the drop happens earlier (< 5s), it’s usually the carrier rejecting the re-INVITE — open a support ticket with your call SID and we’ll pull the SBC trace.See also
- SIP Trunks — the trunk-mode
alternative to inline
sip_forward. Use this when one trunk fans out to many DIDs. - Inbound routing — full reference for the
five route types (
webhook,agent,flow,sip_forward,voicemail). - Webhooks — receive
call.initiated,call.answered, andcall.completedevents for calls forwarded to an AI agent.