4 Explicit Communication transfer (ECT)
24.6293GPPExplicit Communication Transfer (ECT) using IP Multimedia (IM) Core Network (CN) subsystemProtocol specificationRelease 18TS
4.1 Introduction
The service provides a party involved in a communication to transfer that communication to a third party.
Procedures for the ECT AS regarding operator determined barring (ODB) are defined in 3GPP TS 24.315 [12].
4.2 Description
4.2.1 General description
The explicit communication transfer (ECT) service provides a party involved in a communication to transfer that communication to a third party.
There are three actors active in a transfer, they are acting in the following roles:
transferor: the party that initiates the transfer of the active communication that it has with the transferee;
transferee: the party which stays in the communication which is transferred;
transfer target: the party which the communication is transferred to and which replaces the transferor in the communication.
There are two initial situations in which transfer shall be possible:
– the transferor has no ongoing consultation communication with the transfer target (blind/assured transfer), then either:
a) the transferor wants to perform the transfer without any further action on the transfer operation (blind transfer); or
b) the transferor wants to have a feedback on the transfer operation progress with the possibility to retrieve the communication with the transferee (assured transfer); or
– the transferor has a consultation communication with the transfer target (consultative transfer).
The transferor AS takes care that it remains in the signalling path even after the communication is transferred, this allows:
– classical charging models;
– anonymization of the transfer target.
4.3 Operational requirements
4.3.1 Provision/withdrawal
The ECT service may be provided after prior arrangement with the service provider or be generally available.
4.3.2 Requirements on the transferor network side
No specific requirements are needed in the network.
4.3.3 Requirements on the transferee network side
No specific requirements are needed in the network.
4.3.4 Requirements on the transfer target network side
No specific requirements are needed in the network.
4.4 Coding requirements
A user agent that wishes to use the ECT service (to act as a transferor):
– Shall support the REFER method as a client as specified in RFC 3515 [2] as updated by IETF RFC 6665 [14] and IETF RFC 7647 [16].
– Shall support the Referred-By header field as specified in RFC 3892 [3].
– Shall support the Target-Dialog header field as specified in RFC 4538 [15].
A user agent that is the transferred party in a communication transfer (acts as the transferee):
– Shall support the REFER method as a server as specified in RFC 3515 [2] and updated by RFC 6665 [14].
– Shall support the Referred-By header field as specified in RFC 3892 [3].
– Shall support Replaces header field as a client as specified in RFC 3891 [4].
– Shall support the Target-Dialog header field as specified in RFC 4538 [15].
A user agent that is the transfer target in a communication transfer:
– May support the Referred-By header field as a server as specified in RFC 3892 [3].
– May support the Replaces header field as a server as specified in RFC 3891 [4].
4.5 Signalling requirements
4.5.1 Activation/deactivation
The ECT service is activated at provisioning and deactivated at withdrawal.
4.5.1A Registration/erasure
The ECT service requires no registration. Erasure is not applicable.
4.5.1B Interrogation
Interrogation of ECT is not applicable.
4.5.2 Invocation and operation
4.5.2.1 Actions at the transferor UE
A UE that has initiated an emergency call, shall not perform any transfer operation involving the dialog associated with the emergency call.
A UE that initiates a transfer operation shall if the Contact address of the transferee is a GRUU:
– issue a REFER outside an existing dialog as specified in RFC 3515 [2] as updated by IETF RFC 6665 [14] and IETF RFC 7647 [16], where:
a) the request URI shall contain the SIP URI of the transferee as received in the Contact header field:
b) the Refer-To header field shall indicate the public address of the transfer target;
c) in case of Consultative transfer, the transferor UE has a consultation communication with the transfer target, a Replaces header field parameter shall be added to the Refer-To URI together with a Require=replaces header field parameter;
d) the Referred-By header field can be used to indicate the identity of the transferor. When privacy was required in the original communications dialog and a Referred-By header field is included, the UE shall include a Privacy header field set to "user"; and
e) the Target-Dialog header field identifies the dialog to be transferred;
otherwise the UE shall:
– issue a REFER request in the original communications dialog as specified in RFC 3515 [2], where:
a) the request URI shall contain the SIP URI of the transferee as received in the Contact header field;
b) the Refer-To header field shall indicate the public address of the transfer target;
c) in case of consultative transfer, the transferor UE has a consultation communication with the transfer target, a Replaces header field parameter shall be added to the Refer-To URI together with a Require=replaces header field parameter; and
d) the Referred-By header field can be used to indicate the identity of the transferor. When privacy was required in the original communications dialog and a Referred-By header field is included, the UE shall include a Privacy header field set to "user".
If assured transfer is requested, the UE may include an Expires header field in the Refer-To URI of the REFER request.
NOTE 1: The value of the Expires header field indicates the maximum duration of the transfer attempt. If the transfer does not succeed within this duration, the UE will receive a NOTIFY request indicating the transfer failure.
After the REFER request is accepted by the other end with a 2xx response, the transferor UE gets notifications of how the transferee’s communication setup towards the transfer Target is progressing.
When a NOTIFY request is received on the REFER dialog that indicates that the transferee and the transfer Target have successfully setup a communication, the transferor UE may terminate the original communication with the transferee UE, by sending a BYE request on the original dialog.
If an assured transfer attempt is not completed (i.e. the UE has not received a NOTIFY request with a "message/sipfrag" body’s status line containing a final response code indicating the end of the transfer operation), the UE may request to terminate the transfer attempt by:
– sending a REFER request in the same communications dialog as the previous REFER request as specified in RFC 3515 [2] as updated by IETF RFC 6665 [14] and IETF RFC 7647 [16], where:
a) the request URI shall contain the SIP URI of the transferee as received in the Contact header field; and
b) the Refer-To header field shall indicate the public address of the transfer target and shall contain the method parameter set to "CANCEL"; and
c) if applicable include a Target-Dialog header field that identifies the dialog under transfer.
If the UE receives a NOTIFY request indicating that the assured transfer attempt failed,followed by a re-INVITE or an UPDATE request taking the UE off HOLD the UE may decide to retrieve the original communication by sending a re-INVITE request in the original SIP dialog.
NOTE 2: If the user requests the retrieval of the original communication while the transfer attempt has not been completed, the UE needs to first request the termination of the transfer attempt before retrieving the original communication via a re-INVITE request.
4.5.2.2 Void
4.5.2.3 Void
4.5.2.4 Actions at the transferor AS
4.5.2.4.1 Invocation of ECT service
4.5.2.4.1.1 Prerequisite for invocation of the ECT service
For ECT to be provided to end users acting as transferors, the end user’s AS providing ECT shall be in the signalling path for all communications.
If priority is supported, to apply appropriate priority processing of ECT invocation requests (see subclause 4.5.2.4.1.2.2A and subclause 4.5.2.4.1.2.3), the AS shall store call details for all existing dialogs that contain a Resource-Priority header field, including identification of the originating and terminating parties (e.g., based on the P-Asserted Identity header field value and the Request-URI value) and the Resource-Priority header field value most recently received within each dialog.
4.5.2.4.1.2 Determine whether the ECT applies
The transferor AS is the one executing the ECT service logic, which is invoked by the transferor sending a special REFER request.
4.5.2.4.1.2.1 REFER request received on a separate dialog
In order to know whether ECT service applies on a REFER request sent by the served user, the following criteria shall apply before the ECT logic is executed:
– the Target-Dialog header field identifies an existing dialog towards the transferee identified by the Request-URI;
– the REFER request’s Request-URI (transferee) is a GRUU targeted at the same UE instance that is involved in the dialog identified by the Target-Dialog header field; and
– the REFER request’s Refer-To header field contains a URI so that the method constructed from the URI according to RFC 3261 [6] is equal to INVITE;
4.5.2.4.1.2.2 REFER request received in the to be transferred dialog
In order to know whether ECT service applies on a REFER request sent by the served user, the following criteria shall apply before the ECT logic is executed:
– the REFER request’s request-URI (transferee) is targeted at the same UE instance that is involved in the dialog; and
– the REFER request’s Refer-To header field contains a URI so that the method constructed from the URI according to RFC 3261 [6] is equal to INVITE.
Any REFER request that does not comply with these criteria shall not invoke the ECT service and is depending on operator policy:
– rejected;
– handled by another service; or
– proxied on.
If any of the following is true:
– the initial INVITE request on the dialog on which the REFER request is received was identified as a PSAP callback request; or
– the Refer-To header field in the REFER request contains a URI with which the referor is involved in a dialog where the initial INVITE request was identified as a PSAP callback request.
the AS shall based on local policy on how to handle PSAP callbacks reject the REFER request.
The mechanism to identify an INVITE request as a PSAP callback depends on local policy and can be based on the PSAP callback indicator specified in IETF RFC 7090 [13].
4.5.2.4.1.2.2A Procedures for call transfer with 3PCC
When a REFER request is received that invokes the call transfer service (see subclause 4.5.2.4.1), the AS shall follow procedures specified in 3GPP TS 24.628 [10] for special REFER request handling using 3PCC procedures. An AS supporting the assured transfer, shall put the INVITE dialog towards the transferor on HOLD, following procedures in 3GPP TS 24.610 [8].
If the received REFER request contained an Expires header field in the Refer-To URI, the AS shall start a timer set to the value received in the Expires header field when the INVITE request is sent towards the transfer target, as requested by the received REFER request. If this timer expires before the transfer attempt is completed, the AS shall send a CANCEL request towards the transfer target according to RFC 3261 [4].
For blind communication transfer, if required by local policy to do so, the AS shall connect a media server to the transferee UE in order to provide in-band announcement about the progress of the communication establishment with the transfer target.
If the received REFER request pertains to an existing priority dialog that was originated by the transferee UE, the AS shall copy the stored Resource-Priority header field value from the existing dialog (see subclause 4.5.2.4.1.1) to the INVITE request that is sent towards the transfer target.
NOTE 1: The existing dialog is identified using the Target-Dialog header field included in the REFER request for a REFER request received on a separate dialog (see subclause 4.5.2.4.1.2.1) or using the dialog of a REFER request received in a to-be-transferred dialog (see subclause 4.5.2.4.1.2.2).
NOTE 2: This case only applies when the transferee UE has been authorized for priority for the original call.
If the assured transfer attempt fails, the AS shall resume the INVITE dialog with the transferor, following procedures in 3GPP TS 24.610 [8].
4.5.2.4.1.2.3 Actions of ECT when invoked with a transfer request
When a REFER request is received that invokes the ECT service (see subclause 4.5.2.4.1), the ECT service shall perform the following actions:
1) Create a new ECT session identifier URI addressed to this AS. The URI shall be created in such a way that a new dialog set up towards this URI can be easily correlated with the current REFER dialog.
2) The AS stores the value of the Refer-To header field (transfer target URI) from the REFER request and links it to the ECT Session Identifier URI.
3) The AS replaces the Refer-To header field with the ECT Session Identifier URI (this ensures that the transferor AS remains in the loop when the transferee sets up the communication with the transfer target).
NOTE 1: If a Replaces header field parameter and/or a Require=replaces header field parameter are available in the URI contained in the Refer-To header field, the above step implies that they are not forwarded to the transferee.
4) If a Referred-By header field is available in the request, the AS verifies if the provided Referred-By header field contains a valid public identity of the served user. If not it will replace the Referred-By header filed with a valid value matching the REFER request’s P-Asserted-Identity and if "id" privacy was requested, include a Privacy header field set to "user". If the Referred-By header field does not contain a valid public identity of the served user and multiple valid public user identities are received in the REFER request’s P-Asserted-Identity header field, the AS shall select the first one on the list. The AS then stores the Referred-by header field.
5) If no Referred-By header field is available in the request a Referred-By header field is added that matches the REFER request’s P-Asserted-Identity and if "id" privacy was requested, include a Privacy header field set to "user". If multiple valid public user identities are received in the REFER request’s P-Asserted-Identity header field, the AS shall select the first one on the list.
6) If the received REFER request pertains to an existing priority dialog that was originated by the transferee UE, the AS shall copy the stored Resource-Priority header field value from the existing dialog (see subclause 4.5.2.4.1.1) to the Resource-Priority header field of the REFER request that is sent towards the transferee UE.
NOTE 2: The existing dialog is identified using the Target-Dialog header field included in the REFER request for a REFER request received on a separate dialog (see subclause 4.5.2.4.1.2.1) or using the dialog of a REFER request received in a to-be-transferred dialog (see subclause 4.5.2.4.1.2.2).
NOTE 3: This case only applies when the transferee UE has been authorized for priority for the original call.
7) The AS sends the REFER request on to the transferee using basic communication procedures according to 3GPP TS 24.229 [1].
If the AS receives a 403 (Forbidden) or 501 (Not implemented) response to a REFER request, the AS of the initiator of the REFER request may initiate the special REFER handling procedures, according to 3GPP TS 24.628 [10].
If the AS receives a NOTIFY request with a sipfrag message body indicating a 420 (Bad Extension) as defined in RFC 3892 [3], the AS of the initiator of the REFER request may initiate the special REFER handling procedures according to 3GPP TS 24.628 [10].
As a network option, the AS of the initiator of the REFER request that has prior knowledge that the remote party is not allowed to receive or does not support the REFER method, may initiate the special REFER handling procedures directly, according to 3GPP TS 24.628 [10].
4.5.2.4.2 Subsequent procedures
4.5.2.4.2.1 Actions of ECT when invoked again by the transferred communication
When an INVITE is received targeted at the ECT session identifier URI created earlier when the served user requested transfer of an ongoing communication, ECT shall perform the following actions:
0) If the stored transfer target URI linked to the ECT session identifier contains a Replaces header field parameter, then the AS inserts the Replaces header field in the INVITE request and:
a) If the INVITE request does not contain a Requires header field, then the AS inserts a Requires header field in the INVITE request including a "replaces" token; and
b) If the INVITE request does contain a Requires header field without a "replaces" token, then the AS inserts a Requires header field in the INVITE request including a "replaces" token.
1) strip all header field parameters and method parameter from the stored transfer target URI and replace the request URI with the stripped version of the stored transfer target URI linked to the specific ECT session identifier URI;
2) if a Referred-By header field is available in the request, the AS verifies if the provided Referred-By header field contains a valid identity of the served user. If not it will replace the Referred-By header field with a valid value matching the REFER request’s P-Asserted-Identity and if "id" privacy was requested, include a Privacy header field set to "user". If the Referred-By header field does not contain a valid public identity of the served user and multiple valid public user identities are received in the REFER request’s P-Asserted-Identity header field, the AS shall select the first one on the list;
3) if no Referred-By header field is available in the request a Referred-By header field is added that matches the REFER request’s P-Asserted-Identity , and if "id" privacy was requested, include a Privacy header field set to "user". If multiple valid public user identities are received in the REFER request’s P-Asserted-Identity header field, the AS shall select the first one on the list; and
NOTE: If needed the AS can generate charging events to charge for the extra leg.
4) the INVITE request is forwarded towards the transfer target using basic communication procedures 3GPP TS 24.229 [1].
4.5.2.4.2.2 Actions of ECT on failed REFER request
4.5.2.5 Actions at the transferee UE
4.5.2.5.1 Actions at the transferee UE (without 3PCC)
When a REFER request is received in the context of a call transfer scenario (see subclause 4.5.2.4.1), the transferee UE shall perform the following steps:
1) apply the procedure for holding the active communication with the transferor as described in 3GPP TS 24.610 [8] subclause 4.5.2.1;
2) form a request from the URI in the Refer-To header field in accordance with RFC 3261 [6], section 19.1.5. If no "method" URI parameter is included an INVITE request shall be formed in accordance with RFC 3261 [6];
3) send the request to the transfer target;
4) if the UE does not support the Assured transfer service, send a BYE request on the INVITE dialog towards the transferor; and
5) act as a notifier in accordance with RFC 3515[2] as updated by RFC 6665 [14].
A UE supporting the assured transfer service shall keep the INVITE dialog towards the transferor. If the request towards the transfer target fails, the UE supporting the assured transfer service shall resume the session towards the transferor as described in 3GPP TS 24.610 [8] subclause 4.5.2.1.
4.5.2.5.2 Actions at the transferee UE (with 3PCC)
Apply normal re-INVITE procedures according to 3GPP TS 24.229 [1].
4.5.2.6 Void
4.5.2.7 Actions at the transferee AS
4.5.2.7.0 Prerequisite for invocation of the ECT service
For ECT to be provided to end users acting as transferee, the end user’s AS providing ECT shall be in the signalling path for all communications of the served user.
4.5.2.7.1 Determine whether ECT applies
See subclause 4.5.2.4.1 on the criteria that determine that a REFER request is to be treated as a request for transfer of an existing communication.
4.5.2.7.2 Actions of the ECT AS when invoked with a transfer request
When a REFER request is received in the context of a call transfer scenario (see subclause 4.5.2.4.1), the ECT AS shall perform the following steps:
1) Store the value of the Refer-To header field (used later to correlate the new communication with this REFER dialog).
2) Optionally it may store the value of the Referred-By header field, if it wants to ensure that the Referred-By is correct on the resulting INVITE request.
3) If priority is supported and if the REFER request pertains to an existing priority dialog that contains a Resource-Priority header field, the ECT AS shall store the Resource-Priority header value along with dialog details, and based on operator policy shall copy the Resource-Priority header field value to the Resource-Priority header parameter of the SIP URI in the Refer-To header field of the REFER request.
4) Forward the request to the transferee according to basic communication procedures 3GPP TS 24.229 [1].
4.5.2.7.3 Actions of the ECT AS when invoked again by the transferred communication
When an INVITE request is received targeted at the SIP URI stored earlier when a transfer request was received targeted at the served user (transferee), the AS shall perform the following actions:
0) Optionally check the following header fields in the received INVITE request:
a) if a Referred-By header field is present in the INVITE request, the AS may check if it matches the Referred-By header field of the REFER request stored earlier. If it does not match, depending on the policy of the service provider, the AS shall reject the INVITE request or replace the Referred-By header field in the INVITE request with the value stored earlier;
b) if a Referred-By header is absent in the INVITE, the AS shall insert a Referred-By header with the value stored earlier; and
c) if priority is supported and if a Resource-Priority header field is absent in the INVITE request, but was included in the REFER request as described in subclause 4.5.2.7.2, and the INVITE request is associated with the dialog details stored in subclause 4.5.2.7.2, the AS shall insert a Resource-Priority header field with the stored value;
1) optionally generate charging events:
a) to charge for the original communication between the transferee and the transferor, in case the transferee was the originating party in the original communication; and
b) to switch off charging in case the transferee was the terminating party in the original communication; and
2) the INVITE request is forwarded towards the transfer Target using basic communication procedures 3GPP TS 24.229 [1].
4.5.2.8 Void
4.5.2.9 Void
4.5.2.10 Void
4.5.2.11 Void
4.5.2.12 Void
4.5.2.13 Void
4.5.2.14 Void
4.5.2.15 Actions at the transfer target’s AS
Basic communication procedures according to 3GPP TS 24.229 [1] shall apply.
4.5.2.16 Void
4.5.2.17 Actions at the transfer target’s UE
Basic communication procedures according to 3GPP TS 24.229 [1] shall apply.
4.6 Interaction with other services
4.6.1 Communication HOLD (HOLD)
No impact.
4.6.2 Terminating Identification Presentation (TIP)
No impact.
4.6.3 Terminating Identification Restriction (TIR)
No impact.
4.6.4 Originating Identification Presentation (OIP)
No impact.
4.6.5 Originating Identification Restriction (OIR)
Requirements relating to the Referred-By header field are described in subclauses 4.5.2.4.1.2.3 and 4.5.2.4.2.1.
On the reception of an INVITE request from the transferee, the transferor AS shall deduce the "id" related privacy requirement that the transferee has indicated in the initial call between the transferee and the transferor; and shall include a Privacy header field containing the according value in the outgoing INVITE request.
For the transferee AS and the transfer Target AS there is no impact.
4.6.6 CONFerence Calling (CONF)
ECT shall not apply when the following criteria apply:
– a REFER request is received in an INVITE dialog with a conference focus, or a REFER request is received in an INVITE dialog and the Refer-to header field of the REFER request indicates the public address of active dialog to conference focus which is known by the AS providing ECT; and
– the REFER request is originated by the conference controller, the conference controller is the user that created and owns the conference.
An AS can determine that an established INVITE dialog is terminated at a conference focus because according to 3GPP TS 24.605 [9] it either:
– has received a 1xx or 2xx response to the INVITE request with an "isfocus" feature parameter in the Contact header field; or
– has received an INVITE with an "isfocus" feature parameter in the Contact header field.
4.6.7 Communication DIVersion Services (CDIV)
No impact.
4.6.8 Malicious Communication IDentification (MCID)
No impact.
4.6.9 Anonymous Communication Rejection and Communication Barring (ACR/CB)
For the transferor AS the following applies:
– The transferor AS shall not accept transfer requests with a transfer target that is barred by the served users Outgoing Communication Barring (OCB) rules.
– For the transferee AS and the transfer target AS there is no impact.
4.6.10 Explicit Communication Transfer (ECT)
4.6.10.1 Determine whether a previously transferred communication is transferred again
See subclause 4.5.2.4.1 on the criteria that determine that a REFER request is to be treated as a request for transfer of an existing communication.
Additionally the following criteria should apply for this interaction case to apply:
– The INVITE dialog on which the REFER request is received is a previously transferred communication, for which the current ECT instance had the transferor role.
4.6.10.2 Handling of transfer requests
When a REFER request is received and the criteria of subclause 4.6.10.1 apply, then the AS shall perform the following steps:
1) Create a new ECT session identifier URI addressed to this AS. The URI shall be created in such a way that a new dialog set up towards this URI can be easily correlated with the current REFER dialog.
2) The AS stores the value of the Refer-To header field (transfer target) from the REFER request and links it to the ECT session identifier URI.
3) The AS replaces the Refer-To header field with the ECT session identifier URI from step 1). (This ensures that this AS remains in the loop when the transferee sets up the communication with the transfer target.).
4) The AS forwards the REFER request to the transferee using basic communication procedures in 3GPP TS 24.229 [1].
4.6.10.3 Actions when this ECT instance is invoked again by the transferred communication
When an INVITE is received targeted at the ECT session identifier URI created earlier in subclause 4.6.10.2, the AS shall perform the following actions:
1) The AS replaces the request URI with the stored Refer-To header field value linked to the specific ECT session identifier URI.
NOTE: If needed the AS may generate charging events to charge for the extra leg.
2) The AS forwards the INVITE request towards the transfer target using basic communication procedures in 3GPP TS 24.229 [1].
4.6.11 Enhanced Calling Name (eCNAM)
On an established session with an eCNAM subscriber, if a blind transfer takes place, the AS sends a new INVITE request to the transferee without eCNAM information about the transferor.
4.6.12 Multi-Device (MuD)
No impact.
4.6.13 Multi-Identity (MiD)
No impact.
4.7 Interworking with other networks
4.7.1 Void
4.7.2 Void
4.7.3 Void
4.8 Parameter values (timers)
No specific timers are required.
4.9 Service configuration
Not applicable.
Annex A (informative):
Signalling flows