Freeze one pilot, DID and failed attempt
Record UTC and local time, account and site, redacted pilot or billing telephone number, affected DID, expected PBX destination, local E-SBC address, current registration status, actual destination that rang and any configured continuity destination. Preserve the provider ticket or report, customer-edge capture, SIP Call-ID and PBX logs.
Classify the symptom narrowly: pilot registration absent or stale; provider request never reached the E-SBC-facing PBX leg; correct request reached the PBX but the DID identity did not match; correct route selected but the application destination failed; or a provider-side continuity path selected another destination.
Prove registration without treating it as DID delivery
The older Cox PBX guides use a pilot or BTN identity and provider-issued secret for REGISTER through the local E-SBC. Preserve the exact registrar or E-SBC target, challenge, authenticated retry, final response, Contact, expiry and loaded object. Redact credentials and reusable Authorization material.
A 200 response proves only that registration transaction. It does not prove that the affected DID is assigned to the trunk, that the provider attempted the call, that the current Contact is reachable, or that the PBX will match the delivered identity.
Follow the DID from the E-SBC into the PBX
For an authorized inbound attempt, compare the provider timestamp with the customer-edge INVITE. Preserve source address, Request-URI, To, Diversion or History-Info when present, calling identity, first response and retransmissions. If the expected request never arrives, keep PBX route changes out of the first correction.
If it arrives, follow the actual called identity through PJSIP identify or trunk selection, context, normalization and the first loaded Asterisk or FreePBX inbound route. The old Avaya guide's To-header indexing is evidence for that release, not a universal rule; use the headers actually delivered to the current system.
Identify which continuity control selected the next leg
Call Forward Always, Call Forward Not Reachable, Route Exhaustion and a geo-redundant backup PBX are different controls in the older Cox guides. Provider-core SBC diversity is another layer. Preserve the current account configuration, target and order, then correlate the failed primary attempt, response or timeout and subsequent leg.
A call answered at a forwarded PSTN number does not prove that the SIP trunk, local E-SBC or primary PBX recovered. The reviewed current page does not supply a universal trigger, timer, retry-code matrix, restoration sequence or established-call guarantee, so describe only the observed new-call outcome.
Keep media, reporting and emergency evidence separate
After signaling reaches the intended PBX route, prove answer, SDP offer and answer, RTP endpoints, packets in both directions and decoded audio separately. Historical codec or DTMF results do not replace current negotiation. Voice utilization reporting or a support record does not by itself prove edge receipt, route selection or intelligible audio.
Do not use an ordinary DID test or legacy lab feature list as emergency-call validation. Preserve the current emergency identity, approved civic address, callback route and provider-approved test workflow, and keep an alternative calling method available.
Correct one divergence and run bounded checks
Change only the first proven divergence: current registration object, provider assignment, trusted E-SBC source, number normalization, exact inbound route or confirmed continuity rule. Keep rollback state. Then retest the affected DID and one unaffected control DID, recording registration, provider attempt, edge receipt, PBX match, final destination, answer and media independently.
If continuity was involved, coordinate one approved new-call failure and restoration exercise; do not infer established-call survival. No Cox account, pilot, DID, credential, E-SBC, PBX, registration, packet, route, continuity event, emergency call or media stream 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.
- Cox Business Voice Trunking ↗
- Cox Business Asterisk 1.8.7 configuration guide ↗
- Cox Business Avaya IP Office 6.0 configuration guide ↗
- Cox Business Interactive Intelligence CIC configuration guide ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.