4 Explicit Call Transfer (ECT)

04.913GPPExplicit Call Transfer (ECT) supplementary serviceStage 3TS

4.1 Normal operation

The Explicit Call Transfer (ECT) function should be invoked in association with two existing calls which one is answered and in the held state and the other is answered and active or alerting.

The Mobile Station (MS) invokes the service by sending a FACILITY message to the network containing the ECT request (ECT request). This ECT request indicates to the network that the mobile subscriber wishes the two calls to be connected together. The MS shall not change the basic call state or the auxiliary state of either call when sending ECT request.

The network will normally accept the ECT request and connect the two calls, indicates the success of the ECT request to the served subscriber and disconnect afterwards the served mobile subscriber from both calls (see figure 1).

If the ECT request is not accepted, the network will indicate the error to the served subscriber (see figure 1) and leaves the two calls to the condition it was in prior to the ECT request. The network confirms with the same transaction identifier. The detailed coding of the different error values are specified in GSM 04.80. Which error value is used in which error case is described below.

During the ECT operation the MS shall run a timer TECT. This timer is started when the operation is sent, and stopped when a response is received from the network. If this timer expires the MS shall assume that the operation has failed, locally release the invokeID, and may re‑attempt the operation or inform the user of the failure.

4.2 Explicit Call Transfer invocation

MS Network

FACILITY (TI A-B/A-C)

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

Facility (Invoke = ExplicitCT)

DISCONNECT/RELEASE/RELEASE COMPLETE (TI A-B/A-C)

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

Facility (Return result)

DISCONNECT/RELEASE/RELEASE COMPLETE (TI A-C/A-B)

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

FACILITY (TI A-B/A-C)

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – — – – – – – – – – — – – – – – –

Facility (Return error (Error))

FACILITY (TI A-B/A-C)

<- – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – — – – – – – – – – — – – – – – –

Facility (Reject (Invoke_problem))

NOTE: A-B/A-C indicates a choice. The Transaction Identifier (TI) used for the invocation of ECT shall be that of the active/answered call or of the held call. A-C/A-B indicates the TI of the other call.

Figure 1: Invocation of Explicit Call Transfer

In the following table, the use of the different error values is described:

Table 1: Error values

Error

Error case

IllegalSS‑Operation

‑ operation violates the general rules applicable to the service

‑ different calls and either off them or two are not TS 11 (telephony)

‑ one or both of the calls are in the wrong call states

‑ having only one call or one call is clearing

‑ creation of a traffic channel loop

SS‑ErrorStatus

‑ the served subscriber has not subscribed to ECT

SS‑NotAvailable

‑ SS is not available in current location area

SS‑Incompatibility

‑ SS‑Interaction violation

FacilityNotSupported

‑ Facility not supported in VPLMN

SystemFailure

‑ problems in an entity or network resources

ResourcesNotAvailable

‑ problems to allocate resources

CallBarred

‑ contravention with the active barring program

4.3 Notification to the remote parties

If the network received a non‑zero SS Screening indicator from the remote party’s MS the network shall send a notification to the remote party indicating that the call has been transferred and towards the previously‑held party to indicate that he is now retrieved.

If the network did not receive a non‑zero SS Screening indicator from the remote party’s MS it shall not send a notification.

The content of the Notification Indicator and the Redirection Number in detail is given in GSM 03.91 and the coding in GSM 04.80. For the following it is assumed that the Line Identities of the remote parties are available and allowed to be presented to the remote parties.

4.3.1 Notification to the held remote party

If ECT was invoked in the active state the previous‑held remote party will be notified at the invocation of ECT (see figure 2).

MS Network

FACILITY (TI held call)

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

Facility (Invoke = NotifySS (SS-Code = HOLD, CallOnHold-Indicator = CallRetrieved),
Invoke = NotifySS (SS-Code = ECT,
ECT-Indicator (ECT-CallState = active, Rdn = RemotePartyNumber of C)))

Figure 2: Notification of invocation (at active state) to held remote party

If ECT was invoked in the alerting state the previous‑held remote party will be notified at the invocation of ECT (figure 3) and again at the receipt of the ANSWER message from the previous‑alerting remote party (figure 4).

MS Network

FACILITY (TI held call)

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

Facility (Invoke = NotifySS (SS-Code = HOLD, CallOnHold-Indicator = CallRetrieved),
Invoke = NotifySS (SS-Code = ECT, ECT-Indicator (ECT-CallState = alerting)))

Figure 3: Notification of invocation (at alerting state) to held remote party

MS Network

FACILITY (TI previous held call)

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

Facility (Invoke = NotifySS (SS-Code = ECT, ECT-Indicator (ECT-CallState = active,
Rdn = RemotePartyNumber of C)))

Figure 4: Notification to the previous-held remote party at receipt of the ANSWER message
by the previous-alerting remote party

4.3.2 Notification to the active or alerting remote party

MS Network

FACILITY (TI active or alerting call)

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

Facility (Invoke = NotifySS (SS-Code = ECT, ECT-Indicator (ECT-CallState = active,
Rdn = RemotePartyNumber of B)))

Figure 5: Notification of invocation to previous-active or previous-alerting remote party

4.4 Activation and deactivation

Activation and deactivation of ECT cause no signalling on the radio path.

4.5 Registration, erasure and interrogation

Registration, erasure and interrogation of ECT are not applicable.