10 Roles for call termination

24.2923GPPIP Multimedia (IM) Core Network (CN) subsystem Centralized Services (ICS)Release 17Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

10.1 Introduction

This clause specifies the procedures for call termination to an ICS UE and a non-ICS UE. The following procedures describe Terminating Access Domain Selection at both the SCC AS and terminating ICS UE, to decide the service control type for the terminating side of the session. Service control signalling path over Gm for an ICS UE and IMS service control for a non ICS UE via an MSC server enhanced for ICS are specified. Procedures specific to the SCC AS and MSC server enhanced for ICS are also described.

Subclause A.5 provides examples of signalling flows for call termination.

10.2 ICS UE

10.2.1 General

This clause specifies the procedures for call termination by an ICS UE.

Subclause A.5 gives examples of signalling flows for call termination.

10.2.2 ICS UE using Gm

10.2.2.1 General

Subclause 10.2.2 describes the behaviour of the terminating ICS UE.

10.2.2.2 Call control over Gm and all media over IP bearer

When the ICS UE receives a SIP INVITE request containing SDP for establishing a session using just an IP bearer or if the ICS UE decides to use an IP bearer as determined by the procedures in subclause 10.2.2.4, then the ICS UE shall establish this session in accordance with 3GPP TS 24.229 [11] 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 ICS UE and SCC AS the ICS 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;

– 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 ICS UE and SCC AS the SCC AS 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 ICS UE and SCC AS and if so then the ICS 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: The second case is to cover the possibility that requests can arrive out of the order that they were sent

10.2.2.3 Call control over Gm and voice or voice and video over CS bearer

When:

1) the ICS UE receives a SIP INVITE request containing an SDP offer to establish a CS bearer according to IETF RFC 7195 [36] and if the SIP response to the SIP INVITE request is to be sent:

a) using I-WLAN or UTRAN; or

b) using GERAN and both UE and network support dual transfer mode; or

NOTE: Indication that network supports dual transfer mode is specified in 3GPP TS 44.018 [46].

2) the ICS UE has decided to terminate a CS call using the Gm reference point after execution of the procedures in subclause 10.2.2.4;

then the ICS UE shall:

– send a reliable SIP 183 (Session Progress) response towards the IM CN subsystems as specified in 3GPP TS 24.229 [11]. The UE shall populate the SIP 183 (Session Progress) response as follows:

a) the SDP payload proposing an audio stream over a circuit-switched bearer as described by IETF RFC 7195 [36] ], as follows:

– a"c=" line with the nettype portion to "PSTN" and the addrtype portion and connection-address portions both set to "-";

– an CS media "m=" line’s with the media portion set to "audio", port portion set to "9", proto portion to "PSTN" and fmt portion set to "-", as described in IETF RFC 7195 [36];

– an a=setup attribute set to "active";

an a=cs-correlation attribute set to "callerid" along with the MSISDN, of ICS UE in the CS domain, in international E.164 number format;

– an a=connection attribute set to "new";

and may also be proposing a CS video stream, and;

b) an indication that the local preconditions for QoS are not met as specified in 3GPP TS 24.229 [11];

– setup a CS call by sending a SETUP message in accordance with 3GPP TS 24.008 [7] for 3GPP systems. The UE shall populate the SETUP message for 3GPP systems as follows:

a) the called party BCD number information element set to the E.164 number obtained from the connection-address portion of the "c=" line with the nettype portion set to "PSTN" of the audio media, as described in IETF RFC 7195 [36] received in the SDP body of the SIP INVITE request and the selected codec; and

b) Type Of Number is set to "International" and Numbering Plan Indicator set to "E.164".in the Called Party BCD Number information element.

– when the resources are available to the UE, and if the UE has already received an indication from the origination side that related local preconditions for QoS as met on the originating side, shall send a SIP 180 (Ringing) response and continue the call setup as specified in 3GPP TS 24.229 [11].

10.2.2.4 Call control over Gm and T-ADS executed by the UE

When the ICS UE receives, within an initial SIP INVITE request, an SDP offer which allows the UE to select between using an RTP-based IP bearer or a CS bearer for audio media or audio and video media of a session, i.e. in which for the media descriptions ("m=") the following is set:

– the transport protocol within the "m=" line to RTP-based IP bearer;

– the related connection line to an IP address;

– additional a-lines as defined in IETF RFC 5939 [40], IETF RFC 7006 [39], IETF RFC 7195 [36] and IETF RFC 6871 [41] indicating the following:

a) the media capability attribute "omcap" with a "-" for the <encoding-name>;

b) the transport protocol capability attribute "tcap" set to "PSTN"; and

c) the connection data capability attribute "ccap" with nettype set to "PSTN", indicating "E.164" as address type and the connection-address set to the SCC AS PSI DN, in international E.164 number format;

and the ICS UE supports T-ADS execution:

1) if the UE in the response to the INVITE request includes a P-Access-Network-Info header field including an access-type field set to one of "3GPP-E-UTRAN-FDD" or "3GPP-E-UTRAN-TDD", the UE is a CS fallback capable UE, and the UE is not responding with a SIP 3xx response, then the following applies, if the Voice_Domain_Preference_E_UTRAN leaf of the 3GPP IMS Management Object (see 3GPP TS 24.167 [8A]) is configured and is:

a) set to "1" (i.e. "CS Voice only") and the NAS sublayer has indicated a successful NAS combined attach or combined TA update then the UE shall send back a SIP 488 (Not Acceptable Here) response without SDP body;

b) set to "1" and the UE fails to access the CS domain , the UE shall send back a SIP 606 (Not Acceptable) response;

c) set to "2" (i.e. "CS Voice preferred, IMS PS Voice secondary") and the NAS sublayer has indicated a successful NAS combined attach or combined TA update then the UE shall send back a SIP 488 (Not Acceptable Here) response without SDP body;

d) set to "2" and the NAS sublayer has not indicated a successful NAS combined attach or combined TA update and the IMSVoPS indicator indicates

I) voice is supported; or

II) voice is not supported and a persistent EPS bearer context exists at the UE;

then the UE shall use a RTP-based PS bearer for the related audio media stream;

e) set to "2" and the UE fails to access the CS domain and the IMSVoPS indicator indicates voice is not supported and a persistent EPS bearer context does not exist at the UE, then the UE shall send back a SIP 606 (Not Acceptable) response;

f) set to "3" (i.e. "IMS PS Voice preferred, CS Voice secondary") and the IMSVoPS indicator indicates:

I) voice is supported; or

II) voice is not supported and a persistent EPS bearer context exists at the UE;

then the UE shall use a RTP-based PS bearer for the related audio media stream;

g) set to "3" and the IMSVoPS indicator indicates voice is not supported, a persistent EPS bearer context does not exist at the UE and the NAS sublayer has indicated a successful NAS combined attach or combined TA update, then the UE send back a SIP 488 (Not Acceptable Here) response without SDP body;

h) set to "3" and the IMSVoPS indicator indicates voice is not supported, a persistent EPS bearer context does not exist at the UE and the UE fails to access the CS domain , then the UE shall send back a SIP 606 (Not Acceptable) response;

i) set to "4" (i.e. "PS Voice only") and the IMSVoPS indicator indicates:

I) voice is supported; or

II) voice is not supported and a persistent EPS bearer context exists at the UE;

then the UE shall use a RTP-based PS bearer for the related audio media stream or;

j) set to "4" and the IMSVoPS indicator indicates voice is not supported and a persistent EPS bearer context does not exist at the UE, then the UE shall send back a SIP 606 (Not Acceptable) response;

2) if the UE in the response to the INVITE request includes a P-Access-Network-Info header field including an access-type field set to one of "3GPP-UTRAN-FDD" or "3GPP-UTRAN-TDD", and the UE is not responding with a SIP 3xx response, then the following applies, if the Voice_Domain_Preference_UTRAN leaf of the 3GPP IMS Management Object (see 3GPP TS 24.167 [8A]) is configured and is:

a) set to "1" (i.e. "CS Voice only"), then the UE shall use the CS bearer for the related audio media stream;

b) set to "2" (i.e. "CS Voice preferred, IMS PS Voice secondary") and the IMSVoPS indicator indicates voice is not supported, then the UE shall use the CS bearer for the related audio media stream;

c) set to "2" (i.e. "CS Voice preferred, IMS PS Voice secondary") and the IMSVoPS indicator indicates voice is supported, then the UE should use the CS bearer for the related audio media stream or may use a RTP-based PS bearer for the related audio media stream;

d) set to "3" (i.e. "IMS PS Voice preferred, CS Voice secondary") and the IMSVoPS indicator indicates voice is supported, then the UE should use a RTP-based PS bearer for the related audio media stream or may use the CS bearer for the related audio media stream; or

e) set to "3" and the IMSVoPS indicator indicates voice is not supported, then the UE shall use CS bearer for the related audio media stream.

3) if the UE in the response to the INVITE request includes a P-Access-Network-Info header field including an access-type field set to one of "3GPP-E-UTRAN-FDD" or "3GPP-E-UTRAN-TDD", and the Voice_Domain_Preference_E_UTRAN leaf of the 3GPP IMS Management Object (see 3GPP TS 24.167 [8A]) is not configured:

a) if the IMSVoPS indicator indicates:

I) voice is supported; or

II) voice is not supported and a persistent EPS bearer context exists at the UE;

then the UE can use a RTP-based PS bearer for the related audio media stream; and

b) if the IMSVoPS indicator indicates voice is not supported and a persistent EPS bearer context does not exist at the UE, then the UE shall send back a SIP 488 (Not Acceptable Here) response without SDP body;

4) if the UE in the response to the INVITE request includes a P-Access-Network header field including an access-type field set to one of "3GPP-UTRAN-FDD" or "3GPP-UTRAN-TDD", and the Voice_Domain_Preference_UTRAN leaf of the 3GPP IMS Management Object (see 3GPP TS 24.167 [8A]) is not configured:

NOTE 1: The UE decides based on local configuration and network conditions whether to use for the related audio media stream an IP connection, RTP-based IP bearer or a CS bearer.

a) if the IMSVoPS indicator indicates voice is supported, then the UE can use a RTP-based PS bearer for the related audio media stream;

b) if the IMSVoPS indicator indicates voice is not supported, then the UE shall:

I) not use this access technology for a RTP-based PS bearer for the related audio media stream (e.g. using a SIP 3xx response); or

II) send back a SIP 606 (Not Acceptable) response;

5) if the UE in the response to the INVITE request includes a P-Access-Network-Info header field including an access-type field set to "3GPP-GERAN":

NOTE 2: The UE decides based on local configuration and network conditions whether to use for the related audio media stream an IP connection, RTP-based IP bearer or a CS bearer.

a) if both the UE and the network support dual transfer mode, then the UE shall use a CS bearer for the related audio media stream; and

NOTE 3: Indication that network supports dual transfer mode is specified in 3GPP TS 44.018 [46].

b) if the UE, network or both do not support dual transfer mode, then the UE shall send back a SIP 488 (Not Acceptable Here) response without SDP body; and

6) if the UE in the response to the INVITE request includes a P-Access-Network-Info header field including an access-type field not set to one of "3GPP-GERAN", "3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", "3GPP-E-UTRAN-FDD", or "3GPP-E-UTRAN-TDD", based on local configuration and network conditions, decide whether to use for the related audio media stream an IP connection RTP-based IP bearer or a CS bearer.

If the ICS UE decides to use a IP connection or RTP-based IP bearer, the ICS UE shall proceed as described in subclause 10.2.2.2 and in addition indicate that the IP connection or RTP-based IP bearer is used within the SDP answer in accordance with RFC 5939 [40].

If the ICS UE decides to use a CS bearer then the ICS UE shall:

1) send a reliable SIP 1xx provisional response towards the IM CN subsystems as specified in 3GPP TS 24.229 [11]. The UE shall populate the SIP 1xx provisional response as follows:

a) the SDP answer proposing an audio stream over a circuit-switched bearer as described by IETF RFC 7195 [36], as follows:

– a "c=" line with the nettype portion to "PSTN" and the addrtype portion and connection-address portions both set to "-";

– a CS media "m=" line with the media portion set to "audio", port portion set to "9", proto portion to "PSTN" and connection-address portion set to "-" as described in IETF RFC 7195 [36];

– an a=setup attribute set to "active";

– an a=connection attribute set to "new"; and

– an a=cs-correlation attribute set to "callerid" along with the MSISDN, of ICS UE in the CS domain, in international E.164 number format;

b) indicate within the SDP answer that the CS bearer is used in accordance with RFC 5939 [40]; and

c) indicate that the local preconditions for QoS as not met as specified in 3GPP TS 24.229 [11];

2) setup a CS call by sending a CC SETUP message in accordance with 3GPP TS 24.008 [7] for 3GPP systems. The UE shall populate the CC SETUP message for 3GPP systems as follows:

a) the called party BCD number information element set to the E.164 number obtained from the connection data capability attribute "ccap" received in the SDP body of the SIP INVITE request; and

b) Type Of Number is set to "International" and Numbering Plan Indicator set to "E.164".in the Called Party BCD Number information element.

3) when the resources are available to the UE, and if the UE has already received an indication from the origination side that related local preconditions for QoS as met on the originating side, shall send a SIP 180 (Ringing) response and continue the CS call setup as specified in 3GPP TS 24.229 [11]; and

4) if the UE fails to access the CS domain the UE shall send back a SIP 606 (Not Acceptable) response.

10.2.3 ICS UE using CS

An ICS UE shall implement the call termination suitable for ICS via CS domain as specified in 3GPP TS 24.008 [7] for 3GPP systems.

10.2.4 CS fallback

On the reception of an SIP INVITE request:

– if the SDP offer of the SIP INVITE request only includes audio media that can not be served via the current PS connectivity, the ICS UE shall send back a 488 (Not Acceptable Here) response without an SDP body;

NOTE: As an example the UE responds with a 488 (Not Acceptable Here) response when the ICS UE is unable to support the full duplex speech component of a session using the attached PS network or the attached PS network does not support or allow the full duplex speech component of a session.

– if the SDP offer of the SIP INVITE request includes audio media that cannot be served via the current PS connectivity but includes other media that can be served by the current PS connectivity, the ICS UE sends back a18x response including an SDP answer indicating rejection of the audio media and acceptance of the other media

10.2.5 ICS UE using I1

10.2.5.1 Call control over I1 and media over CS bearer

When the ICS UE receives an

a) I1 Invite message from the SCC AS, and the ICS UE determines that it is a mobile Terminated I1 Invite as specified in subclause 7.3.1 in 3GPP TS 24.294 [11B], the ICS UE shall handle the setting up of the I1 session following the procedures specified in subclause 6.2.1.2.2 in 3GPP TS 24.294 [11B]; or

b) I1 Invite (Augmentation) message from the SCC AS, and the ICS UE determines that no I1 session exists for the Call-Identifier value as specified in subclause 7.2.2.1.4 in 3GPP TS 24.294 [11B] received in the I1 Invite message, the ICS UE shall handle the setting up of the I1 session following the procedures specified in subclause 6.2.1.2.3 in 3GPP TS 24.294 [11B].

10.3 MSC Server enhanced for ICS

When the MSC server enhanced for ICS receives an initial SIP INVITE request from the IM CN subsystem, the MSC server enhanced for ICS shall return a 488 (Not Acceptable Here) response as described in 3GPP TS 24.229 [11] if the SIP INVITE request includes an SDP offer which does not contain an acceptable audio codec.

The MSC server enhanced for ICS shall save a copy of the P-Called-Party-ID header field if present in the received initial SIP INVITE request.

When the MSC server enhanced for ICS sends a 1xx or 2xx response the MSC server enhanced for ICS shall set the P-Asserted-Identity header field to the saved public user identity from the P-Called-Party-ID header field, if available.

The MSC server enhanced for ICS shall include a P-Access-Network-Info header field in the SIP response to the initial SIP INVITE request as specified in 3GPP TS 24.229 [11]. The P-Access-Network-Info header field shall contain:

a) an access-type field set to "3GPP-GERAN", "3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", or an access-class field set to "3GPP-GERAN", "3GPP-UTRAN;

b) a "cgi-3gpp" or "utran-sai-3gpp" parameter;

c) if available a "local-time-zone" parameter;

d) a "network-provided" parameter; and

e) if available a "daylight-saving-time" parameter.

The MSC server enhanced for ICS shall implement call termination as specified in 3GPP TS 29.292 [24].

When initiating a SIP failure response to any received request, depending on operator policy, the MSC server enhanced for ICS may insert a Response-Source header field with an "fe" header field parameter constructed with the URN namespace "urn:3gpp:fe", the fe-id part of the URN set to "msc-server" and the "role" header field parameter set to "msc-server-ics" in accordance with subclause 7.2.17 of 3GPP TS 24.229 [11].

10.4 SCC AS

10.4.1 General

The following subclauses describe the procedures at the SCC AS for call termination. In such scenarios, the SCC AS serves the terminating UE. The SCC AS shall follow procedures specified in 3GPP TS 24.229 [11] with the additional procedures described in the subsequent subclauses. These subclauses describe the procedures for the SCC AS when using service control over Gm, I1 and CS, respectively.

10.4.2 Terminating Access Domain Selection

When the SCC AS serving the terminating UE receives an initial SIP INVITE request due to initial filter criteria and a session used for IMS PS voice does not exist for the UE, the SCC AS may perform:

o) the procedures as described in 3GPP TS 29.328 [25] to determine if IMS voice over PS session is supported or unknown over the Radio Access Technology the UE is current on.

The SCC AS shall:

1) if a:

– session used for IMS PS voice does not exist for the UE and T-ADS functionality based upon criteria described in 3GPP TS 23.292 [6] results in choosing to deliver all media in the PS domain and to one or more registered contact(s) for the URI in the Request-URI of the SIP INVITE request; or

– session used for IMS PS voice exists for the UE;

and:

a) the registered contact(s) contain(s) the g.3gpp.ics media feature tag set to "principal" then:

i) insert the Accept-Contact header field containing the media feature tag g.3gpp.ics set to the value "principal" along with the parameters "require" and "explicit" into the SIP INVITE request; and

ii) follow the SCC AS procedures as in subclause 10.4.3;

b) the registered contact(s) contain(s) the g.3gpp.accesstype media feature tag but do not contain the g.3gpp.ics media feature tag set to "principal", then:

i) insert the Reject-Contact header field set to the g.3gpp.ics media feature tag into the SIP INVITE request; and

ii) follow the SCC AS procedures as defined in subclause 10.4.3;

c) the registered contact(s) do not contain the g.3gpp.ics media feature tag set to "principal"and do not contain the g.3gpp.accesstype media feature tag then:

i) insert the Reject-Contact header field set to the g.3gpp.ics and the g.3gpp.accesstype media feature tags into the SIP INVITE request; and

ii) forward the SIP INVITE request in accordance with 3GPP TS 24.229 [2];

NOTE: Where there is a mixture of contacts with or without the g.3gpp.ics media and g.3gpp.accesstype feature tags, the SCC AS can send more than one SIP INVITE request.

2) if T-ADS functionality based upon criteria described in 3GPP TS 23.292 [6] results in choosing to deliver media in the CS domain, and using CS domain service control:

a) at least one registered contact(s) contain(s) the g.3gpp.ics media feature tag set to "server", then follow the SCC AS procedures as defined in subclause 10.4.5; and

b) no registered contact(s) contain the g.3gpp.ics media feature tag set to "server", then follow the SCC AS procedures as defined in subclause 10.4.7;

3) if one or more registered contacts for the URI in the Request-URI of the SIP INVITE request contains the g.3gpp.ics media feature tag set to "principal", and if T-ADS functionality based upon criteria described in 3GPP TS 23.292 [6] results in choosing to deliver media in the CS domain, and using Gm for service control, then follow the SCC AS procedures defined in subclause 10.4.4;

3a) if:

i) one or more registered contacts for the URI in the Request-URI of the SIP INVITE request contains the g.3gpp.ics media feature tag set to "principal"or if local policy determines that the terminating UE is an ICS UE; and

ii) if T-ADS functionality based upon criteria described in 3GPP TS 23.292 [6] results in choosing to deliver media in the CS domain, and using I1 as specified in 3GPP TS 24.294 [11b] for service control;

then follow the SCC AS procedures defined in subclause 10.4.8; and

4) if one or more registered contacts for the URI in the Request-URI of the SIP INVITE request contains the g.3gpp.ics media feature tag set to "principal", and if T-ADS functionality based upon criteria described in 3GPP TS 23.292 [6] results in preferring the ICS UE to execute T-ADS to select an appropriate domain for the media bearer, the SCC AS shall create a SIP INVITE request based upon the incoming request including containing within the SDP offer with an RTP-based IP bearer and an alternative circuit-switched bearer as described in subclause 10.4.6 for the ICS UE to execute T-ADS.

10.4.3 SCC AS for call termination in IM CN

When the SCC AS serving the terminating ICS UE receives an initial SIP INVITE request due to initial filter criteria and the T-ADS results in choosing to deliver media in the PS domain, the SCC AS shall act as a B2BUA, and

– if multiple contacts are registered in the PS domain and the T-ADS chooses to establish different media types using different IP-CANs, the SCC AS shall for each selected PS domain IP-CAN create a SIP INVITE request in accordance with 3GPP TS 24.229 [2] and shall include, in this request;

i) an Accept-Contact header field containing the g.3gpp.accesstype media feature tag containing the value associated at registration with the selected PS domain IP-CAN;

NOTE 1: The SCC AS can determine which g.3gpp.accesstype media feature tag values to use by taking into account the access-type and access-class of the P-Access-Network-Info header and the value of the g.3gpp.accesstype media feature tag. The values in the 3gpp.accesstype media feature tag does not necessarily always identify an IP-CAN.

NOTE 2: It is possible that a handover between different IP-CANs can take place without a reregistration of the UE and corresponding update of access-type and access-class (e.g. from "3GPP-UTRAN" to "3GPP-E-UTRAN"). The SCC AS needs to take this possibility into account when determining the IP-CAN to use.

NOTE 3: If the SCC AS wants to preclude the request to be sent to the UE by the S-CSCF (through sequential forking) over a different IP-CAN than the one it explicitly selected, it needs to include the parameters "require" and "explicit" along with the g.3gpp.accesstype media feature tag. If it intends to allow the S-CSCF to fork between different IP-CANs, it can do that by excluding those parameters.

NOTE 4: If the SCC AS wants to preclude the SIP INVITE request to be sent to UEs by the S-CSCF (through forking) that are registered via an IP-CAN that is not suitable for the media described in the SDP, it can select the UE by including an Accept-Contact header field containing a sip.instance media feature tag of the selected UE along with the parameters "require" and "explicit", or by using a public GRUU of the selected UE as the Request URI.

ii) if an existing leg for this session already exists or is in the process of being established between the SCC AS and the UE using a different IP-CAN then a Target-Dialog header field containing the dialog parameters for that existing dialog between the SCC AS and the UE; and

NOTE 5: The SCC AS includes a Target-Dialog header field in the SIP INVITE request so that the ICS UE can correlate different requests as part of the same session.

iii) SDP for the media type(s) selected to be established using this IP-CAN.

– if multiple contacts are registered in the PS domain and the T-ADS chooses to establish all the media types over the same IP-CAN, the SCC AS shall create a SIP INVITE request in accordance with 3GPP TS 24.229 [2] and shall include, in this request:

i) an Accept-Contact header field containing the g.3gpp.accesstype media feature tag containing the value associated at registration with the selected PS domain IP-CAN;

NOTE 6: The SCC AS can determine which g.3gpp.accesstype media feature tag values to use by taking into account the access-type and access-class of the P-Access-Network-Info header field and the value of the g.3gpp.accesstype media feature tag. The values in the 3gpp.accesstype media feature tag does not necessarily always identify an IP-CAN.

NOTE 7: It is possible that a handover between different IP-CANs can take place without a reregistration of the UE and corresponding update of access-type and access-class (e.g. from "3GPP-UTRAN" to "3GPP-E-UTRAN"). The SCC AS needs to take this possibility into account when determining the IP-CAN to use.

NOTE 8: If the SCC AS wants to preclude the request to be sent to the UE by the S-CSCF (through sequential forking) over a different IP-CAN than the one it explicitly selected, it needs to include the parameters "require" and "explicit" along with the g.3gpp.accesstype media feature tag. If it intends to allow the S-CSCF to fork between different IP-CANs, it can do that by excluding those parameters.

NOTE 9: If the SCC AS wants to preclude the SIP INVITE request to be sent to UEs by the S-CSCF (through forking) that are registered via an IP-CAN that is not suitable for the media described in the SDP, it can select the UE by including an Accept-Contact header field containing a sip.instance media feature tag of the selected UE along with the parameters "require" and "explicit", or by using a public GRUU of the selected UE as the Request URI.

NOTE 10: The SCC AS includes a Target-Dialog header field in the SIP INVITE request so that the UE can correlate different requests as part of the same session.

iii) SDP for all the media types contained in the initial SIP INVITE request.

– if only a single contact is registered in the PS domain the SCC AS shall create a SIP INVITE request in accordance with 3GPP TS 24.229 [2] and shall include, in this request:

i) SDP for all the media types contained in the initial SIP INVITE request.

If the SCC AS receives a 488 (Not Acceptable Here) response, from:

– a UE:

i. not including any SDP body; or

ii. including an SDP body:

a) without a media description ("m=") indicating "audio";

b) with a media description ("m=") only indicating "audio" with the <proto> subfield set to "PSTN" and with a connection data line ("c=") with <nettype> set to "PSTN";

then, the SCC-AS may follow the procedures in:

1) subclause 10.4.5 if one or more registered contacts for the URI in the Request-URI of the initial SIP INVITE request contains the g.3gpp.ics media feature tag set to "server"; or

2) subclause 10.4.7.

If the SCC AS receives a18x response including an SDP answer with a media description ("m=") set to "audio" and port portion set to "0", the SCC AS may follow the procedures in subclause 10.4.5 or subclause 10.4.7.

10.4.4 SCC AS for call control over Gm and voice or voice and video over CS

When the SCC AS serving the ICS UE receives an initial SIP INVITE request due to initial filter criteria and the T-ADS results in choosing to deliver media in the CS domain, the SCC AS shall act as a B2BUA, the SCC AS shall:

0) store the information received in the initial SIP INVITE request received from the remote UE;

1) allocate an SCC AS PSI DN which is specified as an E.164 number, and shall identify and be associated with the stored information in step 1) and associated with the SCC AS ;

2) create a SIP INVITE request and include:

a) a Request-URI set to the value of the Request-URI as received in the incoming SIP INVITE request;

b) a dedicated Accept-Contact header field with a with the value of the g.3gpp.ics media feature tag set to "principal", and append "require" and "explicit";

NOTE 1: Other media feature tags can also be included in the dedicated Accept-Contact header field if the media feature tags have the same requirements on the "explicit" and "require" parameter.

b1) an Accept-Contact header field with the values received in the Accept-Contact header field in the incoming SIP INVITE except for any g.3gpp.ics media feature tags; and

NOTE 2: According to IETF RFC 3841 [35A] when the value of the "explicit" and "require" parameters are different for media feature tag values they will be placed in separate Accept-Contact header fields.

c) an SDP offer based on the received SDP from the originator and including the following:

i) in the SDP offer towards the terminating ICS UE, include an additional media line with media portion set to audio, port portion set to "9", proto portion set to "PSTN" and fmt portion set to "-", as described in IETF RFC 7195 [36] and may also include a CS video media stream according to the initial SIP INVITE received by the SCC AS;

ii) a media level "c=" line, , with the nettype portion set to "PSTN" and with the addrtype portion set to "E164" and the connection-address portion set to the SCC AS PSI DN allocated in step 1), in international E.164 number format, in accordance with IETF RFC 7195 [36];

iii) an a=setup attribute set to "passive"

iv) an a=connection attribute set to "new";

v) an a=cs-correlation attribute set to "callerid;

vi) codecs based on local policy and the received SDP offer from the remote UE; and

vii) an indication that preconditions are not met;

d) a new Record-Route header field that contains only a SIP URI pointing to the SCC AS; and

e) a Contact header field that includes the contents of the Contact header field received in the incoming initial SIP INVITE request; and

3) route the created SIP INVITE request towards the ICS UE.

When the SCC AS has received the 18x response containing the SDP answer accepting an audio stream over a circuit-switched bearer from the ICS UE and receives a SIP INVITE request with the Request-URI a valid SCC AS PSI DN as allocated in the above step 1and with the P-Asserted-Identity header field containing the E.164 number received in the a=cs-correlation attribute contained in the SDP answer from the response to the SIP INVITE request received from the ICS UE thenthe SCC AS shall:

1) check that the SCC AS PSN DN is encoded as a tel URI (see IETF RFC 3966 [42]) or SIP URI with the "user" SIP URI parameter set to "phone", in accordance with 3GPP TS 23.003 [4], subclause 13.5.

NOTE 3: The SCC AS could receive the SIP INVITE request before the SIP 18x response. IETF RFC 7195 [36] provides guidance on handling this situation.

2) use the SCC AS PSI DN and E.164 number received in the a=cs-correlation attribute contained in the SDP answer from the response to the SIP INVITE request received from the ICS UE to correlate the SCC AS PSI DN with the SIP INVITE request from the remote UE; and

3) send a response to the initial SIP INVITE request with the Request-URI containing the SCC AS PSI DN in accordance with 3GPP TS 24.229 [11], indicating local preconditions met.

When the SCC AS receives a 18x response containing the SDP answer accepting an audio stream over a circuit-switched bearer from the ICS UE and the SIP INVITE request with the Request-URI containing the SCC AS PSI DN number, the SCC AS shall generate a SIP 18x response toward the remote UE that includes the information received in the SIP 18x response with the following exceptions:

a) prepare an SDP answer to be sent to the originating UE. The SDP answer shall be based on the SDP answer received from the ICS UE and the SDP offer received from the initial SIP INVITE request with the Request-URI containing the SCC AS PSI DN. If the "m=" lines of the SDP offer from the CS domain includes more than one codecs the SCC AS shall delete the lowest priority codecs. The status line in the response sent to the originating UE shall be the same as received in the 18x response from the ICS UE. The SDP answer sent to the remote UE shall be in accordance with IETF RFC 3264 [31];

b) replace the Record-Route header field(s) received in the SIP 18x response with a new Record-Route header field that only contains a SIP URI pointing to the SCC AS; and

c) set the Contact header field to include the contents of the Contact header received in the SIP 183 (Session Progress) response, except the g.3gpp.ics media feature tag.

When the SCC AS gets aware that the remote precondition is fulfilled on the leg with the remote UE and on the leg with the CS domain, the SCC AS shall send a SIP UPDATE request to the ICS UE indicating that precondition is met.

When the SCC AS receives preconditions are met on the leg with the CS domain the SCC AS shall:

1) send a SIP 200 (OK) for the SIP UPDATE request on the leg with the CS domain; and

2) send a SIP 200 (OK) for the SIP INVITE request on the leg with the CS domain.

10.4.5 SCC AS for call termination to CS network via MSC Server enhanced for ICS

If the SCC AS receives:

– an initial SIP INVITE request due to the initial filter criteria;

– a 488 (Not Acceptable Here) response from the UE:

i. not including any SDP body; or

ii. including an SDP body:

a) without a media description ("m=") indicating "audio"; or

b) with a media description ("m=") only indicating "audio" with the <proto> subfield set to "PSTN" and with a connection data line ("c=") with <nettype> set to "PSTN";

– a 18x response from the UE including an SDP answer with a media description ("m=") set to "audio" and port portion set to "0"; or

– a 500 (Server Internal Error) response, which include a Reason header field, with a protocol value set to "FAILURE_CAUSE" in the "protocol" header field parameter and the "cause" header field parameter set to either "2" or "3" in accordance with subclause 7.2A.18.12.2 of 3GPP TS 24.229 [11];

then the SCC AS may select to complete session establishment in the CS domain via an MSC Server enhanced for ICS.

If the SCC AS selects to complete session establishment in the CS domain via an MSC Server enhanced for ICS, the SCC AS shall act as a B2BUA, the SCC AS shall create a SIP INVITE request in accordance with 3GPP TS 24.229 [11] with the following information;

1) shall set the Request-URI to the value of the Request-URI as received in the incoming SIP INVITE request; and

2) include in Accept-Contact header fields:

– the values received in the Accept-Contact header field(s) in the incoming SIP INVITE request except for any g.3gpp.ics media feature tags

– a g.3gpp.ics media feature tag with the value set to "server", appended with the value "explicit" and "require".

NOTE: According to IETF RFC 3841 [35A] when the value of the "explicit" and "require" parameters are different for media feature tag values they will be placed in separate Accept-Contact header fields.

10.4.6 SCC AS allowing UE to execute T-ADS

When the SCC AS serving the terminating ICS UE receives an initial SIP INVITE request due to initial filter criteria and the T-ADS results in allowing the ICS UE to execute T-ADS, the SCC AS shall act as a B2BUA, the SCC AS shall:

1) allocate an SCC AS PSI DN associated with the SCC AS and the SIP INVITE request from the originating UE;

2) create a SIP INVITE request and include the following:

a) set the Request-URI to the value as received in the Request-URI in the incoming SIP INVITE request;

b) a dedicated Accept-Contact header field with the value of the g.3gpp.ics media feature tag set to "principal", appended with the value "explicit" and "require";

NOTE 1: Other media feature tags can also be included in the dedicated Accept-Contact header field if the media feature tags have the same requirements on the "explicit" and "require" parameter.

b1) an Accept-Contact header field with media feature tag values received in the Accept-Contact header field(s) in the incoming SIP INVITE request except for any g.3gpp.ics media feature tags; and

NOTE 2: According to IETF RFC 3841 [35A] when the value of the "explicit" and "require" parameters are different for feature tag values they will be placed in separate Accept-Contact header fields.

c) within the SDP offer based on the received SDP from the originator, for every media line indicating audio set the following:

i) transport protocol within the media line to RTP-based IP bearer;

ii) related connection line to the value as received from the originator; and

iii) additional a-lines as defined in IETF RFC 5939 [40], IETF RFC 7006 [39], IETF RFC 7195 [36] and IETF RFC 6871 [41] indicating that:

– the required capability negotiation extensions attribute "creq" set to "med-v0", indicating that the SDP capability negotiation mechanism for negotiating media capabilities must be supported by the terminating UE in order to initiate T-ADS;

– the media capability attribute "omcap" with a "-" for the <encoding-name> ;

– the transport protocol capability attribute "tcap" set to "PSTN";

– the connection data capability attribute "ccap" with nettype set to "PSTN", indicating "E.164" as address type and the connection-address portion set to the SCC AS PSI DN allocated in step 1), in international E.164 number format. The SCC AS PSI DN identifies the stored information and is associated with the SCC AS;

– the related preconditions of the originating side are not met as specified in 3GPP TS 24.229 [11]; and

NOTE 3: In the case when the UE chooses to use the CS bearer, the resources are not available in the MGCF. Therefore, regardless on the current status of the resource reservation at the originating side, the SCC AS sets the preconditions to not met.

3) route the created SIP INVITE request towards the ICS UE.

Upon receipt of a SIP response to this SIP INVITE request, including an SDP answer indicating that the UE has chosen the RTP-based IP bearer, the SCC AS shall proceed in accordance with 3GPP TS 24.229 [11].

When the SCC AS receives a SIP INVITE request with the Request-URI containinga valid SCC AS PSI DN encoded as a tel URI (see IETF RFC 3966 [42]) or SIP URI with the "user" SIP URI parameter set to "phone", in accordance with 3GPP TS 23.003 [4], subclause 13.5 as allocated in the above step 1 then the SCC AS shall proceed as defined in subclause 10.4.4.

When the SCC AS has received the SIP 18x response containing the SDP answer accepting an audio stream over a circuit-switched bearer from the ICS UE;

a) and the UE indicates that service control will be via I1, and I1 is supported on the SCC AS, the SCC AS shall generate an I1 Invite message to the terminating ICS UE as specified in subclause 6.2.1.3.2.1 with the additions in accordance to the procedures in 3GPP TS 24.294 [11]; or

b) otherwise, the SCC AS shall proceed as defined in subclause 10.4.4.

If the SCC AS receives a SIP 488 (Not Acceptable Here) response, from a UE:

i. not including any SDP body; or

ii. including an SDP body:

a) without a media description ("m=") indicating "audio";

b) with a media description ("m=") only indicating "audio" with the <proto> subfield set to "PSTN" and with a connection data line ("c=") with <nettype> set to "PSTN";

then, the SCC-AS may follow the procedures in:

1) subclause 10.4.5 if one or more registered contacts for the URI in the Request-URI of the initial SIP INVITE request contains the g.3gpp.ics media feature tag set to "server"; or

2) subclause 10.4.7.

If the SCC AS receives a SIP 18x response including an SDP answer with a media description ("m=") set to "audio" and port portion set to "0", the SCC AS may follow the procedures in subclause 10.4.5 or subclause 10.4.7.

10.4.7 SCC AS for call termination over CS

If the SCC AS receives:

– an initial SIP INVITE request due to the initial filter criteria;

– a 488 (Not Acceptable Here) response from the UE:

i. not including any SDP body; or

ii. including an SDP body:

a) without a media description ("m=") indicating "audio"; or

b) with a media description ("m=") only indicating "audio" with the <proto> subfield set to "PSTN" and with a connection data line ("c=") with <nettype> set to "PSTN";

– a 18x response from the UE including an SDP answer with a media description ("m=") set to "audio" and port portion set to "0";

– a 500 (Server Internal Error) response from the UE, which includes a Reason header field, with a protocol value set to "FAILURE_CAUSE" in the "protocol" header field parameter and the "cause" header field parameter set to either "2" or "3" in accordance with subclause 7.2A.18.12.2 of 3GPP TS 24.229 [11]; or

– a 500 (Server Internal Error) response from the MSC server enhanced for ICS, which includes a Reason header field with a "protocol" header field parameter set to "Q.850" and a "cause" header field parameter set to value "20";

then the SCC AS may select to breakout to the CS domain.

If the SCC AS selects to breakout to the CS domain, the SCC AS retrieves via procedures as defined in subclause 6.4 the correlation MSISDN associated with the private user identity associated with the public user identity which is the served party of the session. The SCC AS shall, based on the correlation MSISDN, fetch a CSRN for routing the call to the CS domain. To perform CS breakout, the SCC AS shall act as B2BUA and shall create the SIP INVITE request in accordance to the procedures in 3GPP TS 24.229 [11] with the header fields as follows:

1) set the Request-URI of the outgoing SIP INVITE request to the CSRN;

2) set the To header field of the outgoing SIP INVITE request to the CSRN; and

NOTE 1: How the CSRN gets selected by the SCC AS is out of the scope of this specification.

3) if according to operator policy, include a Feature-Caps header field according to IETF RFC 6809 [48] with a "+g.3gpp.ics" header field parameter as described in clause B.4.

If required and the SCC AS has the network provided location information available, insert the P-Access-Network-Info header field in the SIP response to the initial SIP INVITE request as specified in 3GPP TS 24.229 [11]. The P-Access-Network-Info header field shall contain:

a) an access-type field set to "3GPP-GERAN", "3GPP-UTRAN-FDD", "3GPP-UTRAN-TDD", or an access-class field set to "3GPP-GERAN", "3GPP-UTRAN";

b) a "cgi-3gpp" or "utran-sai-3gpp" parameter;

c) if available a "local-time-zone" parameter;

d) if available a "daylight-saving-time" parameter; and

e) a "network-provided" parameter.

NOTE 2: The method for determining User Location Information (e.g. CGI or SAI) and/or UE Time Zone Information at the SCC AS is implementation dependant.

10.4.8 SCC AS for call control over I1 and media over CS

10.4.8.0 SCC AS sends I1 Invite message

When the SCC AS receives an initial SIP INVITE request from the remote UE destined for the serving ICS UE, and if upon performing the T-ADS, the SCC AS selects to deliver the media via the CS domain using the I1 protocol, the SCC AS shall:

1) store the information received in the initial SIP INVITE request received from the remote UE;

2) allocate the SCC AS PSI DN which is specified as an E.164 number, and shall identify and be associated with the stored information in step 1); and

3) use the information received in the initial SIP INVITE request to generate, store and forward an I1 Invite message toward the ICS UE in accordance with subclause 6.2.1.3.2.1 in 3GPP TS 24.294 [11B].

When the SCC AS receives a SIP INVITE request from the CS domain (via MGCF) with the Request-URI set to the allocated SCC AS PSI DN., the SCC AS shall:

0) check that the Request URI is

i) set to a valid SCC AS PSI DN as allocated in the above step 2, and

ii) the SCC AS PSI DN is encoded as a tel URI (see IETF RFC 3966 [42]) or SIP URI with the "user" SIP URI parameter set to "phone", in accordance with 3GPP TS 23.003 [4], subclause 13.5;

If the SCC AS PSI DN is valid and if the Timer(s) as specified in subclause 7.5.3.2.2.2 in 3GPP TS 24.294 [11B] has not expired, the SCC AS shall:

1) correlate the received SCC AS PSI DN contained in the Request URI of the SIP INVITE request received from the CS domain with the information saved in step 2 above;

2) send an 18x message that contains the SDP answer toward the remote UE. The SDP answer shall be based on the SDP offer received in the SIP INVITE request from the CS domain; and

3) create a response towards the CS domain in accordance with 3GPP TS 24.229 [11]. The response towards the CS domain shall contain the SDP answer. The SDP answer sent towards the CS domain is based on the SDP offer received in the initial SIP INVITE request previously received from the remote the UE.

If the SCC AS receives an I1 Progress message (with Reason field set to either 180 "Ringing" or 183 "Call Progress") over the I1 interface prior to receiving the SIP INVITE request from the CS domain, the SCC AS shall use the I1 Progress message in accordance with subclause 6.2.1.3.2.2 in 3GPP TS 24.294 [11B] and wait until the SIP INVITE request from the CS domain is received.

When the SCC AS receives an indication from the CS domain that the media resources are available (e.g. the SCC AS receives a SIP message from the MGCF) and upon receiving an I1 Progress message with Reason field set to 180 "Ringing", the SCC AS shall forward a SIP 180 (Ringing) response to the remote UE.

Upon receiving an I1 Success message from the ICS UE, the SCC AS shall forward a SIP 200 (OK) response to the remote UE.

Upon receiving a SIP ACK request from the remote UE, the SCC AS shall send a SIP ACK request towards the CS domain.

10.4.8.1 SCC AS receives a I1 Bye message

When the SCC AS enhanced for I1 receives a binary I1 Bye message using the I1 session control channel:

a) if there are no more I1 service control sessions using the CS bearer, then the SCC AS shall not transmit a I1 Success message using the I1 session control channel back to the ICS UE. If there are other I1 service control sessions using the CS bearer, then the SCC AS shall perform the procedures as in accordance with subclause 6.2.3.3.3 in 3GPP TS 24.294 [11B];

b) based on the value of the Call-Id information element included in the I1 Bye message, the SCC AS shall transmit the following SIP requests:

– if there are no more I1 service control sessions using the CS bearer associated with the value of the Call-Id information element, if a SIP BYE request from the CS domain has not been received, send a SIP BYE request to the CS domain; and

– release the SIP session by sending a SIP BYE request towards the B-party associated with the value of the Call-ID information element.

10.4.8.2 SCC AS receives a SIP Bye message from the CS domain

When the SCC AS enhanced for I1 receives a SIP BYE from the CS domain for a CS bearer:

– the CS bearer release timer shall be cleared, if set;

– respond with a SIP 200 (OK) response to the SIP BYE request;

10.4.8.3 SCC AS receives a SIP BYE message from a remote ICS UE

When the SCC AS receives a SIP BYE request from a remote ICS UE, it shall:

– respond with a SIP 200 (OK) response to the SIP BYE request;

– release the I1 session using an I1 Bye message according to subclause 6.2.3.3.1 in 3GPP TS 24.294 [11B];

– if there are no more I1 service control sessions using the CS bearer, set a CS bearer release timer value.

If the CS bearer release timer expires and no SIP BYE from the CS domain was released, the SCC AS shall release the CS bearer by sending a SIP BYE request to the CS domain. If the SCC AS receives an I1 Success act in accordance to subclause 6.2.3.3.2 in 3GPP TS 24.294 [11B].

10.4.8.4 SCC AS receives SIP error from remote UE

If the SCC AS receives a stastus line as specified in subclause 7.2 of IETF RFC 3261[45] with status code value 3xx to 6xx as specified in subclause 21.3-21.6 of IEFF RFC 3261 [45], the SCC AS shall:

a) send an I1 Failure message in accordance with subclause 6.2.1.4 in 3GPP TS 24.294 [11B] toward the UE.