7 Roles for call origination for service continuity
24.2373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuityRelease 17Stage 3TS
7.1 Introduction
This clause specifies the procedures for call origination, both where the SC UE is generating calls in the CS domain and where the SC UE is generating calls using the IM CN subsystem. Procedures are specified for the SC UE, the SCC AS, the EATF and the ATCF.
Further this clause specifies procedures for cases where the ATCF handles SIP requests that are not related to a call.
7.2 SC UE
7.2.1 General
The SC UE shall support origination of IP multimedia sessions in the IM CN subsystem as specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request according to subclause 6A.2.2.2.
The SC UE shall support origination of calls in the CS domain as specified in 3GPP TS 24.008 [8].
If SC using ICS is enabled then the procedures for call origination where the SC UE is initiating calls using CS media are identical to that for ICS UE specified in 3GPP TS 24.292 [4].
When originating an emergency call as specified in 3GPP TS 24.229 [2] and if the SC UE has an IMEI, then the SC UE shall include the sip.instance media feature tag as specified in IETF RFC 5626 [22] with value based on the IMEI as defined in 3GPP TS 23.003 [12] in the Contact header field of the SIP INVITE request according to IETF RFC 3840 [53].
7.2.2 Additional procedures with MSC server assisted mid-call feature
Upon receiving a SIP 2xx response to the SIP INVITE request, if:
1. the SC UE supports the MSC server assisted mid-call feature;
2. the g.3gpp.mid-call feature-capability indicator is included in the Feature-Caps header field received during session establishment;
3. the remote UE is a conference focus; and
NOTE: conference focus includes the isfocus media feature tag specified in IETF RFC 3840 [53] in own Contact header field when establishing a session.
4. the session was created as result of the SC UE creating a conference;
then the SC UE shall subscribe to the conference event package as specified in 3GPP TS 24.605 [31] and shall populate the Contact header field of the SUBSCRIBE request with the g.3gpp.mid-call media feature tag.
If the subscription is accepted then the SC UE shall keep one subscription to the conference event package with own Contact header field containing the g.3gpp.mid-call media feature tag for each conference where the SC UE participates using procedures specified in 3GPP TS 24.605 [31].
7.3 SCC AS
7.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 origination:
– 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 origination 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. In the procedures below, such requests are known as "SIP INVITE requests due to originating filter criteria". It is assumed that the SCC AS is the first AS that the S-CSCF forwards the request to after receiving the request from the UE.
The SCC AS shall store the SIP INVITE requests due to PS to CS STN (as defined in subclause 9.3.1) and the SIP INVITE requests due to originating filter criteria, at least until their sessions are terminated.
The SCC AS needs to distinguish between the following initial requests to provide specific functionality related to obtaining conference participants:
– SIP SUBSCRIBE requests with an Event header field containing "conference" and with the Contact header field containing the g.3gpp.mid-call media feature tag routed to the SCC AS over the ISC interface as a result of processing initial filter criteria at the S-CSCF according to the originating procedures as specified in 3GPP TS 24.229 [2]. In the procedures below, such requests are known as "SIP SUBSCRIBE requests to conference event package".
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].
7.3.2 Call origination procedures at the SCC AS
When the SCC AS receives a SIP INVITE request due to originating filter criteria, the SCC AS shall follow the SCC AS roles for call origination procedures specified in 3GPP TS 24.292 [4].
The SCC AS shall populate the SIP 1xx response or SIP 2xx response to the SIP INVITE request according to subclause 6A.4.3.
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 INVITE request due to originating filter criteria before forwarding the SIP INVITE request towards the remote UE.
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 the SIP INVITE request due to originating filter criteria before forwarding the SIP INVITE request towards the remote UE.
The SCC AS shall include the "tdialog" option tag and the "replaces" option tag in the Supported header field of SIP 2xx response to the SIP INVITE request due to originating filter criteria.
When the SCC AS receives any SIP 1xx response or SIP 2xx response to a SIP INVITE request due to originating filter criteria, the SCC AS shall:
1) save the Contact header field included in the SIP 1xx response or SIP 2xx response;
2) save the P-Asserted-Identity header field included in the SIP 2xx response; and
3) if included in the SIP response, save the Privacy header field included in the SIP 2xx response.
NOTE: 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 Contact header field of the remote UE in SIP 1xx response or SIP 2xx response to the initial SIP INVITE request due to STN-SR.
7.3.3 Subscription related procedures in the SCC AS
When the SCC AS receives a SIP SUBSCRIBE request to conference event package, if the SCC AS supports the MSC Server assisted mid-call feature according to operator policy and if SCC AS determines that the subscription is related to an anchored session then the SCC AS shall ensure that it remains on the path for future requests in the dialog before forwarding the request.
NOTE: ASs acting as Routeing B2BUA and record-routing ASs acting as SIP proxy remain on the path for future requests in the dialog.
When the SCC AS receives SIP 2xx response to the SIP NOTIFY request with conference information, the SCC AS shall update the stored conference information based on the SIP NOTIFY request content and forward the SIP 2xx response in any manner conformant with 3GPP TS 24.229 [2].
The SCC AS shall determine that a subscription to conference event package is related to a session if:
1. the session was originated by served SC UE;
2. remote UE of the session is a conference focus;
3. the P-Asserted-Identity header field of the served SC UE used at the establishment of the session is the same as the P-Asserted-Identity header field of the served SC UE used at the subscription; and
4. the Contact or the P-Asserted-Identity header field provided to the served SC UE at the establishment of the session is the same as the Request-URI used at the subscription.
If multiple such subscriptions exist, the SCC AS shall select the subscription that originates from the same device as the session.
7.4 EATF
7.4.1 Distinction of requests sent to the EATF
The EATF needs to distinguish between the following initial SIP INVITE requests to provide specific functionality relating to call origination:
– SIP INVITE request including a request URI that contains an emergency service URN, i.e. a service URN with a top-level service type of "sos" as specified in IETF RFC 5031 [17]. In the procedures below, such requests are known as "SIP INVITE requests due to emergency service URN".
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].
7.4.2 Call origination procedures at the EATF
When the EATF receives a SIP INVITE requests due to emergency service URN, the EATF shall store the SIP INVITE request until the session is terminated, anchor the session and act as specified for a routeing B2BUA in 3GPP TS 24.229 [2], subclause 5.7.5.2.1.
In addition, if:
a) the EATF supports PS to CS DRVCC for emergency session;
b) the SC UE has indicated support for PS to CS DRVCC for emergency session by including the g.3gpp.dynamic-e-stn-drvcc media feature tag; and
c) the P-Access-Network-Info header field in the received SIP INVITE request contains an access-class field set to "3GPP-WLAN" or "untrusted-non-3GPP-VIRTUAL-EPC", and a "network-provided" parameter;
then the EATF shall:
NOTE: The coding of the P-Access-Network-Info header field can be found in 3GPP TS 24.229 [2].
a) generate an E-STN-DR that allows to associate the emergency session on the source access leg with a session transfer INVITE request due to E-STN-DR; and
b) insert a Feature-Caps header field as described in RFC 6809 [60] with the g.3gpp.dynamic-e-stn-drvcc feature-capability indicator containing the E-STN-DR in in a SIP 200 (OK) response to the INVITE request due to emergency service URN as described in annex C.28.
In addition, if:
a) the EATF supports the PS to CS SRVCC for originating emergency sessions in alerting phase according to operator policy;
b) the g.3gpp.srvcc-alerting media feature tag as described in annex C is included in the Contact header field of the SIP INVITE request; and
c) the EATF is aware by local policy that all MSC Servers in the network, where the ATCF is, which can be involved in the PS to CS SRVCC procedures, support the PS to CS SRVCC for originating emergency sessions in alerting phase;
then:
a) the EATF shall insert a Feature-Caps header field as described in RFC 6809 [60] with the g.3gpp.srvcc-alerting feature-capability indicator in the SIP 200 (OK) response to the INVITE request due to emergency service URN as described in annex C; and
b) if:
1) the EATF supports the PS to CS SRVCC for originating emergency sessions in pre-alerting phase according to operator policy;
2) the g.3gpp.ps2cs-srvcc-orig-pre-alerting media feature tag as described in annex C is included in the Contact header field of the SIP INVITE request; and
3) the EATF is aware by local policy that all MSC Servers in the network, where the ATCF is, which can be involved in the PS to CS SRVCC procedures, support the PS to CS SRVCC for originating emergency sessions in pre-alerting phase;
then the EATF shall insert a Feature-Caps header field as described in RFC 6809 [60] with the g.3gpp.ps2cs-srvcc-orig-pre-alerting feature-capability indicator in the SIP 200 (OK) response to the INVITE request due to emergency service URN as described in annex C.
7.5 Access Transfer Control Function (ATCF)
7.5.1 Distinction of requests
The ATCF needs to distinguish the following initial SIP requests:
1) SIP INVITE requests:
A) with the ATCF URI for originating requests in the topmost Route header field; and
B) with the Request-URI containing a URI not matching the STI-rSR allocated to the ATCF.
NOTE: If ATCF does not support the CS to PS SRVCC, the STI-rSR is not allocated to the ATCF.
In the procedures below, such requests are known as "originating SIP INVITE requests from SC UE".
2) SIP requests other than SIP INVITE requests creating a dialog, with the ATCF URI for originating requests in the topmost Route header field. In the procedures below, such requests are known as "originating SIP requests other than INVITE, creating a dialog".
3) SIP requests for a standalone transaction with the ATCF URI for originating requests in the topmost Route header field. In the procedures below, such requests are known as "originating SIP standalone request".
4) SIP request for an unknown method that does not relate to an existing dialog with the ATCF URI for originating requests in the topmost Route header field. In the procedures below, such requests are known as "originating unknown SIP requests".
5) 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 "initiator".
In the procedures below, such requests are known as "originating SIP INVITE requests from MSC server".
7.5.2 Call origination procedures in the ATCF
7.5.2.1 General
For all SIP transactions identified:
– if priority is supported, as containing an authorised Resource-Priority header field or a temporarily 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.
7.5.2.2 Sessions originated in PS domain
Upon receiving the originating SIP INVITE request from SC UE, 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.
0) insert a Record-Route header field containing the SIP URI of the ATCF;
1) if the latest SRVCC-related information received for the registration path which the session being established, 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 originating SIP INVITE request from SC UE 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 originating SIP INVITE request from SC UE with an updated SDP offer using media parameters provided by the ATGW; and
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) if the ATCF is located in the visited network, and local policy requires the application of IBCF capabilities in the visited network towards the home network, select an IBCF in the visited network and add the URI of the selected IBCF to the topmost Route header field;
before forwarding the request.
When the ATCF receives any SIP 1xx response or SIP 2xx response to the originating SIP INVITE request from SC UE, the ATCF shall:
1) save the Contact header field included in the SIP 1xx response or SIP 2xx response;
2) save the P-Asserted-Identity header field included in the SIP 2xx response;
3) if included in the response, save the Privacy header field included in the SIP 2xx response;
4) save the P-Charging-Vector header field included in the SIP 1xx response or SIP 2xx response; and
5) save the Feature-Caps header field(s) included in the SIP 1xx response or SIP 2xx response.
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.
7.5.2.3 Sessions originated in CS domain
If the ATCF supports the CS to PS SRVCC, upon receiving the originating SIP INVITE request from MSC server, the ATCF shall act as B2BUA and shall:
1) 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
B) store the value of the g.3gpp.ti media feature tag of the Contact header field of the SIP INVITE request; and
2) send a SIP INVITE request towards the home network according to 3GPP TS 24.229 [2]. The ATCF shall populate the SIP INVITE request towards the home network with:
A) the Request-URI set to the Request-URI of the originating SIP INVITE request from MSC server;
B) all Route header fields of the originating SIP INVITE request from MSC server except the topmost Route header field;
C) the Record-Route header field containing the SIP URI of the ATCF;
D) the Recv-Info header fields of the originating SIP INVITE request from MSC server except the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;
E) the Accept header fields of the originating SIP INVITE request from MSC server except the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type;
F) if an Accept header field of the originating SIP INVITE request from MSC server contains the application/vnd.3gpp.access-transfer-events+xml with the "et" parameter indicating ability to receive "event-type" attribute with values additional to the value "2":
a) 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
b) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;
G) if the originating SIP INVITE request from MSC server 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 originating SIP INVITE request from MSC server 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;
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.
H) if the originating SIP INVITE request from MSC server 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 originating SIP INVITE request from MSC server apart from the application/vnd.3gpp.srvcc-ext+xml MIME body; and
I) if the ATCF is located in the visited network, and local policy requires the application of IBCF capabilities in the visited network towards the home network, select an IBCF in the visited network and add the URI of the selected IBCF to the topmost Route header field.
When the ATCF receives any SIP 1xx response or SIP 2xx response to the SIP INVITE request towards the home network, the ATCF shall:
1) save the Contact header field included in the SIP response; and
2) generate and send a SIP response to the originating SIP INVITE request from MSC server populated with:
A) the same status code as the received SIP response to the SIP INVITE request towards the home network;
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 a SIP 1xx response:
a) 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 value "1", value "3", value "4" and values, if any, indicated in the "et" parameter of the g.3gpp.access-transfer-events info package name of the Recv-Info header field of the received SIP response; and
E) if the SIP response is a SIP 2xx response:
a) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;
b) the Accept header fields of the received SIP response except the Accept header field containing the application/vnd.3gpp.access-transfer-events+xml MIME type; and
c) 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" 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 received SIP response.
7.5.3 Procedures in the ATCF for originating requests not related to a call
Upon receiving a
1. originating SIP request other than SIP INVITE request, creating a dialog;
2. originating SIP standalone request; or
3. originating unknown SIP request;
the ATCF shall:
1) if the ATCF is located in the visited network, and local policy requires the application of IBCF capabilities in the visited network towards the home network, select an IBCF in the visited network and add the URI of the selected IBCF to the topmost Route header field;
before forwarding the request.
7.6 MSC server
7.6.1 Call origination procedures
Upon receipt of a CC SETUP message from the SC UE 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 when sending the SIP INVITE request due to receipt of a CC SETUP message from the SC UE as specified in 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4], then the MSC server shall additionally populate the SIP INVITE request with:
1) topmost Route header field with the ATCF management URI and lr URI parameter;
2) the Accept header field containing application/vnd.3gpp.access-transfer-events+xml MIME type with the "et" parameter indicating ability to receive "event-type" attribute with the value "2";
3) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;
4) 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 "initiator" role of the MSC server in the session set up; and
5) the g.3gpp.ti media feature tag with value as described in subclause C.12 in the Contact header field.