| Protocol | ims | Network | 5G and LTE |
|---|---|---|---|
| Spec | RFC 3261 / RFC 3515 / 3GPP TS 24.229 | Spec Section | SIP 202 Accepted response in deferred-action procedures |
| Direction | UE <-> IMS network | Message Type | SIP success response |
| Full message name | IMS SIP 202 Accepted |
|---|---|
| Protocol | IMS |
| Technology | 5G and LTE |
| Common deployment | VoNR and VoLTE |
| Direction | UE <-> IMS network |
| Interface | Gm with onward IMS routing |
| Signaling bearer / channel | IMS SIP signaling / Deferred-action success response |
| Typical trigger | The request starts later processing, such as REFER-related service behavior. |
| Main purpose | Confirms receipt and acceptance of a request whose final service result is not completed inside the same transaction. |
| Main specification | RFC 3261 / RFC 3515 / 3GPP TS 24.229, SIP 202 Accepted response in deferred-action procedures |
| Release added | See specification history |
| Procedures where used | IMS Transfer Handling, IMS Deferred Service Control |
202 Accepted means the request was accepted for further handling, but the full outcome will be reported later.
Confirms receipt and acceptance of a request whose final service result is not completed inside the same transaction.
202 means the request was accepted for later handling, not that the whole service action is already finished.
Previous message(s): IMS SIP REFER
Next message(s): IMS SIP NOTIFY
Security context: Uses the same protected IMS signaling path as the original request.
SIP/2.0 202 Accepted
Via:
From:
To:
Call-ID:
CSeq:
Content-Length: 0
This is SIP response syntax rather than ASN.1.
SIP/2.0 202 Accepted
Via: SIP/2.0/UDP ue.example.net;branch=z9hG4bK-ref1
From: <sip:alice@example.net>;tag=mo1
To: <sip:bob@example.net>;tag=term1
Call-ID: call-001@example.net
CSeq: 4 REFER
Content-Length: 0
| IE | Required | Description |
|---|---|---|
Status-Line | Yes | Shows the 202 Accepted success code. |
Call-ID | Yes | Correlates acceptance with the original transaction. |
Status-LineShows the 202 Accepted success 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.
Call-IDCorrelates acceptance with the original transaction.
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.
Likely cause: 202 only confirms acceptance for later processing, not full completion.
What to inspect: Check the later reporting branch, such as NOTIFY.
Next step: Follow the deferred service path instead of stopping at 202.
It means the request was accepted, but the final service outcome will appear in later signaling.
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.