Freeze one direction, trunk and failed transaction
Record local and UTC time, inbound or outbound direction, trunk identifier, Static Endpoint or Dynamic Registration, assigned DID, destination host or registrar, current DNS answers, Contact and expiry, translated customer source, authentication method, redacted username, Call-ID, Request-URI, From value, first response, CDR attempt and loaded PBX route.
Classify the earliest divergence: wrong direction; missing outbound access; stale Contact; wrong Request-URI; unexpected DNS or Point of Presence; source-range mismatch; digest failure; Caller ID rejection; provider attempt not reaching the edge; PBX route mismatch; or signaling success without media.
Prove the inbound routing method before editing both paths
For Static Endpoint, compare the saved user part, host, optional port, transport and current DNS resolution with the provider attempt. An empty port exercises DNS SRV; a fixed port does not. If optional inbound authorization is enabled, inspect the receiving system's challenge and DIDWW response without publishing the secret.
For Dynamic Registration, verify one current successful interval, Contact, source IP and port, transport and expiry. The seven-day history chart shows successful active intervals, not individual REGISTER transactions or failed attempts. If no valid registration exists, fix that boundary before changing DID routing.
Trace called identity from DID assignment to loaded PBX route
Confirm that the intended DID is active and assigned to the intended inbound trunk. Capture the provider Request-URI and compare the user part with the trunk's configured construction or Use DID in R-URI behavior. Then compare the delivered value with the exact loaded inbound route and final destination.
Do not add a global wildcard simply because the PBX received a different user part. Correct the narrow owner: DID assignment, trunk destination construction, number normalization or PBX route.
Read outbound source, trunk selection and digest exchange in order
Preserve the source address DIDWW actually sees and compare it with every matching allowed range. Where trunks overlap, apply the documented method and specificity priority before assuming the intended trunk was selected. For Credentials & IP-Based, retain the initial 401 challenge, realm out.didww.com, authenticated retry and final response.
A 401 challenge is not a terminal credential failure. Conversely, valid digest credentials do not override a non-matching source range, Caller ID policy or destination restriction. Correct one proven selection or authentication boundary rather than widening all ranges.
Separate Caller ID validation from downstream presentation
Compare the authenticated trunk's allowed Caller IDs and mismatch behavior with the exact From number. Preserve P-Asserted-Identity or Identity headers where present, but do not treat CNAM OUT or STIR/SHAKEN as a replacement for the calling number.
If DIDWW accepts the Caller ID yet the destination shows another value or no value, keep the provider response and downstream display as different evidence. The terminating network can modify or suppress presentation.
Correct one boundary and correlate the retest
Change only the demonstrated trunk direction, destination, port, DNS record, registration, Contact, source range, digest credential, Caller ID permission, DID assignment or PBX route. Repeat one authorized non-emergency transaction and correlate Call-ID, CDR attempt, provider response, edge receipt, loaded PBX route, answer and both media directions.
Do not represent the result as proof of emergency activation, failover under other faults, capacity, price, availability, compatibility or support performance. No DIDWW account, trunk, registration, credential, 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.
- DIDWW inbound SIP routing methods ↗
- DIDWW create an inbound SIP trunk ↗
- DIDWW inbound SIP connectivity ↗
- DIDWW SIP connectivity reference ↗
- DIDWW registration history ↗
- DIDWW inbound registration credentials ↗
- DIDWW outbound trunks ↗
- DIDWW outbound authentication and security ↗
- DIDWW outbound SIP information ↗
- DIDWW Caller ID and CNAM OUT ↗
- DIDWW service failover and load balancing ↗
- DIDWW inbound call logs ↗
- DIDWW emergency calling on outbound trunks ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.