IMS SIP BYE | IMS Message

Message Fact Sheet

Protocol	ims	Network	5G and LTE
Spec	RFC 3261 / 3GPP TS 24.229	Spec Section	SIP BYE method and dialog termination
Direction	UE <-> IMS network	Message Type	SIP request method

Full message name	IMS SIP BYE
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 / In-dialog SIP termination request
Typical trigger	One side ends the call or service session and needs to release the dialog.
Main purpose	Ends the active IMS session and tells the far side that the dialog should be released.
Main specification	RFC 3261 / 3GPP TS 24.229, SIP BYE method and dialog termination
Release added	See specification history
Procedures where used	IMS Call Release, VoNR Call Release, VoLTE Call Release

What is IMS SIP BYE in simple terms?

BYE is the SIP request that terminates an established dialog.

Ends the active IMS session and tells the far side that the dialog should be released.

Why this message matters

BYE is the SIP request that ends the active IMS dialog.

Where this message appears in the call flow

IMS call release

Call flow position: Main SIP release request inside the active dialog.

Typical state: The session is already established and is now being terminated.

Preconditions:

The INVITE dialog is active.

Next likely message: 200 OK

Caller ends the session

IMS SIP BYE flow showing the originating side ending an established session through the IMS core — When the caller ends the session, BYE is the request that tears down the active IMS dialog.

Called side ends the session

IMS SIP BYE flow showing the terminating side ending an established session through the IMS core — When the called side releases the session, BYE is the dialog-ending request that clears the active call path.

Call flow position

Previous message(s): Established INVITE dialog

Next message(s): 200 OK

Message direction and transport

Sender and receiver: UE <-> IMS network

Interface: Gm (UE <-> P-CSCF) with onward IMS routing

Domain: IMS dialog release

Signaling bearer: IMS SIP signaling

Logical channel: In-dialog SIP termination request

Transport / encapsulation: SIP over UDP, TCP, or TLS

Security context: Sent inside an existing dialog after setup has already completed.

Message Structure Overview

BYE is an in-dialog release request, so dialog identity is the first thing to verify.

ASN.1 Message Syntax for IMS SIP BYE

BYE sip:user@example.net SIP/2.0
Via:
From:
To:
Call-ID:
CSeq:
Route:                             OPTIONAL
Content-Length:

How to read this message syntax

BYE is a SIP dialog-termination request, not an ASN.1-defined signaling message.

IMS SIP BYE - Example Dump

BYE sip:bob@example.net SIP/2.0
Via: SIP/2.0/UDP ue.example.net;branch=z9hG4bK-bye1
From: <sip:alice@example.net>;tag=mo1
To: <sip:bob@example.net>;tag=term1
Call-ID: call-001@example.net
CSeq: 2 BYE
Content-Length: 0

How to read this dump

The important question is whether BYE matches the active dialog identifiers and route set.

Important Information Elements

IE	Required	Description
`Request-URI`	Yes	Targets the remote dialog endpoint.
`Call-ID`	Yes	Identifies the dialog being terminated.
`CSeq`	Yes	Orders the BYE inside the dialog.
`Route`	Optional	Preserves the dialog route set.

Detailed field explanation

`Request-URI`

Targets the remote dialog endpoint.

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-ID`

Identifies the dialog being terminated.

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.

`CSeq`

Orders the BYE inside the dialog.

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.

`Route`

Preserves the dialog route set.

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.

What to check in logs and traces

Check that BYE belongs to the expected dialog.
Inspect Call-ID, tags, and CSeq.
Look for the matching 200 OK.

Common Issues and Troubleshooting

One side releases the call but the far side keeps the dialog alive.

Likely cause: BYE may be missing, misrouted, or not correlated to the right dialog.

What to inspect: Check dialog tags, route set, and whether the far side returned 200 OK.

Next step: Follow the BYE transaction end to end before blaming media or bearer cleanup.

FAQ

What does BYE do in IMS?

It ends an established SIP dialog and starts the release transaction.

Related Procedures

Related Tools

Use This Reference in Practice

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.