What 482 establishes
SIP 482 means the responding element detected a request loop before ordinary processing completed. RFC 3261 distinguishes a loop from a legitimate spiral: the same proxy can be visited again when the routing inputs have changed, but a loop repeats the same routing calculation. RFC 5393 updates the proxy algorithm and strengthens detection requirements for forking proxies.
The code identifies a decision made by the responder. It does not by itself identify every hop, the configuration error, the original source or whether a PBX, SBC, provider or proxy owns the returning route. Preserve the exact method and transaction because an INVITE, REGISTER, OPTIONS or in-dialog request can follow different policies.
Bind the response to the detecting element
Capture the request that received 482 and the response, including source, destination, method, request URI, Route values, Call-ID, CSeq, top Via branch and Max-Forwards. Identify the server that emitted 482 rather than assigning the fault to the nearest visible PBX. Compare an affected destination with a nearby authorized control request.
Retransmissions repeat the same transaction while a sender waits; they are not routing loops. A loop investigation instead follows newly forwarded requests or B2BUA legs and shows a routing owner selecting a path that returns to the same decision. Timestamps, branches, request targets and per-leg identifiers are needed to separate those cases.
Separate a loop, a spiral and hop exhaustion
A legitimate spiral revisits a proxy after the request target or other routing inputs have changed, so the new calculation can lead somewhere different. A loop recreates the same routing decision. Do not remove a valid service chain merely because an address appears twice; compare the full routing inputs used by the detecting element.
SIP 483 is different: it is returned when Max-Forwards reaches zero, whether or not the last server can perform earlier loop detection. RFC 7332 requires B2BUAs to copy and decrement Max-Forwards across the new UAC-side request for applicable out-of-dialog and dialog-forming requests. A 482 can arrive before exhaustion, while 483 is the bounded last defense.
Correct route ownership, not the protection
Trace number, domain and request-target ownership at each decision. Failure shapes can include two peers that both return an unmatched destination, a catch-all route that points back to ingress, or a failover destination that resolves to an earlier hop. These are investigation patterns, not conclusions from 482 alone.
Do not disable loop detection, strip Via values indiscriminately, raise Max-Forwards or add a broader catch-all route as the first repair. Those changes can conceal the evidence or increase signaling amplification. Correct the demonstrated target, ownership or fallback decision and keep unauthorized destinations bounded.
Validate the intended path and the negative path
After one approved route correction, repeat the original method and destination and confirm it reaches the intended owner without recreating the prior decision. Also test an authorized working destination, an unmatched destination and each intended failover path. The negative case should terminate once with the designed treatment rather than return to an earlier owner.
For Asterisk PJSIP, the focused 482 investigation correlates inbound and outbound legs, loaded endpoint and dialplan state, and the external detector without assuming that Via, Call-ID or response handling is end to end.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: proxy loop detection ↗
- IETF RFC 5393: strengthened SIP proxy loop detection ↗
- IETF RFC 7332: B2BUA loop and Max-Forwards behavior ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.