SIP 483
SIP 483 Too Many Hops in Asterisk
Every SIP request carries a Max-Forwards counter that decrements at each hop. When it reaches zero the request is rejected with a 483. Real call paths are a handful of hops long, so a 483 is a loop until proven otherwise.
What it looks like in the log
[2026-08-17 12:14:07] VERBOSE[8890][C-00001c55] res_pjsip_logger.c: <--- Received SIP response (620 bytes) --->
SIP/2.0 483 Too Many Hops
CSeq: 102 INVITEWhat it means
Max-Forwards starts at 70 in most implementations. Burning through 70 hops means the call visited the same routing decision dozens of times, each pass looking locally correct and sending the request onward to somewhere that sends it back.
The loop does not have to be within one box. A common shape is a PBX that forwards to a carrier, a carrier that routes the number back to the same PBX, and a dialplan that forwards it out again - each participant behaving reasonably, the system as a whole spinning.
Most common causes
-
01A call forward pointing back to its own source
Extension A forwards to B, B forwards to A. Straightforward once seen, invisible in either extension's configuration read alone.
-
02A DID routed back out to the carrier
An inbound number that lands in a context whose outbound rules match it again and send it straight back. Frequently created by a catch-all pattern that is broader than intended.
-
03Follow-me or find-me including the originating device
A find-me list that contains the extension the call is already ringing produces a loop that ends only at Max-Forwards.
-
04Two trunks pointing at each other
In a multi-site setup, both sides configured to route unknown numbers to the other creates a loop for any number neither knows.
-
05A recent routing change
Because 483 requires a cycle, it appears the moment a cycle is introduced. If it started today, the change that caused it was made today.
How to tell which one it is
Look for the same destination appearing repeatedly in this call's trace. A loop is visually obvious in a timeline: the same INVITE to the same target, over and over, with nothing else changing between passes.
Then check the Via header stack on the rejected request. Each hop adds a Via, so a request that has passed through your own address more than once carries the proof in its own headers.
How to fix it
-
Break the forwarding cycle
Find the two forwards pointing at each other and remove one. If both are intentional, one needs a condition that stops the second pass.
-
Tighten the outbound pattern
A catch-all outbound rule that matches your own DIDs will always eventually loop. Exclude local numbers from outbound matching explicitly.
-
Filter the originator out of find-me lists
Remove the device that is already ringing from any list that could ring it again.
-
Review whatever changed
A 483 with a start time is a change with a start time. The routing edit made just before it is the one to read.