Freeze one number, interval and unexpected destination
Record UTC and local time, Bell account and trunk group, affected number, caller, expected and actual destination, active Remote Call Forwarding mode, schedule and timezone, out-of-service destination, portal user and role, recent changes, provider call identifier, report filters, edge result and PBX match. Redact credentials and personal data.
Classify the first divergence: the portal rule differed; the schedule window or timezone differed; out-of-service forwarding acted; provider automatic overflow acted; no matching INVITE reached the edge; or the PBX selected another route or local forward.
Identify the exact per-number forwarding model
Bell's portal guides describe Remote Call Forwarding for all calls, scheduled calls and out-of-service conditions. The client guide separately notes that the older Call Forward Always option is not available to new clients. Confirm the account entitlement and named feature before editing any rule; a screenshot from a guide does not prove that the control exists on this account.
Preserve the covered number, active destination, schedule, timezone, out-of-service value, approval, actor and change time. A scheduled rule can be correct while its assumed local time is wrong, and an all-calls rule can mask whether the trunk is reachable.
Separate number forwarding from provider path continuity
Bell's product page describes dual virtual connections and automatic overflow or rerouting to an existing PSTN, PRI/T1 or alternative service. Those provider controls remain distinct from a portal Remote Call Forwarding rule. An alternate destination therefore does not identify which control acted or prove that the primary customer path recovered.
Obtain the ordered topology, covered numbers, configured destination, qualifying condition and restoration procedure. Do not invent a health probe, SIP-code matrix, timer or precedence rule from the public description.
Correlate Bell reporting without treating it as edge proof
Use the affected timestamp, number and trunk group to inspect the corresponding call detail, disconnect cause, call volume, peak usage, service availability and mean opinion score views. Preserve the selected filters, timezone and export time. These provider-side observations can narrow the interval but do not prove that the customer firewall or PBX saw the request.
A mean opinion score is a derived quality indicator, not a listening result. A capacity or peak-usage view also does not establish the ordered access, current PBX channel availability or the exact reason a particular call was forwarded.
Follow any received request through Asterisk or FreePBX
If an authorized edge capture contains the matching INVITE, preserve its source, Request-URI, To and asserted identity, SDP and response sequence. Then follow PJSIP identification, endpoint, transport, context, digit normalization and the first loaded route. In FreePBX, verify generated configuration as well as the GUI record and do not hand-edit generated files.
Keep provider-selected leg, edge receipt, PBX route, local forwarding, answer and media as separate outcomes. Correct only the first demonstrated divergence and keep rollback evidence.
Retest normal service and the approved condition
After an authorized correction, retest the ordinary number path and one unaffected control while recording provider handling, edge receipt, PBX match, answer and media separately. Exercise an outage or scheduled condition only with the owner and Bell-approved method, confirm the alternate result, restore normal state and verify it through the same evidence chain.
Keep the number's current emergency address, calling identity and callback workflow separate from its forwarding destination. Do not place an emergency call as an ordinary regression test. No Bell account, rule, schedule, report, trunk, PBX, packet, call, 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.
- Bell voice solutions and SIP Trunking ↗
- Bell SIP Trunking client administration portal guide ↗
- Bell SIP Trunking end user portal guide ↗
- Bell SIP Trunking performance and service reporting user guide ↗
- Bell SIP Trunking support guide ↗
- Bell SIP Trunking emergency-service limitations ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.