Read 406 as response-body negotiation
RFC 3261 defines SIP 406 when the resource identified by a request can generate only response entities whose content characteristics are unacceptable under the request's Accept header. Preserve the exact method, Request-URI, transaction, responder and Accept value. The same code on OPTIONS, INVITE or SUBSCRIBE can belong to different applications and expected response bodies.
The request's Accept header describes body formats acceptable in the response. It is not the request body's Content-Type and it is not an RTP codec allow list. A SIP reason phrase or user-facing codec message does not override the wire definition.
Distinguish absent, empty and incompatible Accept
RFC 3261 gives a general default of application/sdp when Accept is absent and states that an empty Accept header means no formats are acceptable. A present list can contain media ranges and preferences; compare it with what the specific resource and method can actually generate instead of adding an arbitrary type.
Method or extension rules can refine the baseline. RFC 6665 says that a SUBSCRIBE Accept header names body formats allowed in later NOTIFY requests, while the event package defines the default when Accept is absent. Therefore removing the header is not universally equivalent to advertising every format.
Separate 406 from 415, 488 and 489
SIP 415 rejects the format, encoding or language of the request body. SIP 488 says the proposed session is not acceptable at the addressed resource. SIP 406 instead concerns a response body the server would need to generate under the request's Accept constraints. Changing endpoint audio codecs does not repair a presence subscriber that excludes every body format the notifier can produce.
For SIP events, RFC 6665 preserves another boundary: an unsupported Event value is 489 Bad Event, while a known event whose notifier cannot generate any accepted NOTIFY body format uses 406. Capture both Event and Accept before assigning the failure to the event package or its body generator.
Retry only with an application-valid format
A retry can broaden or correct Accept only when the user agent and application can process the resulting response body. Do not advertise application/sdp, dialog information, PIDF or another MIME type merely to suppress 406. That can move the error from negotiation to misinterpretation.
Use the Asterisk PJSIP 406 investigation to compare the requesting user agent's Accept values with the exact Asterisk application, loaded event handler and available body generator. Verify the resulting response or NOTIFY content and application outcome, not only the disappearance of the status code.
Sources & applicability
Primary references for the technical details above. Operational examples and planning checklists are VoIP.info editorial guidance.
- IETF RFC 3261: Accept and SIP 406 ↗
- IETF RFC 6665: SUBSCRIBE Accept and 406 ↗
- IETF RFC 4475: unacceptable Accept test case ↗
- IANA SIP response-code registry ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.