4 Explicit Call Transfer (ECT)
24.0913GPPExplicit Call Transfer (ECT) supplementary serviceRelease 17Stage 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 3GPP TS 24.080. 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))
Figure 1: Invocation of Explicit Call Transfer
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.
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 3GPP TS 23.091 and the coding in 3GPP TS 24.080. 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.