Freeze one call and classify the first unexpected result
Record UTC and local time, calling and called identities, expected RTM direction and scope, threshold, active-call evidence, overflow destination, emergency-redirection state, provider result, observed destination, edge receipt, PBX route and media result. Redact credentials and personal data.
Classify the first divergence: the call was subject to another RTM; the threshold evidence differs; the provider did or did not select overflow; emergency redirection was active; the attempt reached another edge; identity normalization changed the number; or the PBX selected another route.
Reconcile inward and outward RTM scope before changing capacity
SaskTel documents inward RTM as choking selected categories before they reach the IP Trunking system group and outward RTM as limiting calls to a PSTN connection or toll plan. Confirm the ordered direction, call category or destination, threshold, trunk group and effective time.
Do not infer a threshold from one failed or redirected call. Align provider counters or records with PBX channel evidence and the same time window. Purchased trunks, active calls, call attempts, PBX channel limits and access bandwidth remain different quantities.
Prove the overflow destination and provider attempt
Item 500.23 describes overflow from an RTM to another customer-defined destination within the same serving central-office switch. Compare the current order and change record with the number or destination actually selected. Preserve the provider attempt, response and correlation identifiers.
A configured destination is administrative evidence, and an answered alternate is not proof that the correct threshold triggered or that the primary route failed. If the provider record diverges before the customer edge, keep PBX changes out of the incident.
Exclude customer-requested emergency redirection
Emergency redirection is separate from RTM overflow. SaskTel describes it as redirecting voice traffic to a predetermined alternate business location after a customer request during an emergency, subject to previously specified locations, facilities and capacity. Confirm whether it was invoked, by whom, for which numbers and when restoration was authorized.
Do not treat a disaster-recovery destination, PBX forward or RTM overflow row as the same control. Preserve the provider change and restoration records before testing ordinary new calls.
Trace the selected leg through the customer edge and PBX
At the expected edge, preserve source and destination addresses, transport, Request-URI, To, asserted identity, Via, Contact, SDP and the full response sequence. Correlate the trace with the provider attempt and exact time window.
When the INVITE arrives, follow the loaded PJSIP identify, endpoint, context, digit normalization, inbound route, time condition, destination and any forward. Correct only the first demonstrated divergence. An edge packet does not prove the final route, answer or intelligible media.
Retest ordinary calls and keep 9-1-1 separate
After an authorized correction, retest the affected ordinary number and one unaffected control. Record RTM evidence, provider destination, edge receipt, PBX match, answer and each media direction separately. Verify restoration of any emergency redirection under the approved plan rather than assuming an alternate answer restored the primary route.
Do not place an uncoordinated 9-1-1 call. Registered service address, caller-provided location, calling identity, PBX route, callback and provider-approved validation require their own workflow. No SaskTel account, RTM, overflow, redirection, packet, call, media or emergency result 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.
- SaskTel IP Trunking ↗
- SaskTel CRTC 21412 Item 500.23 — IP Trunking Service ↗
- SaskTel index for all tariffs — effective June 17, 2026 ↗
- SaskTel Emergency Voice Local Network Access Redirection — Item 1000.03 ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.