Communication session Hold

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.

Key Features

• Temporarily suspends bidirectional media streams (audio/video) while maintaining signaling connection
• Provides indication to held party via network-generated tone, music, or message
• Uses SIP re-INVITE/UPDATE with modified SDP for implementation in IMS
• Network-based or terminal-based service implementation options
• Integrates with other services like Call Waiting, Consultation Hold, and Multiparty calls
• Standardized for both Circuit-Switched (GSM, UMTS) and IMS-based networks

Evolution Across Releases

Defining Specifications