2 Call Hold (HOLD)

24.0833GPPCall Waiting (CW) and Call Hold (HOLD) supplementary servicesRelease 17Stage 3TS

2.1 Normal operation

2.1.1 Hold and retrieve functions

The hold and retrieve functions are performed on the same MM‑connection.

The hold function is used to put an existing call which is in the active phase in the Call held auxiliary state. By default, it retains the MM‑connection in use and the transaction identifier of the held call for possible subsequent call retrieval.

On receipt of a HOLD message the network shall return a HOLD ACKNOWLEDGE message, provided that the requested function can be performed. The network disconnects any user information path allocated to the active call when putting that call in the Call held auxiliary state. The mobile station disconnects any user information path to the active call and retains the transaction identifier and the MM‑connection when putting that call in the Call held auxiliary state.

The HOLD ACKNOWLEDGE message puts the call in the Call held auxiliary state and indicates that the hold function has been performed. The HOLD REJECT message indicates that the hold request was denied and returns the call to the condition it was in prior to the hold request. The HOLD REJECT message contains the Cause information element with e.g.:

‑ cause #29 "Facility rejected";

‑ cause #50 "Requested facility not subscribed";

‑ cause #69 "Requested facility not implemented".

The retrieve function reconnects the mobile station to the requested user information path. The RETRIEVE message requests that a call be retrieved. The RETRIEVE ACKNOWLEDGE message indicates that the retrieve function has been performed. The RETRIEVE REJECT message indicates that the retrieve request was denied. The RETRIEVE REJECT message contains the Cause information element with e.g.:

‑ cause #34 "No channel available".

2.1.2 Hold invocation

The served mobile subscriber indicates to the network that communication on the interface is to be interrupted.

The hold function should be invoked in association with an existing active call.

The invocation of the hold function does not affect the existing 3GPP TS 24.008 call states, but does affect the auxiliary state. The request for placing a call on hold places the auxiliary state in the hold request state. The responding entity will acknowledge this request with a HOLD ACKNOWLEDGE message if this operation was successful (see figure 2.1). This will result in the auxiliary state being put in the Call held state.

If the requested hold function cannot be obtained, then a HOLD REJECT message will be returned with the appropriate cause (see figure 2.1). This will result in the auxiliary state returning to the Idle state.

The traffic channel is now available to originate another call or to accept a waiting call (see call waiting). If at any time a call is in the held state, either party may clear the call according to the normal release procedure. Before to originate another call the MS will request the establishment of an MM‑connection first, see 3GPP TS 24.008.

MS Network

HOLD

————————————————————————————————————————>

HOLD ACKNOWLEDGE

<————————————————————————————————————————

HOLD REJECT

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

…..Cause…..

Figure 2.1: Invocation of call hold

If the network received a non‑zero SS Screening indicator from the remote party’s mobile station the network shall send a notification to the remote party indicating that the call has been placed on hold (see figure 2.2). If the network did not receive a non‑zero SS Screening indicator from the remote party’s mobile station it shall not send a notification.

MS Network

FACILITY

<————————————————————————————————————————

Facility (Invoke = NotifySS (HOLD, CallOnHold-Indicator))

Figure 2.2: Notification to the held mobile party that the existing call being put on hold

If the served mobile subscriber clears the current call and another call is still on hold, the normal call clearing procedure is used.

2.1.3 Retrieve procedure

When the mobile subscriber that invoked the call hold service indicates that the call is to be retrieved, the network shall re‑establish communication and send an acknowledgement to the served mobile subscriber (see figure 2.3).

If the network received a non‑zero SS Screening indicator from the remote party’s mobile station the network shall send a notification to the remote party indicating that the call has been retrieved (see figure 2.4). If the network did not receive a non‑zero SS Screening indicator from the remote party’s mobile station it shall not send a notification.

The retrieve function is requested by sending a RETRIEVE message. This message may be sent while the auxiliary state is in the Call held state.

Upon the sending of the RETRIEVE message the auxiliary state of the initiator’s terminal would be the retrieve request state.

If the retrieve request is successful, the RETRIEVE ACKNOWLEDGE message will be returned. The initiator should not assume that call retrieval has occurred until it receives this message. The auxiliary state would then return to the Idle state.

If the retrieve request is not successful, the RETRIEVE REJECT message will be returned with an appropriate cause. The auxiliary state machine would then remain to the Call held state.

MS Network

RETRIEVE

————————————————————————————————————————>

RETRIEVE ACKNOWLEDGE

<————————————————————————————————————————

RETRIEVE REJECT

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

…..Cause…..

Figure 2.3: Notification that the held call is to be retrieved (using the transaction identifier of the held call), by the served mobile subscriber

MS Network

FACILITY

<————————————————————————————————————————

Facility (Invoke = NotifySS (HOLD, CallOnHold-Indicator))

Figure 2.4: Notification to the held mobile party that the held call has been retrieved

2.1.4 Alternate from one call to the other

If the served mobile subscriber is connected to an active call and a call on hold, he can alternate from one call to the other. This results in the previously active call being held and the previously held call becoming retrieved. This is achieved by sending a HOLD message for the active call, followed by a RETRIEVE message for the held call (see figure 2.5). These requests place the auxiliary state for the held and active calls in the retrieve request and hold request states respectively.

If this alternate procedure is successful the HOLD ACKNOWLEDGE message will be returned, followed by the RETRIEVE ACKNOWLEDGE message. The initiator should not assume that the held call is retrieved and the active call is held until it receives both these messages.

If the alternate procedure is not successful the HOLD REJECT message will be returned followed by the RETRIEVE REJECT message. This will result in the auxiliary state for the held and active calls returning to the previous states.

If the network received a non‑zero SS Screening indicator from the remote party’s mobile station the network shall send a notification towards the previously held party that the call has been retrieved (see figure 2.4) and towards the previously active party that the call has been on hold (see figure 2.2). If the network did not receive a non‑zero SS Screening indicator from the remote party’s mobile station it shall not send a notification.

MS Network

HOLD (TI A-B)

————————————————————————————————————————>

RETRIEVE (TI A-C)

————————————————————————————————————————>

HOLD ACKNOWLEDGE (TI A-B)

<————————————————————————————————————————

RETRIEVE ACKNOWLEDGE (TI A-C)

<————————————————————————————————————————

HOLD REJECT (TI A-B)

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

…..Cause…..

RETRIEVE REJECT (TI A-C)

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

…..Cause…..

NOTE: TI A‑B indicates the transaction identifier allocated to the original active call and TI A‑C indicates the transaction identifier allocated to the original held call.

Figure 2.5: Alternate procedure

2.1.5 Auxiliary states for hold and retrieve

It is possible to place a call on hold in the Active state. The concept of dimensioned state space is being introduced to ensure state synchronization between the mobile station and the network. This concept suggests dimensioning the call state machine into two dimensions. In other words, there would be two states associated with each call. The first would be a 3GPP TS 24.008 call state and the second would be an auxiliary state associated with hold. Suppose the dimensioned state space is represented by two co-ordinates: one is a 3GPP TS 24.008 call state co-ordinate and the other is a hold co-ordinate. If a 3GPP TS 24.008 call state transition occurs, the former co-ordinate is updated. If a call is put on hold, the hold co-ordinate is updated. When the held call is reconnected, the hold co-ordinate is again updated.

There are four auxiliary states associated with the hold and retrieve functions:

‑ Idle;

‑ Hold request;

A request has been made for the hold function.

‑ Call held;

The call is held and the user information path has been reserved.

‑ Retrieve request;

A request has been made for the retrieve function.

2.1.6 An example of dimensioned state space

Suppose a call is in the Active state.

The dimensioned state space would be:

(Active, Idle).

Now the mobile station requests the hold function.

The dimensioned state space would become:

(Active, Hold request).

The call is then put on hold.

The mobile station becomes aware of this upon receiving the HOLD ACKNOWLEDGE message from the network.

The dimensioned state space would now be:

(Active, Call held).

Now the mobile station requests the retrieve function.

The dimensioned state space would become:

(Active, Retrieve request).

When a call is reconnected, the dimensioned state space would be:

(Active, Idle).

2.2 Activation and deactivation

Activation and deactivation of the supplementary service call hold cause no signalling on the radio path.

2.3 Registration, erasure and interrogation

Registration, erasure and interrogation of the supplementary service call hold are not applicable.

Annex A (informative):
Change history

Change history
Date	Meeting	TDoc	CR	Rev	Cat	Subject/Comment	New version
Apr 1999						Transferred to 3GPP CN1
CN#03						Approved at CN#03	3.0.0
CN#11						Release 4 after CN#11	4.0.0
CN#16						References updated	4.0.1
CN#16						Rel-5 created after CN#16	5.0.0
CN#26						Rel-6 created after CN#26	6.0.0
CT#36						Upgraded unchanged from Rel-6	7.0.0
CT#42						Upgraded unchanged from Rel-7	8.0.0
2009-12						Update to Rel-9 version (MCC)	9.0.0
2011-03						Update to Rel-10 version (MCC)	10.0.0
2012-09						Update to Rel-11 version (MCC)	11.0.0
2014-09						Update to Rel-12 version (MCC)	12.0.0
2015-12						Update to Rel-13 version (MCC)	13.0.0
2017-03						Update to Rel-14 version (MCC)	14.0.0
2018-06						Update to Rel-15 version (MCC)	15.0.0
2020-07						Update to Rel-16 version (MCC)	16.0.0
2022-03	–	–	–	–	–	Update to Rel-17 version (MCC)	17.0.0