Keep 502 and 504 as different gateway evidence
Capture one complete failed transaction with the method, Call-ID, CSeq, top Via branch, request URI, Route set, source, destination and response direction. RFC 3261 defines 502 for a gateway or proxy that received an invalid response from the downstream server it accessed. It defines 504 for a server acting as a gateway that did not receive a timely downstream response. Neither status identifies the failed dependency by itself.
Establish which SIP element sent the final response and which downstream hop it had attempted. A phone display or final caller announcement cannot show that boundary. Keep INVITE, REGISTER, OPTIONS and in-dialog requests separate, and do not relabel a 504 as a local 408 merely because both involve waiting.
Preserve the original response before Asterisk translation
Use a narrow pjsip set logger on reproduction and correlate it with Asterisk logs by timestamp, Call-ID and channel. Disable protocol logging when the capture ends and protect credentials, identities and SDP. The wire response is primary evidence for the status code, method and responder.
Asterisk's published cause map translates SIP 502 to destination out of order and SIP 504 to recovery on timer expiry. DIALSTATUS can expose a coarser CHANUNAVAIL or CONGESTION result. Preserve HANGUPCAUSE_KEYS() and the per-channel HANGUPCAUSE(channel,tech) or tech_extended value where dialplan evidence is required; do not reconstruct an exact 502 or 504 from a generic cause alone.
Trace the downstream exchange behind a received 502
When Asterisk receives 502 from a carrier-facing proxy or gateway, confirm the exact sender and obtain its matching transaction record. The downstream problem may be an invalid or unusable response beyond Asterisk's visible leg. Compare an authorized known-working destination or route without changing credentials, codecs, NAT, DNS and dialplan together.
Escalate with the time, carrier identifier, responder address, method, request destination and redacted trace. A 502 does not prove that the originating request was malformed, that the called number is invalid or that every route behind the gateway is unavailable. Correct the demonstrated gateway or downstream interaction.
Locate the timer boundary behind a received 504
For 504, identify which gateway waited and the downstream server or service it accessed. Preserve the interval from that gateway's first downstream attempt to its final response when the provider can supply it. Check the selected next hop, DNS result, transport establishment and downstream replies on the same transaction.
Do not globally lengthen Asterisk transaction, dial or application timers to hide an unresponsive dependency. A longer caller wait can delay failure without repairing the route. Change a timeout only when the owning component and documented service behavior demonstrate that its present boundary is wrong, then test both timely success and bounded failure.
Treat REGISTER 502 or 504 as a separate retry state
Asterisk classifies 502 and 504 as temporary outbound-registration failures, alongside no response, 408, 500, 503 and 600-class responses. The registration follows its loaded retry_interval and max_retries; current documentation lists defaults of 60 seconds and 10 retries. Those settings govern REGISTER attempts, not INVITE route advancement.
Inspect the complete REGISTER exchange, loaded server_uri, proxy, transport and retry state before forcing another attempt. Respect provider backoff and avoid a retry storm. Exhausted retries prove that the configured policy stopped, not whether the registrar, gateway, DNS, transport or downstream dependency caused each failure.
Validate the repaired boundary and alternate route
After a documented correction, repeat the same method and destination and capture the successful response path. For calls, confirm caller identity, answer, two-way media, DTMF and ordinary release independently. For registration, confirm a final accepted binding and then test inbound and outbound calls separately.
If an alternate route is intended, verify which exact response advances it, the next attempted destination, loop prevention, caller identity, charging and restoration. Do not assume every dial sequence, DNS target or carrier policy advances on 502 or 504. No gateway, proxy, carrier, registrar, dependency, failover or live-call behavior was validated for this guide.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: SIP 502 and 504 ↗
- Asterisk outbound registration failure handling ↗
- Asterisk PJSIP troubleshooting guide ↗
- Asterisk hangup cause mappings ↗
- Asterisk per-channel hangup cause inspection ↗
- Asterisk Dial application results ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.