Freeze one failed call and every effective DID control
Record the called DID, timestamp and timezone, SIP.US trunk, billing plan, credential or IP-auth mode, current registration details or IP Auth label, primary and secondary trunk, PSTN Forward, PSTN Backup, channel count, portal call evidence, customer-edge receipt, PBX route, response, SDP and audio.
Do not infer the call path from one green status. The DID assignment, identity mode, provider gateway, unconditional forward, conditional backup and PBX route are separate controls.
Check whether PSTN Forward intentionally bypassed the PBX
SIP.US documents PSTN Forward as an all-calls redirect to an external number. It also states that an active PSTN Forward prevents PSTN Backup from engaging. If the DID never reaches the PBX and always reaches an external target, preserve the Forward value and provider attempt before changing registration, firewall or inbound routes.
A working forwarded leg does not prove the PBX path, and removing a forward is a routing change that needs an authorized test and rollback.
Prove whether conditional PSTN Backup became eligible
PSTN Backup is described for no response from the server or no active trunk registration. For credential mode, retain the REGISTER binding and provider-visible loss. For IP authentication, retain the IP Auth mode and actual reachability result because a normal registration row is intentionally absent.
The reviewed documentation does not establish every qualifying response, timer, retry count or restoration interval. Preserve what SIP.US attempted instead of treating every PBX rejection as a promised backup trigger.
Separate provider gateway redundancy from secondary trunk routing
DNS SRV or gw4/gw5 proxy configuration can move the same trunk between provider gateways. Secondary trunk routing instead requires another SIP trunk and a DID assignment to that primary/secondary pair. Record the gateway, trunk and address receiving each attempt.
A second registration, reachable address or firewall rule does not prove that the DID is assigned to that trunk or that the provider advanced to it.
Check channel capacity before blaming the fallback rule
A forwarded call uses two channels on a channel-based plan, one for each leg. SIP.US also warns that backup or failover through the same trunk can fail when the capacity limit is reached. Preserve the purchased capacity, active-call count, portal alert and target trunk at the incident time.
Do not equate a monthly count of capacity-limit events with per-call telemetry, and do not assume a separately assigned trunk shares or does not share capacity without the account record.
Correct the earliest mismatch and bound the result
If SIP reached the customer edge, preserve source, destination, transport, Request-URI, TO number, endpoint identification, context and first route match. Then distinguish SIP answer, SDP, RTP flow, negotiated codec and decoded audio. Change only the demonstrated owner: Forward, Backup, identity mode, Contact or public address, DID assignment, capacity, firewall, PBX identification, number normalization, route or media.
Repeat the same authorized call and verify restoration. This does not prove every DID, trigger, provider gateway, PBX, capacity condition, emergency workflow, compatibility, availability, pricing or established-call survival.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- SIP.US IP authentication guide ↗
- SIP.US registration status guide ↗
- SIP.US current gateways and interconnection requirements ↗
- SIP.US call failover options ↗
- SIP.US inbound call troubleshooting ↗
- SIP.US channel-limit guidance ↗
- SIP.US E911 information ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.