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.

Apply Wavix registration evidence only to the selected model

The Wavix provider record distinguishes the digest registration path from approved IP Authentication.

Do not expect registration from Crazytel IP authentication

The Crazytel SIP trunk diagnostic branches on the selected mode before interpreting Live Registrations or source-IP evidence.

Treat MaxoTel as account-based registration in the reviewed path

The MaxoTel SIP trunk diagnostic follows portal-issued registration evidence rather than inventing direct-IP authentication.

Determine the Aussie Broadband authentication model first

The Aussie Broadband SIP trunk diagnostic leaves registration and source-address trust unassigned until the selected handoff proves one.

Determine the Symbio authentication model first

The Symbio Enterprise SIP trunk diagnostic leaves registration and source trust unassigned until the selected handoff proves one.

Use the selected Telstra identity model

The Telstra SIP Connect diagnostic leaves registration, source trust and credentials unassigned until the order and design prove them.

Use the selected Optus identity model

The Optus Evolve Voice diagnostic leaves REGISTER, source trust and credentials unassigned until OM.37683 and the application prove them.

Use the selected One NZ identity model

The One NZ SIP diagnostic leaves REGISTER, source trust and credentials unassigned until the implementation specification proves them.

Use the ordered 2degrees identity model

The 2degrees SIP diagnostic leaves REGISTER, source trust and credentials unassigned until the implementation pack proves them.

Use the ordered Vocus identity model

The Vocus SIP Voice diagnostic leaves registration, source trust and credentials unassigned until implementation evidence proves them.

Use the ordered Superloop identity model

The Superloop diagnostic leaves registration, source trust and credentials unresolved until issued evidence establishes them.

Use the ordered Enreach identity model

The Enreach diagnostic leaves registration and source trust unassigned until current evidence proves them.

Do not infer the MetTel authentication model

The MetTel SIP trunk diagnostic requires the selected order and provider values because public product records do not define one universal model.

Do not infer the NUSO authentication model

The NUSO diagnostic requires the accepted handoff because public records do not define one universal model.

Choose the exact Telesystem handoff before editing auth

The Telesystem diagnostic distinguishes registration, ESBC and direct peering.

Confirm the TPx handoff before editing authentication

The TPx diagnostic requires account-specific implementation evidence before choosing registration or IP identification.

Confirm the Lingo handoff before editing authentication

The Lingo diagnostic requires account-specific evidence before choosing registration or address identification.

Confirm the Voyant handoff before editing authentication

The Voyant diagnostic requires account-specific evidence before choosing registration or address identification.

Confirm the Windstream handoff before editing identity

The Windstream diagnostic requires account-specific evidence before choosing registration, address identification or managed edge.

Confirm the Granite handoff before editing identity

The Granite diagnostic requires order-specific evidence before choosing registration, address identification or managed edge.

Confirm the FirstLight handoff before editing identity

The FirstLight diagnostic requires order-specific evidence before choosing registration, address identification or another trust model.