12.4 MSC server enhanced for ICS

24.2373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuityRelease 17Stage 3TS

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

12.4.0 MSC server enhanced for ICS supporting PS to CS SRVCC

12.4.0.1 General

The MSC server enhanced for ICS supporting PS to CS SRVCC may support the codec inquiry prior to the PS to CS SRVCC access transfer.

When the MSC server enhanced for ICS supporting SRVCC receives an indication for a PS to CS SRVCC session transfer as described in 3GPP TS 23.216 [49], the MSC server may perform the codec inquiry prior to PS to CS SRVCC access transfer as specified in subclause 12.6.0A according to local policy.

NOTE: The local policy can be based on MSC server configuration of STN-SR(s) owned by ATCF(s) supporting the codec inquiry prior to PS to CS SRVCC access transfer.

If the MSC server enhanced for ICS supporting SRVCC does not support or does not perform the codec inquiry prior to PS to CS SRVCC access transfer as specified in subclause 12.6.0A, the MSC server shall perform the procedures in subclause 12.4.0.2

The MSC server enhanced for ICS supporting PS to CS SRVCC may support the codec re-negotiation after the PS to CS SRVCC access transfer as specified in subclause 12.6.0B.

12.4.0.2 PS to CS SRVCC access transfer

In order to perform the PS to CS SRVCC access transfer, the MSC server enhanced for ICS shall initiate a SIP INVITE request and shall:

1) set the Request-URI to the STN-SR for the session with speech media component to be transferred;

2) set the P-Asserted-Identity header field to the Correlation MSISDN;

3) set the Contact header field to the contact address of the MSC server;

4) include an SDP offer containing only a speech media component. If the MSC server performed procedures in subclause 12.6.0A and received a PS-to-CS-preparation-response, the MSC server should copy into the SDP offer one or more 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) indicated in the <IMS-preferred-codec-list> element of the received PS-to-CS-preparation-response described in subclause 12.6.0A;

5) if SRVCC with priority handling (as described in 3GPP TS 23.216 [49]) is supported and a Allocation/Retention priority (ARP) indication is received (as described in 3GPP TS 29.280 [71]), then include an authorised Resource-Priority header field;

NOTE 1: An MSC server enhanced for ICS will use local configuration to map the received ARP value to appropriate values for the authorised Resource-Priority header field.

6) if the MSC server supports the MSC server assisted mid-call feature:

A) insert the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20];

B) insert the Accept header field containing the MIME type as specified in subclause D.1.3;

C) include in the Contact header field the g.3gpp.mid-call media feature tag as described in annex C; and

D) insert the Recv-Info header field containing the g.3gpp.mid-call package name;

7) if the MSC server enhanced for ICS supports the PS to CS SRVCC for calls in alerting phase, then include:

A) void;

B) a Contact header field containing the g.3gpp.srvcc-alerting media feature tag as described in annex C;

C) void;

D) a P-Early-Media header field containing the "supported" parameter;

E) if the MSC server enhanced for ICS 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 into the Contact header field;

F) if the MSC server does not support the MSC server assisted mid-call feature, a Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20]; and

G) if the MSC server enhanced for ICS supports the PS to CS SRVCC for terminating calls in pre-alerting phase, include the g.3gpp. ps2cs-srvcc-term-pre-alerting media feature tag as described in annex C into the Contact header field;

NOTE 2: IETF RFC 3261 [19] recommends user agent client to include a Supported header field in any SIP INVITE request, listing option tags for extensions to SIP understood by the user agent client. In the step above, the MSC server is mandated to include at least "norefersub" option tag in the Supported header field.

NOTE 3: If the MSC server supports the MSC server assisted mid-call feature, a Supported header field containing the option-tag "norefersub" was already inserted in preceding steps.

8) if the MSC server supports CS to PS SRVCC:

A) the Recv-Info header field containing the g.3gpp.access-transfer-events info package name;

B) 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";

C) the Accept header field containing application/vnd.3gpp.srvcc-ext+xml MIME type; and

D) the g.3gpp.ti media feature tag with value as described in subclause C.12 in the Contact header field;

NOTE 4: An MSC server enhanced for ICS does not apply the ICS procedure described in 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4] when sending the SIP INVITE request.

9) 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;

10) a Recv-Info header field according to IETF RFC 6086 [54] containing the g.3gpp.state-and-event package name;

11) signalling elements described in subclause 6A.7.1 and shall indicate the related local preconditions as met; and

12) include the P-Access-Network-Info header field in the SIP INVITE request as specified in 3GPP TS 24.229 [2]. The P-Access-Network-Info header field shall include:

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) if available, 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.

Upon receiving a SIP 200 (OK) response as the first response to the INVITE due to STN-SR (with the exception of the SIP 100 (Trying) response) and if the MSC server does not apply the MSC server assisted mid-call feature procedures in subclause 12.4A, the MSC server shall enter the "active" (N10) state (defined in 3GPP TS 24.008 [8]), regard the access transfer of the session with active speech media component as completed, send an ACK request as specified in 3GPP TS 24.229 [2] and start interworking CC messages as specified in subclause 12.6.5.

If the MSC server enhanced for ICS supports the MSC server assisted mid-call feature, it shall additionally apply the procedures defined in subclause 12.4A.

If the MSC server enhanced for ICS supports the PS to CS SRVCC for calls in alerting phase procedures, it shall additionally apply the procedures defined in subclause 12.6.3.

After finishing the access transfer procedures and if the access transfer was successful, the MSC server enhanced for ICS shall apply the ICS procedure as specified in 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4].

If the access transfer procedure is unsuccessful and if the UE performs CS attachment procedures as specified in 3GPP TS 24.008 [8] after the unsuccessful access transfer procedure, then the MSC server enhanced for ICS shall apply procedures specified in 3GPP TS 29.292 [18] and 3GPP TS 24.292 [4].

12.4.0A MSC server enhanced for ICS procedures for Emergency Session Transfer

The MSC Server enhanced for ICS shall perform the procedures described in subclause 12.6.2 for the MSC server enhanced for SRVCC using SIP interface.

12.4.0B MSC server enhanced for ICS supporting vSRVCC

When the MSC server enhanced for ICS supporting vSRVCC receives an indication for a PS to CS SRVCC session transfer as described in 3GPP TS 23.216 [49], the MSC server enhanced for ICS supporting vSRVCC shall follow the procedures in subclause 12.4.0.

When an MSC server enhanced for ICS supporting vSRVCC receives an indication for a vSRVCC session transfer as described in 3GPP TS 23.216 [49], the MSC server enhanced for ICS shall initiate a SIP OPTIONS request and shall:

1) set the request URI to the STN-SR;

2) set the P-Asserted-Identity header field to the Correlation MSISDN;

3) set the Contact header field to the address of the MSC server; and

4) set the Accept header field to "application/sdp".

When the MSC server enhanced for ICS supporting vSRVCC receives a SIP 200 (OK) response to the SIP OPTIONS request with an SDP body that contains "m=" lines for audio and video, the MSC server enhanced for ICS shall:

1) initiate a SIP INVITE request and shall:

a) set the request URI to the STN-SR for the session with speech and video media components to be transferred;

b) set the P-Asserted-Identity header field to the Correlation MSISDN;

c) set the Contact header field to the address of the MSC server;

d) include an SDP offer only containing a speech media component and a video media component with default codecs for speech and video (as specified in 3GPP TS 26.111 [69]);

e) if the MSC server enhanced for enhanced for ICS supporting vSRVCC supports PS to CS access transfer for alerting calls, then include:

i) an Accept header field containing the MIME type application/vnd.3gpp.state-and-event-info+xml as specified in subclause D.2.3;

ii) a Contact header field containing the g.3gpp.srvcc-alerting media feature tag as described in annex C; and

iii) a Recv-Info header field containing the g.3gpp.state-and-event package name; and

f) if vSRVCC with priority handling (as described in 3GPP TS 23.216 [49]) is supported and a Allocation/Retention priority (ARP) indication is received (as described in 3GPP TS 29.280 [70]), then include an authorised Resource-Priority header field; and

NOTE: An MSC server enhanced for ICS will use local configuration to map the received ARP value to appropriate values for the authorised Resource-Priority header field.

2) if the MSC server enhanced for ICS supporting vSRVCC supports PS to CS access transfer for alerting calls, then additionally apply the procedures defined in subclause 12.6.3.

When an MSC server enhanced for ICS supporting vSRVCC receives a SIP 200 (OK) response to the SIP OPTIONS request with an SDP body that contains an "m=" line for audio but not video, the MSC server enhanced for ICS supporting vSRVCC shall follow the procedures in subclause 12.4.0.

12.4.1 Void

12.4.2 MSC server enhanced for ICS supporting CS to PS SRVCC

12.4.2.1 Distinction of requests

The MSC server needs to distinguish the following SIP requests:

1) SIP INFO request:

A) with Info-Package header field with value g.3gpp.access-transfer-events; and

B) with application/vnd.3gpp.access-transfer-events+xml MIME body associated with the info package according to IETF RFC 6086 [54] and indicating the session transfer notification response.

In the procedures below, such requests are known as "SIP INFO requests carrying the session transfer notification response".

12.4.2.2 General

If the MSC server supports the CS to PS SRVCC, upon receiving HO required for a UE including an indication that the HO is for CS to PS as described in 3GPP TS 23.216 [15] or if required by procedures in subclause 12.4.2.5, the MSC server shall:

1) determine the transferable dialog set which are all SIP dialogs:

A) interworked with the CS calls of the UE; and

B) supporting a session; and

2) if the determined transferable dialog set is not empty:

NOTE: If the determined transferable dialog set is empty, remaining procedures of this subclause are not invoked.

A) determine the dialog for communication with ATCF as follows:

a) if a CS call in Active (N10) state (defined in 3GPP TS 24.008 [8]) and Idle auxiliary state (defined in 3GPP TS 24.083 [43]) exists, the SIP dialog in the transferable dialog set, which is interworked with the CS call in Active (N10) state (defined in 3GPP TS 24.008 [8]) and Idle auxiliary state (defined in 3GPP TS 24.083 [43]); and

b) if a CS call in Active (N10) state (defined in 3GPP TS 24.008 [8]) and Idle auxiliary state (defined in 3GPP TS 24.083 [43]) does not exist, a SIP dialog in the transferable dialog set, which is interworked with any CS call; and

B) send a SIP INFO request according to 3GPP TS 24.229 [2] within the determined dialog for communication with ATCF. The MSC server shall populate the SIP INFO request with:

a) Info-Package header field with value g.3gpp.access-transfer-events; and

b) application/vnd.3gpp.access-transfer-events+xml MIME body associated with the info package according to IETF RFC 6086 [54] and indicating the session transfer notification request.

Upon receiving SIP INFO request carrying the session transfer notification response within the determined dialog for communication with ATCF, the MSC server shall:

1) send a SIP 200 (OK) response to the SIP INFO request according to 3GPP TS 24.229 [2];

2) if the application/vnd.3gpp.access-transfer-events+xml MIME body indicates that the ATCF does not require the MSC server to redirect the speech media component of the session transferred by the CS to PS SRVCC access transfer, continue handling the procedures in the subclause 12.4.2.3; and

3) if the application/vnd.3gpp.access-transfer-events+xml MIME body indicates that the ATCF requires the MSC server to redirect the speech media component of the session transferred by the CS to PS SRVCC access transfer, continue handling the procedures in the subclause 12.4.2.4.

12.4.2.3 Transfer of session without MSC server redirecting the speech media component

If the MSC server supports the CS to PS SRVCC, if the access transfer is prepared according to 3GPP TS 23.216 [15] and if the ATGW does not require the MSC server to redirect the speech media component of the session transferred by the CS to PS SRVCC access transfer, the MSC server shall:

1) send a SIP INFO request according to 3GPP TS 24.229 [2] within determined dialog for communication with ATCF. The MSC server shall populate the SIP INFO request with:

A) Info-Package header field with value g.3gpp.access-transfer-events; and

B) application/vnd.3gpp.access-transfer-events+xml MIME body associated with the info package according to IETF RFC 6086 [54] and indicating the session transfer preparation.

If the MSC server supports the CS to PS SRVCC, if the ATGW does not require the MSC server to redirect the speech media component of the session transferred by the CS to PS SRVCC access transfer and if the access transfer is cancelled according to 3GPP TS 23.216 [15], the MSC server shall send a SIP INFO request according to 3GPP TS 24.229 [2] within determined dialog for communication with ATCF. The MSC server shall populate the SIP INFO request with:

1) Info-Package header field with value g.3gpp.access-transfer-events; and

2) application/vnd.3gpp.access-transfer-events+xml MIME body associated with the info package according to IETF RFC 6086 [54] and indicating the session transfer cancellation.

12.4.2.4 Transfer of session with MSC server redirecting the speech media component

When the ATGW requires the MSC server to redirect the speech media component of the session transferred by the CS to PS SRVCC access transfer, the MSC server shall:

1) send a SIP INVITE request according to 3GPP TS 24.229 [2]. The MSC server shall populate the SIP INVITE request with:

A) the Request-URI header field set to the ATCF management URI;

B) Contact header field set to the IP address of MSC server;

C) SDP body includes the speech media component of the session transferred by the CS to PS SRVCC access transfer; and

D) the P-Asserted-Identity header field set to the C-MSISDN.

If the access transfer is prepared according to 3GPP TS 23.216 [15] and after the MSC server redirect the speech media component of the session transferred by the CS to PS SRVCC access transfer to the ATGW, the MSC server shall:

1) send a SIP INFO request according to 3GPP TS 24.229 [2] within dialog for communication with ATCF. The MSC server shall populate the SIP INFO request with:

A) Info-Package header field with value g.3gpp.access-transfer-events; and

B) application/vnd.3gpp.access-transfer-events+xml MIME body associated with the info package according to IETF RFC 6086 [54] and indicating the session transfer preparation.

If the MSC server supports the CS to PS SRVCC, if the access transfer is cancelled according to 3GPP TS 23.216 [15], the MSC server shall send a SIP INFO request according to 3GPP TS 24.229 [2] within determined dialog for communication with ATCF. The MSC server shall populate the SIP INFO request with:

1) Info-Package header field with value g.3gpp.access-transfer-events; and

2) application/vnd.3gpp.access-transfer-events+xml MIME body associated with the info package according to IETF RFC 6086 [54] and indicating the session transfer cancellation.

12.4.2.5 Abnormal cases

If the dialog for communication with ATCF is released after receiving HO required for a UE including an indication that the HO is for CS to PS as described in 3GPP TS 23.216 [15] and before sending of the CS to PS handover command as described in 3GPP TS 23.216 [15], the MSC shall perform the procedures in subclause 12.4.2.2 again.

12.4.3 Abnormal cases

12.4.3.1 Permanent response codes

When the MSC server enhanced for ICS receives a SIP reject response to the SIP INVITE request due to STN-SR or SIP INVITE request due to E-STN-SR, the MSC server shall regard any of the following SIP reject responses as permanent errors:

– SIP 404 (Not found);

– SIP 410 (Gone);

– SIP 484 (Address Incomplete); and

– SIP 604 (Does not exist anywhere).

The MSC server enhanced for ICS shall regard all other received SIP reject responses to the SIP INVITE request due to STN-SR or SIP INVITE request due to E-STN-SR as temporary errors.

NOTE: The procedures in 3GPP TS 29.280 [71] requires that the MSC server indicates whether a received SIP reject response to the SIP INVITE request due to STN-SR or SIP INVITE request due to E-STN-SR is temporary or permanent.

12.4.3.2 PS to CS SRVCC cancelled by MME/SGSN or failure of the access transfer procedure in the MSC server

If the MSC server enhanced for ICS receives a SRVCC PS to CS Cancel Notification from the MME/SGSN or if the access transfer procedure fails for any other reason in the MSC server enhanced for ICS, the MSC server shall:

1) in the dialog created by the SIP INVITE request due to STN-SR or SIP INVITE request due to E-STN-SR:

a) if the dialog is a dialog with inactive or active speech media component, send a SIP BYE request; and

b) if the dialog is in the pre-alerting phase or in the alerting phase, send a SIP BYE request or a SIP CANCEL request;

2) if the MSC server applies the MSC server assisted mid-call feature, in the dialog created by the SIP INVITE for the additional transferred session;

a) if the dialog is a dialog with inactive speech media component, send a SIP BYE request; and

b) if the dialog is in the pre-alerting phase or in the alerting phase, send a SIP BYE request or a SIP CANCEL request;

3) if the cancellation is due to SRVCC PS to CS Cancel Notification from the MME/SGSN, include in the SIP request a Reason header field with the protocol value "Q.850" and the "cause" header field parameter with the value "31" (normal unspecified); and

4) if the cancellation is due to any other reason than SRVCC PS to CS Cancel Notification from the MME/SGSN, include in the SIP request a Reason header field with the protocol value "Q.850" and the "cause" header field parameter with a value different from"31", e.g. "41" (temporary failure) or "16" (normal clearing).

NOTE: The inclusion of the protocol value "Q.850" and the "cause" header field parameter with the value "31" (normal unspecified) will result in that the SCC AS delays the release of the source access leg and the remote UE leg allowing the SC UE to continue the call in PS.

If after having sent a SIP CANCEL request:

a) to a SIP INVITE request due to STN-SR; or

b) if the MSC server applies the MSC server assisted mid-call feature, to a SIP INVITE request for the additional transferred session,

and subsequently receiving a SIP 200 (OK) response to such a SIP INVITE request, the MSC server shall send a SIP BYE request containing a Reason header field with the same protocol value and the same "cause" header field as used in the SIP CANCEL request.

12.4.3.3 Guard timer for the CC CONNECT request elapses

NOTE: Timer T313 defined in 3GPP TS 24.008 [8] supervises a CC CONNECT message sent by the MSC server.

If after having sent a CC CONNECT message, the timer that supervises the CC CONNECT message expires before the MSC server has received a CC CONNECT ACK message, the MSC server shall send a SIP BYE request on the SIP dialog created by the SIP INVITE due to STN-SR, by following the rules of 3GPP TS 24.229 [2].