Freeze one missed call and the intended fallback contract
Record one authorized inbound attempt with timestamp and timezone, called number, caller, peoplefone country account, SIP line, intended primary PBX, expected alternate destination and exact observed outcome. Preserve the line and forwarding configuration before changing registration timers or filters.
State whether the requirement is provider-side routing of new calls after the SIP line becomes offline. peoplefone documents that boundary; it does not describe survival of an established call, preservation of IVR or queue behavior, or PBX-side high availability. Keep those requirements separate.
Prove registration loss and the provider offline transition
Capture the PBX outbound-registration state, last successful REGISTER, Contact, requested and granted expiry, last refresh attempt, response and network reachability. Then record the provider portal line state and the time it changed. peoplefone recommends a 180–300 second re-registration interval in troubleshooting and describes fallback after an offline state following its recommended 180-second interval; these values do not prove the exact detection time for an account.
A PBX process being stopped, an OPTIONS timeout, a local WAN alarm and the provider marking a SIP line offline are different events. Do not simulate failure by exposing management interfaces or broadly disabling security controls.
Resolve the forwarding role and number filter
Verify that the rule belongs to the affected SIP line, uses the offline role, is active, selects forwarding rather than voicemail and points to the approved destination. peoplefone documents prefix and exact-number filters and warns through its example that an overly short prefix can match more numbers than intended.
Compare the called number as assigned in the portal with the filter type and value. A visible rule does not prove the call reached that SIP line, that the filter matched, or that another immediate, busy or no-answer rule did not take precedence.
Follow the alternate call as a new provider-originated leg
Once the provider line is observably offline, trace a new inbound attempt into the forwarding decision and toward the alternate network. Record the selected rule, destination normalization, provider response, presented identity, answer state and charge evidence. Do not infer alternate capacity, emergency behavior, DTMF, recording, consent handling or support for the original PBX features.
If the destination is another VoIP service, its registration, routing and media remain a second service path. If it is mobile or PSTN, remote voicemail can answer before a person. Distinguish provider acceptance, remote alerting, answer and two-way conversation.
Correct only the first demonstrated divergence
Correct the first failed boundary: PBX refresh behavior, firewall or NAT reachability, provider offline state, inactive or wrong role, wrong SIP line, overbroad or nonmatching filter, invalid destination, insufficient credit or remote rejection. Preserve rollback and protect credentials and call metadata.
Do not shorten registration or NAT timers aggressively to force faster detection without provider agreement. peoplefone also documents a 30-second NAT keep-alive and recommends disabling SIP ALG; those controls address reachability and must not be confused with the provider forwarding trigger.
Retest failure, restoration and nonmatching numbers
In an approved maintenance window, observe normal primary delivery, the chosen failure trigger, registration loss, provider offline transition, one matching new call to the alternate destination and one nearby nonmatching number. Restore the primary path, confirm re-registration and provider online state, then verify return to primary without a forwarding loop or stale alternate route.
Record actual timestamps rather than promising a detection or restoration interval. Confirm cost, caller identity and capacity separately. This workflow is documentation-derived and was not reproduced on a customer or laboratory trunk.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- peoplefone: SIP-TRUNK setup, registration and forwarding ↗
- peoplefone: registration and network troubleshooting ↗
- peoplefone: firewall, NAT keep-alive and service ranges ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.