HOLD

Communication session Hold

Services →
Introduced in Rel-5

HOLD is a supplementary service that allows a call participant to temporarily suspend media transmission and reception, placing the remote party on hold while keeping the signaling connection active for later retrieval.

Category
Services
Introduced
Rel-5
Where
Services
Specifications
18 specs
HOLD Description Purpose Specifications

Description

The HOLD service is a telecommunications supplementary service that enables a user involved in an active call (Circuit-Switched or IP Multimedia Subsystem-based) to temporarily pause the two-way media exchange without terminating the call session. When invoked, the service places the remote party 'on hold,' suspending the transmission of audio and/or video media streams from the local user to the remote user. The signaling path, managed by protocols like SIP (Session Initiation Protocol) in IMS or ISUP/BICC in CS, remains intact to maintain call state and control. The held party typically receives an indication, such as a hold tone, music-on-hold, or a notification message, and awaits the retrieval of the call.

Technically, the implementation differs between network domains. In the IMS, the service is implemented using SIP signaling methods. The user's terminal (UE) or an Application Server (AS) acting on its behalf sends a SIP re-INVITE or UPDATE request towards the remote party. This request contains a Session Description Protocol (SDP) offer that modifies the media session. To place a call on hold, the offer typically sets the media stream connection address ('c=' line in SDP) to '0.0.0.0' or includes an 'a=sendonly' or 'a=inactive' attribute for the local direction, indicating a temporary halt in media sending. The network may also connect the held party's media path to a Media Resource Function (MRF) that plays an announcement or music. Call retrieval is performed by sending a new SIP re-INVITE/UPDATE with a normal SDP offer re-establishing bidirectional ('sendrecv') media.

In the Core Network architecture, the HOLD service logic can reside in the user's terminal, in a network-based service platform (like an IMS Application Server), or in the Mobile Switching Centre (MSC) for circuit-switched calls. For IMS, it is defined as part of the Multimedia Telephony service set. The service interacts with other supplementary services like Call Waiting and Multiparty calls. Its role is to enhance user control and flexibility during a communication session, allowing actions like answering a second incoming call, consulting in private, or pausing a conversation without disconnecting. The network ensures that the held party's resources are maintained appropriately and that the service invocation does not inadvertently cause a call drop.

Purpose & Motivation

The HOLD service exists to replicate and enhance the familiar 'hold' functionality from traditional landline telephony within mobile and IP-based communication systems. It solves the practical problem of managing multiple concurrent communication tasks or needing a temporary pause during a call. Without it, a user wanting to speak privately to someone else or retrieve information would have to terminate the call, which is disruptive and may lead to failed reconnection attempts. The service provides a controlled, standardized way to suspend media while preserving the signaling session, ensuring the call can be quickly and reliably resumed.

Its creation and standardization were motivated by the need for feature parity between legacy circuit-switched networks (like GSM) and next-generation IP-based networks (like IMS). As 3GPP defined the IMS in Release 5, it was crucial to ensure that all basic and supplementary services from CS networks could be supported to guarantee user acceptance and smooth migration. The HOLD service specification ensured interoperability between different vendors' equipment and across network boundaries (e.g., between IMS and CS). Over subsequent releases, its definition was refined to handle more complex multimedia sessions (video, text) and to integrate seamlessly with other IMS services, maintaining its role as a fundamental user expectation for a complete telephony service.

Release Timeline

Evolution Across Releases

Rel-5 Initial

Initial standardization for IMS as part of the IP Multimedia Subsystem introduction. Defined the basic SIP-based procedures for session hold within the IMS service framework, establishing the foundation for multimedia supplementary services.

Enhancements and corrections to IMS service procedures. Integration with Presence and other new IMS enablers began. Refined the interaction between HOLD and other call control services.

Further refinements for IMS Multimedia Telephony (MMTel). Standardization of MMTel as a primary service package, with HOLD as a core supplementary service within it, ensuring consistent behavior for voice and video calls.

Support for IMS Centralized Services (ICS), allowing CS-access devices to invoke IMS-based supplementary services like HOLD. This was a key step for service consistency across access types.

Enhancements for emergency calls and priority services, defining behavior for HOLD during an emergency session. Continued alignment with GSMA IR.92 (VoLTE) profiles.

Introduction of Rich Communication Services (RCS) and further MMTel enhancements. HOLD procedures were solidified for commercial VoLTE deployments.

Machine-to-Machine (M2M) and service continuity optimizations. Minor updates to service description documents.

Support for Voice over Wi-Fi (VoWiFi) and further enhancements for service consistency across heterogeneous accesses (LTE, Wi-Fi, CS).

Enhancements for mission-critical communication services, defining HOLD behavior for group calls and priority users in MCPTT.

Alignment with 5G system architecture. HOLD service defined for use over 5G NR access within the IMS framework, ensuring continuity from 4G to 5G voice services.

Integration with 5G Media Streaming and edge computing concepts. Considerations for low-latency media handling when placing/releasing hold.

Support for new media types and extended reality (XR) sessions, potentially requiring enhanced hold/resume mechanisms for complex multi-stream sessions.

Continued evolution for 5G-Advanced, with potential AI/ML-based service enhancements and refinements for immersive communication scenarios.

Ongoing maintenance and future-proofing of the service for converged communication networks, ensuring backward compatibility and forward compatibility with new access technologies.

Expected to maintain and potentially evolve the service for future network architectures as part of the 6G study phase, ensuring this fundamental telephony feature persists in next-generation systems.

Explore further

Broader topics and technologies where HOLD plays a role.

Defining Specifications

3GPP specifications that define or reference HOLD, with the latest known release. Sourced from the 3GPP document catalog — see methodology.

SpecificationTitleRelease
TR 21.905 vj00 3GPP Technical Terms and Definitions Rel-19
TS 22.173 vk00 IMS Multimedia Telephony Service Definition Rel-20
TS 22.273 v1700 IMS Multimedia Telephony with PSTN/ISDN Simulation Rel-7
TS 24.173 vj00 Multimedia Telephony Service and Supplementary Services in IMS Rel-19
TS 24.186 vj60 IMS Data Channel applications Rel-19
TS 24.196 vj00 Enhanced Calling Name (eCNAM) Stage 3 Protocol Rel-19
TS 24.406 v810 Message Waiting Indication (MWI) Protocol Rel-8
TS 24.416 v1700 Malicious Call Identification Service Rel-7
TS 24.447 v800 Advice Of Charge (AOC) Service Protocol Rel-8
TS 24.606 vj00 MWI Service Protocol Description Rel-19
TS 24.615 vj00 Communication Waiting (CW) Service Protocol Rel-19
TS 24.642 vj00 CCBS/CCNR/CCNL SIP Protocol Specification Rel-19
TS 24.647 vj00 Advice of Charge (AOC) service protocol Rel-19
TS 29.165 vj10 Inter-IMS Network to Network Interface (NNI) Rel-19
TS 29.364 vj10 IMS AS Service Data Descriptions Rel-19
TS 29.827 vg00 Policy and Charging for Volume Based Charging Rel-16
TS 29.864 v801 Application Server Service Data Definition for IMS Telephony Rel-8
TS 32.275 vj00 MMTel Charging Specification Rel-19
Patrick Zandl

About the author: Patrick Zandl (b. 1974)

Telecommunications specialist, technology journalist (founder of the Mobil server), and developer who has been running since 2025 — the largest Czech-language resource on AI-assisted programming. Formerly Chief Wizard Architect at Prusa3D and head of development for Turris at CZ.NIC; currently a consultant and instructor on AI implementation in companies.