7 Roles for call origination

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

7.1 Introduction

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

Subclause A.4 gives examples of signalling flows for call origination.

7.2 VCC UE

The VCC UE shall support origination 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 origination of calls that may be subject to VCC.

NOTE 1: For INVITE requests initiated by the VCC UE in the IM CN subsystem, the following SIP response codes can indicate failure of the VCC application to process the request with its current characteristics:

– 484 (Address Incomplete);

– 488 (Not Acceptable Here) or 606 (Not Acceptable);

– 503 (Service Unavailable) or 603 (Decline).

NOTE 2: For SETUP messages initiated by the VCC UE in the CS domain, the following cause codes in a response message can indicate failure of the VCC capability to process the request with its current characteristics:

– #21 "Call rejected";

– #28 "Invalid number format (address incomplete);

– #127 "Interworking, unspecified".

7.3 VMSC

There is no VCC specific procedure at the VMSC.

NOTE: the VMSC interacts with CAMEL to proceed with the call origination.

7.4 VCC application

7.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 origination:

– SIP INVITE requests routed to the VCC application over either the ISC interface or the Ma interface using the IMRN as a PSI, and therefore distinguished by the presence of the IMRN in the Request-URI header, and which are known by interaction with the gsmSCF functionality to relate to an originating request rather than a domain transfer request or a terminating request. In the procedures below such requests are known as "SIP INVITE requests due to originating IMRN". These requests are routed firstly to the CSAF and then to the DTF; and

– 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 origination procedures (see 3GPP TS 24.229 [8] subclause 5.4.3.2), are distinguished by the contents of the Request-URI. If the Request-URI contains a VDI, then it is for a domain transfer request. However, absence of a VDI in the Request-URI indicates an origination request. In the procedures below such requests are known as "SIP INVITE requests due to originating filter criteria". These requests are routed firstly to the DTF.

Subclause 8.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 VCC application (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 VMSC and gsmSCF, and is depending whether it relates to an originating request, containing an ordinary called party number, or relates to a domain transfer request, which contains a VDN as the called party number.

7.4.2 Call origination in the IM CN subsystem

When the DTF receives a SIP INVITE request due to originating filter criteria, the DTF shall:

1) 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, the present IP-CAN used to access the IM CN subsystem.. In general, the number of calls presented for anchoring on behalf of the same user, and the media characteristics relating to these calls, will not prevent anchoring, as these issues are dealt with at domain transfer.

NOTE 2: Some checks 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, e.g. values of the P-Access-Network-Info header could form part of the initial filter criteria.

2) if the session is not subject to anchoring, either:

a) forward the SIP INVITE request by acting as a SIP proxy as specified in subclause 5.7.4 of 3GPP TS 24.229 [8], and therefore allow the call to continue without anchoring. The DTF shall not Record-Route on such requests, and the request is not retargetted by changing the Request-URI; or

b) reject the SIP INVITE request. The following SIP response codes are recommended:

– 484 (Address Incomplete), if the Request-URI supplied is not resolvable in the home network (such a Request-URI may have been resolvable in the local network which may be visited by the VCC UE at this time);

– 488 (Not Acceptable Here) or 606 (Not Acceptable), if some aspect of operator policy precluded anchoring; or

– 503 (Service Unavailable) or 603 (Decline) for all other conditions;

and no further VCC specific procedures are performed on this session; and

3) if the session is subject to anchoring, 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 with the following additions:

– copy the Request-URI unchanged from the incoming SIP INVITE request to the outgoing SIP INVITE request;

– copy all other headers unchanged from the received SIP INVITE request to the outgoing SIP INVITE request; and

– copy the body unchanged from the received INVITE request to the outgoing SIP INVITE request.

NOTE 3: Call anchoring is performed before all originating services are executed and thus the DTF is invoked as the first AS in the originating initial Filter Criteria. Example initial Filter Criteria can be found in annex B.

7.4.3 Call origination 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 an originating call, containing a called party number that is not a VDN, the CAMEL service function 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 or a lack of translation rules if the called party number is not in an international number format. 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 domain transfer.

2) if the session 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 session is subject to anchoring, allocate an IMRN or use the CSAF to allocate an IMRN. The IMRN is such that when the VCC application receives a SIP INVITE request it can derive by inspection that the request is due to an originating IMRN. How IMRNs are allocated may vary from one VCC application to another and is not specified in this version of the specification;

4) if the session is subject to anchoring, cause the gsmSCF to respond with a CAMEL CONNECT message, as specified in 3GPP TS 29.078 [9], with the Destination Routing Address set to the IMRN, and optionally, the Original Called Party ID, the Redirecting Party ID; and the Redirection Information.

NOTE 3: 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 4: The final decision on the CAP message sent by the gsmSCF depends on the further service logic associated with the service key.

7.4.4 Call origination in the CS domain – procedures towards IM CN subsystem

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

1) operate as an application server providing 3rd party call control, and specifically as an initiating 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;

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

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

4) if the CSAF has received a History-Info header having an index parameter indicating only one diversion, not include the History-Info header;

NOTE 1: The History-Info header was received as a result of the option of using ISUP call diversion mechanisms to transfer VCC specific information and carries no information relating to a real diversion.

5) insert a Route header pointing to the S-CSCF serving the VCC UE, or to the entry point of the VCC UE’s network (e.g., I-CSCF) and append the orig parameter to that same Route header of the outgoing initial SIP INVITE request; and

6) set the P-Asserted-Identity header of the outgoing SIP INVITE request to a tel-URI which represents the calling party number of the call initiated in the CS domain. This is either available from information associated against the received IMRN or is the value as received in P-Asserted-Identity header of the incoming SIP INVITE request.

NOTE 2: It can happen that the P-Asserted-Identity header is not included in the incoming SIP INVITE request.

NOTE 3: The remaining contents of the outgoing INVITE request are expected to be based on the contents of the received INVITE request due to originating IMRN, unless operator policy indicates otherwise.

The CSAF and DTF in combination should in the outgoing SIP requests and SIP responses include the same values as received in the incoming SIP requests and SIP responses in all other headers with the exception given in this subclause and in subclause 5.7.5 of 3GPP TS 24.229 [8].

The DTF will handle the Privacy header in the outgoing SIP INVITE request in the following way. The DTF shall either:

– if a Privacy header is received in the incoming INVITE request, include the Privacy header as received in the incoming INVITE request; or

– if a value is associated to IMRN and indicates that the presentation of the calling party number is restricted in the CS domain, include a Privacy header with the value set to "id".

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

NOTE 3: After completion of anchoring the call in DTF, the allocated IMRN is available for reuse.