| Protocol | ims | Network | 5G and LTE |
|---|---|---|---|
| Spec | RFC 3261 / 3GPP TS 24.229 | Spec Section | SIP CANCEL method and INVITE cancellation |
| Direction | UE <-> IMS network | Message Type | SIP request method |
| Full message name | IMS SIP CANCEL |
|---|---|
| Protocol | IMS |
| Technology | 5G and LTE |
| Common deployment | VoNR and VoLTE |
| Direction | UE <-> IMS network |
| Interface | Gm (UE <-> P-CSCF) with onward IMS routing |
| Signaling bearer / channel | IMS SIP signaling / Pre-final-response INVITE cancellation |
| Typical trigger | The caller stops the call attempt or the originating side needs to withdraw the pending session before a 2xx final response arrives. |
| Main purpose | Lets the sender withdraw a session setup attempt while the INVITE is still unresolved. |
| Main specification | RFC 3261 / 3GPP TS 24.229, SIP CANCEL method and INVITE cancellation |
| Release added | See specification history |
| Procedures where used | IMS Session Cancellation, IMS Mobile Originated Call, VoNR Mobile Originated Call, VoLTE Mobile Originated Call |
CANCEL is the SIP request that stops a pending INVITE transaction before final acceptance.
Lets the sender withdraw a session setup attempt while the INVITE is still unresolved.
CANCEL stops a pending INVITE before the session is finally accepted.
Call flow position: Abort step while session setup is still pending.
Typical state: The INVITE exists but has not completed successfully.
Preconditions:
Next likely message: 200 OK to CANCEL and 487 Request Terminated
Previous message(s): Pending INVITE
Next message(s): 200 OK to CANCEL, 487 Request Terminated
Security context: Sent while the INVITE branch is still active but not yet finally accepted.
CANCEL sip:user@example.net SIP/2.0
Via:
From:
To:
Call-ID:
CSeq:
Route: OPTIONAL
Content-Length:
CANCEL is a SIP request used to stop an unresolved INVITE transaction.
CANCEL sip:bob@example.net SIP/2.0
Via: SIP/2.0/UDP ue.example.net;branch=z9hG4bK-can1
From: <sip:alice@example.net>;tag=mo1
To: <sip:bob@example.net>
Call-ID: call-001@example.net
CSeq: 1 CANCEL
Content-Length: 0
| IE | Required | Description |
|---|---|---|
Request-URI | Yes | Matches the pending INVITE target. |
Call-ID | Yes | Identifies the INVITE transaction being cancelled. |
CSeq | Yes | Uses the INVITE sequence number with the CANCEL method. |
Request-URIMatches the pending INVITE target.
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-IDIdentifies the INVITE transaction being cancelled.
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.
CSeqUses the INVITE sequence number with the CANCEL method.
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: CANCEL may not match the active INVITE transaction or may arrive too late.
What to inspect: Compare branch, Call-ID, and sequence context against the pending INVITE.
Next step: Read the follow-up 487 handling on the original INVITE branch.
It withdraws a pending INVITE before the session setup reaches final success.
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.