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.
Detected Changes Across Releases
from 3GPP Change RequestsSpecific changes extracted from the „Change history“ tables of 3GPP specifications (23 CRs across 4 releases). Complements the general historical overview above with the evidence-based evolution of this function.
Studied in Rel-5, normative work from Rel-15.
In Release 15, the HOLD function was enhanced as part of the broader "IMS multimedia telephony communication service and supplementary services" framework. Specifically, the foundational procedures for Communication Waiting (CW) and Completion of Communications services (CCBS/CCNR) were introduced using the IP Multimedia (IM) Core Network subsystem. These updates standardized how a multimedia service, which may involve multiple parties and connections, can manage session hold states within the IMS Multimedia Telephony environment.
- IMS multimedia telephony communication service and supplementary services TS 24.173CR0122
- Communication Waiting (CW) using IP Multimedia (IM) Core Network (CN) subsystem TS 24.615CR0073
- Completion of Communications to Busy Subscriber (CCBS) and Completion of Communications by No Reply (CCNR) using IP Multimedia (IM) Core Network (CN) subsystem TS 24.642CR0088
- No unified access control check when adding or removing media during MMTEL session TS 24.173CR0130
In Release 17, the enhancement for the HOLD function specifically introduced support for signed attestation for emergency and priority IMS sessions. This new capability provides a verifiable mechanism to assert the priority level of a communication session. The change focuses on ensuring the integrity and authenticity of session priority claims within the IMS Multimedia Telephony service framework.
- Support for signed attestation for emergency and priority IMS sessions TS 29.165CR1029
In Release 18, the enhancements to the HOLD function focused on providing clarification on the procedure of the IMS Application Server during session setup and session modification. This work aimed to specify more precisely the network's behavior when placing a communication session on hold within a multimedia service involving multiple connections. The clarification ensures consistent handling of session states during these key IMS signaling procedures.
- Clarification on the procedure of IMS AS during session setup and session modification TS 24.186CR0008
In Release 19, the primary enhancement for the "HOLD" function was its integration with the newly introduced standalone IMS Data Channel (DC) sessions, enabling session control and termination procedures specific to this standalone mode. This included defining network-initiated and network-determined termination procedures for these standalone DC sessions after their setup. The updates also covered the alignment of UE and IMS Application Server procedures to support the HOLD function within the context of a standalone IMS data channel session.
- Update session control and DC application related requirement to support the standalone DC TS 24.186CR0039
- Procedure of avatar communication TS 24.186CR0054
- Network initiated standalone IMS DC session setup TS 24.186CR0061
- PS Data off support during IMS session establishment TS 24.186CR0070
- DC termination and standalone DC session termination on KI#2 TS 24.186CR0077
- Update the UE support of standalone DC session procedures TS 24.186CR0078
+ 11 more changes
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.
| Specification | Title | Release |
|---|---|---|
| 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 |