24.2063GPPStage 3TSVoice call continuity between Circuit Switched (CS) and IP Multimedia Subsystem (IMS)
This clause specifies the procedures for domain transfer of a call from the IM CN subsystem to the CS domain. 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.7 gives examples of signalling flows for domain transfer of a call from the IM CN subsystem to the CS domain.
10.2 VCC UE
If the VCC UE is not engaged in an ongoing SIP conferencing service (as specified in 3GPP TS 24.173 [6A]) that it is in control of and, by evaluating the operator policy (as specified in 3GPP TS 24.216 [6B]) and the radio conditions, determines that an ongoing SIP dialog in the IM CN subsystem should be transferred to the CS domain, then the VCC UE shall initiate the release of all the ongoing SIP dialogs in the IM CN subsystem. By an ongoing SIP dialog, it is meant a dialog for which a SIP 2xx response to the initial INVITE request has been sent or received. The VCC UE can receive the operator policy via OMA Device Management. When the VCC UE receives the operator policy, it shall take this information in account when selecting the domain (either CS domain or IM CN subsystem) to initiate calls/session and when deciding to perform domain transfer.
If the UE is engaged in more than one ongoing calls/sessions and the domain transfer is restricted in this case by the specific VCC operator policy, such restriction does not apply in the case the VCC UE is losing coverage in the transferring-out domain.
NOTE 1: If permitted by operator policy, the UE can continue the domain transfer even if the release of the held calls failed to complete (e.g., due to radio conditions).
Afterwards the VCC UE shall send a CC SETUP message in accordance with 3GPP TS 24.008 . The VCC UE shall only send this request if the ongoing SIP dialog in the IM CN subsystem has had the dialog accepted, i.e. a SIP 200 (OK) response to the SIP INVITE request has already been sent.
NOTE 2: If the VCC UE has multiple calls in the IM CN subsystem at this time, then these calls could all be anchored. It is the responsibility of the VCC UE to ensure that the domain transfer request can be resolved by the DTF to a single call.
NOTE 3: The current media characteristics of the call in the IM CN subsystem does not preclude domain transfer, as the media characteristics are renegotiated as part of the domain transfer.
The VCC UE shall populate the CC SETUP message as follows:
1) the called party BCD number information element set to the VDN; and
2) [need to ensure suitable bearer characteristics]
NOTE 4: If the VCC UE receives a release message containing a #20 "Subscriber absent" cause value to the CC SETUP message, then this can indicate that the VCC application was unable to correlate the request to a single anchored call in the IM CN subsystem.
NOTE 5: If the VCC UE receives a release message containing a #127 "Interworking, unspecified" cause value to the CC SETUP message, then this can indicate that the remote terminal was not able to support the media characteristics of the CC SETUP message.
NOTE 6: If the VCC UE receives a release message containing a #63 "Service or option not available" cause value to the CC SETUP message, then this can indicate that the domain transfer was not successful.
There is no VCC specific procedure at the VMSC.
10.4 VCC application
10.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 domain transfer:
– 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 a domain transfer request rather than an originating request or terminating request. In the procedures below such requests are known as "SIP INVITE requests due to domain transfer IMRN". These requests are routed to the DTF.
Subclause 7.4.1, subclause 8.4.1 and subclause 9.3.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 .
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.
10.4.2 Domain transfer 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 a VDN, the CAMEL service function shall:
1) check whether domain transfer is possible;
NOTE 1: The conditions that prevent handover are a matter for implementation, but in general for this check are a matter of lack of resources, e.g. available IMRNs. For other checks the request will be continued so further checks can be performed at the VCC application within the IM CN subsystem.
2) if the call is not subject to domain transfer, cause the gsmSCF to respond with a CAMEL RELEASE CALL and no further VCC specific procedures are performed on this call. The following cause codes are recommended:
– #63 "Service or oiption not available" if there are insufficient resources, e.g. available IMRNs, to continue the handover;
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 domain transfer, allocate an IMRN or use CSAF to allocate 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 a domain transfer 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 call is subject to domain transfer, cause the gsmSCF to respond with a CAMEL CONNECT message with the Destination Routing Address set to the IMRN.
NOTE 3: The IMRN assigned for a domain transfer request can be different from the one assigned for CS origination (different target PSI i.e. different subfunction of the VCC application) and can be used as an indication of a domain transfer request.
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.
10.4.3 Domain transfer in the IM CN subsystem
When the CSAF receives SIP INVITE request due to domain transfer IMRN, the CSAF and DTF in combination shall associate the SIP INVITE request with an ongoing SIP dialog based on information associated with the received IMRN or based on information from the SIP History Info header field and P-Asserted header field and send a SIP reINVITE request towards the remote user using the existing established dialog. By an ongoing SIP dialog, it is meant a dialog for which a SIP 2xx response to the initial SIP INVITE request has been sent or received. Multiple dialogs associated with the same VCC UE may have been anchored when the DTF receives a SIP INVITE due to domain transfer IMRN. This can occur in the event that the UE does not succeed in releasing all inactive dialogs, in which case the identification of the associated dialog is subject to the following conditions:
– if only one SIP dialog exists for the user identified in the P-Asserted-Identity header field and a SIP 2xx response has been sent and there is active audio media, then continue the domain transfer;
– if no SIP dialogs exist for the user identified in the P-Asserted-Identity header field where there is active audio media and a SIP 2xx response has been sent, then send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the domain transfer;
– if more than one SIP dialog exists for the user identified in the P-Asserted-Identity header field and exactly one dialog exists where there is active audio media and a SIP 2xx response has been sent for that dialog, then:
– if the remaining dialogs have inactive audio media, then the DTF may release the inactive dialogs and continue the domain transfer procedures; or
– if the DTF is not able to identify one dialog for domain transfer, then the DTF shall send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the domain transfer.
Continuing the domain transfer procedures, the DTF shall populate the SIP reINVITE request as follows:
– set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with the remote user; and
– a new SDP offer, including the media characteristics as received in the SIP INVITE request due to domain transfer IMRN, by following the rules of the 3GPP TS 24.229 .
NOTE: The History-Info header field 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.
NOTE 1: On completion of the above procedure, the allocated IMRN is available for reuse.
Upon receiving the SIP ACK request from the IM CN subsystem, the DTF shall initiate release of the old access leg by sending a SIP BYE request toward the S-CSCF for sending to the served VCC UE.
Annex A (informative):
Example signalling flows of voice call continuity between the Circuit-Switched (CS) domain and the IP Multimedia (IM) Core Network (CN) subsystem