Prove who generated 482
Record the timestamp and timezone, method, calling and called identities, direction and visible result. Use an authorized, narrowly bounded PJSIP protocol capture and preserve the request that received 482 plus the response. Disable protocol logging after the reproduction and protect credentials, addresses, telephone numbers and SDP.
Identify the response source, destination, request URI, Call-ID, CSeq, top Via branch, Route values and Max-Forwards. Do not assume that Asterisk emitted the code because its phone or console displays it. Asterisk can terminate one SIP leg and create another, so the endpoint-facing and provider-facing exchanges may have different identifiers and different responders.
Follow decisions across the B2BUA boundary
Correlate the Asterisk channels and timestamps, then follow the inbound request into the exact outbound PJSIP request. RFC 7332 requires B2BUAs to carry and decrement Max-Forwards for applicable new requests, but Via-based proxy detection does not automatically cross a B2BUA that creates a new leg. Preserve both exchanges instead of searching for one end-to-end branch.
Repeated packets with the same branch can be transaction retransmissions. Evidence of a routing loop is a sequence of new decisions or legs that returns to an earlier owner with equivalent routing inputs. A falling Max-Forwards count supports the path, while a 482 shows that a server's loop algorithm decided the request repeated.
Inspect the running endpoint and dialplan path
Use the loaded PJSIP endpoint, AOR, contacts and identify rules rather than relying on saved configuration alone. Match the incoming endpoint and context to the exact extension and priority, then record each Goto, GotoIf, Gosub, include, switch, trunk target or explicit SIP URI that can transfer ownership. Asterisk exposes the running CONTEXT, EXTEN, PRIORITY and channel identifiers for correlation.
Asterisk processes exact extensions, patterns, includes and switches in a documented search order, with includes evaluated depth first. That ordering can select a different owner from the one suggested by a visual layout. Reconstruct the actual path for the failing identity and compare one nearby working destination before changing it.
Trace external ownership and failover
Compare the outbound request URI, Route set, resolved next hop and provider or SBC response with the PBX decision. Check whether an unmatched destination, forwarded DID, alternate gateway or failover route points back to the same public identity or ingress system. Ask an external owner for its decision and trace using the same timestamp and redacted identifiers.
Do not treat DNS rotation or a different IP address as proof of an independent route; multiple addresses can lead to the same routing policy. Likewise, do not assume a second trunk is safe failover if its number ownership or default route returns traffic to the first path.
Correct one routing boundary
Change the demonstrated number ownership, domain, context, pattern, trunk selection, request target or fallback destination that recreates the earlier decision. On FreePBX, use supported route, trunk and custom-context controls rather than editing generated dialplan. Export the current configuration and retain a rollback target before applying the change.
Do not disable loop detection, remove Via evidence, raise Max-Forwards or broaden an allow route to make 482 disappear. Those actions can turn an early rejection into 483 exhaustion or amplify traffic. Keep authentication, codecs, NAT and RTP outside the change unless separate evidence shows they are involved.
Retest successful and bounded failure paths
Repeat the original method and destination and confirm that each routing owner is visited only as intended. For a call, verify answer, two-way media, DTMF where required and normal release separately; absence of 482 proves neither media nor service quality. Test an authorized control destination, an unmatched destination and each approved failover branch.
The unmatched case must stop once with the designed rejection or treatment, not revisit the same owners until a later loop or hop-limit response. Remove temporary logging and retain the smallest redacted evidence set needed for review. No PBX, endpoint, proxy, provider, route, failover, media path or live request was tested 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: proxy loop detection ↗
- IETF RFC 5393: strengthened SIP proxy loop detection ↗
- IETF RFC 7332: B2BUA loop and Max-Forwards behavior ↗
- Asterisk PJSIP troubleshooting guide ↗
- Asterisk dialplan contexts, extensions and priorities ↗
- Asterisk CONTEXT, EXTEN and PRIORITY variables ↗
- Asterisk logging configuration ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.