Home / Call Flows / 5G / VoNR Call Termination

VoNR Call Termination Procedure

call-flow VoNR | SIP BYE | Call Release | RTP Teardown

VoNR Call Termination is the release procedure that cleanly ends an active IMS voice session on 5G.

A healthy release is more than a user pressing End. It requires SIP dialog closure, media stop, and resource cleanup to line up cleanly.

Introduction

Once a VoNR call is established, ending it should be one of the simplest procedures in the trace. In practice, this is where stuck calls, ghost media, and post-call instability often appear.

The clean release ladder is usually straightforward: a side sends BYE, the far side returns 200 OK, media stops, and the network frees the voice-related state.

What Is VoNR Call Termination in Simple Terms?

What starts the procedure: A user or the network decides to end an active voice session.
What the UE and network want to achieve: Close the SIP dialog cleanly and free media and service resources.
What success looks like: BYE and 200 OK complete, media stops, and the session is fully released.
What failure means: The dialog, media, or post-call state stays partially active and creates user-visible problems.

Why this procedure matters

A clean termination is part of service quality. If release is unstable, the next call, the user experience, and even charging behavior can all be affected.

Quick Fact Sheet

Procedure name	VoNR Call Termination
Domain	5G voice session release over IMS
Main trigger	Either endpoint or the network decides to end an active voice call
Start state	A VoNR call is already established with active SIP dialog and media path
End state	The SIP dialog is released, media stops, and voice resources are freed
Main nodes	UE-A, UE-B, IMS core, UPF, gNB
Main protocols	SIP BYE, 200 OK, RTP teardown, QoS release
Main success outcome	The dialog closes cleanly and no stale media or session state remains
Main failure outcome	The call appears ended to one side but stale dialog, media, or resource state remains
Most important messages	BYE, 200 OK, media stop, QoS cleanup
Main specs	TS 24.229, TS 23.228, TS 23.501

Preconditions

A VoNR call is already active with a valid SIP dialog.
The endpoints and IMS path still share the same dialog context.
The network can carry the final release signaling cleanly.
Media and service resources can be released after the dialog closes.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
Terminating UE	Starts the release by sending BYE or reacts to a release initiated by the far end or network.
IMS core	Routes the release transaction and cleans up dialog state.
Remote UE	Acknowledges release with 200 OK and stops the active media session.
UPF and radio side	Stop carrying the dedicated voice media and release related service treatment.

Interfaces used

Interface	Path	Role
IMS SIP path	UE <-> IMS core <-> remote UE	Carries BYE and 200 OK for the call-release transaction.
User-plane RTP path	UE <-> UPF <-> remote UE	Carries media until the release is completed and the stream stops.
NR-Uu and service QoS path	UE <-> gNB / core	Carry any final voice service packets until the release is complete.

End-to-End Call Flow

UE-A              IMS core              UE-B
|-- BYE ----------->|--------------------->|
|<-- 200 OK --------|<---------------------|
|=========== RTP stops and resources release ===========|

Major Phases

Phase	What happens
1. Release trigger	A user action, remote release, or network condition decides the active call must end.
2. SIP release transaction	BYE travels through IMS and reaches the far side.
3. Release acknowledgement	The far side returns 200 OK and confirms dialog closure.
4. Media and resource cleanup	RTP stops and any voice-specific treatment is released.

Step-by-Step Breakdown

One side decides to end the active VoNR call

Sender -> receiver: UE or network release trigger

Message(s): User ends call, remote side ends call, or service failure triggers release

Purpose: Start the controlled teardown of the voice session.

State or context change: The call moves from active media state into release handling.

Note: Always identify which side triggered the release first. It changes how you read the trace and user complaint.

The releasing side sends BYE through IMS

Sender -> receiver: UE-A -> IMS -> UE-B

Message(s): BYE

Purpose: Request that the current SIP dialog be terminated cleanly.

State or context change: IMS treats the dialog as a release-in-progress instead of an active call.

Note: A visible BYE is the cleanest sign this is a normal release, not an abrupt radio or media collapse.

The far side acknowledges the release

Sender -> receiver: UE-B -> IMS -> UE-A

Message(s): 200 OK

Purpose: Confirm that the release transaction completed correctly.

State or context change: The dialog is now formally closed at the SIP layer.

Note: If 200 OK never returns, one side may think the call ended while the other still holds session state.

Media and policy cleanup complete

Sender -> receiver: Both UEs and network service path

Message(s): RTP stop and resource release

Purpose: Stop voice packets and free the resources used for the call.

State or context change: The session leaves active voice state and returns to post-call service readiness.

Note: Resource cleanup matters because stale media or QoS state creates confusing ghost-call symptoms.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
BYE	SIP	Releasing side -> remote side	Starts controlled dialog release.	Check who sent it first and whether the route path matches the active dialog.
200 OK	SIP	Remote side -> releasing side	Acknowledges successful dialog teardown.	A missing 200 OK is a key sign of incomplete release.
RTP stop	Media	Both directions	Marks the end of the active voice path.	Confirm that media stops immediately after the SIP release completes.
QoS or policy cleanup	Service control	Network internal	Releases voice-specific treatment tied to the session.	Useful when users report ghost media or stale resource behavior after hang-up.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
Release initiator	The side that decided to end the call.	Before BYE	Helps explain whether the complaint is local release, remote release, or network-driven termination.	Wrong initiator assumptions lead to wrong troubleshooting direction.
Dialog identifiers	Call-ID and tags for the active session.	BYE and 200 OK	Needed to correlate the release to the exact active call.	Mismatched dialog state causes failed or ignored release.
Release timing	How quickly 200 OK follows BYE and media stops.	During release transaction	Shows whether teardown is clean or delayed.	Slow release often points to IMS routing or endpoint behavior issues.
Media stop behavior	Whether RTP really stops after dialog release.	Post-release stage	Separates signaling success from media cleanup success.	One-way lingering media usually means incomplete cleanup.
Post-call readiness	Whether the UE returns to stable idle or voice-ready service state.	After release	Important for repeated-call testing and next-call reliability.	Bad cleanup causes later call failures that appear unrelated.

Success Criteria

The release initiator is clear and the correct dialog is targeted.
BYE reaches the far side and 200 OK returns quickly.
Media stops immediately after the dialog closes.
The session leaves no stale signaling or voice-resource state behind.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
BYE is sent but the call does not end cleanly	The release transaction or endpoint state is incomplete.	BYE routing, 200 OK, and dialog correlation.	BYE, 200 OK	IMS SIP path	This is the classic stuck-release case.
Media continues after hang-up	Media cleanup or endpoint teardown failed after signaling release.	RTP stop timing and resource release.	Post-BYE media	User plane	Treat this as cleanup failure, not initial call-setup failure.
Release is delayed	IMS routing, endpoint processing, or interworking delayed the 200 OK.	Release timing and route path.	BYE, 200 OK	IMS control path	Timing patterns often reveal the real bottleneck.
Next call behaves badly after a previous release	The old session was not fully cleaned up.	Post-call readiness and stale dialog or media state.	End of previous release	Cross-layer cleanup	Many repeated-call bugs are really previous-call cleanup bugs.

What to Check in Logs and Traces

Identify who initiated the release before anything else.
Correlate BYE and 200 OK with the exact active dialog identifiers.
Check whether media stop timing matches signaling completion.
If repeated-call problems appear, inspect the previous release cleanup carefully.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is VoNR Call Termination?

It is the controlled teardown of an active 5G voice session, usually using SIP BYE followed by 200 OK.

Can either side terminate the call?

Yes. The originating side, terminating side, or even the network under some failure conditions can trigger release.

What proves success?

The BYE transaction completes, 200 OK returns, and media stops without stale session state remaining.

What should I inspect first?

Start with who initiated the release, then verify BYE and 200 OK, and finally confirm media and resource cleanup.

Why can users still hear audio after hang-up?

Because the SIP release may have completed while RTP or related media cleanup lagged or failed.