Freeze one DDI, one attempt and the accepted registration
Record the customer and trunk identifiers, service order, headline number, affected DDI, port state, timestamp and timezone, PBX release and driver, issued registrar, current Contact and expiry, public source mapping, channel state, provider call-log row, first inbound packet, SIP response, matched route, destination, answer, media and caller result. Redact credentials, Authorization values, personal numbers and packet payloads.
Classify the earliest missing boundary: number not assigned, port incomplete, DDI not aliased, registration stale, no provider attempt, no packet at the PBX edge, rejected source, unidentified endpoint, unmatched number, wrong destination, no answer or media-only failure. A green registration state does not choose the inbound route.
Prove the binding that the provider is expected to use
Compare the issued account with the loaded registration, full response sequence, Contact, expiry and current public address. Confirm that the selected PBX object—not a retired phone, lab host or old NAT mapping—owns the accepted binding. Preserve any provider SMS non-registration alert as alert evidence only; the service schedule limits its frequency and it does not prove which device received a call.
If registration is current, stop changing credentials. Establish whether an INVITE was attempted toward the bound address. If the provider attempted a different target, preserve the portal and provider evidence before forcing a new registration or widening network access.
Reconstruct headline, alias and porting state
The service schedule says the standard arrangement aliases DDIs to the first headline number and sends inbound calls through the single registered account. It also says a DDI needing different rerouting must be configured as a separate headline number. Compare the selected account and number range with the portal assignment, port completion, delivered Request-URI or To identity and inbound call log.
A signed authority, scheduled port date, portal row, prepared PBX route and completed delivery are not equivalent. Correct only the first demonstrated provider-side assignment or porting mismatch; do not rewrite PBX normalization when no INVITE was sent.
Prove edge receipt and the first PBX identity and route match
Use an authorized capture and Asterisk log for the exact attempt. Record the provider source, destination transport and port, Request-URI, To and asserted identity, endpoint-identification result, response code, loaded inbound context, normalized DID, first route match and destination. Compare that evidence with the firewall and NAT state without disabling protection or trusting a broad network.
If the request reaches Asterisk, preserve the exact delivered number before adding a catch-all route. A catch-all can hide an alias, port, normalization or route-priority error and can expose unintended destinations.
Keep diversion, DNS and media outside the DDI match
Portal call diversion, NAPTR or SRV target selection and the registered Contact are different paths. Record whether diversion was active, which target the provider attempted and whether the PBX actually used DNS discovery. Do not infer that a secondary DNS target, configured mobile diversion or successful outbound call proves normal inbound DDI delivery.
If signaling reaches the intended destination but audio is absent, preserve SDP and both RTP directions as a separate media case. Do not change DDI aliases, porting state or registration to repair packets that were negotiated to an unreachable address.
Correct the earliest proven mismatch and retest safely
Correct only the demonstrated owner: number assignment, completed port, headline alias, active binding, provider target, firewall rule, endpoint identity, number normalization, inbound route or destination. Apply the change through the supported provider portal or PBX owner, preserve the previous state and repeat one authorized non-emergency inbound call.
Record provider attempt, PBX receipt, SIP result, route match, alert, answer, two-way audio and clean release separately. Remove temporary captures and broad access. Do not place an uncoordinated 999 or 112 call, assume service availability from one call or treat a portal status as compatibility proof. No account, trunk, DDI, port, PBX, packet, media stream or live call was inspected or tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- Voip Unlimited SIP Trunks ↗
- Voip Unlimited voice portfolio ↗
- Voip Unlimited partner operations and support tools ↗
- Voip Unlimited legal and regulatory documents ↗
- Voip Unlimited Master Services Agreement V3.0 ↗
- RFC 3263: Locating SIP Servers ↗
- RFC 2782: DNS SRV resource records ↗
- RFC 3403: DDDS DNS database and NAPTR records ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.