VoIP.infoThe independent guide to business communications.
VoIP.info Provider research

Exotel Dynamic SIP Trunking: object model, call directions and evidence boundaries

Map Exotel product, REST management, trunk, number mode, flow, destination, authorization, signaling, media and rate-limit evidence without treating one state as proof of another.

Reviewed 2026-10-23Current Exotel SIP Trunking developer and docs portals were reviewed October 23, 2026. Account, KYC, region, trunk, number, flow, destination, network, entitlement and commercial state remain deployment specific. No Exotel account, API credential, SIP credential, trunk, Exophone, mapping, flow, applet, destination, address, DNS answer, PBX, SBC, firewall, packet, Call SID, call, media stream, capacity, price, availability, compatibility or support response was inspected or testedAdvancedDocumentation based · not lab tested

Separate the SIP product from its REST management API

Exotel describes SIP Trunking as the product connecting a PBX, SBC or SIP platform to the PSTN, and Dynamic SIP Trunking as the REST API used to create and manage trunk objects. The management API uses regional HTTPS base URLs and HTTP Basic authentication with an API key and token. Those credentials and its documented 200-requests-per-minute control are not SIP credentials, a trunk call-start limit or active-call capacity.

Preserve account SID, API region, trunk SID, status, assigned number, mapping, flow, destination and SIP authentication as different records. A successful API response proves only that request. It does not prove number entitlement, inbound routing, outbound authorization, PBX reachability, media or an answered call.

Documented service facts

Reviewed 2026-10-23. Compare SIP trunk services →

Authentication

Documented

Outbound SIP authorization uses an allowed source address and/or digest credentials. The REST management API instead uses an API key and token over HTTPS. These identities, the account domain and the final SIP response remain separate evidence.

SIP registration

Documented

Current India TCP and TLS documentation says SIP registration is not supported. Digest authenticates SIP requests and does not create a REGISTER binding; an absent registration indicator is not a trunk fault.

Inbound delivery

Documented

Classic inbound delivery requires a phone number mapped in pstn mode, a published Flow whose Connect applet dials sip:<trunk_sid>, and a destination URI. Voice AI or StreamKit journeys use flow mode. Each object must be verified independently.

Inbound failover

Documented

Exotel publishes primary and secondary outbound proxy FQDNs and allows FQDN or ordered inbound destinations. Those are new-call routing inputs, not proof of health-aware recovery, retry timing, provider diversity or established-call survival.

Number and regional availability

Documented

The current India interface pages describe a Mumbai point of presence and regional Exophone setup examples. They do not establish current inventory, portability, number type, address eligibility or serviceability for every Indian region or another Exotel market. Require a dated orderability and port result for each requested number and location.

Audio codecs and DTMF

Documented

Current trunk guidance lists PCMA and PCMU, RFC 2833, and RTP or SRTP over UDP 10000–40000. Capture SDP and both media directions; configured capability does not establish negotiation, audio quality or universal interoperation.

T.38 fax

Not verified

The reviewed Dynamic SIP Trunking sources do not establish T.38, G.711 pass-through, modem support or a fax acceptance procedure. Qualify the exact number, direction, gateway, document set, ECM behavior, switchover and fallback independently rather than inferring fax support from ordinary G.711 voice.

Signaling and media encryption

Documented

TLS signaling uses port 443 and TCP uses 5070; RTP or SRTP uses UDP 10000–40000. Validate certificate, signaling and media protection separately. API keys, tokens and SIP secrets must not appear in shared traces.

Concurrent calls and burst

Documented

The India TLS guide documents a default 20 calls per minute per trunk, while the REST management API documents 200 requests per minute. These are different controls and neither establishes simultaneous-call capacity, billing or guaranteed acceptance.

Emergency calling

Not verified

The reviewed Dynamic SIP Trunking sources do not establish emergency-calling eligibility, accepted identity, registered location, callback route, nomadic-use rules or an approved test procedure. Resolve these for every site and number, maintain an independent fallback and never place an uncoordinated live emergency test.

Pricing model

Not verified

The reviewed technical documentation requires an upgraded, KYC-complete account but does not provide a complete current trunk quote. Obtain dated terms for setup, numbers, usage, call-start or concurrency changes, support, taxes, commitments, renewal and termination. Do not convert a technical rate limit or Exophone example into commercial entitlement.

Administration and support

Documented

Manage trunk, number mapping, mode, destination, allowlist and credentials as distinct objects. Correlate management request ID, Call SID or Call-ID, SIP response, PBX result and media; no support, recovery or SLA result was measured.

SMS and MMS

Not verified

Exotel publishes separate messaging APIs, but the reviewed Dynamic SIP Trunking sources do not establish SMS or MMS entitlement on an Exophone assigned to a trunk. Verify number capability, sender registration, consent controls, application or API path, throughput, retention and fees separately.

Model outbound and inbound as different call paths

The current call-direction guide documents outbound as customer SIP to Exotel to PSTN. It requires a phone number mapped to the trunk plus an allowed source address and/or digest credentials. Inbound is PSTN to Exotel Flow to SIP trunk to the customer system. It requires a destination URI and a Flow whose Connect applet dials sip:<trunk_sid>.

Record direction, number, mapping ID and mode, flow version, Connect target, destination URI, source address, digest identity and first response. A working outbound call is not evidence that the inbound Flow is published, and a reachable destination is not evidence that an outbound source or credential is authorized.

Choose `pstn` or `flow` mode from the actual journey

Exotel sets routing mode when a phone number is mapped to a trunk. The documented classic PBX and inbound Connect-app journey uses pstn, while Voice AI, StreamKit or related App Bazaar journeys use flow. The mode, selected Flow and Connect target therefore answer different routing questions.

For the Connect path, keep Exophone assignment, pstn mapping, published Flow, sip:<trunk_sid> target, required destination URI and loaded PBX route distinct. Correct the first wrong object instead of toggling both modes or inserting a broad PBX route. A 404 mapping response and a 480 unavailable destination identify different boundaries.

Keep API auth, SIP authorization and registration distinct

Outbound SIP authorization can use source-address allowlisting, digest credentials or both. The current India TCP and TLS interface documentation says SIP registration is not supported; digest authenticates an INVITE and does not create a REGISTER binding. The REST API separately uses an API key and token over HTTPS.

Preserve the public source Exotel sees, expected account domain, allowed range, digest challenge and authenticated retry. A 403 can reflect the from-domain, allowlist or credential mismatch; a 401 challenge is not by itself a terminal failure. Do not expose API tokens, SIP secrets or reusable Authorization headers in shared evidence.

Prove signaling and media on their own paths

The current India documentation assigns TLS signaling to port 443 and TCP signaling to port 5070. It documents RTP or SRTP on UDP 10000–40000 and warns that inbound source ports are dynamic. The manage-trunk guide lists PCMA and PCMU plus RFC 2833, while the troubleshooting material keeps signaling, codec, SRTP and NAT faults separate.

Retain DNS answers, certificate validation, transport, Call-ID or Call SID, SIP responses, SDP offer and answer, selected payload and both media directions. A 200 OK does not prove audio, TLS does not prove SRTP on every leg, and a silent call does not justify opening unrestricted UDP. Scope firewall rules to current first-party endpoints and authorized evidence.

Separate rate controls, regional scope and unresolved service claims

The current India TLS page documents a default 20 calls per minute per trunk and an account-review path for higher bursts. The management API separately documents 200 requests per minute. Neither number establishes concurrent-call entitlement, billing, guaranteed acceptance or media capacity. Confirm simultaneous calls, rejection behavior and current account limits independently.

The reviewed India pages identify Mumbai and current India endpoints but do not prove number inventory, portability, emergency-calling eligibility, every-country coverage, price, SLA, compatibility, fax or trunk-number messaging. Require dated account evidence for those claims. No Exotel account, API credential, SIP credential, trunk, Exophone, mapping, flow, applet, destination, network, call, media stream, capacity, price, availability, compatibility or support response was tested.

Sources & applicability

Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.

Examples require adaptation to your topology. No live PBX or hardware testing is claimed.

Continue your research

Hub · Provider records reviewed individually on their listed dates; account-specific terms and availability require direct confirmation

SIP trunk provider research

Compare the connection model, call routing, media support and cost structure of documented SIP trunk services.

Explore topic →
Troubleshooting · Current Exotel SIP Trunking developer and docs portals were reviewed October 23, 2026. Account, KYC, region, trunk, number, flow, destination, network, entitlement and commercial state remain deployment specific. No Exotel account, API credential, SIP credential, trunk, Exophone, mapping, flow, applet, destination, address, DNS answer, PBX, SBC, firewall, packet, Call SID, call, media stream, capacity, price, availability, compatibility or support response was inspected or tested

Exotel trunk is active but inbound, outbound or audio fails

Trace one failed Exotel transaction through direction, trunk state, number mode, Flow, destination, source or digest authorization, signaling and media.

Read guide →
Guide

SIP trunking: numbers, capacity and operational control

Plan the carrier relationship that connects a self-managed PBX to outside calling.

Read guide →
Guide

SIP trunk IP authentication

Understand source-address trust and the consequences of a WAN address change.

Read guide →
Protocol reference

SIP authentication: challenges and modern digest support

Understand the difference between a normal challenge, failed credentials and an unsupported algorithm.

Read guide →
Reference · SIP standards; extension support depends on both peers

SIP DNS discovery: NAPTR, SRV and address records

Understand service selection and failover before hard-coding a SIP server IP address.

Read guide →
Guide

SIP trunk failover and redundant calling paths

Design alternate routing without assuming active calls will survive.

Read guide →
Protocol reference · RFC 3261 SIP, RFC 3711 SRTP, RFC 4568 SDP Security Descriptions, RFCs 5763 and 5764 DTLS-SRTP, and current Asterisk PJSIP documentation reviewed October 6, 2026; deployed endpoints, intermediaries, certificates and calls require direct verification

SIP TLS and SRTP: what each protects

Distinguish adjacent-hop signaling protection, SRTP media protection, SDES and DTLS-SRTP keying, and the actual termination points on every call leg.

Read guide →
Guide · Current Asterisk PJSIP object, outbound-registration, configuration-example and res_pjsip references reviewed October 1, 2026; no account, carrier, PBX, endpoint, registration, identifier, route, call, emergency workflow, media stream, capacity or failover path was tested

Plan and configure an Asterisk SIP trunk

Translate each carrier direction into explicit PJSIP objects, identification, restricted dialplan, retry policy and leg-by-leg acceptance evidence.

Read guide →
Guide · FreePBX 17 and current Asterisk res_pjsip documentation reviewed October 5, 2026; Sangoma's generic module pages are responsibility guides rather than an exact installed field map; no FreePBX host, module, account, credential, trunk, route, registration, number, identity, call, media path, failover, capacity, emergency workflow or compatibility was tested

Configure and verify a FreePBX 17 PJSIP trunk

Translate current carrier requirements into FreePBX-owned PJSIP trunk, route and identity controls, then verify the generated Asterisk objects and each call direction independently.

Read guide →
Guide

Firewall rules for VoIP

Define management, signaling and media access separately using actual deployment requirements.

Read guide →
Guide · Wireshark 4.x / current upstream tool documentation; inspect installed versions

VoIP packet-capture methodology

Select interfaces, time windows and paired capture points that distinguish network loss from missing evidence.

Read guide →
Troubleshooting · First-party Asterisk documentation and SIP standard reviewed September 30, 2026; FreePBX 17 terminology retained; no PBX, provider, number, route or live call test

Inbound VoIP calls do not reach the business

Trace carrier delivery, Asterisk endpoint identification, DID matching and the final destination without collapsing the boundaries.

Read guide →
Hub

VoIP troubleshooting

Use symptoms and evidence to isolate registration, routing, media and device faults.

Explore topic →