Capture the 606 and the offer it rejected
Use a narrowly timed, authorized PJSIP trace and retain the INVITE, complete session description, 606 response, Warning fields, response body, Call-ID, CSeq, tags, top Via branch, response source and PJSIP channel. Correlate both legs when Asterisk receives one call and originates another; each leg can have a different offer, URI, Call-ID and final response.
RFC 3261 gives 606 two important properties: the user's agent was reached but cannot adequately support the described session, and the client knows no other endpoint will answer. A handset display or final dialplan result does not preserve either the exact mismatch or that global scope.
Locate the responder and preserve fork state
Determine whether Asterisk received 606 from a phone or provider, generated it locally, or translated another failure. Record every branch that existed when the response arrived and any resulting CANCEL and 487 messages. A 6xx response can stop proxy forking, while Asterisk dialplan fan-out or a provider's B2BUA may create independent calls with different handling.
Do not assume that one contact's codec or security policy justifies a global response. If another eligible endpoint could answer, preserve that evidence and investigate why 606 rather than the resource-local 488 was selected.
Inspect session constraints, not only codecs
Compare each offer with the loaded endpoint's allow list and the applicable incoming-offer, outgoing-offer, incoming-answer and outgoing-answer codec preferences. Asterisk's current advanced codec-negotiation documentation explains that an empty resolved topology can terminate a call, but its documented local examples use 488 or another local failure path rather than proving a received 606.
Also inspect media types, transports, address family, media-security requirements, RTP events, bandwidth and relevant SDP attributes. Keep 415 body-format failures and authentication or routing failures outside this branch unless their own wire evidence is present.
Keep the SIP response separate from cause 58
Asterisk maps SIP 488 and 606 to AST_CAUSE_BEARERCAPABILITY_NOTAVAIL, Q.850 cause 58. After Dial(), inspect HANGUPCAUSE_KEYS() and the technology-specific and Asterisk values for each called channel, but do not infer 606 from cause 58 alone. Parallel and sequential channels can have different responses, and a final aggregate variable can hide the decisive leg.
Preserve the wire response before using a cause-based announcement, failover or retry policy. A retry with the same offer does not establish negotiation and may repeat a globally scoped failure.
Treat a local 606 as an explicit policy decision
Current Asterisk documentation provides PJSIPHangup() to send a selected 400–699 response on an incoming PJSIP channel before another final response has been sent. Confirm the installed release, loaded application and exact executed priority before attributing a local 606 to it.
In FreePBX, inspect generated dialplan and the matched supported objects, but change routes and media settings through supported controls or documented extension points. Do not edit generated files or weaken SRTP and codec policy solely to replace the visible code.
Retest scope and media separately
Change one demonstrated session constraint and keep a rollback record. Retest the original offer, a documented compatible offer and another eligible endpoint when policy permits. Confirm the responder, code, Warning fields, selected media description and branch outcomes for each.
After setup succeeds, test answer, two-way audio, DTMF if required, hold or transfer involved in the incident, and normal release. Remove temporary PJSIP logging and redact credentials, identities and media addresses from shared traces. No PBX, endpoint, proxy, provider, codec, SDP, media path, dialplan, fork 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: 606 Not Acceptable, 488 and 6xx handling ↗
- Asterisk hangup-cause mappings ↗
- Asterisk hangup-cause inspection ↗
- Asterisk PJSIP advanced codec negotiation ↗
- Asterisk PJSIPHangup application ↗
- Asterisk PJSIP troubleshooting guide ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.