2 Call Hold (HOLD)

04.833GPPCall Waiting (CW) and Call Hold (HOLD) supplementary servicesStage 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 GSM 04.08 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 GSM 04.08.

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 GSM 04.08 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 GSM 04.08 call state co-ordinate and the other is a hold co-ordinate. If a GSM 04.08 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 Request History

Status
of
Technical Specification GSM 04.83

Date Version Remarks

No phase 1 version

October 1990 version 4.0.0 TS approved by GSM#28

January 1992 version 4.1.0 CR 04.83-03 rev 1 (category D) approved by SMG#01
CR 04.83-04 rev 1 (category C)
CR 04.83-05 (category C)
CR 04.83-06 rev 1 (category D

April 1992 version 4.2.0 CR 04.83-07 rev 1 (category D) approved by SMG#02
CR 04.83-09 (category D)
CR 04.83-10 rev 1 (category C)

June 1992 version 4.2.1 CR 04.83-11 (category D) approved by SMG#03
CR 04.83-13 (category D)
CR 04.83-14 (category D)

January 1993 version 4.3.0 CR 04.83-16 rev 1 (category C) approved by SMG#05

April 1993 version 4.4.0 CR 04.83-17 (category C) approved by SMG#06
CR 04.83-18 rev 1 (category C)
Reference to CCBS removed
TS frozen for phase 2 by SMG#06

October 1993 version 4.4.1 Changed to draft prETS 300 567

January 1994 version 4.5.0 CR 04.83-20 rev 1 (category F) approved by SMG#09

October 1994 version 4.5.1 TS changed to final draft prETS 300 567

January 1995 version 4.5.2 TS changed to ETS 300 567 first edition

February 1996 version 4.6.0 CR 04.83-A002 rev 1 (category F) approved by SMG#17

January 1995 version 4.5.2 TS changed to ETS 300 567 second edition

December 1996 version 5.0.0 GTS converted to draft prETS 300 953 for Release 96

May 1997 version 5.0.1 ETS 300 953 first edition

January 1999 version 6.0.0 Release 1997 version

July 1999 version 7.0.0 Specification version 6.0.0 upgrade to Release 1998 version 7.0.0

January 2000 version 7.0.1 Version update to 7.0.1 for Publication

Stylesheet: etsiw_70.dot