8 Roles for call termination for service continuity
24.2373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuityRelease 17Stage 3TS
8.1 Introduction
This clause specifies the procedures for call termination, both where the SC UE is receiving calls in the CS domain and where the SC UE is receiving calls using the IM CN subsystem. Procedures are specified for the SC UE, the SCC AS and the ATCF.
8.2 SC UE
The SC UE shall support termination of multimedia sessions in the IM CN subsystem as specified in 3GPP TS 24.229 [2] with the following clarifications:
1) If the SC UE supports the MSC server assisted mid-call feature, and the receiving SIP INVITE request includes g.3gpp.mid-call feature-capability indicator, as described in annex C, in the Feature-Caps header field, the SC UE shall include the g.3gpp.mid-call media feature tag as described in annex C in the Contact header field of the SIP 2xx response to the SIP INVITE request according to IETF RFC 3840 [53].
1a) If the SC UE supports the PS to CS SRVCC for calls in alerting phase, and the receiving SIP INVITE request includes the g.3gpp.srvcc-alerting feature-capability indicator as described in annex C in a Feature-Caps header field, the SC UE shall include the g.3gpp.srvcc-alerting media feature tag as described in annex C in the Contact header field of the SIP 1xx and SIP 2xx responses to the SIP INVITE request according to IETF RFC 3840 [53].
1b) If the SC UE supports the PS to CS SRVCC for terminating calls in pre-alerting phase, and the receiving SIP INVITE request includes the g.3gpp.ps2cs-srvcc-term-pre-alerting feature-capability indicator as described in annex C in a Feature-Caps header field, the SC UE shall include the g.3gpp.ps2cs-srvcc-term-pre-alerting media feature tag as described in annex C in the Contact header field of the SIP 1xx and SIP 2xx responses to the SIP INVITE request according to IETF RFC 3840 [53].
2) If the SC UE not supporting ICS or supporting ICS but with ICS capabilities disabled receives a SIP INVITE request containing a SDP offer which includes speech media component transported using an IP bearer, and:
NOTE 1: An indication that an SC UE with ICS capabilities has its ICS capabilities enabled or disabled can be found in the ICS MO ICS_Capabilities_Enabled leaf node (see 3GPP TS 24.286 [23]).
a) if the SC UE sends the response to the SIP INVITE request over GERAN;
b) if the SC UE sends the response to the SIP INVITE request over:
– E-UTRAN, the IMSVoPS indicator indicates that voice is not supported, and no persistent EPS bearer context exists at the SC UE; or
– UTRAN, and the IMSVoPS indicator indicates that voice is not supported; or
c) if the SC UE sends the response to the SIP INVITE request over an access network other than E-UTRAN, UTRAN and GERAN, and the access network does not support the offered speech media component transported using an IP bearer;
then the SC UE shall send back a SIP 488 (Not Acceptable Here) response without a message body.
The SC UE not supporting ICS or with ICS capabilities disabled shall support termination of calls in the CS domain as specified in 3GPP TS 24.008 [8].
An SC UE that supports ICS and has ICS capabilities enabled shall follow the call termination procedures as specified in 3GPP TS 24.292 [4].
When the SC UE not supporting ICS or with ICS capabilities disabled, and supports multiple registrations receives a SIP INVITE request containing SDP for establishing a session using just an IP bearer, then the SC UE shall establish this session in accordance with 3GPP TS 24.229 [2] with the following clarification:
– if the SIP INVITE request contains a Target-Dialog header field containing dialog parameters that correspond to an existing dialog (or a dialog in the process of being established) between the SC UE and SCC AS, the SC UE shall treat the SIP INVITE request as another dialog that is part of the same session as the dialog identified by the dialog parameters contained in the Target-Dialog header field; and
– if the SIP INVITE request does not contain a Target-Dialog header field but there is an existing dialog (or a dialog in the process of being established) between the SC UE and SCC AS, the SC UE shall check if the dialog parameters for this request correspond to the dialog parameters received in a Target-Dialog header field received on an existing dialog (or a dialog in the process of being established) between the SC UE and SCC AS and if so then the SC UE shall treat the SIP INVITE request as another dialog that is part of the same session as the dialog that the Target-Dialog header field was received on.
NOTE 2: The second case is to cover the possibility that requests can arrive out of the order that they were sent.
If the SC UE supports the use of dynamic STN, the SC UE shall include the g.3gpp.dynamic-stn media feature tag according to annex C in the Contact header field of SIP 1xx and SIP 2xx responses according to IETF RFC 3840 [53].
If the SC UE supports PS to CS dual radio access transfer of calls in alerting phase and if the g.3gpp.drvcc-alerting feature-capability indicator is included in the SIP INVITE request, the SC UE shall include in all SIP 18x responses to the SIP INVITE request, the g.3gpp.drvcc-alerting media feature tag as described in annex C in the Contact header field according to IETF RFC 3840 [53].
8.3 SCC AS
8.3.1 Distinction of requests sent to the SCC AS
The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality relating to call termination:
– SIP INVITE requests routed to the SCC AS over the ISC interface as a result of processing filter criteria at the S-CSCF according to the termination procedures as specified in 3GPP TS 24.229 [2], and therefore distinguished by the URI relating to this particular filter criteria appearing in the topmost entry in the Route header field. In the procedures below, such requests are known as "SIP INVITE requests due to terminating filter criteria". It is assumed that the SCC AS is the last AS that the S-CSCF forwards the request to.
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 [2].
8.3.2 Call termination procedures in the SCC AS
When the SCC AS receives a SIP INVITE request due to terminating filter criteria, the SCC AS shall:
1) follow the SCC AS roles for call termination procedures specified in 3GPP TS 24.292 [4];
2) save the Contact header field included in the terminating SIP INVITE request;
2) save the P-Asserted-Identity header field included in the terminating SIP INVITE request; and
3) if included in the response, save the Privacy header field included in the terminating SIP INVITE request.
NOTE 1: If the SCC AS subsequently receives an initial SIP INVITE request due to STN-SR, the SCC AS will include the saved P-Asserted-Identity in the SIP 2xx response to the initial SIP INVITE request due to STN-SR and the saved the Contact header field of the remote UE in its SIP 1xx responses and the SIP 200 (OK) response to the initial SIP INVITE request due to STN-SR.
If:
1. the SCC AS supports the MSC Server assisted mid-call feature according to operator policy; and
2. the SCC AS is aware:
– by local policy; or
– by ATCF indicating support of the MSC server assisted mid-call feature;
NOTE 2: An ATCF can indicate support of the MSC server assisted mid-call feature by inclusion of the g.3gpp.mid-call feature-capability indicator in the Feature-Caps header field, with the g.3gpp.atcf feature-capability indicator, in the SIP REGISTER request that created the binding of the SC UE.
that all MSC Servers in the network where the UE is registered which can be involved in the PS to CS SRVCC procedures support the MSC Server assisted mid-call feature;
then the SCC AS shall include the g.3gpp.mid-call feature-capability indicator, as described in annex C, in the Feature-Caps header field of the SIP INVITE request due to terminating filter criteria according to IETF RFC 6809 [60].
If the SCC AS supports the MSC Server assisted mid-call feature according to operator policy, the SCC AS shall remove the g.3gpp.mid-call media feature tag as described in annex C from the SIP 2xx response to the SIP INVITE request due to terminating filter criteria before forwarding the SIP 2xx response towards the remote UE.
If:
1. the SCC AS supports the PS to CS SRVCC for calls in alerting phase according to operator policy; and
2. the SCC AS is aware:
– by local policy; or
– by ATCF indicating support of the PS to CS SRVCC for calls in alerting phase;
NOTE 3: An ATCF can indicate support of the PS to CS SRVCC for calls in alerting phase by inclusion of the g.3gpp.srvcc-alerting feature-capability indicator in the Feature-Caps header field, with the g.3gpp.atcf feature-capability indicator, in the SIP REGISTER request that created the binding of the SC UE.
that all MSC Servers in the network where the UE is registered which can be involved in the PS to CS SRVCC procedures support the PS to CS SRVCC for calls in alerting phase;
then the SCC AS shall include the g.3gpp.srvcc-alerting feature-capability indicator as described in annex C in the Feature-Caps header field of the SIP INVITE request due to terminating filter criteria according to IETF RFC 6809 [60].
If:
1. the SCC AS supports the PS to CS SRVCC for terminating calls in pre-alerting phase according to operator policy; and
2. the SCC AS is aware:
– by local policy; or
– by ATCF indicating support of the PS to CS SRVCC for terminating calls in pre-alerting phase;
NOTE 4: An ATCF can indicate support of the PS to CS SRVCC for terminating calls in pre-alerting phase by inclusion of the g.3gpp.ps2cs-srvcc-term-pre-alerting feature-capability indicator in the Feature-Caps header field, with the g.3gpp.atcf feature-capability indicator, in the SIP REGISTER request that created the binding of the SC UE.
that all MSC Servers in the network where the UE is registered which can be involved in the PS to CS SRVCC procedures support the PS to CS SRVCC for terminating calls in pre-alerting phase;
then the SCC AS shall include the g.3gpp.ps2cs-srvcc-term-pre-alerting feature-capability indicator as described in annex C in the Feature-Caps header field of the SIP INVITE request due to terminating filter criteria according to IETF RFC 6809 [60].
If the SCC AS supports the PS to CS SRVCC for calls in alerting phase according to operator policy, the SCC AS shall remove the g.3gpp.srvcc-alerting media feature tag as described in annex C from SIP 1xx and SIP 2xx responses to the SIP INVITE request due to terminating filter criteria before forwarding the SIP 1xx and SIP 2xx responses towards the remote UE.
If the SCC AS supports the PS to CS SRVCC for terminating calls in pre-alerting phase according to operator policy, the SCC AS shall remove the g.3gpp.ps2cs-srvcc-term-pre-alerting media feature tag as described in annex C from SIP 1xx and SIP 2xx responses to the SIP INVITE request due to terminating filter criteria before forwarding the SIP 1xx and SIP 2xx responses towards the remote UE.
If the SCC AS supports the PS to CS dual radio access transfer for calls in alerting phase according to operator policy, the SCC AS shall include the g.3gpp.drvcc-alerting feature-capability indicator as described in annex C in the Feature-Caps header field of the SIP INVITE request due to terminating filter criteria according to IETF RFC 6809 [60].
If the SCC AS supports the use of dynamic STN according to operator policy, the SCC AS shall include an E.164 number as the dynamic STN for this session and include this dynamic STN in the g.3gpp.dynamic-stn feature-capability indicator with the dynamic STN as described in annex C in a Feature-Caps header field in the SIP INVITE request according to IETF RFC 6809 [60].
NOTE 5: The dynamic STN can either be the same or different per call based on implementation.
The SCC AS shall include the "tdialog" option tag and the "replaces" option tag in the Supported header field of the SIP INVITE request due to terminating filter sent toward the SC UE.
8.4 Access Transfer Control Function (ATCF)
8.4.1 Distinction of requests
The ATCF needs to distinguish the following initial SIP requests:
1) SIP INVITE requests with the ATCF URI for terminating requests in the topmost Route header field. In the procedures below, such requests are known as "terminating SIP INVITE requests for PS".
2) SIP INVITE requests:
A) with the ATCF management URI in the topmost Route header field; and
B) with application/vnd.3gpp.srvcc-ext+xml MIME body containing <srvcc-ext> root element containing <Setup-info> element containing <direction> element with value "receiver".
In the procedures below, such requests are known as "terminating SIP INVITE requests for CS".
8.4.2 Call termination procedures in the ATCF
8.4.2.1 General
For all SIP transactions identified:
– if priority is supported, as containing an authorised Resource-Priority header field or, if such an option is supported, relating to a dialog which previously contained an authorised Resource-Priority header field;
the ATCF shall give priority over other transactions or dialogs. This allows special treatment of such transactions or dialogs.
NOTE: The special treatment can include filtering, higher priority processing, routeing, call gapping. The exact meaning of priority is not defined further in this document, but is left to national regulation and network configuration.
8.4.2.2 Sessions terminated in PS domain
Upon receiving the terminating SIP INVITE request for PS, the ATCF shall:
NOTE 1: Since the ATCF acts as proxy, the dialog identifier of the SIP INVITE request is not modified by procedures of the subclause.
1) if a Feature-Caps header field containing the g.3gpp.srvcc feature-capability indicator is contained in the SIP INVITE request:
A) insert a Record-Route header field containing the SIP URI of the ATCF; and
B) if the latest SRVCC-related information received for the registration path which the session being established, is using contains ATU-STI for PS to CS SRVCC and C-MSISDN:
a) associate the session being established with the C-MSISDN and the ATU-STI for PS to CS SRVCC bound to the registration path (see subclause 6A.3.1); and
b) if the terminating SIP INVITE request for PS contains an SDP offer and if the ATCF decided to anchor the media according to operator policy as specified in 3GPP TS 23.237 [9], replace the SDP offer in the terminating SIP INVITE request with an updated SDP offer using media parameters provided by ATGW;
NOTE 2: ATCF interacts with ATGW to provide the needed media related information. The details of interaction between ATCF and ATGW are out of scope of this document.
2) save the Contact header field included in the terminating SIP INVITE request for PS;
3) save the P-Asserted-Identity header field included in the terminating SIP INVITE request for PS;
4) if included, save the Privacy header field included in the terminating SIP INVITE request for PS;
5) save the P-Charging-Vector header field included in the terminating SIP INVITE request for PS, and
6) save the Feature-Caps header field(s) included in the terminating SIP INVITE request for PS.
NOTE 3: If the ATCF subsequently receives an initial SIP INVITE request due to STN-SR, the ATCF will include the saved P-Asserted-Identity in the SIP 2xx response to the initial SIP INVITE request due to STN-SR and the saved the Contact header field of the remote UE in its SIP 1xx responses and the SIP 200 (OK) response to the initial SIP INVITE request due to STN-SR as describe in subclause 12.7.2.2.
NOTE 4: There are situations when the P-Asserted-Identity header field with the public user identity of the remote user can not be saved during the establishement of the communication, e.g. if presentation of the remote user public identity is restricted or if the user does not subscribe to the OIP or TIP service. In those situations the P-Asserted-Identity header field with a public user identity will not be delivered to the MSC server in the SIP 2xx response to the SIP INVITE due to STN-SR or the SIP INVITE request transferring additional session and can this limit the supplementary services that the MSC server can use after SRVCC access transfer is completed.
before forwarding the request.
8.4.2.3 Sessions terminated in CS domain
If ATCF supports CS to PS SRVCC then upon receiving the terminating SIP INVITE request for CS, the ATCF shall act as B2BUA and shall:
1) save the Contact header field included in the terminating SIP INVITE request for CS;
2) if ATCF contains an SRVCC-related information (see subclause 6A.3.1) containing C-MSISDN equal to the <C-MSISDN> element of the <Setup-info> element of the value <srvcc-ext> root element of the application/vnd.3gpp.srvcc-ext+xml MIME body of the SIP INVITE request:
A) associate the session being established with the latest SRVCC-related information (see subclause 6A.3.1) containing C-MSISDN equal to the <C-MSISDN> element of the <Setup-info> element of the value <srvcc-ext> root element of the application/vnd.3gpp.srvcc-ext+xml MIME body of the SIP INVITE request; and
3) send a SIP INVITE request towards the MSC server according to 3GPP TS 24.229 [2]. The ATCF shall populate the SIP INVITE request towards the MSC server with:
A) the Request-URI set to the Request-URI of the terminating SIP INVITE request for CS;
B) all Route header fields of the terminating SIP INVITE request for CS except the topmost Route header field;
C) the Record-Route header field containing the SIP URI of the ATCF;
D) the Accept header fields of the terminating SIP INVITE request for CS except the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type;
E) the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type with the "et" parameter indicating ability to receive "event-type" attribute with value "1", value "3", value "4" and values, if any, indicated in the "et" parameter of the application/vnd.3gpp.access-transfer-events+xml MIME type of the Accept header field of the terminating SIP INVITE request for CS;
F) the Recv-Info header fields of the terminating SIP INVITE request for CS;
G) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name, if not included already;
H) if the terminating SIP INVITE request for CS contains an SDP offer and if the ATCF decided to anchor the media according to operator policy as specified in 3GPP TS 23.237 [9]:
a) all MIME bodies of the terminating SIP INVITE request for CS apart from the application/vnd.3gpp.srvcc-ext+xml MIME body and apart from application/sdp MIME body; and
b) application/sdp MIME body with updated SDP offer using media parameters provided by the ATGW; and
NOTE: ATCF interacts with ATGW to provide the needed media related information. The details of interaction between ATCF and ATGW are out of scope of this document.
I) if the terminating SIP INVITE request for CS does not contain an SDP offer or if the ATCF decided not to anchor the media according to operator policy as specified in 3GPP TS 23.237 [9]:
a) all MIME bodies of the terminating SIP INVITE request for CS apart from the application/vnd.3gpp.srvcc-ext+xml MIME body.
When the ATCF receives any SIP 1xx response or SIP 2xx response to the SIP INVITE request towards the MSC server, the ATCF shall:
1) store the value of the g.3gpp.ti media feature tag of the Contact header field of the received SIP response to the SIP INVITE request towards the MSC server;
2) generate and send a SIP response to the terminating SIP INVITE request for CS populated with:
A) the same status code as the received SIP response to the SIP INVITE request towards the MSC server;
B) the Record-Route header field containing the SIP URI of the ATCF;
C) the Recv-Info header fields of the received SIP response except the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;
D) if the SIP response is SIP 1xx response:
a) if the SIP response contains an Recv-Info header field containing the g.3gpp.access-transfer-events info package name with the "et" parameter indicating ability to receive "event-type" attribute with values additional to the value "2", then the Recv-Info header field containing the g.3gpp.access-transfer-events info package name with the "et" parameter indicating ability to receive "event-type" attribute with the additional values; and
E) if the SIP response is SIP 2xx response:
a) if the SIP response contains an Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type with the "et" parameter indicating ability to receive "event-type" attribute with values additional to the value "2":
i) the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type with the "et" parameter indicating ability to receive "event-type" attribute with the additional values; and
ii) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name.
8.5 MSC server
8.5.1 Distinction of requests
The MSC server needs to distinguish the following initial SIP requests:
1) SIP INVITE requests with the topmost Route header field containing the Path header field value inserted by the MSC server in a REGISTER request. In the procedures below, such requests are known as "terminating SIP INVITE requests from home network".
2) SIP INVITE requests with the MSC URI for redirected terminating sessions in the topmost Route header field. In the procedures below, such requests are known as "redirected terminating SIP INVITE requests".
8.5.2 Call termination procedures
8.5.2.1 SIP INVITE request from home network
Upon receiving the terminating SIP INVITE request from home network and if the MSC server:
1) is enhanced for ICS and supports CS to PS SRVCC; and
2) the latest SRVCC information received for the registration path of the SC UE contains the ATCF management URI and the C-MSISDN;
then the MSC server instead of interworking of mobile terminating call setup from SIP to NAS signalling according 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4], the MSC server shall:
1) send a SIP INVITE request towards the ATCF according to 3GPP TS 24.229 [2]. The MSC server shall populate the SIP INVITE request towards the ATCF with:
A) the Request-URI set to the Request-URI of the terminating SIP INVITE request from home network;
B) topmost Route header field with the ATCF management URI and lr URI parameter;
C) all MIME bodies of the terminating SIP INVITE request from home network; and
D) application/vnd.3gpp.srvcc-ext+xml MIME body with the <srvcc-ext> root element containing the <Setup-info> element containing the CS to PS SRVCC information bound to the registration path (see subclause 6A.3.1) and indicating the "receiver" role of the MSC server in the session set up.
When the MSC server receives any SIP 1xx response or SIP 2xx response to the SIP INVITE request towards the ATCF, the MSC server shall generate and send a SIP response to the terminating SIP INVITE requests from home network populated with the same status code as the received SIP response to the SIP INVITE request towards the ATCF.
8.5.2.2 SIP INVITE request from ATCF
If the MSC server is enhanced for ICS and supports CS to PS SRVCC then upon receiving the redirected terminating SIP INVITE request, the MSC server shall interworking the mobile terminating call setup from SIP to NAS signalling according 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4].
When sending a SIP 1xx response or SIP 2xx response to the redirected terminating SIP INVITE requests, MSC server shall additionally populate the SIP response with:
1) the g.3gpp.ics media feature tag with value "server" in the Contact header field;
2) if the SIP response is SIP 1xx response:
A) Recv-Info header field containing the g.3gpp.access-transfer-events info package name and with the "et" parameter indicating ability to receive "event-type" attribute with value "2";
3) if the SIP response is SIP 2xx response:
A) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name; and
B) the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type with the "et" parameter indicating ability to receive "event-type" attribute with the value "2"; and
4) the g.3gpp.ti media feature tag with value as described in subclause C.12 in the Contact header field.