6A Roles for General Capabilities
24.2373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuityRelease 17Stage 3TS
6A.1 Introduction
This clause describes the general roles for each functional entity as specified.
6A.2 UE roles
6A.2.1 Operator policy enforcement
The SC UE may receive the operator policy via OMA Device Management, see 3GPP TS 24.216 [5]. When the SC UE receives the operator policy, for each non-emergency session to be transferred, it shall take the operator policy into account when deciding to perform the following:
– selecting the access for initiating the transfer;
– determining whether to transfer full or partial media during PS-PS transfer; or
– determining whether to add or remove media during the PS-PS transfer.
If the SC UE is configured with the operator policy (e.g. via OMA Device Management as described in 3GPP TS 24.216 [5]) then, for each media or group of media contained in the MediaorGroup node, the SC UE shall:
1) restrict originating non-emergency sessions and session transfer of non-emergency sessions towards the access networks contained in the RestrictedAccessNetworkType node;
2) consider the list of access networks contained in the PreferredAccessNetworks node in the order of priority from the access networks such that, when available, the highest priority access network can be used for originating non-emergency sessions and session transfer of non-emergency sessions;
3) if a new access network gets available- transfer media components to a higher priority target network than the current access network based on the value contained in the SC_media_transfer node value. If the SC_media_transfer node value is:
– "shall" the UE shall start a session transfer of non-emergency sessions according to the home operator’ s list of preferred access networks contained in the PreferredAccessNetworks node;
– "should" the UE is recommended to start session transfer of non-emergency sessions according to the home operator’s list of preferred access networks contained in the PreferredAccessNetworks node. The UE can evaluate if session transfer of non-emergency sessions is possible and desirable after having taken into account the Local Operating Environment Information; and
– "may" the UE can decide whether or not to start session transfer of non-emergency sessions in accordance with user preferences if configured in the UE. The UE can evaluate if session transfer of non-emergency sessions is possible and desirable after having taken into account the Local Operating Environment Information. If user preferences are not configured, the UE can evaluate the home operator’s list of preferred access networks contained in the PreferredAccessNetworks node; and
4) decide whether to keep or drop non transferable media components in the case of partial session transfer of non-emergency sessions based on the SC_non_transferrable_media node value.
6A.2.2 Signalling elements
6A.2.2.1 Common SIP message set up procedures
This subclause describes the common procedures for setting up SIP messages sent by SC UE.
6A.2.2.2 SIP INVITE request
When sending a SIP INVITE request regardless of Request-URI, the SC UE shall include the following media feature tags in the Contact header field of the SIP INVITE request according to RFC 3840 [53]:
1) if the SC UE supports the MSC server assisted mid-call feature, include the g.3gpp.mid-call media feature tag as described in annex C;
2) if the SC UE supports the PS to CS SRVCC for calls in alerting phase and is sending an initial SIP INVITE request:
A) include the g.3gpp.srvcc-alerting media feature tag as described in annex C; and
B) if the SC UE supports the PS to CS SRVCC for originating calls in pre-alerting phase, include the g.3gpp.ps2cs-srvcc-orig-pre-alerting media feature tag as described in annex C;
3) if the SC UE supports the PS to CS dual radio access transfer for calls in alerting phase and is sending an initial SIP INVITE request:
A) include the g.3gpp.drvcc-alerting media feature tag as described in annex C; and
B) if the SC UE supports the PS to CS dual radio access transfer for originating calls in pre-alerting phase, include the g.3gpp.ps2cs-drvcc-orig-pre-alerting media feature tag as described in annex C; and
4) if the SC UE supports the use of dynamic STN, include the g.3gpp.dynamic-stn media feature tag as described in annex C.
Inclusion of the media feature tags of item 2) and 3) in a reINVITE request is optional.
When sending a SIP INVITE request with the Request URI set to an emergency service URN:
1) if the SC UE supports PS to CS DRVCC for emergency session, the SC UE shall include the g.3gpp.dynamic-e-stn-drvcc media feature tag in the Contact header field as described in annex C; and
2) if the SC UE supports the MSC server assisted mid-call feature and supports the PS to CS SRVCC for emergency session in early dialog state with active speech media component when both the emergency session in early dialog state with active speech media component and a non-emergency call in confirmed dialog state with inactive speech media component exists, the SC UE shall include the g.3gpp.ps2cs-srvcc-mid-call-emergency media feature tag in the Contact header field as described in annex C.
6A.3 ATCF
6A.3.1 SRVCC information bound to the registration path
The ATCF shall keep track of existing registrations of the served UEs. Each registration path is identified by the ATCF Path URI.
The ATCF shall bind the following information to the registration path identified by the ATCF Path URI:
– the S-CSCF Service-Route URI;
– the ATU-STI for PS to CS SRVCC; and
– the C-MSISDN.
If the ATCF supports CS to PS SRVCC, the ATCF shall additionally bind the following information to the registration path identified by the ATCF Path URI:
– the ATU-STI for CS to PS SRVCC;
– the contact address of the SC UE;
– the route set towards the SC UE;
– the UE information for CS to PS SRVCC; and
– the ATGW information for CS to PS SRVCC.
When a registration of a served UE expires or is deregistered, the ATCF can remove any SRVCC-related information bound to the registration path.
The ATCF shall determine that a session is established for a specific registration path:
– if the S-CSCF Service-Route URI used during the registration matches the URI in the most bottom Route header field of the originating initial SIP INVITE request; or
– if the ATCF Path URI used during the registration matches the URI in the top Route header field of the terminating initial SIP INVITE request.
6A.4 SCC AS
6A.4.1 Common SIP message set up procedures
This subclause describes the common procedures for setting up SIP messages sent by SCC AS.
6A.4.2 SIP INVITE request
When sending SIP INVITE request towards the served user and if the session being established is anchored in SCC AS as described in subclause 4.2.2 then the SCC AS shall populate the SIP INVITE request with:
1) a Feature-Caps header field according to IETF RFC 6809 [60]:
A) including the g.3gpp.srvcc feature-capability indicator as described in annex C; and
B) including the g.3gpp.remote-leg-info feature-capability indicator as described in annex C;
2) an Accept header field according to IETF RFC 3261 [19] containing the MIME type application/vnd.3gpp.state-and-event-info+xml as specified in subclause D.2.3; and
3) a Recv-Info header field according to IETF RFC 6086 [54] containing the g.3gpp.state-and-event package name.
6A.4.3 SIP INVITE responses towards the SC UE
When sending SIP 1xx response or SIP 2xx response to the SIP INVITE request towards the served user, the SCC AS shall populate the SIP response with a Feature-Caps header field according to IETF RFC 6809 [60] containing:
1) if the session being established is anchored in SCC AS as described in subclause 4.2.2:
A) include the g.3gpp.srvcc feature-capability indicator as described in annex C;
B) if:
a) the SCC AS supports the PS to CS SRVCC with the MSC server assisted mid-call feature according to operator policy;
b) the g.3gpp.mid-call media feature tag as described in annex C is included in the Contact header field of the SIP INVITE request; and
c) the SCC AS is aware:
– by local policy; or
– by ATCF indicating support of the PS to CS SRVCC with the MSC server assisted mid-call feature;
NOTE 1: An ATCF can indicate support of the PS to CS SRVCC with 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 PS to CS SRVCC with the MSC server assisted mid-call feature;
NOTE 2: SCC AS can identify the network, where the UE is registered, based on the P-Visited-Network-Id header field and the P-Access-Network-Info header field of the SIP REGISTER request.
include the g.3gpp.mid-call feature-capability indicator as described in annex C;
C) if:
a) the SCC AS supports the PS to CS SRVCC for calls in alerting phase according to operator policy;
b) the g.3gpp.srvcc-alerting feature tag as described in annex C is included in the Contact header field of the SIP INVITE request; and
c) 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;
NOTE 4: SCC AS can identify the network, where the UE is registered, based on the P-Visited-Network-Id header field and the P-Access-Network-Info header field of the SIP REGISTER request.
include the g.3gpp.srvcc-alerting feature-capability indicator as described in annex C;
D) if:
a) the SCC AS supports the PS to CS SRVCC for originating calls in pre-alerting phase and the PS to CS SRVCC for calls in alerting phase according to operator policy;
b) the g.3gpp.ps2cs-srvcc-orig-pre-alerting media feature tag as described in annex C and the g.3gpp.srvcc-alerting media feature tag as described in annex C are included in the Contact header field of the SIP INVITE request due to originating filter criteria;
c) the SCC AS is aware:
– by local policy; or
– by ATCF indicating support of the PS to CS SRVCC for originating calls in pre-alerting phase;
NOTE 5: An ATCF can indicate support of the PS to CS SRVCC for originating calls in pre-alerting phase by inclusion of the g.3gpp.ps2cs-srvcc-orig-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 PS to CS SRVCC procedures support the PS to CS SRVCC for originating calls in pre-alerting phase and the PS to CS SRVCC for calls in alerting phase; and
NOTE 6: The SCC AS can identify the network where the UE is registered based on the P-Visited-Network-Id header field and the P-Access-Network-Info header field of the SIP REGISTER request.
d) SIP 180 (Ringing) response to the SIP INVITE request has not been received yet;
include the g.3gpp.ps2cs-srvcc-orig-pre-alerting feature-capability indicator as described in annex C; and
E) include the g.3gpp.remote-leg-info feature-capability indicator as described in annex C;
2) if the SCC AS supports the PS to CS dual radio access transfer for calls in alerting phase according to operator policy, and if the SIP INVITE request included the g.3gpp.drvcc-alerting media feature tag as described in annex C in the Contact header field, include the g.3gpp.drvcc-alerting feature-capability indicator as described in annex C;
3) if:
A) the SCC AS supports the PS to CS dual radio access transfer for originating calls in pre-alerting phase and the PS to CS dual radio access transfer for calls in alerting phase;
B) the g.3gpp.ps2cs-drvcc-orig-pre-alerting media feature tag as described in annex C and the g.3gpp.drvcc-alerting media feature tag as described in annex C are included in the Contact header field of the SIP INVITE request; and
C) SIP 180 (Ringing) response to the SIP INVITE request has not been received yet;
include the g.3gpp.ps2cs-drvcc-orig-pre-alerting feature-capability indicator as described in annex C; and
4) if the SCC AS supports the use of dynamic STN according to operator policy, and if the Contact header field of the SIP INVITE request includes the g.3gpp.dynamic-stn media feature tag as described in annex C, include the g.3gpp.dynamic-stn feature-capability indicator as described in annex C with the dynamic STN.
NOTE 7: Based on implementation the dynamic STN can either be the same or different per call.
Additionally, when sending SIP 1xx response or SIP 2xx response to the SIP INVITE request towards the served user, the SCC AS shall populate the SIP response with:
1) if the session being established is anchored in SCC AS as described in subclause 4.2.2:
A) if the SIP response is a SIP 2xx response, an Accept header field according to IETF RFC 3261 [19] containing the MIME type application/vnd.3gpp.state-and-event-info+xml as specified in subclause D.2.3; and
B) a Recv-Info header field according to IETF RFC 6086 [54] containing the g.3gpp.state-and-event package name.
6A.4.3A SIP INVITE responses towards the MSC server
When sending a SIP 1xx response or SIP 2xx response to a SIP INVITE request due to STN-SR or to a SIP INVITE request due to PS to CS STN and if a Contact header field was saved in subclause 7.3.2 or subclause 8.3.2, the SCC AS shall include the saved Contact header field of the remote UE.
When sending a SIP 2xx response to a SIP INVITE request due to STN-SR or to a SIP INVITE request due to PS to CS STN and if a P-Asserted-Identity header field was saved in subclause 7.3.2 or subclause 8.3.2, the SCC AS shall include the P-Asserted-Identity header field with the identity of the remote user saved in subclause 7.3.2 or subclause 8.3.2 along with the Privacy header field, if available.
When sending a SIP 2xx response to a SIP INVITE request transferring additional session and if a P-Asserted-Identity header field was saved in subclause 7.3.2 or subclause 8.3.2, the SCC AS shall include the P-Asserted-Identity header field with the identity of the remote user saved in subclause 7.3.2 or subclause 8.3.2 along with the Privacy header field, if available.
NOTE: 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, the SIP INVITE request due to PS to CS STN or the SIP INVITE request transferring additional session and can limit the supplementary services that the MSC server can use after SRVCC access transfer is completed.
When sending a SIP 1xx response or SIP 2xx response to a SIP INVITE request due to STN-SR, a SIP INVITE request due to ATU-STI, a SIP INVITE request transferring additional session or a SIP INVITE request due to PS to CS STN, the SCC AS shall include:
1) the g.3gpp.remote-leg-info feature-capability indicator as described in annex C in a Feature-Caps header field according to IETF RFC 6809 [60];
2) if the SIP response is a SIP 2xx response, the Accept header field according to IETF RFC 3261 [19]containing the application/vnd.3gpp.state-and-event-info+xml MIME type; and
3) the Recv-Info header field according to IETF RFC 6086 [54] containing the g.3gpp.state-and-event info package name.
6A.4.4 Handling of OMR specific attributes
When an SDP offer containing OMR specific attributes specified in subclause 7.5.3 of 3GPP TS 24.229 [2] is received from either the source access leg or the target access leg, the SCC AS supporting OMR shall perform the actions specified in subclause 7.2.2 of 3GPP TS 29.079 [77].
When the SCC AS supporting OMR sends an SDP offer towards the remote party and if
– the SDP offer consists of several media lines merged from a source access leg and a target access leg; and
– any of the media lines contains OMR attributes;
then the SCC AS shall recalculate the checksums as specified in subclause 5.6.3 3GPP TS 29.079 [77].
If the SCC AS has not changed the content of a m-line and associated attributes, an SCC AS supporting OMR shall only calculate the session level checksum and replace the new value in each occurrences of the "a=omr-s-cksum" attribute.
The SCC AS supporting OMR shall forward the OMR specific attributes received in the SDP answer.
NOTE: When the SCC AS does not support OMR an optimal media path created before the transfer will not be established again.
6A.4.5 Target refresh request for a dialog and associated responses
The SCC AS shall include into the Feature-Caps header field of any target refresh request and, in each SIP 1xx response or SIP 2xx response to target refresh request sent to the SC UE:
A) the g.3gpp.srvcc feature-capability indicator if the session being established is anchored in the SCC AS as described in subclause 4.2.2 and if the SCC AS inserted the g.3gpp.srvcc feature-capability indicator into the Feature-Caps header field of:
1) the SIP INVITE request in accordance with subclause 6A.4.2; or
2) the SIP 1xx response or SIP 2xx response to the SIP INVITE request in accordance with subclause 6A.4.3;
B) the g.3gpp.mid-call feature-capability indicator if the SCC AS inserted the g.3gpp.mid-call feature-capability indicator into the Feature-Caps header field of:
1) the SIP 2xx response to the SIP INVITE request due to originating filter criteria in accordance with subclause 7.3.2;
2) the SIP INVITE request due to terminating filter criteria if the SCC AS applies the MSC Server assisted mid-call feature in accordance with subclause 8.3.2;
3) the SIP 2xx response to the SIP INVITE request due to PS to CS STN if the SCC AS applies the MSC Server assisted mid-call feature in accordance with subclause 9.3.2A;
4) the SIP 2xx response to the SIP INVITE request due to static STI if the SCC AS applies the MSC Server assisted mid-call feature in accordance with subclause 9.3.4; or
5) the SIP 2xx response to the SIP INVITE request due to STI if the SCC AS applies the MSC Server assisted mid-call feature in accordance with subclause 10.3.3;
C) the g.3gpp.srvcc-alerting feature-capability indicator if the SCC AS inserted the g.3gpp.srvcc-alerting feature-capability indicator into the Feature-Caps header field of:
1) any SIP 1xx response or SIP 2xx response to the SIP INVITE request due to originating filter criteria if the SCC AS applies PS to CS SRVCC for calls in alerting phase in accordance with subclause 7.3.2; or
2) the SIP INVITE request due to terminating filter criteria if the SCC AS applies PS to CS SRVCC for calls in alerting phase in accordance with subclause 8.3.2; and
D) the g.3gpp.ps2cs-srvcc-orig-pre-alerting feature-capability indicator if the SCC AS inserted the g.3gpp.ps2cs-srvcc-orig-pre-alerting indicator into the Feature-Caps header field of any SIP 1xx response or SIP 2xx response to the SIP INVITE request due to originating filter criteria if the SCC AS applies PS to CS SRVCC for calls in alerting phase in accordance with subclause 7.3.2.
If a feature-capability indicator was indicated in a Feature-Caps header field of the initial SIP INVITE request sent to the MSC server or of the SIP 1xx response or SIP 2xx response to the initial SIP INVITE request sent to the MSC server, then the SCC AS shall include the feature-capability indicator into the Feature-Caps header field of any target refresh request and into the Feature-Caps header field of each SIP 1xx response or SIP 2xx response to target refresh request sent to the MSC server.
6A.4.6 Rejecting malicious SIP REFER requests from remote UE
If the SCC AS supports the PS to CS SRVCC of calls in alerting phase, then upon receiving a SIP REFER request:
1. sent inside a SIP dialog on the remote leg;
2. with the Refer-Sub header field containing "false" value;
3. with the Supported header field containing "norefersub" value;
4. with the Refer-To header field containing a SIP URI with the Target-Dialog URI header field; and
5. containing a MIME body of application/vnd.3gpp.state-and-event-info+xml MIME type specified in the subclause D.2.4;
the SCC AS shall reject the SIP REFER request with a SIP 403 (Forbidden) response as specified in 3GPP TS 24.229 [2].
If the SCC AS supports the MSC server assisted mid-call feature, then upon receiving a SIP REFER request:
1. sent inside a SIP dialog on the remote leg;
2. with the Refer-Sub header field containing "false" value;
3. with the Supported header field containing "norefersub" value;
4. with the Refer-To header field containing a SIP URI with the Target-Dialog URI header field; and
5. containing a MIME body of application/vnd.3gpp.mid-call+xml MIME type specified in the subclause D.1.3;
the SCC AS shall reject the SIP REFER request with a SIP 403 (Forbidden) response as specified in 3GPP TS 24.229 [2].
6A.4.7 Protecting from malicious SIP INFO requests with remote leg information from remote UE
The SCC AS shall not include the Accept header field containing the application/vnd.3gpp.state-and-event-info+xml MIME type and shall not include the Recv-Info header field containing the g.3gpp.state-and-event info package name in the SIP INVITE request, SIP re-INVITE request and SIP UDPATE request and related responses sent towards the remote UE.
6A.4.8 Precondition and access transfer
If according to operator policy, the SCC AS:
1) shall support UA role procedures defined in IETF RFC 3262 [86], IETF RFC 3311 [87], IETF RFC 3312 [88] and IETF RFC 4032 [89]; and
2) if the remote leg is a precondition enabled dialog and if the SIP INVITE request on target access leg is not a precondition enabled initial INVITE request, shall interwork precondition related signalling at the remote leg with the target access leg established by SIP response to SIP INVITE request on target access leg. Details of interworking are out of scope of this specification.
6A.5 SDP media description conflict between target and remote access leg
When the SCC AS, the EATF or the ATCF receives an SDP offer on the target access leg, the SDP media descriptions on the target access leg and the remote access leg, can be in conflict. The way how the SCC AS, EATF and ATCF resolve the conflict is implementation dependent.
NOTE 1: Examples of conflicts are when, for a given media type, different IP versions are used on each access leg, or when the same payload type number has been assigned to different codecs on each access leg.
NOTE 2: An example on how to solve a conflict can be that transcoding functionality is enabled by inserting an MRF (in case of SCC AS or EATF) or an ATGW (in case of ATCF). Another example is that a SIP 488 (Not Acceptable Here) response is sent with the correct SDP media description.
When the MSC server receives a SIP 488 (Not Acceptable Here) response to an initial SIP INVITE request and an SDP body is present in the response:
1) if the MSC server supports one or more RTP payload types indicated in the received SDP body, the MSC server should re-initiate the initial SIP INVITE request with an SDP offer containing the RTP payload types (each comprising of an RTP payload type number indicated in a sub-field of an <fmt> portion of an "m=" line and, if included, an "a=rtpmap" attribute and an "a=frmtp" attribute for the RTP payload type number):
a) copied from the received SDP body (with the RTP payload type number indicated in the received SDP body); and
b) supported by the MSC server; and
2) if the MSC server does not support any RTP payload type of the received SDP body, the MSC server should re-initiate the initial SIP INVITE request with an SDP offer containing one or more RTP payload types supported by MSC server, associated with RTP payload type number(s) not indicated in the received SDP body.
6A.6 Indicating traffic leg
6A.6.1 The SCC AS server procedure for indicating traffic leg
If the SCC AS supports indicating the traffic leg associated with a URI as specified in IETF RFC 7549 [83] and the UE is roaming, the SCC AS may append the "iotl" SIP URI parameter with the value "visitedA-homeA" to the additional transferred session SCC AS URI for PS to CS SRVCC in the Refer-To URI of SIP REFER requests.
NOTE: The SCC AS can use the P-Visited-Network-Identity header field in the 3rd party SIP REGISTER request received when the UE registered in PS to determine if the UE is roaming or not.
6A.6.2 The MSC server procedure for indicating traffic leg
If the MSC supports indicating the traffic leg associated with a URI as specified in IETF RFC 7549 [83]:
1) the UE is roaming; and
2) the STN-SR does not identify an ATCF in the visited network;
then the MSC server shall, if required by local policy:
1) convert the STN-SR in the Request-URI to the form of a SIP URI with user=phone; and
2) append an "iotl" SIP URI parameter with a value set to "visitedA-homeA" in the Request-URI of the SIP INVITE request due to STN-SR and, if vSRVCC is supported and applied, in the SIP OPTIONS request.
6A.6.3 The ATCF server procedure for indicating traffic leg
If the ATCF supports indicating the traffic leg associated with a URI as specified in IETF RFC 7549 [83]:
1) the UE is roaming; and
2) the ATCF is not in the home network;
then the ATCF may, if required by local policy and if ATCF support the PS to CS SRVCC access transfer, append an "iotl" SIP URI parameter with a value set to "homeB-visitedB" to the ATCF management URI in the g.3gpp.atcf-mgmt-uri feature-capability indicator of the SIP REGISTER request.
6A.7 MSC server
6A.7.1 Precondition and access transfer
Unless local configuration indicates that the network is serving users not supporting SIP preconditions, the following applies for an MSC server supporting PS to CS SRVCC access transfer:
1) the MSC server shall support UA role procedures defined in IETF RFC 3262 [86], IETF RFC 3311 [87], IETF RFC 3312 [88] and IETF RFC 4032 [89];
2) upon generating an initial INVITE request, the MSC server shall include the "precondition" option tag in the Supported header field as defined in IETF RFC 3312 [88] as updated by IETF RFC 4032 [89] and the MSC server shall not indicate the requirement for the precondition mechanism by using the Require header field mechanism; and
3) the MSC server shall indicate the related local preconditions, using the segmented status type, as defined in IETF RFC 3312 [88] and IETF RFC 4032 [89], as well as the strength-tag value "mandatory" for the local segment and the strength-tag value either "optional" or as specified in RFC 3312 [88] and RFC 4032 [89] for the remote segment.