Home / Call Flows / 5G / VoNR Call Hold / Resume

VoNR Call Hold / Resume Procedure

call-flow VoNR | Hold | Resume | SIP re-INVITE | SDP

VoNR Call Hold / Resume is an IMS session-modification procedure used on an already established 5G voice call.

The dialog stays alive. What changes is the media direction and user-plane behavior, usually through a new SDP offer and answer exchange.

Introduction

This procedure is best understood as a controlled in-dialog update rather than as a fresh call setup.

Because of that, the most important checks are usually the new SDP attributes and the real RTP behavior after signaling, not only the SIP status line.

What Is VoNR Call Hold / Resume in Simple Terms?

What starts the procedure: A user presses Hold or Resume during an active VoNR call.
What the UE and network want to achieve: Modify media behavior while keeping the same active call dialog.
What success looks like: The call stays established and media pauses or resumes exactly as intended.
What failure means: The signaling or media state changes incompletely, leaving wrong audio behavior.

Why this procedure matters

Hold and resume problems are highly visible to users and are often misdiagnosed as generic call drops even though the dialog itself never actually failed.

Quick Fact Sheet

Procedure name	VoNR Call Hold / Resume
Domain	IMS in-dialog voice session modification over 5G
Main trigger	A user places the call on hold or resumes media on an existing VoNR call
Start state	A VoNR call is already established and media is active
End state	The dialog stays active while media direction changes to hold or back to normal flow
Main nodes	Holding UE, remote UE, P-CSCF, S-CSCF, optional TAS / MRF
Main protocols	re-INVITE or UPDATE, SDP offer and answer, RTP media state change
Main success outcome	The call remains established and media state changes exactly as requested
Main failure outcome	Hold or resume signaling completes incorrectly, leaving wrong media behavior or failed service state
Most important messages	re-INVITE, 200 OK, ACK, SDP direction attributes
Main specs	TS 24.610, TS 24.628, TS 24.229, TS 23.228

Preconditions

A VoNR call is already established and stable.
Both sides still share the same active SIP dialog.
The IMS path can carry in-dialog updates cleanly.
The user-plane path can enforce the negotiated media-state change.

Nodes and Interfaces

Nodes involved

Node	Role in this procedure
Holding or resuming UE	Starts the in-dialog session modification that changes the media direction.
IMS core	Routes the in-dialog transaction and keeps the existing dialog consistent.
Remote UE	Accepts the hold or resume request and updates media behavior accordingly.
Optional TAS / MRF	Participate when supplementary-service logic or media resources such as tones are involved.

Interfaces used

Interface	Path	Role
IMS SIP path	UE <-> IMS core <-> remote UE	Carries the in-dialog session modification such as re-INVITE and 200 OK.
User-plane RTP path	Both UEs through the media path	Changes from active media to held media behavior and back again.
NR-Uu	UE <-> gNB	Maintains the underlying service continuity during hold or resume.

End-to-End Call Flow

UE-A              IMS core              UE-B
|-- re-INVITE (hold/resume) ------------->|
|<---------------------- 200 OK ----------|
|---------------------- ACK ------------->|
|====== RTP media changes to hold or normal flow ======|

Major Phases

Phase	What happens
1. Active call state	A normal VoNR voice session is already established.
2. Hold or resume request	One side sends an in-dialog SIP update with new SDP media direction.
3. Far-side acceptance	The other side answers the SDP change and keeps the dialog active.
4. Media-state transition	RTP pauses, changes direction, or resumes based on the negotiated SDP.

Step-by-Step Breakdown

User requests hold or resume on an active call

Sender -> receiver: UE local call-control -> IMS dialog handling

Message(s): User action leading to a session modification

Purpose: Change media behavior without tearing down the established dialog.

State or context change: The call remains active, but the media profile is about to be renegotiated.

Note: This is a session-modification problem, not a fresh call-setup problem.

The UE sends re-INVITE or equivalent with updated SDP

Sender -> receiver: Holding UE -> IMS -> remote UE

Message(s): re-INVITE with a=sendonly, a=inactive, or a=sendrecv

Purpose: Signal the far side that media should be paused or resumed.

State or context change: The dialog stays established while SDP renegotiation is in progress.

Note: The most useful fields here are the media direction attributes, not only the SIP response code.

The far side answers the session modification

Sender -> receiver: Remote UE -> IMS -> holding UE

Message(s): 200 OK and matching SDP answer

Purpose: Accept the change in media direction without ending the call.

State or context change: Both sides now agree on the held or resumed media state.

Note: A successful 200 OK with the wrong SDP direction still produces broken behavior.

ACK completes the update and media behavior changes

Sender -> receiver: Holding UE -> remote UE and media path

Message(s): ACK and RTP state change

Purpose: Finish the in-dialog transaction and apply the new media state.

State or context change: The call is either held with paused media or resumed with normal speech flow.

Note: Always validate the user-plane behavior after signaling, especially when one-way audio is reported after resume.

Important Messages in This Flow

Message	Protocol	Direction	Purpose in this procedure	What to inspect briefly
re-INVITE	SIP	UE -> remote side	Starts the hold or resume transaction.	Inspect the SDP direction attributes carefully.
200 OK	SIP	Remote side -> UE	Accepts the hold or resume state change.	Check whether the returned SDP really matches the requested operation.
ACK	SIP	UE -> remote side	Completes the in-dialog update.	A missing ACK leaves the modification unstable.
SDP direction attributes	SDP	Inside the offer and answer	Define whether media is sendonly, recvonly, inactive, or sendrecv.	This is the fastest way to explain wrong hold or resume behavior.

Important Parameters to Inspect

Parameter	What it is	Where it appears	Why it matters	Common issues
SDP media direction	The negotiated audio direction during hold or resume.	re-INVITE and 200 OK	Core explanation for whether media should pause or continue.	Wrong direction causes one-way audio or no resume.
Dialog continuity	Whether the update stays inside the existing dialog.	In-dialog SIP transaction	Ensures hold or resume modifies the current call rather than creating confusion with a new transaction.	Broken dialog continuity causes unexpected SIP errors.
Supplementary-service involvement	Whether TAS or related logic participates.	Service-control path	Useful when operator features affect hold behavior.	Service logic can change user expectations and trace shape.
RTP behavior after hold	Whether media actually pauses as expected.	After 200 OK and ACK	Confirms the negotiated state is enforced in practice.	Signaling may look right while media still leaks.
RTP behavior after resume	Whether bidirectional media returns cleanly.	Resume completion	Separates successful signaling from successful service restoration.	A common complaint is successful signaling with no real audio return.

Success Criteria

The dialog stays active while the media-state update is negotiated.
The returned SDP matches the intended hold or resume operation.
ACK completes the in-dialog transaction.
The RTP path behaves exactly like the negotiated new state.

Common Failures and Troubleshooting

Symptom	Likely cause	Where to inspect	Relevant message(s)	Relevant interface(s)	Likely next step
Hold signaling succeeds but audio still leaks	The negotiated media state is not enforced properly.	SDP direction and actual RTP behavior.	re-INVITE, 200 OK	Media path	This is a classic signaling-versus-media mismatch.
Resume completes but one-way audio remains	The resumed media state is only partially restored.	Resume SDP answer and post-resume RTP path.	200 OK, ACK	User plane	Treat this as post-modification media failure.
re-INVITE fails with SIP error	IMS routing, policy, or dialog-state handling rejected the update.	SIP error and current dialog state.	re-INVITE, error response	IMS SIP path	This is an in-dialog service-control failure, not call-setup failure.
Hold and resume are inconsistent across interworking cases	Interworking or service logic changes the expected behavior.	TAS, remote side type, and feature handling.	Full transaction	Service layer	PSTN or interworking cases often differ from UE-to-UE IMS behavior.

What to Check in Logs and Traces

Treat the case as an in-dialog update, not a new call setup.
Read the SDP direction fields before interpreting user audio symptoms.
Confirm that ACK completed after 200 OK.
Always compare signaling success with the real media behavior after the update.

Related sub-procedures

Related message reference pages

Related troubleshooting pages

FAQ

What is VoNR Call Hold / Resume?

It is the in-dialog IMS procedure that pauses and later restores media without tearing down the active voice call.

Does hold end the call?

No. The dialog stays established and only the media direction changes.

What proves a good hold?

The SIP update completes and RTP behavior matches the negotiated held state.

What proves a good resume?

The SIP update completes and bidirectional media returns normally.

What should I inspect first?

Start with the SDP direction attributes, then confirm ACK and actual RTP behavior.