Freeze one call, trunk group and observed edge
Record UTC and local time, calling and called identities, expected and observed trunk group, site, connectivity, CIU or demarcation, carrier target, customer edge, SIP result, PBX endpoint and first route. Redact credentials and personal data.
Classify the first divergence: the order maps the call elsewhere; TELUS selected another trunk group; required IP reachability failed; the provider attempt did not reach the expected edge; the edge selected another PJSIP object; identity normalization changed the number; or the PBX chose another route.
Reconcile the order and resiliency purpose first
TELUS service terms distinguish additional trunk groups for connectivity resiliency, customer-equipment resiliency and carrier SBC geo-redundancy. Compare the current order and handoff with the affected trunk group, site, access, CIU, provider target and customer equipment. Do not assume the same selection or restoration behavior across those purposes.
Preserve the provider change record, intended priority and effective time. A configured alternate is administrative evidence until an authorized call proves the provider attempt and customer-edge receipt.
Prove required IP reachability without calling it delivery
The R4 terms require traffic to be routable to the IP addresses used by the VoIP service. Confirm the ordered connectivity, routing, NAT, firewall and current target without copying a generic endpoint table into production. Reachability or an OPTIONS response does not prove that the provider selected the expected trunk group or delivered the affected INVITE.
Preserve route and firewall evidence at the correct boundary. If the expected edge saw no request, keep the PBX unchanged while TELUS and the access owner reconcile the selected target.
Match the provider attempt to the customer edge
At the expected edge, preserve source and destination addresses, transport, Request-URI, To, asserted identity, Via, Contact, SDP and the full response sequence. Correlate those fields with the provider-side record and exact time window.
A provider record is not proof of customer-edge receipt, and an edge INVITE is not proof of the loaded PBX route or media. Record the first interface where expected and observed evidence differ.
Follow the request through Asterisk or FreePBX
When the INVITE reaches the expected edge, follow the effective PJSIP identify, endpoint, transport and context. Preserve the delivered identity before and after normalization, then record the first loaded inbound route, time condition, destination and any forward. Correct only the first demonstrated divergence.
Keep TELUS Universal Call Blocking and caller-identity syntax separate from inbound trunk-group selection. A malformed calling identity may be blocked, but it does not identify which provider trunk group or customer edge was selected.
Retest ordinary routing and exclude emergency calls
After an authorized correction, retest the affected number and one unaffected control while recording provider selection, edge receipt, PBX match, answer and media separately. If continuity behavior was changed, prove restoration under the provider-approved plan rather than assuming an alternate answer restored the primary path.
Keep VoIP 9-1-1 validation outside this regression. Portal address, caller identity, PBX route, callback and emergency handling require the provider-approved workflow. No TELUS account, order, trunk group, CIU, provider target, PBX, 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.
- TELUS Business SIP Trunking ↗
- TELUS SIP Trunking Service R4 eContract service terms ↗
- TELUS Universal Call Blocking support ↗
- TELUS Partner Solutions support ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.