Locate the response family
- 1xx ProvisionalRequest is progressing
- 2xx SuccessRequest succeeded
- 3xx RedirectionAnother destination
- 4xx Request failureInterpret this request
- 5xx Server failureServer could not fulfil
- 6xx Global failureFailure across destinations606 belongs here
Read the status with its request method and call leg. For example, 200 after REGISTER confirms a binding; it does not prove an INVITE succeeded.
Require both a session mismatch and global scope
RFC 3261 defines 606 after the user's agent has been contacted successfully but the described session cannot be supported adequately. The unacceptable aspect can involve media, bandwidth, addressing style or another session-description parameter. The response also carries global 6xx scope: it is returned only when the client knows that no other endpoint will answer the request.
Do not translate the number into a universal codec error. Preserve the exact offer, responder and fork state. A provider, proxy or back-to-back user agent can also translate a downstream result before the calling endpoint sees it.
Use 488 for a resource-local mismatch
488 Not Acceptable Here has the same session-description meaning but applies only to the resource addressed by the Request-URI; the request may succeed elsewhere. A 606 therefore needs evidence for both the mismatch and the conclusion that another endpoint will not answer.
415 Unsupported Media Type is different again: it rejects the request body's format, encoding, language or handling context. A understood SDP body with unacceptable session parameters is not the same problem as an unsupported MIME body.
Preserve the response's diagnostic material
A 606 may include Warning header fields that describe why the session cannot be supported. It may also carry a body describing media capabilities, formatted according to the INVITE's Accept header or as application/sdp when Accept is absent. Save those fields and the complete offer before changing policy.
Warnings are scoped clues rather than proof of a single root cause. Compare media types, formats, transports, addresses, bandwidth and relevant attributes on the rejecting leg, then correlate the decision with the responder's documented policy.
Do not reconstruct 606 from Asterisk cause 58
Asterisk maps both SIP 488 and 606 to AST_CAUSE_BEARERCAPABILITY_NOTAVAIL, Q.850 cause 58. That translation preserves a broad capability failure but loses the original SIP code, responder and global-versus-local scope. A CDR, announcement or cause-based dialplan branch showing cause 58 therefore cannot establish that a PJSIP leg received 606.
Retain the wire response and per-channel technology cause. The focused Asterisk investigation separates a received 606, a locally generated response, another media failure and the coarser mapped cause.
Change one demonstrated constraint
Correct only the mismatch supported by the evidence: for example, an invalid address family, unavailable media type, incompatible media transport, unsupported format or explicit bandwidth policy. Do not enable every codec, disable media security or broaden routing merely to suppress the response.
Retest the original offer, a documented compatible offer and a route with another eligible endpoint where policy permits. Confirm the exact response and selected parameters, then verify answer, two-way media and release separately.
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 Warning headers ↗
- Asterisk hangup-cause mappings ↗
- Asterisk PJSIP advanced codec negotiation ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.