Freeze one failed call and the intended account state
Record UTC and local time, calling and called numbers, provider and PBX Call-ID where available, expected location, expected PBX or gateway, DID inventory row, configured failover number, recent portal or support change and exact observed destination. Capture the first SIP response and elapsed time before changing the DID, route and failover together.
Classify the symptom narrowly: DID assigned beneath the wrong location; provider monitors the intended location as unavailable; failover destination is stale; provider sends to the correct edge but the wrong PBX identifies the request; inbound route misses; an enhanced-number feature owns the DID; signaling succeeds but audio fails; or primary routing is not restored after recovery.
Prove DID assignment and the ordered PBX location
In HostPilot, retain the exact location identifier, address, nickname, trunk or trunk group and phone-number association. Compare them with the implementation record and current customer-service state. Two PBXs at one street address can be separate portal locations, so do not reconcile them by address alone.
For the affected DID, distinguish portal inventory from the provider attempt. Obtain recent examples and determine whether Intermedia targeted the normal location or the configured alternate. Only after that evidence should a PBX administrator broaden an inbound match or move the number.
Correlate monitoring, failover selection and restoration
Preserve the provider-visible availability state and timestamps before, during and after the failed call. Compare the configured per-number alternate with the destination that actually received the new call. Do not infer the private monitoring probe, SIP trigger or restoration timer from the word unavailable; the public pages do not publish that complete decision contract.
If an alternate answers, record that result as successful forwarding on a separate PSTN or provider leg, not proof that the original PBX path worked. If the primary location appears healthy again, verify a new call is routed back before removing a working contingency.
Trace provider delivery through the customer edge and PBX
When Intermedia targets the primary location, capture source and destination addresses, transport, Request-URI, To, From and asserted identity, then correlate endpoint or peer identification, assigned context, first inbound-route match and final destination. A portal call-history row and a packet at the firewall are different observations.
If the provider attempt never reaches the edge, keep the current account peer and trunk-specific implementation record authoritative. Do not copy an endpoint-oriented port table or an old partner guide into the firewall. If it reaches the edge, correct the first PBX or network divergence rather than moving the DID to hide it.
Use call history, QoS and media evidence within their scope
Export the relevant location and phone-number call-history rows and retain query scope and time zone. If the connected call is available in the QoS tool, preserve its route summary and jitter, round-trip delay and packet-loss fields before the documented retention window expires. Absence from an outbound view can depend on PBX configuration and is not universal proof that no call occurred.
Correlate those records with the SIP transaction, SDP, selected payload, RTP endpoints, packet directions and authorized audio observation. A connected-call row, SIP answer or packets in both directions does not alone prove intelligible two-way audio.
Correct the first divergence and protect emergency identity
Change only the first demonstrated mismatch: portal location, DID assignment, failover destination, provider-owned monitoring state, customer edge, PBX identification, inbound route or media policy. Provider and portal changes need their effective time and rollback; PBX and firewall changes need separate approval and backup.
If the DID is a location default or dedicated remote-phone 911 number, reconcile physical address, portal acceptance, PBX caller identity and callback route before any change. Repeat bounded primary and failover calls, verify restoration and follow the provider-approved emergency verification process. No Intermedia account, location, DID, monitor, PBX, packet, media stream, failover event or emergency 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.
- Intermedia SIP Trunking product page ↗
- Intermedia SIP Trunking overview ↗
- Intermedia SIP Trunking HostPilot overview ↗
- Intermedia SIP Trunking failover routing ↗
- Intermedia PBX configuration guides ↗
- Intermedia service and configuration port information ↗
- Intermedia certified PBX list ↗
- Intermedia emergency 911 policy and information ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.