Identify the responder, method and rejected transaction
Capture one bounded failure and preserve the request method, request URI, Call-ID, CSeq, response source and timestamp. Determine whether Asterisk sent 415 on an inbound request or received it from a phone, SBC or provider on an outbound leg. In a back-to-back call, notification or messaging workflow, those are different applications and ownership paths.
Do not begin with a codec change. RFC 3261 defines 415 around the request message body's format for the requested method. A SIP response reason phrase, Asterisk log summary or user-facing failure message does not identify which body or body part was unsupported.
Preserve the complete body description and bytes
With authorized temporary tracing, retain Content-Type and its parameters, Content-Disposition and handling, Content-Encoding, Content-Language, Content-Length and every multipart boundary and per-part header. Compare the declared types with the captured bytes; a malformed boundary, missing required part or mismatched length can present differently from a correctly formed but unsupported body.
Asterisk's PJSIP troubleshooting guide recommends pjsip set logger on after increasing bounded debug and verbosity. Limit the reproduction to the affected transaction, then disable protocol logging and protect credentials, phone numbers, message content and session descriptions in the trace.
Read Accept headers without overgeneralizing
Preserve Accept, Accept-Encoding and Accept-Language from the 415 response. RFC 3261 uses these to report understood formats, encodings or languages. Compare them with the rejected request and the exact application owner; do not blindly resend a body merely because its type appears in Accept.
RFC 5621 explains that a content type can be accepted in one method and disposition context but rejected in another. A user agent might understand application/sdp as a session body for INVITE yet reject it as rendered content in MESSAGE. Multipart wrappers and disposition handling can therefore be the deciding layer even when every individual MIME type looks familiar.
Separate session-body support from session parameters
If the rejected request carries application/sdp, first prove whether the receiver rejected the SDP body type or understood the body and rejected its session proposal. The latter belongs to offer-answer and commonly leads to 488, not a generic 415 conclusion. Preserve any subsequent or parallel response rather than translating both into a codec error.
For MESSAGE, NOTIFY, PUBLISH or extension-specific requests, identify the Asterisk module, dialplan application or external application expected to consume that content in this method. An endpoint's allow codec list does not establish support for message bodies, event-package payloads or multipart disposition contexts.
Correct only the demonstrated producer or consumer
When the sender generated the wrong Content-Type, encoding, language, multipart structure or required disposition, correct that producer under its own documentation. When the receiver lacks the required handler or application, either enable a supported implementation with an explicit security review or stop sending the unsupported feature. Do not relabel arbitrary bytes as an accepted MIME type or mark a security-critical body optional.
In FreePBX, keep custom message-body and endpoint changes out of generated files. Use supported module or application ownership and preserve rollback. An automatic retry must carry content that remains semantically valid for the method; stripping a required session, identity or event body can make a superficially accepted request incorrect.
Prove the narrow repair and a negative case
Repeat the same method and intended body, confirm that the same responder accepts it, and verify the complete application outcome rather than stopping at the absence of 415. For a call, confirm negotiated media and hangup; for a message or event, confirm delivery, interpretation and authorization. Retain one unsupported or unauthorized body as a controlled negative test so acceptance has not become unbounded.
Remove temporary PJSIP logging and redact retained evidence. No PBX, endpoint, provider, request body, MIME handler, multipart parser, message application, codec, protected-content path, availability or live call 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: content processing and SIP 415 ↗
- IETF RFC 5621: SIP message-body handling ↗
- Asterisk PJSIP troubleshooting guide ↗
- Asterisk bounded debug-information collection ↗
- Asterisk res_pjsip configuration reference ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.