12.4A MSC server assisted mid-call feature

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

Upon receiving a SIP 2xx response to the SIP INVITE request due to STN-SR, the MSC server shall:

1. if inactive speech media component is negotiated by the SDP answer of the SIP 2xx response to the SIP INVITE request due to STN-SR, associate the dialog created by the SIP INVITE request due to STN-SR with a CS call with transaction identifier 0 and TI flag value as in mobile terminated call and enter the "active" (N10) state (defined in 3GPP TS 24.008 [8]), the "call held" hold auxiliary state (defined in 3GPP TS 24.083 [43]), the "idle" multi party auxiliary state (defined in 3GPP TS 24.084 [47]) for the CS call, regard the access transfer of the session with inactive speech media component as completed and start interworking CC messages as specified in subclause 12.6.5. If the speech media component in SDP answer of the SIP 2xx response to the SIP INVITE request due to STN-SR:

– has "recvonly" directionality, the MSC server shall determine that the remote UE does not hold the call; and

– has "inactive" directionality, the MSC server shall determine that the remote UE holds the call; and

2. if active speech media component is negotiated by the SDP answer of the SIP 2xx response to the SIP INVITE request due to STN-SR, associate the dialog created by the SIP INVITE request due to STN-SR with a CS call with the transaction identifier 0 and TI flag value as in mobile terminated call and enter the "active" (N10) state (defined in 3GPP TS 24.008 [8]), the "idle" hold auxiliary state (defined in 3GPP TS 24.083 [43]), the "idle" multi party auxiliary state (defined in 3GPP TS 24.084 [47]) for the CS call, regard the access transfer of the session with active speech media component as completed and start interworking CC messages as specified in subclause 12.6.5. If the speech media component in SDP answer of the SIP 2xx response to the SIP INVITE request due to STN-SR:

– has "sendrecv" directionality, the MSC server shall determine that the remote UE does not hold the call; and

– has "sendonly" directionality, the MSC server shall determine that the remote UE holds the call.

Upon receiving a SIP INFO request:

– sent inside in the dialog created by the SIP INVITE request due to STN-SR;

– with the Info-Package header field containing the g.3gpp.mid-call package name;

– with the application/vnd.3gpp.mid-call+xml MIME body associated with the info package according to IETF RFC 6086 [54]; and

– with one or more participants included in the application/vnd.3gpp.mid-call+xml MIME body;

and if the SIP INVITE request due to STN-SR established a session with conference focus then the MSC server shall:

1. if inactive speech media component is negotiated by the SDP answer of the SIP 2xx response to the SIP INVITE request due to STN, associate the session and the participants extracted from the application/vnd.3gpp.mid-call+xml MIME body with CS calls:

– with transaction identifiers 0, 2, 3, 4, 5 assigned to the participants in their order in the list of the extracted participants; and

– with TI flag value as in mobile terminating call;

and enter the "active" (N10) state (defined in 3GPP TS 24.008 [8]), the "call held" hold auxiliary state (defined in 3GPP TS 24.083 [43]), the "call in MPTY" multi party auxiliary state (defined in 3GPP TS 24.084 [47]) for the CS calls, regard the access transfer of conference participants with transaction identifiers 2,3,4,5 and the TI flag value as in the mobile terminating call as completed and start interworking CC messages as specified in subclause 12.6.5. The MSC server may subscribe to the conference event package as specified in 3GPP TS 24.605 [31]; and

NOTE 1: The transaction identifier and TI flag value for the first participant are assigned by the call activation procedures for SRVCC in 3GPP TS 24.008 [8].

NOTE 2: The multi party auxiliary state was initially set to "idle" on reception of the SIP 2xx response to the SIP INVITE request due to STN-SR. This state is re-assigned to "call in MPTY" after processing the SIP INFO request to reflect the multi party auxiliary state associated with the first participant .

2. if active speech media component is negotiated by the SDP answer of the SIP 2xx response to the SIP INVITE request due to STN, associate the session and the participants extracted from the application/vnd.3gpp.mid-call+xml MIME body with CS calls:

– with transaction identifiers 0, 2, 3, 4, 5 assigned to the participants in their order in the list of the extracted participants; and

– with TI flag value as in mobile terminating call;

and enter the "active" (N10) state (defined in 3GPP TS 24.008 [8]), the "idle" hold auxiliary state (defined in 3GPP TS 24.083 [43]), the "call in MPTY" multi party auxiliary state (defined in 3GPP TS 24.084 [47]) for the CS calls, regard the access transfer of conference participants with transaction identifiers 2,3,4,5 and the TI flag value as in the mobile terminating call as completed and start interworking CC messages as specified in subclause 12.6.5. The MSC server may subscribe to the conference event package as specified in 3GPP TS 24.605 [31].

NOTE 3: For an MSC server enhanced for PS to CS SRVCC using SIP interface, following access transfer, the procedures for the handling of transferred conference participants are implementation dependent.

Upon receiving a SIP REFER request:

1. with the Refer-Sub header field containing "false" value;

2. with the Supported header field containing "norefersub" value;

3. with the Refer-To header field containing a SIP URI with the Target-Dialog URI header field;

4. sent inside a SIP dialog:

A. created by the SIP INVITE request due to STN-SR; and

B. where the g.3gpp.mid-call feature-capability indicator as specified in annex C was included in the Feature-Caps header field of the SIP 2xx response to the SIP INVITE request due to STN-SR; and

5. containing a MIME body of MIME type specified in the subclause D.1.3;

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 4: 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 for transfer of an additional session with inactive speech media component in accordance with the procedures specified in 3GPP TS 24.229 [2] and IETF RFC 3515 [13]. If the MSC server is enhanced for ICS, the MSC server 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 for transfer of an additional session with inactive speech media component. Additionally, the MSC server shall populate the SIP INVITE request for transfer of an additional session with inactive speech media component as follows:

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

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

C. the SDP offer with:

a. the same amount of the media descriptions as in the "body" URI header field 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 "body" URI header field 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 "body" URI header field in the URI in the Refer-To header field of the received SIP REFER request has port with zero value;

d. media directionality as in the "body" URI header field in the URI in the Refer-To header field of the received SIP REFER request; and

e. 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;

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

D. 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;

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;

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 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 SIP REFER request is received.

Upon receiving SIP 2xx response to the SIP INVITE request for transfer of an additional session with inactive speech media component, the MSC server shall:

1. if:

a) the SIP INVITE request for transfer of the additional session with inactive speech media component did not established a session with a conference focus; or

b) the application/vnd.3gpp.mid-call+xml MIME body included in the SIP REFER request does not contain one or more participants:

then associate the additional session with inactive speech media component with CS call with transaction identifier 1 and TI flag value as in mobile terminated call and enter the "active" (N10) state (as defined in 3GPP TS 24.008 [8]), the "call held" hold auxiliary state (as defined in 3GPP TS 24.083 [43]) and the "idle" multi party auxiliary state (defined in 3GPP TS 24.084 [47]) for the CS call. If the speech media component in SDP answer of the SIP 2xx response to the SIP INVITE request for transfer of an additional session with inactive speech media component:

– has "recvonly" directionality, the MSC server shall determine that the remote UE does not hold the call; and

– has "inactive" directionality, the MSC server shall determine that the remote UE holds the call;

2. if the SIP INVITE request for transfer of an additional session with inactive speech media component established a session with a conference focus and the application/vnd.3gpp.mid-call+xml MIME body included in the SIP REFER request contained one or more participants:

a) associate the additional session and the participants extracted from the application/vnd.3gpp.mid-call+xml MIME body included in the SIP REFER request with CS calls:

– with transaction identifiers 1, 2, 3, 4, 5 assigned to the participants in their order in the list of the extracted participants; and

– with TI flag value as in mobile terminated call;

and enter the "active" (N10) state (defined in 3GPP TS 24.008 [8]), the "call held" hold auxiliary state (defined in 3GPP TS 24.083 [43]) and the "call in MPTY" multi party auxiliary state (defined in 3GPP TS 24.084 [47]) for the CS calls. The MSC server may subscribe to the conference event package as specified in 3GPP TS 24.605 [31]; and

3. the MSC server shall send the SIP ACK request as specified in 3GPP TS 24.229 [2] and regard the access transfer of the session with inactive speech media component and conference participants (if applicable) as completed and start interwork CC messages as specified in subclause 12.6.5.

NOTE 6: 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 sent between the SC UE and the SCC AS just before the handover from the PS domain to the CS domain occurred did not result in incompatible call state or auxiliary states. If the call state or auxiliary states are incompatible the transferred session is released.