8 Roles for call termination

24.2063GPPStage 3TSVoice call continuity between Circuit Switched (CS) and IP Multimedia Subsystem (IMS)

8.1 Introduction

This clause specifies the procedures for call termination, both where the VCC UE is receiving calls in the CS domain and where the VCC UE is receiving calls using the IM CN subsystem. Procedures are specified for the VCC UE and the various functional entities within the VCC application, and if the CAMEL service function is used, for the CAMEL service function towards the gsmSCF.

Subclause A.5 gives examples of signalling flows for call termination.

8.2 VCC UE

The VCC UE shall support termination of calls suitable for VCC both via the CS domain (as specified in 3GPP TS 24.008 [5]) and the IM CN subsystem (as specified in 3GPP TS 24.229 [8]).

There are no VCC specific requirements for the termination of calls that may be subject to VCC.

8.3 GMSC

There is no VCC specific procedure at the GMSC.

NOTE: Call diversion from CS domain to IM CN subsystem is required to proceed call termination. Several techniques are available at the GMSC to implement the call diversion as described in 3GPP TS 23.206 [8] Annex A. Those techniques are implementation options.

8.4 VCC application

8.4.1 Distinction of requests sent to the VCC application

The VCC application needs to distinguish between the following initial SIP INVITE requests to provide specific functionality relating to call termination:

– SIP INVITE requests routed to the VCC application over the ISC interface as a result of processing filter criteria at the S-CSCF according to the termination procedures (see 3GPP TS 24.229 [8] subclause 5.4.3.3), and therefore distinguished by the URI relating to this particular filter criteria appearing in the topmost entry in the Route header. In the procedures below such requests are known as "SIP INVITE requests due to terminating filter criteria". These requests are routed to the DTF and then to the DSF; and

– SIP INVITE requests routed to the VCC application over the Ma or ISC interface using the IMRN as a PSI, and therefore distinguished by the presence of the IMRN in the Request-URI header, which is different from the VDN. In the procedures below such requests are known as "SIP INVITE requests due to terminating IMRN". These requests are routed firstly to the CSAF and then to the DTF and then to the DSF.

Subclause 7.4.1, subclause 9.3.1 and subclause 10.4.1 detail other procedures for initial INVITE requests with different recognition conditions.

Other SIP initial requests for a dialog, and requests for a SIP standalone transaction can be dealt with in any manner conformant with 3GPP TS 24.229 [8].

The CAMEL service function also processes requests from the gsmSCF via a protocol not defined in this version of the specification.

NOTE: The functionality associated with these requests is described, based on the actions occurring at the interface between GMSC and gsmSCF.

8.4.2 Call termination in the IM CN subsystem

When the VCC application receives a SIP INVITE request due to terminating filter criteria:

1) the DTF shall check anchoring is possible for this session;

NOTE 1: The conditions that prevent anchoring are a matter for implementation, but can include operator policy on a number of conditions, e.g. roaming of the VCC UE, or a matter of lack of resources, e.g. available CSRNs. In general, the number of calls presented for anchoring on behalf of the same user will not prevent anchoring, as these issues are dealt with at handover. If anchoring fails, the call is presented to the user without anchoring.

NOTE 2: Such a check can also form part of the initial filter criteria in the S-CSCF to determine if the SIP INVITE request is sent to the DTF in the first place.

2) if the session is not subject to anchoring, the DTF shall forward the SIP INVITE request by acting as a SIP proxy as specified in subclause 5.7.4 of 3GPP TS 24.229 [8]. The DTF shall not Record-Route on such requests and no further VCC specific procedures are performed on this session;

3) if the session is subject to anchoring, the DTF shall operate as an application server providing 3rd party call control, and specifically as a routeing B2BUA, as specified in subclause 5.7.5 of 3GPP TS 24.229 [8] for this request and all future requests and responses in the same dialog;

4) the DSF shall perform domain selection based on:

– operator preferences;

– callee capabilities of the terminating UE, as obtained during registration;

– access network information, as provided in the P-Access-Network-Info header of the terminating UE;

– call states; and

– whether the session has characteristics other than audio media;

NOTE 3: The media characteristics can be derived from SDP information as well as from further capability indications of the terminating UE, such as e.g. callee preferences.

5) if the IM CN subsystem is selected by the DSF, the DSF or the combination of the DTF and DSF shall leave the Request-URI unchanged between the incoming SIP INVITE request and the outgoing SIP INVITE request; and

6) if the CS domain is selected by the DSF, the DSF shall determine a CSRN optionally using the CSAF and set the headers of the outgoing SIP INVITE request as follows:

a) set the Request-URI of the outgoing SIP INVITE request to the CSRN; and

b) set the To header field of the outgoing SIP INVITE request to the CSRN;

NOTE 4: The SIP AS that implements the DSF or the combination of the DTF and DSF acting as a B2BUA – which performs the third-party call control – needs to be the last located application server to ensure that all application servers that need to remain in the path of a call after domain transfer will do so. Example initial Filter Criteria can be found in Annex B.

On completion of the above procedure, the call is anchored in the DTF.

In the case where call delivery attempt fails in the selected domain and where the operator policy requires it, the DSF in the VCC application may re-attempt the call setup to the other domain. If this call delivery also fails no further call attempts shall be made.

8.4.3 Call termination in the CS domain – procedures towards the gsmSCF

When the CAMEL service function receives an indication that the gsmSCF has received a CAMEL IDP relating to a terminating call, the CAMEL service function and DTF in combination shall:

1) check anchoring is possible for this call;

NOTE 1: The conditions that prevent anchoring are a matter for implementation, but can include operator policy on a number of conditions, e.g. roaming of the VCC UE, or a matter of lack of resources, e.g. available IMRNs. In general, the number of calls presented for anchoring on behalf of the same user will not prevent anchoring, as these issues are dealt with at handover. If anchoring fails, the call is presented to the user without anchoring.

2) if the call is not subject to anchoring, cause the gsmSCF to respond with a CAMEL CONTINUE and no further VCC specific procedures are performed on this call; and

NOTE 2: The final decision on the CAP message sent by the gsmSCF depends on the further service logic associated with the service key.

3) if the call is subject to anchoring, allocate an IMRN or use CSAF to allocate an IMRN. How IMRNs are allocated may vary from one VCC application to another and is not specified in this version of the specification;

NOTE 3: For call termination, different options on IMRN derivation are available as described in 3GPP TS 23.206 [8] Annex A.

4) if the call is subject to anchoring, cause the gsmSCF to respond with a CAMEL CONNECT message with the Destination Routing Address set to the IMRN.

NOTE 4: The gsmSCF will include further parameters in the CAMEL CONNECT message as appropriate for the service key that was received in the CAMEL IDP.

NOTE 5: The final decision on the CAP message sent by the gsmSCF depends on the further service logic associated with the service key.

8.4.4 Call termination in the CS domain – procedures towards IM CN subsystem

When the CSAF receives SIP INVITE request due to terminating IMRN, the CSAF and DTF in combination shall:

NOTE 1: All SIP INVITE requests directed to the VCC application using an IMRN are assumed to be suitable for VCC anchoring, because any checks have been performed in conjunction with the CAMEL procedures.

1) operate as an application server providing 3rd party call control, and specifically as a routeing B2BUA, as specified in subclause 5.7.5 of 3GPP TS 24.229 [8] for this request and all future requests and responses in the same dialog;

NOTE 2: The SIP AS that implements the DTF acting as a B2BUA – which performs the 3rd party call control – needs to be the last located application server to ensure that all application servers that need to remain in the path of a call after domain transfer will do so. Example initial Filter Criteria can be found in annex B.

2) set the Request-URI of the outgoing initial SIP INVITE request to a tel-URI which represents the called party number of the original call as terminated in the CS domain. The tel-URI may be available from the received IMRN or from the "History-Info" header; and

3) set the To header field of the outgoing initial SIP INVITE request to a tel-URI which represents the called party number of the original call as terminated in the CS domain. The tel-URI may be available from the received IMRN or from the "History-Info" header.

NOTE 3: If call diversion parameters from the "History-Info" header are used to retrieve the original called party number and the VCC call was subject to call diversion before it was routed to the GMSC, the DTF will restore the original call diversion information. If multiple call diversion has occurred, the redirecting number can be lost.