Freeze one call, DID, Site and unexpected destination
Record UTC and local time, product and agreement, affected DID, caller, expected and actual Site or peer, primary and alternate access state, ordered continuity option, provider call identifier, CDR filters, edge result and PBX match. Redact credentials and personal data.
Classify the first divergence: the ordered peer set differed; load balancing selected another active peer; the primary trunk was fully utilized and overflow acted; failover or an as-needed emergency redirect was active; no matching request reached the edge; or the PBX selected another route or local forward.
Map document labels to the signed order
Rogers' schedule names SIP Peer Failover, SIP Peer Load Balancing, SIP Peer Overflow and Emergency Redirect. The branded information sheet instead lists Access Failover, Enterprise Failover, DID Number Re-route and SIP Trunk Overflow. Do not assume that similarly worded controls are identical or included.
Preserve the exact ordered label, covered Sites or DIDs, eligible peer set, configured destination, activation state, customer approval, change record and restoration procedure. Public descriptions do not establish one common health probe, timer, response-code policy or priority relationship.
Separate outage failover, active distribution and capacity overflow
Peer Failover concerns emergency or outage redirection, Peer Load Balancing distributes incoming calls across active peers, and Peer Overflow applies when the primary trunk is fully utilized. Emergency Redirect is an as-needed action identified by the customer. A call reaching an alternate peer therefore does not identify the mechanism by itself.
Correlate the call with provider state, ordered session quantity, concurrent-call observations, access status and the change or incident record. Do not turn an alternate answer into proof that the primary path failed, recovered or lacked capacity.
Correlate Rogers records with the customer edge
Use the affected timestamp, DID and provider identifier to inspect the relevant CDR and support or change record. Preserve the selected timezone, filters and export time. A Rogers CDR is provider-side correlation evidence; it does not prove which customer interface received the request, which PBX route loaded or whether two-way media worked.
Match any provider attempt to an authorized edge capture. If none exists, keep the fault boundary with provider routing, access or the capture point. If it exists, preserve source, requested identity, asserted identity, SDP and response sequence before changing the PBX.
Follow any received request through Asterisk or FreePBX
For a matching edge request, follow PJSIP identification, endpoint, transport, context, digit normalization and the first loaded dialplan route. In FreePBX, compare the GUI record with generated configuration and do not hand-edit generated files. A correct provider peer can still reach an unexpected PBX destination through overlapping patterns, local forwards or stale generated state.
Correct only the first demonstrated divergence. Keep provider-selected peer, edge receipt, PBX route, answer, SDP agreement, RTP delivery and decoded audio as separate observations with rollback evidence.
Retest normal routing and only the approved continuity condition
After an authorized correction, retest the ordinary DID path and one unaffected control while recording provider handling, edge receipt, PBX match, answer and media separately. Exercise failover, overflow or an emergency redirect only through an owner- and Rogers-approved plan; confirm the alternate result, restore normal state and verify restoration through the same evidence chain.
Keep each Site's emergency address and callback workflow separate from continuity destinations. Do not place an emergency call as an ordinary regression test. No Rogers account, peer, DID, CDR, PBX, packet, continuity event, emergency result or support response 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.
- Rogers Business Fixed Network Terms — SIP Services schedule (April 2021) ↗
- Rogers Business SIP Trunking information sheet ↗
- Rogers Business SIP trunking overview ↗
- Rogers SIP Trunking Pizza Pizza case study ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.