Freeze one termination attempt and its exact identities
Record the timestamp and timezone, Twilio account and Trunk SID, configured Termination SIP URI, selected edge or outbound proxy, DNS answers, PBX or SBC and version, transport, observed public source address, associated ACL and Credential Lists, dialed Request-URI, From and identity headers, SIP Call-ID, first INVITE, any 407 challenge, authenticated retry, final response, Twilio Call Log or Debugger record and caller treatment. Redact credentials, Authorization data, account identifiers and customer addresses before sharing evidence.
Classify the first divergence as no request generated, no response, initial INVITE receives 403, authenticated retry receives 403, 400 number error, caller-ID rejection, permission rejection, capacity response or later media failure. These outcomes do not share one repair.
Prove the personal Termination URI before chasing authentication
Twilio requires the Request-URI host to contain the trunk's personal Termination SIP URI so the traffic can be identified. The user part must contain the destination in E.164 format, including the plus sign. Preserve the on-wire Request-URI rather than inferring it from a PBX trunk label.
A personalized domain can identify the trunk while a generic localized domain is used as an outbound proxy or Route target for edge selection. Do not replace the personal Request-URI domain with a generic proxy name. If the Request-URI does not reference the configured Termination URI, Twilio documents that the traffic may be treated as malicious and dropped rather than answered with an authentication error.
Keep DNS and edge reachability separate from a 403
For no response, retain the DNS query and every returned target or address, selected edge, transport, outbound firewall counters and retransmission sequence. Twilio publishes several addresses per edge and recommends using the available addresses instead of pinning one IP; its best-practices page separates the personal request domain from a generic localized proxy that exposes NAPTR and SRV records.
No response is not proof of bad credentials. A request that never leaves, cannot resolve the target, uses the wrong Request-URI or is sent to only one failed address must be corrected before interpreting ACL or digest state.
Use the position of the 403 to identify the authentication boundary
Twilio says an initial digest-less INVITE receiving 403 most likely indicates that the observed source address is not accepted by the trunk ACL. Preserve the response Via received value and compare it with every address in the associated ACL. Error 32201 is the provider-specific source-address-not-in-ACL signal.
When a Credential List is attached, Twilio challenges the INVITE and the PBX or SBC must retry with a matching username and password. A 403 on the authenticated INVITE after 407 points toward the credential list or digest construction. Do not rotate credentials to fix an initial ACL rejection, or expand an ACL to hide a demonstrated credential failure.
Treat combined ACL and credential policy as cumulative
Twilio requires at least an IP ACL or Credential List for termination and documents that, when both are configured, both are enforced. The Trunk resource reports the authentication types mapped to the domain, while the CredentialList resource describes the challenge and accepted username/password membership.
Verify associations on the exact Trunk SID rather than merely finding an ACL or Credential List elsewhere in the account. A successful 407 exchange does not prove the source address is allowed, and an allowed source address does not prove the authenticated identity belongs to an attached list.
Continue through addressing, identity, policy and call outcome
After the request receives a provider response and authentication succeeds, keep later outcomes separate. Twilio documents 400 for invalid E.164 addressing; 403 can also represent invalid caller ID, a blocked number or missing international authorization; 503 can represent call-start or concurrent-call limits. Use the exact SIP response, Debugger code and Call Log row rather than treating every final rejection as an ACL error.
Correct only the first demonstrated owner, then repeat a bounded call to an authorized non-emergency destination. Verify provider acceptance, PSTN result, answer, two-way media, hangup and log correlation separately. No Twilio account, trunk, ACL, credential, address, packet, permission, capacity state, media stream or live call was inspected or tested for this diagnostic.
Do not transfer Twilio termination authentication into origination
Termination URI, ACL and credential evidence applies to calls sent toward Twilio. The origination diagnostic covers number-to-PBX delivery, priority, weight and disaster recovery.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Twilio Elastic SIP Trunking configuration ↗
- Twilio Elastic SIP Trunking troubleshooting ↗
- Twilio sending-SIP best practices ↗
- Twilio CredentialList resource ↗
- Twilio Trunk resource ↗
- Twilio error 32201: source IP address not in ACL ↗
- Twilio OriginationUrl resource ↗
- Twilio Programmable Voice failover best practices ↗
- Twilio Elastic SIP Trunking IP addresses ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.