Freeze one direction and one failed transaction
Record local and UTC time, inbound or outbound direction, region, account SID, trunk SID and status, mapped number, mapping mode, Flow version, Connect target, destination URI, transport, redacted digest identity, translated source address, Call-ID or Call SID, first response, SDP summary, loaded PBX route and media symptoms.
Classify the earliest divergence: inactive or wrong trunk; missing number mapping; wrong pstn or flow mode; unpublished or wrong Flow; wrong Connect target; absent destination; wrong account domain; source or digest failure; edge reachability; PBX route rejection; SDP mismatch; or signaling success without media.
Prove the product and API objects before reading SIP traces
Use the regional management endpoint to read the intended trunk, number mapping and destination without publishing credentials. Confirm that the returned account, trunk SID, status, phone number and mode are the objects expected by the deployment. Keep the API response and its request ID as management evidence only.
Do not interpret the API rate limit, HTTP success or saved object as a SIP call result. If the trunk, number or mode is wrong, correct that narrow object and preserve the before-and-after response before changing the PBX.
Trace the inbound Flow and destination in order
For the classic inbound path, confirm the number uses pstn, the intended published Flow is assigned, Connect dials exactly sip:<trunk_sid>, and the trunk has the intended destination URI. Then compare Exotel signaling with the current DNS answers, firewall receipt and loaded PBX route.
If no INVITE arrives, distinguish wrong Flow or destination from blocked signaling. A 408 points to reachability or the return path, while a received INVITE followed by PBX rejection belongs to the PBX identity, domain or dialplan boundary. Do not add a catch-all route before proving the delivered Request-URI.
Trace outbound domain, source and digest as separate checks
Confirm the PBX sends to the current Exotel proxy using the trunk domain <account_sid>.pstn.exotel.com, the selected TLS or TCP port, and a number mapped to the trunk. Compare the public source Exotel sees with the allowlist and, when digest is configured, preserve the initial challenge, redacted username, authenticated retry and final response.
Do not configure SIP REGISTER as a recovery step. A 403 can identify the wrong from-domain, an unlisted source or a credential mismatch, so change one proven owner at a time. A completed challenge still does not prove number mapping, destination permission or PSTN acceptance.
Follow signaling success into SDP and both media directions
When the dialog connects but audio is silent or one-way, compare the SDP offer and answer, PCMA or PCMU selection, RFC 2833 expectation, SRTP alignment, advertised addresses and actual packets in both directions. Check the documented UDP 10000–40000 media path separately from TLS 443 or TCP 5070 signaling.
Preserve NAT translation and session-timer evidence for calls dropping near 30 seconds. Do not disable certificate validation, broaden media access to every source or turn off protection globally. Correct the narrow transport, address, codec, SRTP or NAT boundary demonstrated by the trace.
Correct one boundary and correlate a bounded retest
Change only the demonstrated trunk object, number mapping, mode, Flow, Connect target, destination URI, domain, source allowlist, digest credential, transport, firewall rule, PBX route, SDP or NAT setting. Repeat one authorized non-emergency transaction and correlate API request ID, Call-ID or Call SID, SIP responses, edge receipt, PBX decision, answer and both media directions.
Do not describe the result as proof of emergency activation, failover under other faults, account capacity, price, availability, compatibility or support performance. No Exotel account, credential, trunk, Exophone, mapping, Flow, destination, packet, call or media stream was inspected or tested.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Exotel SIP Trunking overview ↗
- Exotel SIP Trunking quickstart ↗
- Exotel call directions and routing modes ↗
- Exotel Dynamic SIP Trunking API ↗
- Exotel developer network and firewall guidance ↗
- Exotel SIP errors and troubleshooting ↗
- Exotel Connect Applet setup for inbound SIP ↗
- Exotel Dynamic SIP Trunking overview ↗
- Exotel SIP Trunking TCP India ↗
- Exotel SIP Trunking TLS India ↗
- Exotel Network and Firewall Configuration ↗
- Exotel view and manage a trunk ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.