| Protocol | ims | Network | 5G and LTE |
|---|---|---|---|
| Spec | RFC 3261 / 3GPP TS 24.229 | Spec Section | SIP 182 Queued provisional response |
| Direction | IMS network -> UE | Message Type | SIP provisional response |
| Full message name | IMS SIP 182 Queued |
|---|---|
| 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 / Provisional session-progress response |
| Typical trigger | The far side or service logic accepts the request for later handling but cannot process it immediately. |
| Main purpose | Tells the sender that the session attempt is not rejected yet, but service handling is delayed. |
| Main specification | RFC 3261 / 3GPP TS 24.229, SIP 182 Queued provisional response |
| Release added | See specification history |
| Procedures where used | IMS Session Setup |
182 Queued shows that the request is waiting in a queue instead of progressing immediately.
Tells the sender that the session attempt is not rejected yet, but service handling is delayed.
182 means the request is waiting in a queue instead of moving forward right away.
Previous message(s): IMS SIP INVITE
Next message(s): 180 Ringing, 183 Session Progress, 200 OK
Security context: Uses the same protected IMS signaling path as the request it answers.
SIP/2.0 182 Queued
Via:
From:
To:
Call-ID:
CSeq:
Content-Length: 0
This is SIP response syntax rather than ASN.1.
SIP/2.0 182 Queued
Via: SIP/2.0/UDP ue.example.net;branch=z9hG4bK-inv1
From: <sip:alice@example.net>;tag=mo1
To: <sip:bob@example.net>;tag=term1
Call-ID: call-001@example.net
CSeq: 1 INVITE
Content-Length: 0
| IE | Required | Description |
|---|---|---|
Status-Line | Yes | Shows the 182 response code. |
Call-ID | Yes | Correlates the queued indication with the request. |
Status-LineShows the 182 response 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 the queued indication with the request.
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: The transaction is being held for later processing instead of advancing immediately.
What to inspect: Check whether 182 is followed by alerting or final answer after a service delay.
Next step: Correlate it with service logic or queueing behavior on the far side.
It means the request is accepted for later handling but is not being processed immediately.
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.