Identify the exact profile, gateway and failed call leg
Record the switch, profile, gateway name, destination, source identity, time, UUID and observed cause. Confirm that the dialplan selected sofia/gateway/<name>/<number> for the intended gateway. A local GATEWAY_DOWN before an INVITE leaves is a different boundary from a 403, 404, 480 or 503 returned by the upstream.
Compare one known permitted call through the same gateway and retain a restriction test after any route change.
Read gateway State and Status together
sofia status gateway <name> exposes lifecycle state and a simpler UP or DOWN status. REGED is healthy for a gateway intended to register. FAILED, FAIL_WAIT, EXPIRED or TIMEOUT indicate a broken registration path. NOREG is normal when register=false; NOREG / UP can therefore be a healthy IP-authenticated peer, while NOREG / DOWN can indicate failed OPTIONS reachability when ping is configured.
Do not enable registration merely to replace a normal NOREG label.
If registration is required, follow REGISTER
Compare the gateway proxy, realm, authentication identity, secret source and transport with the provider contract. Capture a short profile-scoped trace and read the REGISTER, challenge, authenticated retry and final response. A timeout needs DNS, route, firewall or far-end evidence; a rejection needs identity and policy evidence.
Correct one boundary, rescan or restart only as required, and confirm the resulting state. Keep secrets out of the evidence.
If the gateway does not register, prove reachability separately
For IP-authenticated peering, confirm the provider-authorized source address, target host, port and transport. When OPTIONS ping is enabled, retain the request, response and Ping-Status; when it is disabled, do not invent a keepalive result. DNS resolution and a reachable socket still do not prove that the upstream accepts an INVITE.
Keep profile bind and advertised addresses distinct from the egress address the provider observes.
Follow the outbound INVITE and final response
If an INVITE leaves, retain the Request-URI, From and asserted identity, selected transport, final SIP response and mapped Q.850 cause for that b-leg. FreeSWITCH can map multiple SIP responses to one cause, so the cause alone is incomplete. If the call answers, prove the SDP and both RTP directions rather than closing on signaling success.
Avoid changing credentials, number format, caller identity and firewall policy in one attempt.
Close with a bounded repeat and rollback
After the smallest documented correction, repeat the failed destination, one known working route and one restricted route. Confirm gateway state, upstream response, answer, two-way media, hangup and cleanup, then turn tracing back off. Preserve the previous configuration and the exact command used to apply the change.
No gateway, provider relationship, failover event or call was tested for this diagnostic.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- FreeSWITCH gateways and trunk registration ↗
- FreeSWITCH SIP profiles with Sofia ↗
- FreeSWITCH diagnostic toolbox ↗
- FreeSWITCH call-setup failures ↗
- FreeSWITCH SIP trace and CDR reading ↗
- FreeSWITCH events catalog ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.