SIPTRUNK registration or IP-authentication mode does not match the call path

Freeze one trunk, one direction and one failed attempt

Record the trunk identifier, timestamp and timezone, call direction, dialed number, calling identity, PBX and version, customer public source address and port, selected SIPTRUNK gateway, portal mode, portal status, number assignment, first SIP request and response, first PBX route and any failover result. Redact credentials, Authorization values and customer addresses before sharing evidence.

Classify the symptom before changing settings: no REGISTER leaves the PBX, REGISTER receives no response, authentication is rejected, portal shows registered but inbound fails, IP-authenticated traffic comes from the wrong address, outbound fails after mode change, or the call enters an unexpected treatment. These are different boundaries.

Prove the configured authentication mode before reading status

SIPTRUNK documents credential registration and IP authentication as mutually exclusive on one trunk. In registration mode, expect a REGISTER, a 401 credential challenge, an authenticated retry and a final result. In IP-authentication mode, the provider accepts outbound traffic only from the stored public address and delivers inbound calls only to the stored address and port.

Do not treat the absence of a registration indicator as an outage when the portal shows IP Auth. Conversely, do not assume a successful digest challenge proves the portal still assigns that trunk to registration mode. Preserve the portal setting and the PBX behavior from the same time window.

Trace DNS, gateway reachability and the first provider response

For registration, prove that the PBX generated REGISTER, resolved the intended gateway, sent it through the expected public address and received the provider response. SIPTRUNK publishes several gateway names; the selected DNS answer, route, source translation and return path must belong to the same attempt.

A 401 can be the expected challenge, while a later rejection, a 407 associated with the wrong IP-authentication address or port, silence, or an absent authenticated retry points to a different failure. Preserve headers without secrets rather than rotating credentials and firewall policy together.

Compare REGISTER Contact with the observed source address

In registration mode, SIPTRUNK displays the address and port from the Contact alongside the public source it observed. The provider says inbound delivery uses the Contact value. Compare both address-and-port pairs, the PBX external-media and external-signaling policy, firewall translation and the current access address.

A 200 registration result is not proof that the Contact is publicly reachable or that a number is assigned to the trunk. If the Contact is private, stale or translated to a different port, correct the earliest address owner and repeat a bounded registration before changing inbound routes.

Keep provider delivery separate from PBX routing

After provider mode and destination are correct, retain an authorized inbound INVITE and response. Compare the delivered Request-URI and To value with the first PBX rule, number format, trunk identification and final destination. SIPTRUNK documents an eleven-digit To form by default; a portal-visible registration does not prove the PBX route matches that value.

Also confirm that the DID is assigned to the intended trunk and plan. An outbound call does not prove inbound number assignment, and a received INVITE does not prove that an extension, queue, menu or voicemail destination accepted it.

Test failover and restoration as separate policies

SIPTRUNK documents gateway redundancy or SRV behavior separately from PSTN Backup, unconditional forwarding and voicemail treatments. Record which policy is configured, its destination, the provider-visible qualifying failure, the new-call result and the restoration step. Do not infer active-call survival, exact retry timers or customer-WAN resilience from those feature descriptions.

After the earliest mismatch is corrected, repeat registration or source-address acceptance, outbound authorization, inbound delivery, PBX routing, two-way media and each approved failover state. No SIPTRUNK account, device, route, failover event or call was tested for this diagnostic.

Do not use VoIP.ms registration as a DID-route test

Credential registration, IP authentication, DID POP and primary destination are separate evidence. Use the VoIP.ms diagnostic to trace them.