12.6 MSC server enhanced for SRVCC using SIP interface

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.6.0 General

The MSC server enhanced for SRVCC using SIP interface may support the codec inquiry prior to the PS to CS SRVCC access transfer.

When the MSC server enhanced for SRVCC using SIP interface 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 SRVCC using SIP interface 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.6.1.

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

12.6.0A Codec inquiry prior to PS to CS SRVCC access transfer

In order to perform the codec inquiry prior to PS to CS SRVCC access transfer, the MSC server shall send a SIP OPTIONS request according to 3GPP TS 24.229 [2]. In the SIP OPTIONS request, the MSC server:

1) shall set the Request-URI to the STN-SR received over Sv interface as described in 3GPP TS 23.216 [49];

2) shall set the P-Asserted-Identity header field to the C-MSISDN received over Sv interface as described in 3GPP TS 23.216 [49]; and

3) shall include an application/vnd.3gpp.PS-to-CS-preparation+xml body specified in subclause D.6 carrying the PS-to-CS-preparation-request. In the PS-to-CS-preparation-request, the MSC server may include an <MSC-server-supported-codec-list> element containing an SDP body with one audio m= line with one or more RTP payload types that are supported commonly by the served SC UE, the target RAN and the target CS-MGW selected by the MSC server. The MSC server shall associate the RTP payload type(s) with the RTP payload type number(s) according to local policy.

If no SIP final response is received within a time defined by local policy to the SIP OPTIONS request, the MSC server shall perform the procedures in subclause 12.6.1 or subclause 12.4.0.2.

Upon receiving a SIP 3xx, 4xx, 5xx or 6xx response to the SIP OPTIONS request, the MSC server shall perform the procedures in subclause 12.6.1 or subclause 12.4.0.2.

Upon reception of a SIP 2xx response to the SIP OPTIONS request:

1) if the SIP 2xx response does not contain an application/vnd.3gpp.PS-to-CS-preparation+xml body specified in subclause D.6 carrying the PS-to-CS-preparation-response, the MSC server shall perform the procedures in subclause 12.6.1 or subclause 12.4.0.2; and

2) if the SIP 2xx response contains an application/vnd.3gpp.PS-to-CS-preparation+xml body specified in subclause D.6 carrying the PS-to-CS-preparation-response, the MSC server:

a) if the PS-to-CS-preparation-response indicates that the PS to CS SRVCC access transfer is currently possible, shall perform the procedures in subclause 12.6.1 or subclause 12.4.0.2; and

b) if the PS-to-CS-preparation-response indicates that the PS to CS SRVCC access transfer is currently not possible, can send SRVCC PS to CS Response as specified in 3GPP TS 23.216 [49] with a reject cause or can repeat the procedures of the present subclause after a time defined by local policy.

12.6.0B Codec re-negotiation after session transfer

If a PS to CS SRVCC access transfer has been successfully performed, different RTP payload types were selected during the PS to CS SRVCC access transfer on the CS radio interface and on the dialog in the IMS towards the remote peer, the MSC server may send a SIP re-INVITE request or a SIP UPDATE request on the dialog in the IMS towards the remote peer. In the SIP re-INVITE request or the SIP UPDATE request, the MSC server shall include an SDP offer. In the SDP offer, the MSC server shall indicate a speech media component with RTP payload types supported by the MSC server, with the RTP payload type used at the CS radio interface as the most preferred RTP payload type.

NOTE: If the RTP payload type used at the CS radio interface is compatible with the RTP payload type of the speech media component used on the dialog in the IMS towards the remote peer, then the MGW controlled by the MSC server can influence the encoding of RTP packets by the remote peer using a media plane means, e.g. Codec Mode Request of AMR-WB or EVS sent within the media stream of the speech media component, as described in 3GPP TS 26.114 [68].

12.6.1 Session transfer from MSC server enhanced for SRVCC using SIP interface

12.6.1.1 Session transfer from MSC server enhanced for SRVCC using SIP interface supporting PS to CS SRVCC

In order to perform the PS to CS SRVCC access transfer, the MSC server enhanced for SRVCC using SIP interface 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;

NOTE 1: In deployments without IMS-level roaming interfaces, where the UE is a roaming UE, the MSC server can route the SIP INVITE request based on configuration or translate the STN-SR to a globally routable SIP URI using either an ENUM/DNS translation mechanism or any other available database, or route the SIP INVITE request by any other means.

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; and

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 2: An MSC server enhanced for SRVCC using a SIP interface 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 SRVCC using SIP interface supports the PS to CS SRVCC for calls in alerting phase, then include:

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

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

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

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

e) if the MSC server enhanced for SRVCC using SIP interface 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 SRVCC using SIP interface 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 3: 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 4: 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) signalling elements described in subclause 6A.7.1 and shall indicate the related local preconditions as met; and

9) include the P-Access-Network-Info header field in the SIP INVITE request as specified in 3GPP TS 24.229 [11]. 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 SRVCC using SIP interface supports the MSC server assisted mid-call feature then it shall additionally apply the procedures defined in subclause 12.4A.

If the MSC server enhanced for SRVCC using SIP interface supports the PS to CS SRVCC for calls in alerting phase then in addition to the procedures in this subclause it shall additionally apply the procedures defined in subclause 12.6.3.

12.6.1.2 Session transfer from MSC server enhanced for SRVCC using SIP interface supporting vSRVCC

When an MSC server enhanced for SRVCC using SIP interface and supporting vSRVCC receives an indication for a vSRVCC session transfer as described in 3GPP TS 23.216 [49], then the MSC server enhanced for SRVCC using SIP interface 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 an MSC server enhanced for SRVCC using SIP interface and 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 SRVCC using SIP interface 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 containing only 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 SRVCC using SIP interface supports the PS to CS SRVCC for calls in alerting phase, 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;

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 SRVCC using a SIP interface 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 SRVCC using SIP interface supports the PS to CS SRVCC for calls in alerting phase, then additionally apply the procedures defined in subclause 12.6.3.

Upon receiving 200 (OK) response to the INVITE due to STN-SR the MSC server shall regard the access transfer of session with active speech and video media components 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.When an MSC server enhanced for SRVCC using SIP interface and 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 SRVCC using SIP interface shall follow the procedures in subclause 12.6.1.1.

12.6.2 Emergency session transfer from MSC server enhanced for SRVCC using SIP interface

When an MSC server enhanced for SRVCC using SIP interface receives an indication for a session transfer for an emergency session as described in 3GPP TS 23.216 [49], then the MSC server enhanced for SRVCC using SIP interface shall initiate a SIP INVITE request and shall:

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

2) include the sip.instance media feature tag as specified in IETF RFC 5626 [22] with a value based on the IMEI as defined in 3GPP TS 23.003 [12] in the Contact header field;

3) set the P-Asserted-Identity header field to the Correlation MSISDN if one is available;

4) include an SDP offer with media which the MSC server wishes to use in the session;

5) include the P-Access-Network-Info header field in the SIP INVITE request as specified in 3GPP TS 24.229 [11]. 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; and

6) if the MSC server enhanced for SRVCC using SIP interface supports the PS to CS SRVCC for originating emergency sessions in alerting phase, then include:

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

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

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

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

e) if the MSC server enhanced for SRVCC using SIP interface supports the PS to CS SRVCC for originating emergency sessions 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.

Upon receiving a SIP 200 (OK) response as the first response to the INVITE due to E-STN-SR (with the exception of the SIP 100 (Trying) response), 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 SRVCC using SIP interface supports the PS to CS SRVCC for originating emergency sessions in alerting phase then in addition to the procedures in this subclause it shall additionally apply the procedures defined in subclause 12.6.3.

12.6.3 MSC server enhanced for SRVCC using SIP interface procedures for PS to CS access transfer for calls in alerting phase or pre-alerting phase

Upon receiving a SIP 1xx response with P-Early-Media header field authorizing backward early media, unless the CS-MGW has already been through-connected, the MSC server instructs the CS-MGW to through-connect.

Upon receiving a SIP INFO request inside the early dialog created with the SIP INVITE request due to STN-SR or E-STN-SR:

1. with the Info-Package header field containing the g.3gpp.state-and-event; and

2. containing an application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package according to IETF RFC 6086 [54] and compliant to the XML schema specified in the subclause D.2 with the state-info XML element containing "early" and direction XML element containing "initiator";

the MSC server enhanced for SRVCC using SIP interface shall enter the "call delivered" (N4) state as specified in 3GPP TS 24.008 [8]. The MSC server enhanced for SRVCC using SIP interface shall associate this session with transaction identifier value and TI flag as described in 3GPP TS 24.008 [8], regard the access transfer of the session in the alerting phase as completed and start interworking CC messages as specified in subclause 12.6.5.

If the MSC server enhanced for SRVCC using SIP interface supports the PS to CS SRVCC for originating calls in pre-alerting phase then upon receiving a SIP INFO request inside the early dialog created with the SIP INVITE request due to STN-SR or E-STN-SR:

1. with the Info-Package header field containing the g.3gpp.state-and-event; and

2. containing an application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package according to IETF RFC 6086 [54] and compliant to the XML schema specified in the clause D.2 with the state-info XML element containing "pre-alerting" and direction XML element containing "initiator";

the MSC server enhanced for SRVCC using SIP interface shall associate this session with transaction identifier value and TI flag as described in 3GPP TS 24.008 [8] and shall enter the state "Mobile originating call proceeding" (N3) as specified in 3GPP TS 24.008 [8], regard the access transfer of the session in the originating pre-alerting phase as completed and start interworking CC messages as specified in subclause 12.6.5.

NOTE 1: The MSC server enhanced for SRVCC using SIP interface can send CC PROGRESS message to the UE to prevent CS call release early.

If the MSC server enhanced for SRVCC using SIP interface supports the PS to CS SRVCC for terminating calls in pre-alerting phase then upon receiving a SIP INFO request inside the early dialog created with the SIP INVITE request due to STN-SR:

1. with the Info-Package header field containing the g.3gpp.state-and-event; and

2. containing an application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package according to IETF RFC 6086 [54] and compliant to the XML schema specified in the clause D.2 with the state-info XML element containing "pre-alerting" and direction XML element containing "receiver";

Upon receiving a SIP INFO request inside the early dialog created with the SIP INVITE request due to STN-SR:

1. with the Info-Package header field containing the g.3gpp.state-and-event; and

and when a related CC CONNECT has not been received, the MSC server enhanced for SRVCC using SIP interface shall enter the "call received" (N7) state as specified in 3GPP TS 24.008 [8]. The MSC server enhanced for SRVCC using SIP interface will not generate an in-band ring tone towards the calling party. The MSC server enhanced for SRVCC using SIP interface shall associate this session with transaction identifier value and TI flag as described in 3GPP TS 24.008 [8]. If the CS-MGW has already been through-connected, the MSC server instructs the CS-MGW not to through-connect. The MSC server shall regard the access transfer of the session in the alerting phase as completed and start interworking CC messages as specified in subclause 12.6.5.

Upon receiving a CC ALERT message when in "Mobile terminating call confirmed" (N9) state as specified in 3GPP TS 24.008 [8], the MSC server enhanced for SRVCC using SIP interface shall send a SIP INFO request inside the dialog created with the SIP INVITE request due to STN-SR for access transfer containing:

1. an Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info package name; and

2. include application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package according to IETF RFC 6086 [54] and compliant to the XML schema specified in the subclause D.2 with the event XML element containing "alerting-started" to indicate that the called party is being alerted.

Upon receiving a CC CONNECT message when in "call received" (N7) state as specified in 3GPP TS 24.008 [8], the MSC server enhanced for SRVCC using SIP interface shall send a SIP INFO request inside the dialog created with the SIP INVITE request due to STN-SR for access transfer containing:

1. an Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info package name; and

2. include application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package according to IETF RFC 6086 [54] and compliant to the XML schema specified in the subclause D.2 with the event XML element containing "call-accepted" to indicate that the called party has answered the call.

NOTE 2: At this point the MSC server enters the "active" (N10) state in accordance with 3GPP TS 24.008 [8] subclause 5.2.2.6 including instructing the CS-GW to through-connect in both directions.

Upon receiving a CC CONNECT message after having sent the SIP INVITE request due to STN-SR when not yet in "call received" (N7) state as specified in 3GPP TS 24.008 [8], the MSC server enhanced for SRVCC using SIP interface shall store this event and proceed with the procedures in 3GPP TS 24.008 [8] subclause 5.2.2.6.

NOTE 3: At this point the MSC server enters the "active" (N10) state in accordance with 3GPP TS 24.008 [8] subclause 5.2.2.6 including instructing the CS-GW to through-connect in both directions.

Once a related SIP INFO request inside the associated early dialog:

1. with the Info-Package header field containing the g.3gpp.state-and-event; and

is received, then

1. void; and

2. the MSC server shall send a SIP INFO request inside the dialog created with the SIP INVITE request due to STN-SR for access transfer containing:

a) an Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info package name; and

b) include application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package according to IETF RFC 6086 [54] and compliant to the XML schema specified in the subclause D.2 with the event XML element containing "call-accepted" to indicate that the called party has answered the call.

NOTE 4: Procedures in the MSC server enhanced for SRVCC using SIP interface on how to store and supervise the reception of the INFO request are left implementation specific.

Upon receiving a SIP REFER request:

1. sent inside the dialog created by the SIP INVITE request due to STN-SR where a received Feature-Caps header field contains the g.3gpp.srvcc-alerting feature-capability indicator as described in annex C;

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 application/vnd.3gpp.state-and-event-info+xml MIME body with the state-info XML element containing "early" or "pre-alerting";

the MSC server shall:

1. handle the SIP REFER request as specified in 3GPP TS 24.229 [2], IETF RFC 3515 [13] as updated by IETF RFC 6665 [81], and IETF RFC 4488 [20] without establishing an implicit subscription; and

NOTE 5: In accordance with IETF RFC 4488 [20], the MSC server inserts the Refer-Sub header field containing the value "false" in the SIP 2xx response to the SIP REFER request to indicate that it has not created an implicit subscription.

2. send a SIP INVITE request transferring the additional transferred session according to 3GPP TS 24.229 [2] and IETF RFC 3515 [13]. The MSC server shall populate the SIP INVITE request as follows:

A. header fields which were included in the URI in the Refer-To header field of the received SIP REFER request as specified in IETF RFC 3261 [19] except the header field with hname "body";

B. include the g.3gpp.srvcc-alerting media feature tag as described in annex C in the Contact header field according to IETF RFC 3840 [53];

C. if the MSC server enhanced for SRVCC using SIP interface 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 in the Contact header field according to IETF RFC 3840 [53]; and

D. the SDP offer with:

a. the same amount of the media descriptions as in the header field with hname "body" in the URI in the Refer-To header field of the received SIP REFER request;

b. each "m=" line having the same media type as the corresponding "m=" line in the header field with hname "body" in the URI in the Refer-To header field of the received SIP REFER request;

c. port set to zero value in each "m=" line whose corresponding "m=" line in the header field with hname "body" in the URI in the Refer-To header field of the received SIP REFER request has port with zero value; and

d. payload type numbers and their mapping to codecs and media parameters supported by MSC server, not conflicting with those in the "body" URI header field in the URI in the Refer-To header field of the received SIP REFER request; and

NOTE 6: Port can be set to zero or non zero value for the offered "m=" line whose corresponding "m=" line in the header field with hname "body" in the URI in the Refer-To header field of the received SIP REFER request has port with nonzero value.

E. if the MSC server supports CS to PS SRVCC and the SIP REFER request contains the application/vnd.3gpp.srvcc-ext+xml MIME body:

a) the topmost Route header field with the ATCF management URI received in the application/vnd.3gpp.srvcc-ext+xml MIME body of the SIP REFER request and "lr" URI parameter;

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 Recv-Info header field containing the g.3gpp.access-transfer-events info package name;

d) the application/vnd.3gpp.srvcc-ext+xml MIME body with the <srvcc-ext> root element containing the <Setup-info> element containing the CS to PS SRVCC information received in the application/vnd.3gpp.srvcc-ext+xml MIME body of the SIP REFER request and indicating the "initiator" role of the MSC server in the session set up; and

e) the g.3gpp.ti media feature tag with value as described in subclause C.12 in the Contact header field according to IETF RFC 3840 [53];

F. if the MSC server supports procedures in subclause 22.2:

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

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

H. include the P-Access-Network-Info header field in the SIP INVITE request as specified in 3GPP TS 24.229 [11]. 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; and

I. if an authorised Resource-Priority header field was included in the SIP INVITE request due to STN-SR, then include an authorised Resource-Priority header field with the same values as used in the SIP INVITE request due to STN-SR; and

J. if a P-Asserted-Identity header field is not included in the headers portion of the URI in the Refer-To header field of the received SIP REFER request as specified in IETF RFC 3261 [19], include a P-Asserted-Identity header field with the value of the C-MSISDN contained in the SIP INVITE requests due to STN-SR which created the dialog in which the REFER request is received;

3. if application/vnd.3gpp.state-and-event-info+xml MIME body contains the state-info XML element containing "early" and the direction XML element containing "initiator", then enter the "call delivered" (N4) state as specified in 3GPP TS 24.008 [8] for the CS call with transaction identifier 1 and TI flag value as in mobile terminated call;

4. if application/vnd.3gpp.state-and-event-info+xml MIME body contains the state-info XML element containing "early" and the direction XML element containing "receiver", then enter the "call received" (N7) state as specified in 3GPP TS 24.008 [8] for the CS call with transaction identifier 1 and TI flag value as in mobile terminated call. The MSC server will not generate an in-band ring tone towards the calling party; and

5. if application/vnd.3gpp.state-and-event-info+xml MIME body contains the state-info XML element containing "pre-alerting" and the direction XML element containing "initiator", then enter the "Mobile originating call proceeding" (N3) state as specified in 3GPP TS 24.008 [8] for the CS call with transaction identifier 1 and TI flag value as in mobile terminated call.

Upon receiving the SIP 183 (Session Progress) response to the SIP INVITE request transferring the additional transferred session, the MSC server shall regard the access transfer of the additional session as completed, send a SIP PRACK request as specified in 3GPP TS 24.229 [2] and start interworking CC messages as specified in subclause 12.6.5.

Upon receiving a CC CONNECT message with transaction identifier 1 and TI flag value as in mobile terminated call when in "call received" (N7) state as specified in 3GPP TS 24.008 [8], the MSC server shall send a SIP INFO request inside the dialog created by the SIP INVITE request transferring the additional transferred session containing:

NOTE 7: If the SIP INVITE request transferring the additional transferred session has already been sent and an early dialog has not been established by a SIP response to the SIP INVITE request transferring the additional transferred session yet, the MSC server delays sending of the SIP INFO request till after an early dialog is established by a SIP response to the SIP INVITE request transferring the additional transferred session.

1. an Info-Package header field as specified in IETF RFC 6086 [54] with 3gpp.state-and-event info package name; and

2. include application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package according to IETF RFC 6086 [54] and compliant to the XML schema specified in the clause D.2 with the event XML element containing "call-accepted" to indicate that the called party has answered the call.

NOTE 8: At this point the MSC server enters the "active" (N10) state in accordance with 3GPP TS 24.008 [8] subclause 5.2.2.6 including instructing the CS-GW to through-connect in both directions.

NOTE 9: Prior to sending a CC CONNECT, the MSC can send a CC PROGRESS message to attach the user connection (as specified in 3GPP TS 24.008 [8]) to allow the network to provide in-band tones and announcements to the UE, overriding any internally generated alerting indication in the UE.

NOTE 10: The procedure in subclause 5.2.1.6 of 3GPP TS 24.008 [8] results in that the MSC server will instruct the CS-GW to through-connect in both direction and then, after an acknowledgment from the SC UE, the MSC server enters the "active" (N10) state.

NOTE 11: When the access transfer is completed the MSC server can verify the call state of its peer entity using the STATUS ENQUIRY procedure in accordance with procedures in 3GPP TS 24.008 [8] to ensure that SIP requests or SIP responses that have been sent between the SC UE and the SCC AS or the EATF during the handover from the PS domain to the CS domain did not result in incompatible call states. If the call states are incompatible the transferred session are released.

12.6.4 Abnormal cases

12.6.4.1 Permanent response codes

When the MSC server enhanced for SRVCC using SIP interface receives a SIP reject response to the SIP INVITE request due to STN-SR, the MSC server shall regard the SIP response codes listed in subclause 12.4.3.1 as permanent errors.

12.6.4.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 SRVCC using SIP interface 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 SRVCC using SIP interface, the MSC server shall perform the actions in the subclause 12.4.3.2.

12.6.4.3 Guard timer for the CC CONNECT request elapses

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 perform the actions specified in subclause 12.4.3.3.

12.6.5 Interworking of CC messages and SIP messages when PS to CS SRVCC access transfer is completed

When the PS to CS SRVCC access transfer procedure is completed the MSC server shall interwork between the 3GPP profile of SIP as described in 3GPP TS 24.229 [2] and NAS signalling as described in 3GPP TS 24.008 [8] required for the support of IM CN subsystem based multimedia telephony and supplementary services as specified in 3GPP TS 29.292 [18] with the clarifications and exceptions described in this subclause.

When the MSC server is in the "mobile originating call proceeding" (N3) state, the MSC server shall perform interworking as specified in 3GPP TS 29.292 [18] subclauses 5.3.4, 5.3.4a, 5.3.4b, 5.3.6, 5.3.7, 5.3.8 and 5.3.9.When the MSC server is in the "call delivered" (N4) state, the MSC server shall perform interworking as specified in 3GPP TS 29.292 [18] subclauses 5.3.4a, 5.3.4b, 5.3.6, 5.3.7, 5.3.8 and 5.3.9.

When the MSC server is in the "call received" (N7) state receives a CC CONNECT message from the SC UE the MSC server shall send a SIP INFO request as specified in subclause 12.6.3.

When the MSC server is in the "active" (N10) state and in any of the hold and multiparty auxiliary states for a non-emergency session, the MSC server shall perform interworking as specified in 3GPP TS 29.292 [18] subclauses 5.5, 5.6.3 and 5.6.8. When the MSC server is in the "active" (N10) state for an emergency session, the MSC server shall perform interworking as specified in 3GPP TS 29.292 [18] subclauses 5.5.

The MSC server shall interact with CS-GW as specified in 3GPP TS 29.292 [18] subclauses 7.1, 7.3, 7.4, 7.5 and 7.6.

If the MSC server in the "call received" (N7) state:

1) receives a call clearing message from the SC UE, the MSC server shall send a SIP BYE request or a SIP CANCEL request as specified in 3GPP TS 29.292 [18] subclause 5.3.9; or

2) determines due to internal procedures that the call shall be released, the MSC Server shall send a SIP BYE request or a SIP CANCEL request as specified in 3GPP TS 29.292 [18] subclause 5.3.11.

If the MSC server enhanced for SRVCC using SIP interface supports the MSC server assisted mid-call feature and subscribes to the conference event package as described in 3GPP TS 24.147 [95] subclause 5.3.1.2, then after the PS to CS SRVCC access transfer procedure is completed, the MSC server shall apply the interworking procedures as specified in 3GPP TS 29.292 [18] subclauses 5.6.8.2.7.