| Protocol | ims | Network | 5G and LTE |
|---|---|---|---|
| Spec | RFC 3261 / 3GPP TS 24.229 | Spec Section | SIP 415 Unsupported Media Type failure response |
| Direction | IMS network -> UE | Message Type | SIP request-failure response |
| Full message name | IMS SIP 415 Unsupported Media Type |
|---|---|
| Protocol | IMS |
| Technology | 5G and LTE |
| Common deployment | VoNR and VoLTE |
| Direction | IMS network -> UE |
| Interface | Gm with onward IMS routing |
| Signaling bearer / channel | IMS SIP signaling / Final request-failure response |
| Typical trigger | The request body uses an unsupported content type or body format. |
| Main purpose | Rejects the request because the body type or body encoding is not supported. |
| Main specification | RFC 3261 / 3GPP TS 24.229, SIP 415 Unsupported Media Type failure response |
| Release added | See specification history |
| Procedures where used | IMS Content Negotiation Failure |
415 Unsupported Media Type means the target cannot process the request body in the format that was sent.
Rejects the request because the body type or body encoding is not supported.
415 means the request body format was not supported.
Previous message(s): IMS SIP INVITE, IMS SIP MESSAGE, IMS SIP INFO
Next message(s): Corrected retry if applicable
Security context: Uses the same protected IMS signaling path as the original request.
SIP/2.0 415 Unsupported Media Type
Via:
From:
To:
Call-ID:
CSeq:
Accept: OPTIONAL
Content-Length: 0
This is SIP response syntax rather than ASN.1.
SIP/2.0 415 Unsupported Media Type
Via: SIP/2.0/UDP ue.example.net;branch=z9hG4bK-msg1
From: <sip:alice@example.net>;tag=msg1
To: <sip:bob@example.net>
Call-ID: msg-001@example.net
CSeq: 1 MESSAGE
Content-Length: 0
| IE | Required | Description |
|---|---|---|
Status-Line | Yes | Shows the 415 failure code. |
Accept | Optional | May indicate the content types that are supported. |
Status-LineShows the 415 failure code.
Presence: Required
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
AcceptMay indicate the content types that are supported.
Presence: Optional
In practice: In practice, compare this field with the original request and with any later release-dependent optional fields so you can see whether the network accepted the same service model the UE asked for.
Likely cause: The receiving side does not support the content type or body format used.
What to inspect: Check Content-Type, body structure, and any Accept hints in the response.
Next step: Compare the sent body format against the supported media types.
It means the receiving side could not process the format of the body that was sent.
Decode this message with the 3GPP Decoder, inspect the related message database, or open the matching call flow to see where this signaling step fits in the full procedure.