Find the request that constrained the response
Capture one bounded failure and record the request method, Request-URI, Call-ID, CSeq, Event header where present, every Accept value, response source and timestamp. Determine whether Asterisk sent 406 on an inbound request or received it from an endpoint, proxy or service on an outbound leg. A back-to-back PBX can terminate one dialog and create another, so preserve each leg independently.
With authorized temporary tracing, Asterisk's PJSIP guide uses pjsip set logger on. Limit the capture to the affected exchange, then disable protocol logging and protect identities, message bodies, presence state and credentials. Do not infer the requester or responder from a telephone display alone.
Compare Accept with the response producer
List the types the request permits and the types the exact Asterisk application can generate in that context. RFC 3261 distinguishes an absent Accept header from an empty one; for SUBSCRIBE, RFC 6665 delegates the absent-header default to the event package. Preserve media-range parameters and preference values instead of comparing only the first token.
For OPTIONS or INVITE, establish whether the application expected to return a descriptive body. For SUBSCRIBE, establish the event package and the format required for subsequent NOTIFY messages. A format supported by one method or package does not establish support in another.
Inspect the loaded subscription and body-generator path
Asterisk documents res_pjsip_pubsub.so as the SUBSCRIBE/NOTIFY core, with event handlers and body generators supplied by additional modules. Its presence guide names res_pjsip_exten_state.so for presence and dialog events, res_pjsip_xpidf_body_generator.so for application/xpidf+xml and res_pjsip_dialog_info_body_generator.so for application/dialog-info+xml. Treat that list as a documented implementation boundary, not proof that the modules are loaded on this PBX.
Inspect the running module and subscription state using supported Asterisk CLI and management views for the deployed release. Compare it with the endpoint's documented Event and Accept behavior. In FreePBX, preserve module ownership and generated configuration; do not make an untracked edit to generated files to force a body type.
Keep adjacent failures distinct
If the receiver rejects the request body's MIME type or disposition, investigate 415. If it understands an SDP body but rejects session parameters, investigate 488. If a notifier does not support the Event value, RFC 6665 specifies 489 Bad Event. A 406 on SUBSCRIBE instead means the notifier cannot generate a NOTIFY body format permitted by the request's Accept header.
Do not change endpoint allow codec settings, trunk media preferences or RTP ports unless the trace establishes a separate session-media fault. Those controls do not install a presence body generator or change what a subscriber advertises for NOTIFY.
Correct the narrow owner and prove interpretation
When the subscriber advertises the wrong formats, correct that endpoint or application's Accept policy under its own documentation. When Asterisk lacks the required handler or body generator, confirm that the needed module is supported for the deployed version and event package before enabling it. If no safe common format exists, disable the unsupported subscription or feature instead of claiming success from a syntactic workaround.
Repeat the same request, confirm the intended responder no longer returns 406, inspect the response or NOTIFY Content-Type and verify the phone or application interprets the state correctly. Retain one bounded negative case for an unsupported format. No PBX, endpoint, subscription, event package, body generator, response entity, presence indication, availability or live transaction was tested for this guide.
core set verbose 4
core set debug 4
pjsip set logger on
# Reproduce one authorized transaction, then disable temporary logging.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: SIP event notification ↗
- IETF RFC 4475: unacceptable Accept test case ↗
- Asterisk presence-subscription module and body-generator guide ↗
- Asterisk PJSIP body-type publication guide ↗
- Asterisk PJSIP troubleshooting guide ↗
- Asterisk bounded debug-information collection ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.