| Protocol | ims | Network | 5G and LTE |
|---|---|---|---|
| Spec | RFC 3261 / 3GPP TS 24.229 | Spec Section | SIP 406 Not Acceptable failure response |
| Direction | IMS network -> UE | Message Type | SIP request-failure response |
| Full message name | IMS SIP 406 Not Acceptable |
|---|---|
| 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 | Accept, feature, or content constraints cannot be met by the target. |
| Main purpose | Rejects the request when the target cannot match the requested acceptability constraints. |
| Main specification | RFC 3261 / 3GPP TS 24.229, SIP 406 Not Acceptable failure response |
| Release added | See specification history |
| Procedures where used | IMS Capability Negotiation Failure |
406 Not Acceptable means the request was understood, but the target cannot satisfy the acceptable formats or features indicated.
Rejects the request when the target cannot match the requested acceptability constraints.
406 means the requested acceptable format or feature set could not be satisfied.
Previous message(s): IMS SIP OPTIONS, IMS SIP INVITE
Next message(s): Procedure stop or reformulated retry
Security context: Uses the same protected IMS signaling path as the original request.
SIP/2.0 406 Not Acceptable
Via:
From:
To:
Call-ID:
CSeq:
Content-Length: 0
This is SIP response syntax rather than ASN.1.
SIP/2.0 406 Not Acceptable
Via: SIP/2.0/UDP ue.example.net;branch=z9hG4bK-opt1
From: <sip:alice@example.net>;tag=opt1
To: <sip:service@example.net>;tag=srv1
Call-ID: opt-001@example.net
CSeq: 1 OPTIONS
Content-Length: 0
| IE | Required | Description |
|---|---|---|
Status-Line | Yes | Shows the 406 failure code. |
Accept | Optional | May be relevant to why the requested content was unacceptable. |
Status-LineShows the 406 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 be relevant to why the requested content was unacceptable.
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 far side cannot satisfy the acceptability constraints in the request.
What to inspect: Check Accept, feature tags, and any content negotiation details.
Next step: Compare the request constraints against what the target actually supports.
It means the target understood the request but could not satisfy the requested acceptable formats or features.
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.