SIP.US primary gateway works but failover or inbound calls fail

Freeze one failure state and its intended redundancy layer

Record the timestamp and timezone, SIP.US trunk and DID, selected authentication mode, current portal registration details or IP Auth label, PBX and version, configured proxy or SRV target, resolved gateway, public Contact and observed source address, trusted gateway policy, primary and secondary trunk assignment, PSTN Backup or Forward setting, first INVITE and response, RTP result and restoration step. Redact credentials, authorization fields and customer addresses before sharing evidence.

Classify the requirement first: survive one provider gateway loss, reach a second customer trunk or site, forward to the PSTN after no response, or recover inbound delivery after a registration change. Those are different controls and should not share one vague failover test.

Use the current gateway inventory, not a legacy example

SIP.US says its enhanced infrastructure uses gw4.sip.us and gw5.sip.us for all SIP traffic, and that systems configured only for legacy gw1.sip.us and gw2.sip.us no longer register or receive inbound calls. The same current guide recommends gw.sip.us DNS SRV where supported or explicit primary and backup proxies otherwise.

The older registration-status article still mentions loss of registration to gw1 in one SRV paragraph. Treat that as stale wording, not an additional live gateway. Preserve the DNS query, ordered answers, selected address, registration transaction and firewall counters from one test window.

Prove registration or IP authentication before testing redundancy

For credential mode, compare the portal trunk number, REGISTER realm and username, challenge, authenticated retry, final response, Contact, observed source alias, expiry and selected gateway. For IP authentication, expect an IP Auth label rather than a registration state, use the exact stored public address and port, and confirm the PBX accepts traffic from the documented SIP.US gateways.

SIP.US describes credential registration and IP authentication as mutually exclusive on one trunk. Do not interpret an ignored REGISTER as a gateway outage when the public address is assigned to an IP-authenticated trunk.

Keep gateway redundancy separate from a secondary trunk

DNS SRV or multiple proxies can move the same trunk between SIP.US gateways. A secondary trunk is a separate DID assignment that SIP.US documents as manually configured and tried after the primary route fails to receive a response. A linked trunk can share billing capacity while retaining unique credentials.

Record which trunk and gateway received each INVITE, the primary response or timeout, whether another branch was attempted and the channel capacity available to that path. One successful secondary registration does not prove the DID is assigned to it, and a secondary assignment does not prove that a rejection qualifies for advancement.

Trace inbound Contact, number format and the first PBX rule

In registration mode, SIP.US says it sends inbound traffic to the Contact address and port shown in registration status. Compare that value with the observed public source alias, NAT translation and actual PBX listener. Then retain the inbound INVITE and match the documented default eleven-digit TO value to the first PBX route.

A portal-visible registration does not prove the Contact is reachable, both gateways are trusted, the DID is assigned to the intended trunk or the PBX number format matches. Correct the earliest mismatch and repeat the same inbound attempt before changing media or fallback treatment.

Exercise failure and restoration without claiming continuity

Run separately authorized tests for current-gateway loss, primary-trunk non-response, customer PBX or access loss, PSTN Backup and restoration. Preserve the provider-visible trigger, new-call result, caller treatment, channel use and return-to-primary behavior. Test two-way media after signaling because the interconnection guide says RTP can arrive from varied addresses and ports.

Do not infer active-call survival, automatic customer-WAN recovery, exact retry timers or service availability from the feature descriptions. Remove any temporary firewall or logging changes and confirm the original primary path after the exercise. No SIP.US account, gateway failure, PBX, route, failover event or live call was tested for this diagnostic.

Keep DID treatment separate from gateway recovery

A healthy gw4/gw5 path does not establish which DID control runs next. The DID precedence diagnostic separates PSTN Forward, conditional Backup, secondary trunk assignment and capacity.