Prove which leg received 483
Record the exact timestamp and timezone, method, calling and called identities, affected direction and the result heard or displayed. Use an authorized, narrowly scoped pjsip set logger on reproduction and preserve the request that received 483 plus the response. Disable protocol logging when the capture ends and protect credentials, telephone numbers, IP addresses and SDP.
Identify the response source, destination, Call-ID, CSeq and top Via branch. Asterisk can terminate one SIP dialog and create another, so the phone-facing and provider-facing legs may have different identifiers. A handset display or DIALSTATUS does not prove whether Asterisk generated 483 locally or received it from another server.
Follow Max-Forwards across new hops, not retransmissions
For each matching forwarded request, record Max-Forwards, request URI, Route headers, source, destination and Via branch. RFC 3261 requires forwarding servers to decrement the remaining count; a server receiving zero returns 483. Look for a sequence that falls toward zero and eventually revisits an earlier routing owner.
Do not count identical UDP retransmissions as routing hops. The same method, CSeq and branch repeated while awaiting a response is transaction behavior, whereas a newly forwarded request normally carries evidence of another transaction or dialog leg. Correlate Asterisk's channel and linked identifiers without asserting end-to-end identity where Asterisk has created a new leg.
Reconstruct the Asterisk routing decision
Match the incoming endpoint and context to the exact dialplan extension and priority that ran, then identify the selected PJSIP endpoint, AOR contact or explicit SIP URI. Inspect what the running system loaded rather than relying on a saved file. Compare a nearby working destination while changing no credentials, codecs, NAT or media settings.
On a FreePBX-managed system, follow the inbound route, outbound route, trunk sequence and any supported custom-context handoff that owned the call. Check whether a catch-all route sends an unmatched number to a provider that returns it to the same DID or PBX. Do not edit generated dialplan files; make a supported configuration change only after the loop boundary is demonstrated.
Separate the SIP header from Asterisk call forwarding
Current Asterisk documentation lists the PJSIP global max_forwards option with a default of 70 for SIP requests. That value is a loop limit, not a substitute for correct routing. Increasing it can extend a loop and increase load without changing ownership. Preserve the configured value unless the system owner has an independently justified requirement.
Asterisk also exposes CHANNEL(max_forwards) as the allowed number of phone redirects and local-channel forwards, and its documentation explicitly says this has no relation to the SIP Max-Forwards header. Do not change that channel item to repair a SIP 483. PJSIP_HEADER() can read a named header from an inbound PJSIP channel, but its result is channel-specific; a protocol trace remains the clearest evidence across both legs.
Correct one route owner and preserve bounded failure
Correct the exact number ownership, domain, request URI, Route set, trunk target, inbound mapping, outbound pattern or failover destination that returned the request to an earlier owner. If a provider controls one side, escalate with the redacted transaction sequence, timestamps, account or trunk identifier, responder address and falling Max-Forwards values rather than only the final code.
Avoid disabling loop limits, adding a broad allow route or forcing every unmatched destination to another trunk. Those actions can enlarge the failure domain, enable toll misuse or turn one loop into several. Apply one approved change and confirm the running dialplan and endpoint state before retesting.
Retest the original and negative paths
Repeat the original method and destination and confirm that signaling reaches the intended owner without revisiting a prior hop. For a call, verify answer, two-way media, DTMF where required and normal release independently; removal of 483 does not prove media. Test another authorized destination, an unmatched destination, inbound and outbound directions where relevant, and each intended failover branch.
The unmatched case should stop once with the designed rejection or treatment, not traverse the same owners until Max-Forwards is exhausted. Restore temporary logging and access controls after the test. No PBX, proxy, provider, FreePBX route, custom dialplan, Max-Forwards setting, 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: Max-Forwards and 483 Too Many Hops ↗
- Asterisk PJSIP troubleshooting guide ↗
- Asterisk res_pjsip global max_forwards ↗
- Asterisk CHANNEL max_forwards distinction ↗
- Asterisk PJSIP_HEADER function ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.