Freeze one call and identify the first unexpected leg
Record UTC and local time, selected Allstream service and country, calling and called identities, expected DID or group, portal rule and scope, Unavailable state, trunk continuity state, expected edge, provider attempt, PBX receipt, selected route, answer and media result. Redact addresses, credentials and personal data where required.
Classify the first divergence: the wrong portal object was active; the PBX was considered unavailable; another endpoint or telephone number was selected; the INVITE did not reach the expected edge; identity changed; or the loaded PBX selected another destination.
Prove the portal rule, scope and effective state
Allstream documents Immediate, Busy/No Answer, Unavailable and Selected Callers forwarding and distinguishes group-level from individual-DID controls. Confirm the exact service family, administrator or user scope, DID or group, destination, saved state and change timestamp. Preserve the provider record rather than relying on a screenshot without object identity.
Unavailable Call Forwarding is not the same as a busy or no-answer route. A configured destination does not prove the rule was selected, the PBX was judged unavailable, or the forwarded leg answered.
Separate PBX availability from trunk failover and pooling
The quick-start separately lists OPTIONS, trunk overflow to a telephone number, multi-endpoint failover and two-endpoint load sharing. Determine which features are actually ordered, their peer or destination sequence, trigger, timers and restoration behavior. Align provider attempts with the same time window as edge and PBX evidence.
An OPTIONS response, IP match or SIP registration is not proof of inbound routing. An alternate answer does not identify which control triggered or establish recovery of the primary path.
Trace the expected Allstream request through the edge
Compare the current order and handoff with the observed source, destination, transport and Allstream SBC identity. Preserve Request-URI, To, P-Asserted-Identity, Privacy, Via, Contact, SDP, session-timer fields and the full response sequence. Check NAT or ALG translation against the ordered topology rather than applying generic SIP-ALG advice.
If the provider attempt does not reach the authorized edge, keep dialplan edits out of the incident. If it reaches another edge, reconcile provider selection and customer failover before changing the PBX.
Follow the loaded PBX route and media separately
When the INVITE arrives, follow the effective endpoint or identify match, context, number normalization, inbound route, time condition, destination and any PBX-side forward. For FreePBX, distinguish database and generated configuration from the loaded Asterisk objects. Correct only the first demonstrated divergence.
After answer, preserve both SDP bodies, selected codec, DTMF method, RTP or SRTP tuples and decoded audio. Provider delivery does not prove the PBX route, answer or two-way media.
Retest ordinary calls and keep 911 separate
After an authorized correction, retest the affected ordinary number and one unaffected control. Record portal state, provider selection, expected edge receipt, PBX route, answer and each media direction. Verify restoration of any temporary forward or alternate path under the approved change plan.
Do not place an uncoordinated 911 call. The Canadian advisory requires a current Registered Location and records power, broadband, location-update and calling-party-number dependencies. Keep location, default BTN, PBX route, callback and an alternate calling method in their own acceptance record. No Allstream account, forward, trunk, 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.
- Allstream SIP Trunking Quick Start Guide ↗
- Allstream SIP Portal Overview — Native SIP and PRI-SIP ↗
- Allstream SIP Portal Overview — SIP Extreme and SIP Gateway ↗
- Allstream advisory for 911 access using VoIP services in Canada ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.