Freeze one number, route and failed attempt
Record UTC and local time, called and calling identities, exact DID, account, static or dynamic service model, assigned proxy, public address or current Contact, Number Routing selection, Request-URI translation, disaster-recovery targets and the destination that actually rang. Preserve the provider ticket or call identifier, customer-edge capture, SIP Call-ID and PBX logs.
Classify the symptom narrowly: wrong static address or registered Contact; unexpected provider proxy; wrong translated Request-URI user; correct edge followed by PBX rejection or route mismatch; or an alternate recovery destination. Do not combine signaling, routing and media into one assumed failure.
Prove the active static or registered target
For static service, compare the assigned public destination with the address that received the INVITE; do not require REGISTER merely because an outbound call authenticated. For dynamic service, retain the current successful REGISTER, Contact, expiry and provider-facing address, then compare that Contact with the actual inbound destination.
A portal Active state or successful outbound request does not prove the inbound target. If neither expected edge receives the INVITE, keep the PBX unchanged and resolve the account route, registration or provider-attempt evidence first.
Compare number routing with the delivered Request-URI
Export or record the affected number's term type, selected IP or registration destination and Request-URI translation. Compare those values with the customer-edge INVITE, including Request-URI user and host, To, Diversion or History-Info when present, source address and first response.
If the correct edge received the request, follow the translated user through PJSIP identification, endpoint or trunk match, context and the first loaded Asterisk or FreePBX inbound route. Correct the narrow identity or route mismatch; do not broadly trust arbitrary sources or accept every called number.
Identify which recovery layer selected the destination
Provider proxy redundancy and per-number Disaster-Recovery Routing are separate controls. Preserve DNS answers or proxy selection on the provider layer, then record each number-level alternate target and order. For the failed attempt, retain the response code or absence of response, timestamps and whether the next destination was a telephone number or IP endpoint.
A call answered at an alternate telephone number does not prove the SIP trunk or PBX recovered. The public guide does not supply one universal timer, response-code matrix or established-call guarantee, so describe only the observed new-call transition.
Do not use an SLA as packet or route proof
The base SIP SLA excludes customer and third-party systems, incorrect IP-PBX or CPE routing, reconfigured lines and backup or alternate routes from availability calculations. A ticket, availability percentage, response target or credit decision therefore does not establish Number Routing, Request-URI translation, customer-edge receipt or PBX acceptance for this call.
Keep the signed service schedule, affected SIP port, ticket-open time, provider determination and remedy separate from packet and PBX evidence. Do not apply SIP HyperNetwork terms to base SIP service unless the account documentation identifies that product.
Restore one path and run bounded checks
After one authorized correction, place bounded calls to the intended primary path and approved alternate targets. Confirm the number route, selected service model, provider proxy, delivered Request-URI, customer-edge receipt, PBX match, final route, answer, SDP and both RTP directions independently. Retain rollback and restoration timestamps.
Validate emergency identity and address only under the current approved 933 procedure; ordinary inbound success and a disaster-recovery answer do not verify emergency routing. No account, trunk, number, registration, packet, PBX, recovery event, SLA event, emergency call or live media path 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.
- BCM One SIP Trunking and Implementation Guide, September 2024 ↗
- BCM One customer portals ↗
- BCM One legal and service documents ↗
- BCM One SIP Service Level Agreement ↗
- BCM One SIP Service E-911 and Service Addendum ↗
- BCM One SIP HyperNetwork Service Level Agreement ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.