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 Detected Changes 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.

Detected Changes Across Releases

from 3GPP Change Requests

Specific 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.

Rel-15 4 changes

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
Rel-17 1 change

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
Rel-18 1 change

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
Rel-19 17 changes

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.

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