Select the exact Dynamic SIP Trunking object first
Exotel's current quickstart uses the Dynamic SIP Trunking APIs to create a trunk under an Account SID, assign an account-domain name and map at least one Exophone. The India examples also require a KYC-complete account and distinguish their Mumbai interface from other regions and products. Preserve the exact account, API region, trunk SID, domain, selected transport, ordered number and current interface page before configuring a PBX.
A documented API object is not proof that the account is entitled, the Exophone is orderable, the route is active or the PBX is compatible. Keep KYC, account upgrade, trunk creation, number mapping, network reachability, request authentication, accepted identity and an answered call as separate evidence states. Do not use Alpha support pages or a generic Exotel product description to override the current trunk object and docs portal.
Documented service facts
Reviewed 2026-09-30. Compare SIP trunk services →
Authentication
DocumentedExotel's current Dynamic SIP Trunking quickstart supports source-address allowlisting, digest credentials or both, selected for the platform's egress model. A permitted address and a completed digest challenge are separate evidence states. Keep API credentials, SIP credentials and reusable authorization material out of shared captures, and confirm the exact trunk object rather than copying an Alpha or historical setup.
SIP registration
DocumentedThe current India TCP and TLS interface pages say SIP registration-based authentication is not supported. Digest credentials authenticate requests; they do not create a REGISTER binding. Do not diagnose an absent registration indicator as a trunk failure or transfer a phone-registration template into this service.
Inbound delivery
DocumentedFor the documented Connect applet path, an Exophone is mapped to a flow whose Connect applet dials sip:<trunk_sid>; the trunk then uses its destination URI, and the phone-number mode is pstn. Exophone assignment, mode, flow publication, destination reachability, delivered identity and an answered call remain separate states.
Inbound failover
DocumentedExotel documents an FQDN destination that is resolved for each call attempt and can represent changing or multiple A or AAAA addresses. That is a destination-resolution capability, not proof of health-aware ordering, qualifying SIP responses, recovery timing, provider-PoP diversity or established-call survival. Validate the selected destination behavior with bounded new-call tests.
Number and regional availability
DocumentedThe 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
DocumentedExotel's troubleshooting material identifies G.711 and SDP incompatibility as causes of 415 or 488 responses, while the current network guidance requires UDP 10000-40000 for media. That does not establish a complete codec list, packetization, DTMF method or measured audio quality. Retain the actual offer, answer, selected payload and media endpoints from authorized calls.
T.38 fax
Not verifiedThe 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
DocumentedThe current India guides distinguish TLS on port 443 with SRTP media from unencrypted TCP signaling on port 5070 with RTP. TLS is preferred in the developer guide, but a configured option is not proof that every leg negotiated protection or that certificate validation was correct. Verify signaling and media separately without weakening validation.
Concurrent calls and burst
DocumentedThe current docs portal states a default limit of 20 calls per minute per trunk and says higher bursts require review. That is a call-start rate, not simultaneous-call capacity, bandwidth, billing or a guaranteed acceptance result. Older support material can show different historical values; the current docs and account entitlement take precedence. Confirm concurrency and rejection behavior separately.
Emergency calling
Not verifiedThe 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 verifiedThe 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
DocumentedExotel exposes API-managed trunk, phone-number, allowlist, credential and destination objects. Its troubleshooting guide maps 401 to credentials, 403 to source authorization, 404 to number mapping, 415 or 488 to media or SDP and 480 to destination availability, and asks for Account SID, transport, Call SIDs and traces. Preserve redacted object state, timestamps and rollback; no SLA or support response was tested.
SMS and MMS
Not verifiedExotel 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.
Separate allowlisting and digest from registration
The developer quickstart supports a static egress address in the trunk's allowlist and optional digest credentials for a dynamic or cloud platform; it describes authentication as IP ACL, digest or both. Current India TCP and TLS pages also say SIP registration-based authentication is not supported. Digest authenticates a SIP request and does not create a REGISTER binding.
Record which control the actual trunk enforces, the exact public egress addresses, credential owner, secret-rotation path and expected challenge. A 401 can indicate missing or invalid credentials and a 403 can indicate an address-authorization failure, but neither response proves the other layer. Do not expose API keys, API tokens, SIP secrets or reusable Authorization headers in shared traces.
Build the inbound path as explicit objects
For the documented Connect applet path, map the Exophone to the trunk with phone-number mode pstn, create and publish an App Bazaar flow, configure Connect to dial sip:<trunk_sid> and give the trunk a destination URI. Exotel depicts the resulting path as PSTN to Exophone to Flow to SIP trunk to destination URI to the customer SIP system. A voicebot or another applet can use flow mode, but the destination URI remains required.
Retain the Exophone assignment, mapping ID, mode, flow version, Connect target, destination URI and PBX route separately. A successful API response or published flow does not prove that Exotel reached the destination, that the PBX accepted the delivered identity or that media flowed. Treat a 404 number-mapping response and a 480 destination-availability response as different faults.
Verify signaling, media and protection independently
The current documentation offers TLS on port 443 and TCP on port 5070, and recommends TLS for production. The India TLS guide pairs TLS with SRTP; the TCP guide uses unencrypted signaling with RTP. Network guidance keeps signaling source addresses and media pools separate and identifies UDP 10000-40000 for media. Exotel's troubleshooting page references G.711 and SDP incompatibility for 415 or 488 responses.
Record DNS, certificate chain and name validation, negotiated transport, SIP endpoints, SDP offer and answer, selected payload and media endpoints on each authorized test. A TLS socket does not prove SRTP on every leg, and a 200 response does not prove two-way audio. The reviewed sources do not establish a complete codec list, DTMF method, packetization, T.38 or fax acceptance; qualify those separately.
Keep FQDN routing and call-start capacity distinct
Exotel accepts an inbound destination as an address or FQDN. Its FQDN guidance describes resolution for each call attempt and multiple A or AAAA results, which can support a changing or highly available customer destination. That does not establish health-aware ordering, qualifying SIP responses, retry timing, recovery behavior, provider-PoP diversity or survival of an established call. Exercise only bounded new-call tests and preserve DNS answers and timestamps.
The current docs portal states a default 20 calls per minute per trunk and directs higher-burst requests to account review. That is a call-start rate, not concurrent-call entitlement, media bandwidth, billing or guaranteed acceptance. Older support content can show different historical values, so the current docs and account state win. Confirm simultaneous calls, burst window, rejection response and upgrade process independently.
Close regional, emergency and commercial gaps before cutover
The current India pages establish a Mumbai interface and give regional Exophone examples, but they do not prove nationwide number inventory, portability, address eligibility or another country's service. Require a dated serviceability and port result for every number and location. The reviewed trunk sources also do not establish emergency-calling eligibility, accepted identity, registered location, callback route, nomadic rules or an approved test procedure. Maintain an independent fallback and never make an uncoordinated live emergency test.
Obtain current terms for setup, Exophones, usage, capacity changes, support, taxes, commitments, renewal and termination. Separate Exotel messaging APIs do not establish SMS or MMS entitlement on trunk-assigned numbers. Preserve redacted API state, Call SIDs, transport, traces, timestamps and rollback for support, but do not infer an SLA. No account, KYC result, order, PBX, SBC, trunk, credential, address, Exophone, flow, destination, DNS result, route, call, media, capacity, emergency call, message, price, availability, API operation or support response was tested for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Exotel SIP Trunking quickstart ↗
- Exotel network and firewall guidance ↗
- Exotel SIP errors and troubleshooting ↗
- Exotel SIP Trunking FAQs ↗
- Exotel Dynamic SIP Trunking overview ↗
- Exotel SIP Trunking TCP India ↗
- Exotel SIP Trunking TLS India ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.