SIP 483 Too Many Hops

What this response means

RFC 3261 defines 483 Too Many Hops as the response a server sends after receiving a request whose Max-Forwards value is zero. The header is a remaining-forward count: each forwarding server decrements it, and the RFC recommends 70 as an initial value. A 483 identifies exhaustion at the responding server; by itself it does not identify the two routing decisions that formed a loop.

Bind it to one request path

Capture the method, Call-ID, CSeq, top Via branch, request URI, Route set, source, destination, Max-Forwards value and response direction for one failure. Establish which server generated 483 and which hop sent it the zero-valued request. Keep an INVITE failure separate from REGISTER, OPTIONS or an in-dialog request with a different route.

Repeated UDP packets with the same transaction identifiers can be retransmissions rather than new hops. A loop is supported when successive forwarded requests show new Via branches or legs, a falling Max-Forwards count and a destination that returns to an earlier routing owner.

Trace the routing ownership decision

Compare the request URI, Route and Record-Route state, resolved next hop and the destination selected by each intermediary. Common failure shapes include a PBX sending an unmatched number to a carrier that returns it to the same PBX, two proxies treating the other as authoritative, or a default route that feeds its own ingress path. Those are investigation patterns, not conclusions from the code alone.

Correct the demonstrated number ownership, domain, route, failover target or default policy. Do not change credentials, codecs, media, NAT and routing together; 483 is signaling-path evidence and says nothing about RTP quality.

Do not hide the loop by increasing the count

Raising an initial Max-Forwards value usually lets the same loop run longer and consume more signaling work. A lower diagnostic value may help an authorized administrator trace a path, but it is not a production repair. Preserve the normal documented boundary unless the implementation owner has a separate standards-based reason to change it.

Asterisk's current res_pjsip reference documents a global max_forwards default of 70 for SIP requests. Its dialplan CHANNEL(max_forwards) item instead limits Asterisk call forwarding and explicitly has no relation to the SIP Max-Forwards header. Keep those two controls separate.

Validate success and bounded failure

After one approved route correction, repeat the original method and destination and confirm the request reaches the intended owner without revisiting an earlier hop. Test an authorized working destination and a deliberately unmatched destination so the default route fails once, predictably, rather than recirculating. Confirm failover does not point back into the same path.

For Asterisk PJSIP, the focused 483 investigation follows the inbound and outbound legs, running route decision and two different max_forwards controls.