Read 415 as a request-body decision
RFC 3261 defines SIP 415 for a request whose message body format is not supported by the server for that requested method. The specific problem can be the body's Content-Type, Content-Encoding or Content-Language. It is not the HTTP status code despite sharing the number, and it is not a general statement that an RTP audio codec is unavailable.
Bind the response to the exact method, transaction and responder. An INVITE, MESSAGE, NOTIFY or another request can carry different body types in different contexts. A response on one method does not prove the same body is unsupported everywhere.
Use the response headers as scoped evidence
RFC 3261 requires the response to list acceptable formats through Accept, Accept-Encoding or Accept-Language according to the problem. Preserve those headers alongside the rejected request. The requesting user agent can retry with supported content, encodings and languages, but only when the method and application permit a safe equivalent body.
RFC 5621 adds an important boundary: support for a content type depends on context, including the method and disposition. A 415 can contain an Accept value also present in the rejected request when the receiver does not support that body type or disposition in this particular context.
Inspect required and optional body handling
Record Content-Disposition and its handling parameter for the top-level body and each multipart section. RFC 5621 states that an unknown required content or disposition is rejected with 415, while an unknown optional body can be ignored. The default handling value is required.
Do not remove an integrity, identity, session or application body solely to make the response disappear. The body can be required for security or correct feature behavior. Confirm the originating application, extension specification and intended fallback before changing its handling.
Keep 415 separate from 488
An INVITE with an unsupported or contextually invalid message-body type can receive 415. A receiver that understands the session-description body but rejects the proposed session parameters can instead use 488 Not Acceptable Here. The difference matters: changing codec allow lists does not repair an unknown MIME body, and changing Content-Type does not create compatible media parameters.
Use the Asterisk PJSIP 415 investigation to preserve both SIP legs and the body's exact bytes, headers and multipart structure before assigning the fault.
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 ↗
- IANA SIP response-code registry ↗
Examples require adaptation to your topology. No live PBX or hardware testing is claimed.