Freeze the number, package and one failed call
Record UTC and local time, called and calling identities, exact active number, sub-account, billing type, current package, route-profile name and type, primary or ordered trunks, redundant trunk, translations, recent order or move time and the destination that actually rang. Preserve provider CDR or ADR identifiers, SIP Call-ID, customer-edge capture and PBX logs.
Classify the symptom narrowly: wrong package; wrong routing profile; unexpected round-robin, sequential or proportional selection; primary or redundant trunk behavior; unconditional Forward; Failover translation; provider delivery to the correct edge followed by a PBX route mismatch; or correct signaling followed by a media problem.
Prove current package ownership before reading the profile
Confirm the number in the current portal inventory or DID-management response and record its package before interpreting any trunk profile. IntelePeer states that all numbers in a package follow that package's routing policy. If a number was moved, retain the completed operation and the destination package rather than relying on a stale worksheet or prior order.
If package membership is wrong, correct it through the authorized inventory workflow. Do not edit Asterisk or FreePBX identification rules to make traffic from the wrong provider route look correct.
Apply the correct routing model
Determine whether the package is bundle or usage based. For a bundle package, inspect the primary trunk and optional redundant trunk. For a usage package, export or record the complete Round Robin, Sequential or Proportional profile and every configured trunk. Preserve signaling addresses and order state for each entry.
A different trunk in a Round Robin or Proportional profile can be an intended selection rather than failover. A lower sequential entry or redundant bundle trunk requires evidence that the earlier path could not complete the new call. The reviewed public pages do not define one universal response-code and timer matrix for every account.
Inspect switched-number translations separately
Query or inspect the number's translation record for type, destination, failover, name and overwrite result. Forward is unconditional. Failover is documented for a trunk not responding to INVITEs. The portal guide says the submitted change can take five to ten minutes to become active, so preserve submission and observation timestamps before declaring the new state ineffective.
A telephone-number failover can ring a mobile, voicemail or another PSTN destination without proving that the original SIP trunk, redundant trunk or PBX recovered. Remove or alter it only with the service owner's approval and a recorded rollback.
Correlate provider records with edge and PBX evidence
Retain the unique CDR ID, customer trunk name, package, label, translated number, calling identity, codec and duration fields available for the call. Align them with the customer-edge packet arrival, Request-URI, To, From and P-Asserted-Identity, PBX endpoint or trunk match, context, inbound route and final SIP response.
A provider CDR or billable duration does not prove the expected PBX handled the call or that media worked. If the correct edge received the INVITE, fix the first local identification or routing mismatch instead of changing package-level routing.
Restore the intended path with bounded tests
After one authorized correction, wait through the documented translation interval when applicable and place bounded calls to primary and alternate paths. Confirm number package, routing profile, selected trunk, provider record, customer-edge receipt, PBX route, answer, SDP and both RTP directions independently. Retain rollback and restoration timestamps.
Emergency routing requires its own approved 933 and simulated-failure procedure; do not infer it from an ordinary inbound test or place an uncoordinated 911 call. No account, package, trunk, translation, CDR, packet, failover, emergency workflow 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.
- IntelePeer Customer Portal quick-start guide ↗
- IntelePeer Customer Portal FAQs ↗
- IntelePeer call-detail record reference ↗
- IntelePeer number forwarding and failover ↗
- IntelePeer Phone Number DID Management API ↗
- IntelePeer Dynamic 911 integration testing ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.