9 Roles for PS-CS access transfer

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

9.1 Introduction

For a UE or an AS not supporting ICS procedures, PS-CS access transfer procedures enable transfer of

– one full-duplex session with active speech or speech/video component;

– up to one full-duplex session with active speech or speech/video media component and up to one full-duplex session with inactive speech or speech/video media component when the MSC Server assisted mid-call feature is supported;

– one full-duplex session in an early dialog phase that can be in a pre-alerting or an alerting phase when dual radio access transfer for originating calls in pre-alerting phase or dual radio access transfer for calls in alerting phase are supported;

– one full-duplex session with active speech media component and one full-duplex session in an early dialog state, that can be in an originating pre-alerting or an alerting phase, when dual radio access transfer for originating calls in pre-alerting phase or dual radio access transfer for calls in alerting phase are supported; and

– one full-duplex session with inactive speech media component and one full-duplex session in an early dialog phase, that can be in a pre-alerting or alerting phase, when the MSC Server assisted mid-call feature and the dual radio access transfer for originating calls in pre-alerting phase or dual radio access transfer for calls in alerting phase are supported.

9.1A Additional procedures with MSC Server assisted mid-call feature

When a conference is transferred to CS domain using MSC Server assisted mid-call feature, the participants are extracted from the stored conference information as follows:

1. at maximum first 5 participants listed in the <user> elements:

a. included in <users> parent element included in <conference-info> root element of the conference information;

b. containing at least one <endpoint> child element with <status> child element containing one of the states "connected", "on-hold", "muted-via-focus", "pending", "alerting", "dialing-in" or "dialing-out"; and

c where "entity" attribute is different than the URI in the P-Asserted-Identity header field of the served SC UE used at the subscription.

9.2 SC UE

9.2.0 General

Void

9.2.1 SC UE not using ICS procedures for PS to CS access transfer

The SC UE may be engaged in one or more ongoing sessions at the time of initiating access transfer. By an ongoing session, it is meant a session for which the SIP 2xx response for the initial SIP INVITE request to establish this session has been sent or received.

Additional to the ongoing sessions, the SC UE can be engaged in one or more sessions in an early dialog phase at the time of initiating access transfer. By a session in an early dialog phase, it is meant a session for which the SIP 18x response for the initial SIP INVITE request to establish this session has been sent or received but the SIP 2xx response has not yet been received or sent.

If the SC UE is not using ICS capabilities and if the SC UE does not apply the MSC Server assisted mid-call feature as specified in subclause 9.2.1A, subject to the SC_non_transferrable_media node value in the Communication Continuity MO (see subclause 5.27 in 3GPP TS 24.216 [5]), the SC UE shall:

a) if more than one ongoing full-duplex session with speech media component exists and if the SC UE does not support PS to CS dual radio access transfer of a session in an early dialog phase or if no session in an early dialog phase exists:

1) initiate the release of all the full-duplex sessions with speech media component except the full-duplex session with active speech media component that was most recently made active; and

2) transfer the remaining ongoing full-duplex session with active speech media component by sending a CC SETUP message as described in step A);

b) if one ongoing full-duplex session with active speech media component exist, one or more session in the early dialog phases fulfilling the criteria in subclause 9.2.4 exists and if the SC UE supports PS to CS dual radio access transfer of a session in an early dialog phase:

1) select a session in an early dialog phase to be transferred as specified in subclause 9.2.4;

2) initiated the release of the remaining sessions in early dialog phase, except the selected session in an early dialog phase;

3) if the selected session in the early dialog phase is a session in the terminating alerting phase,

– transfer the ongoing full-duplex session with active speech media component by sending a CC SETUP message as described in step A) below; and

– when the transfer of the ongoing full-duplex session with active speech media component is completed, transfer the selected session in the terminating alerting phase by sending a SIP 488 (Not Acceptable Here) response to the SIP INVITE request creating the session in the terminating alerting phase without an SDP body as described in subclause 10.2.4 of 3GPP TS 24.292 [4]; and

4) if the selected session in the early dialog phase is not a session in the terminating alerting phase, transfer the ongoing full-duplex session with active speech media by sending a CC SETUP message as described in step A) below and when the transfer is completed:

– if a session in the pre-alerting phase was transferred, assign the TI flag as in the mobile originating case and the TI value as described in the table 9.2.1A-1 in subclause 9.2.1A and continue the session in the pre-alerting phase in the CS domain in the "Mobile originating call proceeding" (U3) call state as described in 3GPP TS 24.008 [8]; and

– if a session in the originating alerting phase was transferred, assign the TI flag as in the mobile originating case and the TI value as described in the table 9.2.1A-1 in subclause 9.2.1A and continue the session in the originating alerting phase in the CS domain in the "Call delivered" (U4) call state as described in 3GPP TS 24.008 [8]; and

NOTE 1: One CC SETUP message transfers both the ongoing full-duplex session with active speech media component and the session in the early dialog phase.

c) if no ongoing full-duplex session with active speech media component exists, one or more session in the early dialog phases fulfilling the criteria in subclause 9.2.4 exists and if the SC UE supports PS to CS dual radio access transfer of asession in an early dialog phase:

1) select an session in the early dialog phase to be transferred as specified in subclause 9.2.4;

2) initiate the release of remaining sessions in early dialog phase, except the selected session;

3) if the selected session in the early dialog phase is a session in the terminating alerting phase, transfer the selected session by sending a SIP 488 (Not Acceptable Here) response to the SIP INVITE request creating the session in the terminating alerting phase without an SDP body as described in subclause 10.2.4 of 3GPP TS 24.292 [4]; and

4) if the selected session in the early dialog phase is not a session in the terminating alerting phase, transfer the selected session by sending a CC SETUP message as described in step A).

When transferring the session(s) not using ICS capabilities, the SC UE shall:

A) send a CC SETUP message (as specified in 3GPP TS 24.008 [8]) and set up a call over the CS domain. When sending CC SETUP message, the SC UE shall populate the CC SETUP message as follows:

1) the called party BCD number information element set to:

– if the SC UE supports the use of the dynamic STN and if a dynamic STN was received from the SCC AS in the g.3gpp.dynamic-stn feature-capability indicator in a Feature-Caps header field of SIP 1xx responses or the SIP 2xx response to the initial SIP INVITE request as specified in annex C, the E.164 number from the tel URI from the received dynamic STN associated with the call to transfer; or

NOTE 2: The SC UE could have multiple dialogs (e.g active session and a session on hold). The dynamic STN only applies to the dialog for which it is received so the UE needs to store the dynamic STN associated with the dialog on which it was received and upon termination of the dialog (i.e upon sending or receiving a SIP BYE request or SIP CANCEL request) the dynamic STN associated with the dialog is discarded.

– if the use of dynamic STN is not supported by the SC UE or if a dynamic STN was not received from the SCC AS in a g.3gpp.dynamic-stn feature-capability indicator in a Feature-Caps header field of SIP 1xx responses or in the SIP 2xx response to the initial SIP INVITE request, the static STN; and

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

If the SC UE receives a SIP BYE request for a session subject for access transfer and before the access transfer is completed the SC UE shall:

1. send the SIP 200 (OK) response to the SIP BYE request in accordance with 3GPP TS 24.229 [2]; and

2. abort the transfer of the session and if the session is an additional session, internally release any reserved CS resources.

NOTE 3: If only one session is subject for access transfer the session, CS resources will be released by 3GPP TS 24.008 [2] procedures.

NOTE 4: If more than one session is subject for access transfer the remaining session will be transferred by the CC SETUP message.

If the SC UE receives a release message to the CC SETUP message sent, then the PS to CS access transfer has not completed successfully and the call will continue in the Source Access Leg.

After completion of session transfer, if the SC UE is not using Gm, the SC UE shall locally release the resources, if any, that are associated with the source access leg.

9.2.1AAA SC UE not using ICS procedures for PS to CS access transfer of emergency session

The UE may support PS to CS transfer of an emergency session for which the SIP 2xx response for the initial SIP INVITE request to establish this session has been sent or received.

If an E-STN-DR was received from the EATF in g.3gpp.dynamic-e-stn-drvcc feature-capability indicator in a Feature-Caps header field of a SIP 2xx response to the initial SIP emergency INVITE request as specified in annex C, the SC UE, when transferring the emergency session, shall:

A) send a CC SETUP message (as specified in 3GPP TS 24.008 [8]) and set up a call over the CS domain. When sending CC SETUP message, the SC UE shall populate the CC SETUP message as follows:

1) the called party BCD number information element set to the E.164 number of the tel URI from the received E-STN-DR associated with the call to transfer, and

NOTE 1: The E-STN-DR only applies to the dialog for which it is received so the UE needs to store the E-STN associated with the dialog on which it was received and upon termination of the dialog (i.e upon sending or receiving a SIP BYE request or SIP CANCEL request) the E-STN-DR associated with the dialog is discarded.

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

If the SC UE receives a SIP BYE request for a session subject for access transfer and before the access transfer is completed the SC UE shall:

1. send the SIP 200 (OK) response to the SIP BYE request in accordance with 3GPP TS 24.229 [2]; and

2. abort the transfer of the session and if the session is an additional session, internally release any reserved CS resources.

NOTE 2: The access transfer is completed once the SC UE has received CC CONNECT message.

If the SC UE receives a release message to the CC SETUP message sent, then the PS to CS access transfer has not completed successfully and the call will continue in the Source Access Leg.

After successful completion of session transfer, the SC UE shall locally release the resources, if any, that are associated with the speech media component of the emergency session on the source access leg.

9.2.1AA SC UE using ICS procedures for PS to CS access transfer

If SC UE uses ICS capabilities, this subclause applies for IMS sessions containing speech media component only, otherwise subclause 11.2.1.2 applies.

If SC using ICS is enabled and if the SC UE is using Gm, then for each session with speech media component to be transferred and starting with the session with the active speech media component, the SC UE shall send a SIP INVITE request to the SCC AS. The SC UE shall populate the SIP INVITE request as follows:

1) the Request-URI set to:

– if the PS to PS STI URI is configured in the SC UE, the configured PS to PS STI URI; and

– if the PS to PS STI URI is not configured in the SC UE, the URI contained in the Contact header field returned at the creation of the dialog on the Source Access Leg;

2) include in the Contact header field according to IETF RFC 3840 [53]:

– a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at registration; and

– the g.3gpp.ics media feature tag set to "principal" as specified in annex B of 3GPP TS 24.292 [4];

3) select one of the following options:

– if usage of SIP Replaces extension is selected:

a) the Replaces header field populated as specified in IETF RFC 3891 [10], containing the dialog identifier of the session to be transferred; and

b) the Require header field populated with the option tag value "replaces";

– if usage of SIP Target-Dialog extension is selected:

a) the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of the session to be transferred; and

b) the Require header field populated with the option tag value "tdialog";

4) SDP proposing an audio stream over a circuit-switched bearer in accordance with procedures for SDP for ICS UE proposing using a CS audio stream in 3GPP TS 24.292 [4]; and

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

Upon the SC UE receiving a reliable SIP 1xx provisional response including a PSI DN from the SCC AS, the SC UE shall follow the procedures for ICS YE setting up a CS call in 3GPP TS 24.292 [4].

When the CS resources are available to the UE, the SC UE shall send an SDP offer including an indication that the related local preconditions for QoS for audio as met as specified in 3GPP TS 24.229 [11].

Upon receiving a SIP 2xx response for the SIP INVITE request, the SC UE shall:

1) send a SIP ACK request; and

2) send a SIP BYE request to the SCC AS on the Source Access Leg to terminate the dialog on the Source Access Leg, if the dialog is still active (e.g. it has not been released by the SCC AS) and no active media streams remain on that dialog on the Source Access Leg.

NOTE: If the contact address used by the dialog over the Source Access Leg was registered using multiple registration procedure, then upon transferring the dialog to the CS domain, the SC UE is still registered on the Source Access Leg and its subscription dialog to its reg-event on the Source Access Leg is intact.

If the SC UE receives any SIP 4xx – 6xx response to the SIP INVITE request, then PS-CS access transfer has not completed successfully and the call will continue on the PS Access Leg.

If the SC UE receives a release message to the CC SETUP message sent, then PS-CS access transfer has not completed successfully and the call will continue in the Source Access Leg.

9.2.1A SC UE procedures for PS to CS access transfer with MSC server assisted mid-call feature

The SC UE shall apply the MSC Server assisted mid-call feature when transferring the session not using ICS capabilities if:

1. the SC UE supports the MSC Server assisted mid-call feature; and

2. one of the following is true:

A. there is at least one ongoing full-duplex session with active speech media component and the Feature-Caps header field received during the establishment of the ongoing full-duplex session with active speech media component which has been most recently made active includes the g.3gpp.mid-call feature-capability indicator as described in annex C;

B. there is no ongoing full-duplex session with active speech media component and the Feature-Caps header field received during the establishment of the ongoing full-duplex session with inactive speech media component which became inactive most recently includes the g.3gpp.mid-call feature-capability indicator as described in annex C; or

C. if

– there is one ongoing full-duplex session with active speech media component or one ongoing full-duplex session with inactive speech media component and the Feature-Caps header field received during the establishment of the ongoing full-duplex session includes the g.3gpp.mid-call feature-capability indicator as described in annex C; and

– there is at least one session in the early dialog phase fulfilling the criteria in the subclause 9.2.4 exists.

When the SC UE applies the MSC Server assisted mid-call feature, in addition to the procedures described in subclause 9.2.1, and before sending a message to set up a call over the CS domain, the SC UE shall:

1. if there are two or more ongoing full-duplex sessions with active speech media component:

A. initiate the release of all the ongoing full-duplex sessions with speech media component except two that were most recently made active;

B. initiate the session modification of the ongoing full-duplex session with speech media component that was made active less recently and offer the speech media component with "sendonly" or "inactive" directionality; and

C. transfer two remaining ongoing full-duplex sessions with speech media component;

NOTE 1: When full-duplex session with active speech media component and another session with inactive speech media component exist, one CC SETUP message transfers both sessions.

2. if there are one ongoing full-duplex session with active speech media component and one or more ongoing full-duplex session with inactive speech media component:

A. initiate the release of all the ongoing full-duplex sessions with inactive speech media component except the one which became inactive most recently; and

B. transfer two remaining ongoing full-duplex sessions with speech media component;

NOTE 2: When full-duplex session with active speech media component and another session with inactive speech media component exist, one CC SETUP message transfers both sessions.

3. if there is one ongoing full-duplex session with active speech media component and no ongoing full-duplex session with inactive speech media component, transfer the ongoing full-duplex session with the speech media component;

4. if there is no ongoing full-duplex session with active speech media component and there is one or more ongoing full-duplex session with inactive speech media component:

A. initiate the release of all the ongoing full-duplex sessions with inactive speech media component except the one which became inactive most recently; and

B. transfer the ongoing full-duplex session with speech media component; and

NOTE 3: The ongoing full-duplex session with inactive speech media component is transferred to a held CS call.

5. if one ongoing full-duplex session with active speech media component or one ongoing full-duplex session with inactive speech media component, one or more session in the early dialog phases fulfilling the criteria in subclause 9.2.4 and if the SC UE supports PS to CS dual radio access transfer of a session in an early dialog phase:

A) select a session in an early dialog phase to be transferred as specified in subclause 9.2.4;

B) initiated the release of the remaining sessions in early dialog phase, except the selected session; and

C) if the selected session in the early dialog phase is a session in the terminating alerting phase,

– transfer the ongoing full-duplex session with active speech media component by sending a CC SETUP message as described in subclause 9.2.1; and

– if a session in the pre-alerting phase was transferred, continue the session in the pre-alerting phase in the CS domain in the "Mobile originating call proceeding" (U3) call state as described in 3GPP TS 24.008 [8]; and

– if a session in the originating alerting phase was transferred, continue the session in the originating alerting phase in the CS domain in the "Call delivered" (U4) call state as described in 3GPP TS 24.008 [8].

NOTE 4: One CC SETUP message transfers both the ongoing full-duplex session with active or inactive speech media component and the session in the early dialog phase.

The SC UE shall associate the additional transferred session with a CS call with transaction identifier calculated as in the table 9.2.1A-1 and TI flag value as in mobile originated call.

NOTE 5: If the additional transfer sessions was a session in the terminating alerting phase, the TI flag value and TI value need not to be calculated as in table 9.2.1A-1, instead the TI flag value and the TI value is assigned by the MSC server and the UE using 3GPP TS 24.008 [8] call establishment procedures.

Table 9.2.1A-1: held session transaction identifier calculation formula

<transaction identifier of the additional transferred session> = (1 + <transaction identifier indicated in the CC SETUP message>) modulo 7

If the SC UE has a subscription as described in subclause 7.2.2 for the ongoing full-duplex session with active speech media component then:

1. the SC UE shall associate the ongoing full-duplex session and the participants extracted in subclause 9.1A with CS calls:

– with transaction identifiers calculated as in the table 9.2.1A-2. The offsets 0, 2, 3, 4, 5 are assigned to the participants in their order in the list of the extracted participants; and

– with TI flag value as in mobile originated call; and

NOTE 6: The transaction identifier of the CS call established by the CC SETUP message (i.e. transaction identifier of the conference) is the transaction identifier assigned to the first participant (offset 0).

2. the SC UE shall enter the "active" (U10) state (defined in 3GPP TS 24.008 [8]), the "idle" 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.

NOTE 7: The "active" (U10) state for the first participant is entered as a result of the CS call being established by the 3GPP TS 24.008 [8] procedures.

Table 9.2.1A-2: transaction identifier assignment for participants

<transaction identifier of participant> = (<transaction identifier of transaction identifier indicated in the CC SETUP message> + <offset of participant>) modulo 7

If the ongoing full-duplex session with active speech media component does not exist and the SC UE has a subscription as described in subclause 7.2.2 for the ongoing full-duplex session with inactive speech media component then:

1. the SC UE shall associate the ongoing full-duplex session and the participants extracted in subclause 9.1A with CS calls:

– with transaction identifiers calculated as in the table 9.2.1A-2. The offsets 0, 2, 3, 4, 5 are assigned to the participants in their order in the list of the extracted participants; and

– with TI flag value as in mobile originated call; and

NOTE 8: The transaction identifier of the CS call established by the CC SETUP message (i.e. transaction identifier of the conference) is the transaction identifier assigned to the first participant (offset 0).

2. the SC UE shall enter the "active" (U10) 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.

NOTE 9: The "active" (U10) state for the first participant is entered as a result of the CS call being established by the 3GPP TS 24.008 [8] procedures.

1. the ongoing full-duplex session with active speech media component exists and the SC UE does not have a subscription as described in subclause 7.2.2 for the ongoing full-duplex session with active speech media component; and

2. the SC UE has a subscription as described in subclause 7.2.2 for the additional transferred session;

then:

1. the SC UE shall associate the ongoing full-duplex session and the participants extracted in subclause 9.1A with CS calls:

– with transaction identifiers calculated as in the table 9.2.1A-2. The offsets 1, 2, 3, 4, 5 are assigned to the participants in their order in the list of the extracted participants; and

– with TI flag value as in mobile originated call; and

2. the SC UE shall enter the "active" (U10) state (defined in 3GPP TS 24.008 [8]), the "call held" 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.

If the SC UE does not have a subscription as described in subclause 7.2.2 for the transferred session then when the transfer is completed, the SC UE shall:

1) if the call is an additional transferred session with inactive speech media, enter the "active" (U10) state (defined in 3GPP TS 24.008 [8]); and

2) if a call is a session with inactive speech media component, enter the "call held" hold auxiliary state (defined in 3GPP TS 24.083 [43]) for the held call.

9.2.1B SC UE procedures for PS to CS access transfer with MSC server assisted mid-call feature for speech and video session

When PS to CS access transfer occurs, with a speech and video session and another speech session using PS media in the SC UE, the SC UE applies the MSC Server assisted mid-call feature according to the procedures described in subclause 9.2.1A with the following additions:

– if the SC UE supports SCUDIF feature, and the speech and video session is active and speech session is inactive the SC UE shall transfer the active speech and video session as specified in subclause 9.2.1, and indicate the support of SCUDIF in the CC SETUP message as specified in 3GPP TS 24.008 [8], with multimedia bearer capability preferred for the current active session; and

– if the SC UE supports SCUDIF feature, and the speech and video session is inactive and speech session is active, the SC UE shall transfer the speech session as specified in subclause 9.2.1, and indicate the support of SCUDIF in the CC SETUP message as specified in 3GPP TS 24.008 [8], with speech bearer capability preferred for the current active session.

NOTE: After successful transfer of the speech and video session and another speech session from PS to CS, the UE can switch between the two sessions by holding/releasing the active session and resuming the inactive session as specified in 3GPP TS 24.008 [8], with the addition that the UE can initiate the in-call modification or Redial procedures as specified in 3GPP TS 24.008 [8] to change the shared CS bearer of the two sessions from speech to multimedia, or vice versa.

9.2.2 SC UE procedures for CS to PS access transfer

9.2.2.1 Distinction of request

The SC UE needs to distinguish the following SIP requests:

1) 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 Target-Dialog URI header field in the URI of the Refer-To header field;

4. where the g.3gpp.mid-call feature-capability indicator or the g.3gpp.cs2ps-drvcc-alerting feature-capability indicator as described in annex C was included in the Feature-Caps header field of the SIP 2xx response to the SIP INVITE request due to static STI; and

5. containing application/vnd.3gpp.mid-call+xml MIME body or the application/vnd.3gpp.state-and-event-info+xml MIME type specified in annex D.

In the procedures below, such requests are known as "SIP REFER requests for transfer of an additional session".

2) SIP INFO request:

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

B) 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 "early" and direction XML element containing "receiver".

In the procedures below, such requests are known as "SIP INFO requests for transfer of incoming early session".

9.2.2.2 SC UE procedure for transferring the first CS call

The SC UE may be engaged in one or more ongoing sessions before performing access transfer. By an ongoing session, it is meant a CS call for which the CS call setup procedure is complete, e.g. a CC CONNECT message has been sent or received as described in 3GPP TS 24.008 [8] or a call for which the SIP 2xx response for the initial SIP INVITE request to establish this session has been sent or received.

Additional, the SC UE may be involved in one CS session in an early phase before performing access transfer. If not already registered in the IM CN subsystem, the SC UE shall follow the procedures specified in subclause 6.2 to perform registration over the Target Access Leg before performing CS to PS access transfer.

If SC using ICS is enabled then if the original sessions are established using ICS capabilities as defined in 3GPP TS 24.292 [4], then for each session with speech media component to be transferred and starting with the one with active speech media component, the SC UE shall send a SIP INVITE request to the SCC AS in accordance with the UE procedures specified in 3GPP TS 24.229 [2]. The SC UE shall populate the SIP INVITE request as specified for PS-PS access transfer with full media transfer in subclause 10.2.1.

If the original sessions are not established using ICS capabilities and the SC UE does not support the MSC Server assisted mid-call feature as described in subclause 9.2.3, subject to the SC_non_transferrable_media node value in the Communication Continuity MO (see subclause 5.27 in 3GPP TS 24.216 [5]) the SC UE shall:

a) if more than one ongoing full-duplex session with speech media component exists, first initiate the release of all the ongoing sessions that are currently not active with the UE procedures specified in 3GPP TS 24.083 [43] and then transfer the remaining ongoing full-duplex session with active speech media component;

b) if one ongoing full-duplex session with speech media component and one session in a CS session in an early phase exists but the conditions in the subclause 9.2.5.1 for transferring a CS session in an early phase are not fulfilled, release the CS session in an early phase with the UE procedure specified in 3GPP TS 24.008 [8] and then transfer the remaining ongoing full-duplex session with active speech media component; and

c) if no ongoing full-duplex session with speech media component and one CS session in an early phase exists and the conditions in the subclause 9.2.5.1 for transferring a CS session in an early phase are fulfilled, transfer the CS session in an early phase.

When transferring the session(s) not using ICS capabilities, the SC UE shall send a SIP INVITE request to the SCC AS in accordance with the UE procedures specified in 3GPP TS 24.229 [2]. The SC UE shall:

A) populate the SIP INVITE request as follows:

1) the Request-URI set to the static STI;

2) if a GRUU was received at registration, include in the Contact header field a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2]; and

3) the signalling elements described in subclause 6A.2.2.2; and

B) if the conditions in the subclause 9.2.5.1 for transferring a CS session in an early phase are fulfilled, additionally apply the procedures defined in subclause 9.2.5.2.

If the SC UE receives any SIP 4xx – 6xx response to the SIP INVITE request, then session transfer has not occurred and the call will continue in the CS domain.

When the SC UE receives a CS call release message, e.g. CC DISCONNECT message as specified in 3GPP TS 24.008 [8], from the network, the SC UE shall comply with network initiated call release procedures to release the CS bearer.

After completion of session transfer, if the SC UE is not using Gm, the SC UE shall locally release the resources, if any, that are associated with the source access leg.

9.2.3 SC UE procedures for CS to PS access transfer with MSC server assisted mid-call feature

When the SC UE supports the MSC Server assisted mid-call feature, the SC UE shall populate the SIP INVITE request for transferring a session not using ICS capabilities as follows in addition to the procedures described in subclause 9.2.2.2:

1. the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20]; and

2. the Accept header field containing the MIME type as specified in subclause D.1.3.

NOTE 1: If the original sessions are not established using ICS capabilities as defined in 3GPP TS 24.292 [4] and the SCC AS and the SC UE support the MSC Server assisted mid-call feature, up to one active and up to one inactive CS call can be transferred.

NOTE 2: Upon receiving a SIP 2xx response for the SIP INVITE request for transferring a session not using ICS capabilities, the speech media component of the session supported by the dialog is an inactive speech media component, and if the SC UE supports 3GPP TS 24.610 [28], then the SC UE considers the session as being held.

Upon receiving a SIP REFER request within the SIP session established by the SIP INVITE request due to static STI for transferring the session not using ICS capabilities:

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

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

3. with the Target-Dialog URI header field in the URI of the Refer-To header field;

4. 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 static STI; and

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

and if the SC UE supports the MSC Server assisted mid-call feature, then the SC UE 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 3: In accordance with IETF RFC 4488 [20], the SC UE 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 an additional inactive session in accordance with the procedures specified in 3GPP TS 24.229 [2] and IETF RFC 3515 [13]. The SC UE shall populate the SIP INVITE request 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 a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2] if a GRUU was received at registration;

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

NOTE 4: 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.

e) all or a subset of payload type numbers and their mapping to codecs and media parameters 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

D. the signalling elements described in subclause 6A.2.2.2.

Upon receiving a SIP 2xx response for the SIP INVITE request due to additional session transfer, then the SC UE shall proceed as specified in subclause 7.2.2.

9.2.4 SC UE procedures for selecting a session in an early dialog phase to be transferred using PS to CS dual radio access transfer procedure

When transferring a session not using ICS capabilities and when the SC UE supports PS to CS dual radio access transfer for calls in an early phase, the SC UE shall select one session to be transferred.

NOTE 1: There can be several sessions fulfilling the conditions below and it is an UE implementation issue which one to select.

Any session that fulfils one of the following conditions can be selected to be transferred:

1) if there are one or more dialogs supporting a session with active speech media component such that:

a. all dialogs are early dialogs created by the same SIP INVITE request;

b. a SIP 180 (Ringing) response to SIP INVITE request was received in at least one of those early dialogs;

c. a g.3gpp.drvcc-alerting feature-capability indicator as described in annex C was included in a Feature-Caps header field provided by the SCC AS in the SIP 18x responses; and

d. the Contact header field in the SIP INVITE request sent by the SC UE towards the SCC AS included the g.3gpp.drvcc-alerting media feature tag as described in annex C;

2) if there is one dialog supporting a session with active speech media component such that:

a. the dialog is created by a SIP INVITE request;

b. a SIP 180 (Ringing) response to the SIP INVITE request was sent by the SC UE in the early dialog;

c. a g.3gpp.drvcc-alerting feature-capability indicator as described in annex C was included in a Feature-Caps header field provided by the SCC AS in the initial SIP INVITE request; and

d. the Contact header field in the SIP 180 (Ringing) response sent by the SC UE towards the SCC AS included the g.3gpp.drvcc-alerting media feature tag as described in annex C; or

3) if there are zero, one or more dialogs supporting a session with speech media component and a SIP INVITE request was sent by SC UE such that:

a. all dialogs are early dialogs created by a SIP response to the SIP INVITE request;

b. a final SIP response to the SIP INVITE request has not been received yet;

c. a SIP 180 (Ringing) response to the SIP INVITE request has not been received yet in any of the existing dialogs;

d. the SC UE included in the SIP INVITE request a Contact header field containing the g.3gpp.ps2cs-drvcc-orig-pre-alerting media feature tag as described in annex C; and

e. a SIP 18x response to the SIP INVITE request was received where the SIP 18x response contained a Feature-Caps header field with the g.3gpp.ps2cs-drvcc-orig-pre-alerting feature-capability indicator as described in annex C;

NOTE 2: UE can have zero dialogs if all the early dialogs were terminated by the SIP 199 (Early Dialog Terminated) response as described in IETF RFC 6228 [80].

9.2.5 SC UE procedures for CS to PS dual radio access transfer of calls in an early phase

9.2.5.1 Conditions for CS to PS dual radio access transfer of calls in originating pre-alerting or in the alerting phase

A CS call in the pre-alerting phase or in the alerting phase is subject for CS to PS dual radio access transfer when one of the following conditions is fulfilled:

1. the CS call is a CS session in an early phase such that:

a. the SC UE support CS to PS access transfer of a session in the alerting phase;

b. the CS call is in the "call delivered" (U4) call state as defined in 3GPP TS 24.008 [8]; and

c. no CS call in the "active" (U10) call state as defined in 3GPP TS 24.008 [8] exists;

2. if the CS call is a CS session in an early phase such that:

a. the SC UE support CS to PS access transfer of a session in the alerting phase; and

b. the CS call is in the "call received" (U7) call state as defined in 3GPP TS 24.008 [8]; and

3. if the CS call is a CS session an early phase such that:

a. the SC UE support CS to PS access transfer of a session in the alerting phase and in the originating pre-alerting phase;

b. the CS call is in the "mobile originating call proceeding" (U3) call state as defined in 3GPP TS 24.008 [8]; and

c. no CS call in the "active" (U10) call state as defined in 3GPP TS 24.008 [8] exists.

9.2.5.2 SC UE procedure for CS to PS dual radio access transfer of calls in originating pre-alerting or in the alerting phase

When the SC UE supports CS to PS dual radio access transfer for calls in alerting phase or CS to PS dual radio access transfer for originating calls in pre-alerting phase and the conditions for transferring a CS session in an early phase in subclause 9.2.5.1 are fulfilled, the SC UE shall, in addition to the procedures described in subclause 9.2.2, populate the SIP INVITE request for transferring the session not using ICS capabilities as follows:

1. include:

a) the g.3gpp-cs2ps-drvcc-alerting media feature tag as described in annex C in the Contact header field according to IETF RFC 3840 [34];

b) if the SC UE supports CS to PS dual radio access transfer for originating calls in pre-alerting phase, the g.3gpp.cs2ps-drvcc-orig-pre-alerting media feature tag as described in annex C in the Contact header field according to IETF RFC 3840 [34]; and

c) the signalling elements described in subclause 6A.2.2.2.

Upon receiving the SIP INFO request for transfer of an incoming CS session in an early phase inside an early dialog created with the SIP INVITE request due to static STI, the SC UE shall:

1) send SIP 200 (OK) response to the SIP INFO request;

2) consider the SIP dialog to be:

a) the transferred originating pre-alerting session if the application/vnd.3gpp.state-and-event-info+xml MIME 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 the direction XML element containing "initiator"; and

b) the transferred incoming alerting session if the application/vnd.3gpp.state-and-event-info+xml MIME 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 "early" and the direction XML element containing "receiver".

Upon receiving a SIP 180 (Ringing) response to the SIP INVITE due to static STI the SC UE shall consider the SIP dialog to be the transferred originating alerting session.

When the served user accepts the transferred incoming CS session in an early phase or if the user has accepted it already, the SC UE shall send a SIP INFO request accepting the session inside the early dialog created with the SIP INVITE request due to static STI according to 3GPP TS 24.229 [2] populated with:

1) an Info-Package header field with 3gpp.state-and-event info package name; and

2) 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".

When the served user rejects the transferred incoming CS session in an early phase, the SC UE shall send a SIP CANCEL request cancelling the SIP INVITE request due to STI according to 3GPP TS 24.229 [2 populated with a Reason header field containing protocol "SIP" and the "cause" parameter indicating the selected status code and the "text" parameter indicating the selected reason phrase.

9.2.5.3 SC UE procedures for transferring an additional CS session in an early phase

When the SC UE supports CS to PS dual radio access transfer for calls in alerting phase or CS to PS dual radio access transfer for originating calls in pre-alerting phase, the SC UE shall, in addition to the procedures described in subclause 9.2.2, populate the SIP INVITE request for transferring the session not using ICS capabilities as follows:

1. the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20]; and

2. the Accept header field containing the MIME type as specified in subclause D.2.4.

NOTE 1: If the original sessions are not established using ICS capabilities as defined in 3GPP TS 24.292 [4] and the SCC AS and the SC UE support transferring of an additional CS session in an early phase, one active CS call or one inactive CS call and one CS session in an early phase can be transferred.

Upon receiving a SIP REFER request within the SIP session established by the SIP INVITE request due to static STI for transferring the session not using ICS capabilities:

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

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

3. with the Target-Dialog URI header field in the URI of the Refer-To header field;

4. where the g.3gpp.cs2ps-drvcc-alerting feature-capability indicator or the g.3gpp.cs2ps-drvcc-originating-pre-alerting feature-capability indicator as described in annex C was included in the Feature-Caps header field of the SIP 2xx response to the SIP INVITE request due to static STI; and

5. containing a MIME body of MIME type specified in the subclause D.2.4,

then the SC UE 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 2: In accordance with IETF RFC 4488 [20], the SC UE 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 in accordance with the procedures specified in 3GPP TS 24.229 [2] and IETF RFC 3515 [13]. The SC UE shall populate the SIP INVITE request as follows:

B. if a GRUU was received at registration, include in the Contact header field a public GRUU or temporary GRUU as specified in 3GPP TS 24.229 [2];

C) the signalling elements described in subclause 6A.2.2.2; and

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

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.

NOTE 3: port can be set to zero or nonzero 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.

Upon receiving a SIP 2xx response for the SIP INVITE request for transfer of an additional session, then the SC UE shall proceed as specified in subclause 7.2.2.

9.3 SCC AS

9.3.0 General

Void

9.3.1 Distinction of requests sent to the SCC AS

The SCC AS needs to distinguish between the following initial SIP INVITE requests to provide specific functionality relating to access transfer:

– SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in the Replaces header field or Target-Dialog header field and not containing the Inter UE Transfer SCC AS URI defined in 3GPP TS 24.337 [64] in the Request-URI. In the procedures below, such requests are known as "SIP INVITE requests due to STI".

– SIP INVITE requests routed to the SCC AS containing a static STI in the Request-URI. In the procedures below, such requests are known as "SIP INVITE requests due to static STI".

– SIP INVITE requests routed to the SCC AS containing either a dynamic STN, a static STN or an IMRN (as described in 3GPP TS 24.292 [4]) in the Request-URI. In the procedures below, such requests are known as "SIP INVITE requests due to PS to CS STN".

– SIP INVITE requests routed to the SCC AS containing a STI belonging to the subscribed user in Target-Dialog header field and containing additional transferred session SCC AS URI in the Request-URI. In the procedures below such requests are known as "SIP INVITE requests transferring additional session".

NOTE 1: The media streams that need to be transferred are identified using information described in the subsequent sections.

NOTE 2: SIP INVITE requests routed to the SCC AS containing the additional transferred session SCC AS URI in the Request-URI which are used in the PS-CS access transfer with the MSC server assisted mid-call feature are handled by the PS-PS access transfer procedure as described in subclause 10.3.

Other SIP initial requests for a dialog and requests for a SIP standalone transaction can be dealt with in any manner conformant with 3GPP TS 24.229 [2].

9.3.2 SCC AS procedures for PS to CS access transfer

This subclause does not apply to reception of a SIP INVITE request due to STI with CS media and other kind of media or without CS media.

When the SCC AS receives a SIP INVITE request due to STI with CS media only on the Target Access Leg, the SCC AS shall follow the procedures specified in subclause 10.3.2 with the following exceptions:

– As the SIP INVITE request includes an active speech media component using CS bearer, then the SCC AS shall follow the procedures for SCC AS for service control over Gm in 3GPP TS 24.292 [4] to send the PSI DN to the SC UE and wait for the SC UE to set up CS bearer before sending a SIP re-INVITE request to the remote end.

– The SCC AS shall correlate the STI with the allocated PSI DN in order to identify the remote leg to be updated.

When the SCC AS receives SIP INVITE request due to PS to CS STN, the SCC AS shall:

1) associate the SIP INVITE request with an ongoing dialog supporting a session based on information associated with the received IMRN (as described in 3GPP TS 24.292 [4]) or based on information from the SIP History-Info header field or P-Asserted-Identity header field or Contact header field; or

NOTE 1: By an ongoing dialog supporting a session, it is meant a dialog for which a SIP 2xx response to the initial SIP INVITE request has been sent or received.

2) associate the SIP INVITE request with an dialog in an early phase supporting a session based on information associated with the received IMRN (as described in 3GPP TS 24.292 [4]) or based on information from the SIP History-Info header field or P-Asserted-Identity header field or Contact header field.

NOTE 2: By a dialog in an early phase supporting a session is meant a dialog for which SIP 18x responses has been sent or received but no SIP 2xx response has yet been sent or received.

NOTE 3: Multiple dialogs supporting a session associated with the same SC UE can have been anchored when the SCC AS receives a SIP INVITE request due to PS to CS STN. This can occur in the event that the UE does not succeed in releasing all dialogs supporting a session with inactive speech media component or if the UE applies the MSC Server assisted mid-call feature or if the SC UE applies the PS to CS dual radio access transfer of sessions in the pre-alerting or in the alerting phase.

The identification of the associated dialog is subject to the following conditions:

1. if only one ongoing dialog supporting a session with active speech media component exists for the user identified in the P-Asserted-Identity header field and a SIP 2xx response has been sent, then continue the session transfer with the ongoing dialog supporting a session with active speech media component;

2. if no ongoing dialogs supporting a session with active speech media component exist for the user identified in the P-Asserted-Identity header field and a SIP 2xx response has been sent and the SCC AS does not apply the MSC Server assisted mid-call feature as specified in subclause 9.3.2A, then send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer;

3. if more than one ongoing dialog supporting a session with active speech media component exists for the user identified in the P-Asserted-Identity header field for which SIP 2xx responses have been sent, then the SCC AS shall perform session transfer procedures for the ongoing dialog that originates from the same device that initiated the received SIP INVITE request due to PS to CS STN. If more than one such dialogs exists from the same device, the SCC AS shall proceed with the next step in this list;

NOTE 4: Whether the dialog originates from the same UE as the received SIP INVITE request due to PS to CS STN is determined based on local information and information related to the correlation MSISDN or the GRUU of the originating user as determined via registration procedures as defined in subclause 6.3.

4. if more than one ongoing dialog supporting a session exists for the user identified in the P-Asserted-Identity header field and exactly one dialog supporting a session with active speech media component exists and a SIP 2xx response has been sent for that dialog, then:

– if the SCC AS does not apply the MSC Server assisted mid-call feature as specified in subclause 9.3.2A, then the SCC AS may release the ongoing dialogs supporting a session with inactive speech media component and continue the session transfer procedures with the ongoing dialog supporting a session with active speech media component; or

– if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer;

5. if more than one ongoing dialog supporting a session with active speech media component exist for the user identified in the P-Asserted-Identity header field and a SIP 2xx response has been sent for that dialog, then:

– if the SCC AS does not apply the MSC Server assisted mid-call feature as specified in subclause 9.3.2A, the SCC AS may release all dialogs supporting a session with speech media component of the user identified in the P-Asserted-Identity header field for which a SIP 2xx response has been sent except the one with the active speech media component that was most recently made active and continue the session transfer procedures; or

6. if one ongoing dialog supporting a session with active speech media component where a SIP 2xx response has been sent for that dialog and if zero, one or more early dialogs created by the same SIP INVITE request exist for the user identified in the P-Asserted-Identity header field, then:

– if the SCC AS does not apply the MSC Server assisted mid-call feature as specified in subclause 9.3.2A, continue the session transfer procedures with the ongoing dialog supporting a session with active speech media component as described in step A); or

7. if no ongoing dialogs supporting a session with active speech media component where a SIP 2xx response has been sent towards the SC UE and zero, one or more early dialogs created by the same SIP INVITE request exist for the user identified in the P-Asserted-Identity header field, then:

– if the conditions for applying the SCC AS procedures for PS to CS dual radio access transfer of calls in an early dialog phase as specified in subclause 9.3.5.1 are fulfilled, the SCC AS shall continue the session transfer procedure with the early session fulfilling the conditions in subclause 9.3.5.1; or

– if the conditions for applying the SCC AS procedures for PS to CS dual radio access transfer of calls in an early dialog phase as specified in subclause 9.3.5.1 are not fulfilled, the SCC AS shall send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer.

NOTE 5: The SC UE can have zero dialogs if all the early dialogs were terminated by the 199 (Early Dialog Terminated) response as described in IETF RFC 6228 [80].

If the session transfer procedure continues, the SCC AS shall:

A) if a dialog in an early phase exists and if the conditions for applying the SCC AS procedures for PS to CS dual radio access transfer for calls in an early phase as specified in subclause 9.3.5.1 are not fulfilled, the SCC AS shall release the dialog in the early phase in accordance with 3GPP TS 24.229 [2];

B) send a SIP re-INVITE request and populate the SIP re-INVITE request as follows:

1) if the dialog to transfer is an ongoing dialog supporting a session with a speech media component:

a. set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with the remote UE;

b. set the contact header field to the contact header field provided by the served UE at the creation of the dialog with the remote UE; and

c. if the remote leg is not a precondition enabled dialog, a new SDP offer, including the media characteristics as received in the SIP INVITE request due to PS to CS STN but excluding any precondition mechanism specific SDP attributes, by following the rules of 3GPP TS 24.229 [2];

d. following the rules of 3GPP TS 24.229 [2], include a new SDP offer, including:

– the media characteristics as received in the SIP INVITE request due to PS to CS STN (including any precondition mechanism specific SDP attributes); and

– if the SIP INVITE request due to PS to CS STN is not a precondition enabled initial SIP INVITE request, indicate preconditions as met, using the segmented status type, as defined in IETF RFC 3312 [88] and IETF RFC 4032 [89], as well as the strength-tag value "mandatory" for the local segment and the strength-tag value either "optional" or as specified in RFC 3312 [88] and RFC 4032 [89] for the remote segment; and

2) if the dialog to transfer is an early dialog fulfilling the conditions in subclause 9.3.5.1 and if the SCC AS does not apply the MSC server assisted mid-call feature as specified in subclause 9.3.2A:

a. if the dialog is in the originating alerting phase, perform the actions in the subclause 9.3.5.2 and do not continue with the procedures in this subclause; and

b. if the dialog is in the originating pre-alerting phase, perform the actions in the subclause 9.3.5.3 and do not continue with the procedures in this subclause; and

Upon receiving a SIP reliable provisional response to the SIP re-INVITE request and the reliable provisional SIP response contains an SDP answer, the SCC AS shall:

A. if the SIP INVITE request due to PS to CS STN is a precondition enabled initial SIP INVITE request, forward the SIP response on the target access leg following the rules of 3GPP TS 24.229 [2];

B. if the SIP INVITE request due to PS to CS STN is not a precondition enabled initial SIP INVITE request, forward the SIP 183 (Session Progress) response on the target access leg following the rules of 3GPP TS 24.229 [2] but remove from the SDP answer precondition mechanism specific SDP attributes;

C. if the SCC AS supports the PS to CS dual radio access transfer of calls in alerting phase, include the g.3gpp.drvcc-alerting feature-capability indicator as described in annex C in the Feature-Caps header field according to IETF RFC 6809 [60]; and

D. include the signalling elements described in subclause 6A.4.3A.

Upon receiving a PRACK to the SIP provisional response to the SIP INVITE request due to PS to CS STN, forward the SIP PRACK request towards the remote UE following the rules of 3GPP TS 24.229 [2].

Upon receiving a SIP 200 (OK) SIP response to the SIP PRACK request from the remote UE the SCC AS shall, forward the SIP response on the target access leg following the rules of 3GPP TS 24.229 [2].

Upon receiveing a SIP UPDATE request on the target access leg, the SCC AS shall forward the request towards the remote UE following the rules of 3GPP TS 24.229 [2].

Upon receipt of a SIP 200 (OK) response to the SIP UPDATE request, the SCC AS shall forward the SIP response on the target access leg following the rules of 3GPP TS 24.229 [2].

Upon receiving the SIP 2xx response to the SIP re-INVITE request the SCC AS shall:

1. if a SIP 200 (OK) response to the SIP INVITE due to PS to CS STN has not been sent yet,

A. send the SIP 200 (OK) response to the SIP INVITE request due to PS to CS STN on the target access leg. If the SIP 2xx response to the SIP re-INVITE request includes an SDP answer:

a. if the SIP INVITE request due to PS to CS STN is a precondition enabled initial SIP INVITE request, use relevant media parameter of the SDP answer in the received SIP response, by following the rules of 3GPP TS 24.229 [2]; and

b. if the SIP INVITE request due to PS to CS STN is not a precondition enabled initial SIP INVITE request, remove from the SDP answer precondition mechanism specific SDP attributes;

B. if the SCC AS supports the PS to CS dual radio access transfer of calls in alerting phase, include the g.3gpp.drvcc-alerting feature-capability indicator as described in annex C in the Feature-Caps header field according to IETF RFC 6809 [60];

C. include the signalling elements described in subclause 6A.4.3A;

Upon reception of the SIP ACK request to the the SIP 200 (OK) response to the SIP INVITE request due to PS to CS STN, the SCC AS shall send the SIP ACK request to the SIP 2xx response to the SIP re-INVITE request;

2. if the SIP 200 (OK) response to the SIP INVITE request due to PS to CS STN was already sent, the SCC AS shall send the SIP ACK request to the SIP 2xx response to the SIP re-INVITE request;

3. remove non-transferred audio media components and release the source access leg for the session supporting an active speech media component as specified in subclause 9.3.6; and

4. if the SCC AS supports dual radio access transfer for calls in an early phase and if the conditions specified in subclause 9.3.5.1 are fulfilled for transfer of a session in the pre-alerting phase or in the originating alerting phase, the SCC AS shall follow the procedures in the subclause 9.3.5.4 and do not continue with the procedures in this subclause.

If the SCC AS supports dual radio access transfer for calls in the alerting phase and if the conditions specified in subclause 9.3.5.1 are fulfilled for a dialog in the terminating alerting phase, the SCC AS shall follow the procedures in the subclause 9.3.5.5.

9.3.2A SCC AS procedures for PS to CS access transfer with MSC server assisted mid-call feature

The SCC AS supporting PS to CS access transfer with MSC server assisted mid-call feature shall:

I) if:

1. the Contact header field of the SIP INVITE request due to PS to CS STN includes the g.3gpp.mid-call media feature tag as specified in annex C; and

2. one of the following is true:

A. at least one confirmed dialog supporting a session with active speech media component exists for the user identified in the P-Asserted-Identity header field and the following is true for the confirmed dialog supporting a session with active speech media component which has been most recently made active:

– the Contact header field provided by the SC UE at the establishment of the dialog supporting a session with active speech media component which has been most recently made active included the g.3gpp.mid-call media feature tag as described in annex C; and

– the Feature-Caps header field sent by SCC AS towards the SC UE at the establishment of the dialog included the g.3gpp.mid-call feature-capability indicator as described in annex C; or

B. no confirmed dialog supporting a session with active speech media component exists for the user identified in the P-Asserted-Identity header field, one or more confirmed dialogs supporting a session with inactive speech media component exists for the user and the following is true for the confirmed dialog supporting a session with inactive speech media component which has been most recently made inactive:

– the Contact header field provided by the SC UE at the establishment of the dialog included the g.3gpp.mid-call media feature tag as described in annex C; and

– the Feature-Caps header field sent by SCC AS towards the SC UE at the establishment of the dialog included the g.3gpp.mid-call feature-capability indicator as described in annex C;

apply the MSC Server assisted mid-call feature; and

II) if:

1. the Contact header field of the SIP INVITE request due to PS to CS STN does not include the g.3gpp.mid-call media feature tag as specified in annex C; and

2. if a confirmed dialog supporting a session with inactive speech media component exists for the user identified in the P-Asserted-Identity header field and the following is true for the confirmed dialog supporting a session with inactive speech media component:

A. the Contact header field provided by the SC UE at the establishment of the dialog included the g.3gpp.mid-call media feature tag as described in annex C; and

B. the Feature-Caps header field sent by SCC AS towards the SC UE at the establishment of the dialog included the g.3gpp.mid-call feature-capability indicator as described in annex C,

not apply the MSC Server assisted mid-call feature and send a SIP BYE request to the SC UE on the source access leg and towards the remote UE in accordance with 3GPP TS 24.229 [2]; and continue the procedure in subclause 9.3.2 to identify an associated dialog for the SIP INVITE request due to PS to CS STN.

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in subclause 9.3.2, and before determining that the SCC AS is not able to identify one dialog for session transfer, the SCC AS may:

1. if more than one confirmed dialog supporting a session exists for the user identified in the P-Asserted-Identity header field, and exactly one confirmed dialog supporting a session with active speech media component exists and there is at least one remaining confirmed dialog supporting a session with inactive speech media component, then:

– release all dialogs supporting a session with active speech media component for which SIP 2xx responses have not been sent for these dialogs; and

– release all confirmed dialogs supporting a session with inactive speech media component except the one with the speech media component which became inactive most recently and continue the session transfer procedures with the confirmed dialog supporting a session with active speech media component;

2. if more than one confirmed dialog supporting a session with active speech media component exists for the user identified in the P-Asserted-Identity header field, release all confirmed dialogs supporting a session with speech media component except two with the speech media component which became active most recently and continue the session transfer procedures with the confirmed dialog supporting a session with the speech media component which became active most recently;

3. if no confirmed dialog supporting a session with active speech media component exists for the user identified in the P-Asserted-Identity header field, one or more confirmed dialogs supporting a session with inactive speech media component exists for the user then the SCC AS may release all confirmed dialogs supporting a session with speech media component except the one with the speech media component which became inactive most recently and continue the session transfer procedures with the confirmed dialog supporting a session with inactive speech media component; and

4 if one confirmed dialog supporting a session with active or inactive speech media component exists and one or more early dialogs created by the same SIP INVITE request continue with the session with active or inactive speech media component.

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in subclause 9.3.2, the SCC AS shall include the g.3gpp.mid-call feature-capability indicator, as described in annex C, in the Feature-Caps header field of the SIP 2xx response to the SIP INVITE request due to PS to CS STN according to IETF RFC 6809 [60].

When the SCC AS applies the MSC Server assisted mid-call feature and a confirmed dialog supporting a session with inactive speech media component was associated with the SIP INVITE request due to PS to CS STN, in addition to the procedures described in subclause 9.3.2, the SCC AS shall set the directionality of the audio media in the SDP offer as used in the session with remote UE.

If:

– the SCC AS applies the MSC Server assisted mid-call feature;

– the session associated with the SIP INVITE request due to PS to CS STN is related to a subscription as described in subclause 7.3.3; and

– a SIP 2xx response was received to the last SIP NOTIFY request with conference information sent to the UE within the related subscription;

then the SCC AS shall send a SIP INFO request towards the MSC Server as specified in 3GPP TS 24.229 [2] and IETF RFC 6086 [54] in the dialog created by the SIP INVITE request due to PS to CS STN. The SCC AS shall populate the SIP INFO request as follows:

1. include the Info-Package header field as specified in IETF RFC 6086 [54] with g.3gpp.mid-call package name; and

2. include application/vnd.3gpp.mid-call+xml XML body associated with the info package according to IETF RFC 6086 [54] and containing the participants extracted as specified in the subclause 9.1A of the subscription related to the session associated with the SIP INVITE request due to PS to CS STN as described in subclause 7.3.3.

If the SCC AS applies the MSC Server assisted mid-call feature,

1. two confirmed dialogs supporting a session with speech media component exist for the user identified in the P-Asserted-Identity header field;

2. one confirmed dialog supporting a session with speech media component and one early dialog exist for the user identified in the P-Asserted-Identity header field fulfilling the conditions in subclause 9.3.5.1 for transfer of a session in the originating alerting phase and if the SCC AS included the g.3gpp.drvcc-alerting feature-capability indicator as described in annex C in a Feature-Caps header field in a SIP 180 (Ringing) response; and

3. one confirmed dialog supporting a session with speech media component and one early dialog exist for the user identified in the P-Asserted-Identity header field fulfilling the conditions in subclause 9.3.5.1 for transfer of a session in the originating pre-alerting phase and if the SCC AS included the g.3gpp.ps2cs-drvcc-orig-pre-alerting feature-capability indicator as described in annex C in a Feature-Caps header field in a SIP 18x responses,

then the SCC AS shall send a SIP REFER request towards the MSC Server in accordance with the procedures specified in 3GPP TS 24.229 [2], IETF RFC 4488 [20] and IETF RFC 3515 [13] as updated by IETF RFC 6665 [81] and IETF RFC 7647 [90] in the dialog created by the SIP INVITE request due to PS to CS STN.

The SCC AS shall populate the SIP REFER request as follows:

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20];

2. the Supported header field with value "norefersub" as specified in IETF RFC 4488 [20];

3. the Refer-To header field containing the information related to the additional transferred session, i.e. session with speech media component other than the session associated with the SIP INVITE request due to PS to CS STN, i.e. set to the additional transferred session SCC AS URI and the following URI header fields:

A. the Target-Dialog URI header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of the session with the SC UE;

B. the Require URI header field populated with the option tag value "tdialog";

C. the To URI header field populated as specified in IETF RFC 3261 [19], containing the P-Asserted-Identity provided by the remote UE during the session establishment;

D. the From URI header field populated as specified in IETF RFC 3261 [19], containing the public user identity of the SC UE provided during the session establishment;

E. the Content-Type header field with "application/sdp";

F. the hname "body" URI header field populated with SDP describing the media streams as negotiated in the session with the remote UE and:

a. if directionality used by SC UE is "sendrecv" or "sendonly", with the "sendonly" directionality; and

b. if directionality used by SC UE is "recvonly" or "inactive", with the "inactive" directionality; and

G. optionally the P-Asserted-Identity URI header field containing value of the P-Asserted-Identity header field of the received SIP INVITE request;

4. the Content-Type header field with the value set to MIME type as specified in the subclause D.1.3; and

5. a XML body compliant to the XML schema specified in the subclause D.1.2. If

A. the session associated with the SIP INVITE request due to PS to CS STN is not related to any subscription as described in subclause 7.3.3;

B. the additional transferred session is related to a subscription as described in subclause 7.3.3; and

C. a SIP 2xx response was received to the last SIP NOTIFY request with conference information sent to the UE within the related subscription;

then SCC AS shall populate the XML body with the participants extracted as specified in the subclause 9.1A of the subscription related to the additional transferred session as specified in subclause 7.3.3.

When the SCC AS receives a SIP INVITE request transferring additional session for dual radio, the SCC AS shall:

– associate the SIP INVITE request transferring additional session with a previously established SIP dialog i.e. identify the Source Access Leg. The SIP dialog on the Source Access Leg is identified by matching the dialog ID present in the Target-Dialog header field (see IETF RFC 4538 [11]) of the SIP INVITE request transferring additional session with the previously established SIP dialog. By a previously established SIP dialog, it is meant a dialog for which SIP 18x responses or a SIP 2xx response to the initial SIP INVITE request has been sent or received;

– if the SCC AS is unable to associate the SIP INVITE with a unique previously established SIP dialog, send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and not processes the remaining steps;

– if the number of media lines in the Target Access Leg is less than the number of media lines in the Source Access Leg or the media type for the corresponding media lines is not the same as in the original session, send a SIP 4xx response to reject the SIP INVITE request relating to the access transfer and not process the remaining steps;

– if the additional session is a confirmed session, send a SIP re-INVITE request towards the remote UE using the existing established dialog. The SCC AS shall populate the SIP re-INVITE request , following the rules specified in 3GPP TS 24.229 [2] as follows:

A) include a new SDP offer with:

a) if the remote leg is not a precondition enabled dialog, the media characteristics as received in the SIP INVITE request transferring additional session but excluding any precondition mechanism specific SDP attributes for media streams whose port is not set to zero;

b) for the media streams in the SIP INVITE request transferring additional session whose port is set to zero, include the corresponding media characteristics of those streams from the Source Access Leg; and

c) if the remote leg is a precondition enabled dialog, include a new SDP offer, including:

– the media characteristics as received in the SIP INVITE request transferring additional session for PS to CS for dual radio (including any precondition mechanism specific SDP attributes);

NOTE: If the MSC server is using the precondition mechanism, the local preconditions will always be indicated as met according to subclause 9.5.

– if the additional session is a originating session in pre-alerting phase, perform the actions in the subclause 9.3.5.4; and

– if the additional session is a originating session in the alerting phase perform the actions in the subclause 9.3.5.4.

Upon receiving the SIP 2xx response to the SIP re-INVITE request triggered by the SIP INVITE request transferring additional session for dual radio the SCC AS shall:

1. send the SIP 200 (OK) response to the SIP INVITE request transferring additional session for dual radio on the target access leg.

a. if the SIP INVITE request transferring additional session for dual radio is a precondition enabled initial SIP INVITE request, use relevant media parameter of the SDP answer in the received SIP response, by following the rules of 3GPP TS 24.229 [2]; and

b. if the SIP INVITE request transferring additional session for dual radio is not a precondition enabled initial SIP INVITE request, remove from the SDP answer precondition mechanism specific SDP attributes;

2. if the SCC AS supports the PS to CS dual radio access transfer of calls in alerting phase, include the g.3gpp.drvcc-alerting feature-capability indicator as described in annex C in the Feature-Caps header field according to IETF RFC 6809 [60];

3. include the signalling elements described in subclause 6A.4.3A.

The SCC AS shall remove non-transferred audio media components and release source access legs as specified in subclause 9.3.6.

9.3.3 SCC AS procedures for CS to PS access transfer

When the SCC AS receives a SIP INVITE request due to STI on the Target Access Leg offering PS media only, the SCC AS shall follow the procedures specified in subclause 10.3.2.

When the SCC AS receives a SIP INVITE request due to static STI, the SCC AS shall:

1) associate the SIP INVITE request with an ongoing dialog supporting a session; or

NOTE 1: By an ongoing dialog supporting a session, it is meant a dialog for which a SIP 2xx response to the initial SIP INVITE request has been sent or received.

2) if the SCC AS supports CS to PS dual radio access transfer for calls in alerting phase or CS to PS dual radio access transfer for originating calls in pre-alerting phase, associate the SIP INVITE request with a dialog in an early phase.

NOTE 2: By a dialog in an early phase, it is meant a dialog for which a SIP 2xx response to the initial SIP INVITE request has not been sent or received.

Multiple dialogs supporting a session associated with the same SC UE may have been anchored when the SCC AS receives a SIP INVITE request due to static STI.

NOTE 3: This multiple dialogs supporting a session associated with the same SC UE can occur in the event that the UE does not succeed in releasing all dialogs supporting a session with inactive speech media component or if the UE supports the MSC Server assisted mid-call feature or if the SC UE supports the CS to PS dual radio access transfer for calls in alerting phase or CS to PS dual radio access transfer for originating calls in pre-alerting phase, in which case.

The identification of the associated dialog is subject to the following conditions:

1. if only one ongoing dialog supporting a session with active speech media component exists for the user identified in the P-Asserted-Identity header field and a SIP 2xx response has been sent, then continue the session transfer procedures with the ongoing dialog supporting a session with active speech media component;

2. if no ongoing dialogs supporting a session with active speech media component exists for the user identified in the P-Asserted-Identity header field and a SIP 2xx response has been sent and the SCC AS does not apply the MSC Server assisted mid-call feature as specified in subclause 9.3.4 and the condition for transferring dialog(s) in an early dialog phase in subclause 9.3.7.1 are not fulfilled, then send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer;

3. if more than one ongoing dialog supporting a session exists for the user identified in the P-Asserted-Identity header field and exactly one ongoing dialog supporting a session with active speech media component and a SIP 2xx response has been sent for that dialog, then:

A. if the remaining dialogs support a session with inactive speech media component and the SCC AS does not apply the MSC Server assisted mid-call feature as specified in subclause 9.3.4, then the SCC AS may release the dialogs supporting a session with inactive speech media component and continue the session transfer procedures with the dialog supporting a session with active speech media component;

4. if one ongoing dialog with active speech media component and one or more dialogs in an early dialog phase exists and the condition for transferring dialog(s) in an early dialog phase in subclause 9.3.7.1 are fulfilled, continue the session transfer with the ongoing dialog with active speech media component;

5. if one ongoing dialog with active speech media component and one or more dialogs in an early dialog phase exists but the condition for transferring dialog(s) in an early dialog phase in subclause 9.3.7.1 are not fulfilled, then the SCC AS may release the dialogs in an early dialog phase and continue the session transfer with the ongoing dialog with active speech media component;

6. if no ongoing dialogs supporting a session with speech media component and one or more early dialog in an early phase exists and the condition for transferring dialog(s) in an early dialog phase in subclause 9.3.7.1 are fulfilled, proceed with the session transfer as specified in subclause 9.3.7; and

7. if the SCC AS is not able to identify one dialog for session transfer, then the SCC AS shall send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the session transfer and do not continue with the access transfer.

If the session transfer procedures continues and if the dialog to be transferred is an ongoing dialog supporting a session with speech media component, the SCC AS shall send a SIP re-INVITE request towards the remote UE using the existing established dialog. The SCC AS shall populate the SIP re-INVITE request as follows:

1) set the Request-URI to the URI contained in the Contact header field returned at the creation of the dialog with the remote UE; and

2) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to the static STI, by following the rules of 3GPP TS 24.229 [2].

Upon receiving the SIP 2xx response to the SIP re-INVITE request the SCC AS shall send the SIP 200 (OK) response to the SIP INVITE request due to static STI on the target access leg populated as follows:

1) the relevant media parameter of the SDP answer in the received response, by following the rules of 3GPP TS 24.229 [2];

2) if the SCC AS supports CS to PS dual radio access transfer for calls in alerting phase according to operator policy,

a) the g.3gpp.cs2ps-drvcc-alerting feature-capability indicator as described in annex C in a Feature-Caps header field according to IETF RFC 6809 [60]; and

b) if the SCC AS supports PS to CS dual radio access transfer for originating calls in pre-alerting phase the g.3gpp.cs2ps-drvcc-orig-pre-alerting feature-capability indicator as described in annex C in the Feature-Caps header field according to IETF RFC 6809 [60]; and

3) the signalling elements described in subclause 6A.4.3.

Upon receiving the SIP ACK request originated from the SC UE, the SCC AS shall:

1) release the source access leg as specified in subclause 9.3.6.; and

2) if the SCC AS supports the CS to PS dual radio access transfer for a call in an early phase and the condition for transferring dialog(s) in an early dialog phase in subclause 9.3.7.1 are fulfilled, proceed with transferring of the dialog(s) in the early phase as specified in the subclause 9.3.7.4.

If, subsequent to initiating the SIP re-INVITE request to the remote UE, and prior to the SIP ACK request originated from the UE being received from the IM CN subsystem for the source access leg, the SCC AS decides (for any reason) to reject the session transfer request back to the UE (e.g. by sending a SIP 4xx response), the SCC AS shall release the target access leg and maintain the source access leg.

9.3.4 SCC AS procedures for CS to PS access transfer with MSC server assisted mid-call feature

The SCC AS shall apply the MSC Server assisted mid-call feature if:

1. the Contact header field of the SIP INVITE request due to static STI includes the g.3gpp.mid-call media feature tag as described in annex C; and

2. the SCC AS supports the MSC Server assisted mid-call feature according to operator policy.

When the SCC AS applies the MSC Server assisted mid-call feature, in addition to the procedures described in subclause 9.3.3, and before determining that the SCC AS is not able to identify one dialog for session transfer, SCC AS may:

1. if more than one dialog exists for the user identified in the P-Asserted-Identity header field, and exactly one dialog supporting an ongoing session with active speech media component exists, and a SIP 2xx response has been sent for that dialog and there is at least one remaining dialog supporting a session with inactive speech media component, release all dialogs supporting a session with inactive speech media component except the one with the speech media component which became inactive most recently and continue the session transfer procedures with the dialog supporting a session with active speech media component;

2. if no dialog supporting an ongoing session with active speech media component exists for the user identified in the P-Asserted-Identity header field, one or more dialogs supporting a session with inactive speech media component exists for the user and a SIP 2xx response has been sent for these dialogs then the SCC AS may release all dialogs supporting a session with speech media component except the one with the speech media component which became inactive most recently and continue the session transfer procedures with the dialog supporting a session with inactive speech media component; and

3. if more than one dialog exists for the user identified in the P-Asserted-Identity header field, and exactly one dialog supporting an ongoing session with inactive speech media component exists, and a SIP 2xx response has been sent for that dialog and the condition for transferring dialog(s) in an early dialog phase in subclause 9.3.7.1 are fulfilled continue the session transfer procedures with the dialog supporting a session with inactive speech media component;

The SCC AS shall include the signalling elements described in subclause 6A.4.3 in the SIP 1xx response and SIP 2xx response to the SIP INVITE request due to static STI.

When the SCC AS applies the MSC Server assisted mid-call feature and a dialog supporting a session with inactive speech media component was associated with the SIP INVITE request due to static STI, in addition to the procedures described in subclause 9.3.3, the SCC AS shall set the directionality of the speech media component in the SDP offer as used in the session with remote UE.

If the SCC AS applies the MSC Server assisted mid-call feature, two SIP dialogs supporting a session with a speech media component exist for the user identified in the P-Asserted-Identity header field and a SIP 2xx response has been sent for those dialogs then the SCC AS shall send a SIP REFER request towards the SC UE in accordance with the procedures specified in 3GPP TS 24.229 [2], IETF RFC 4488 [20] and IETF RFC 3515 [13] as updated by IETF RFC 6665 [81] and IETF RFC 7647 [90] in the dialog created by the SIP INVITE request due to static STI. The SCC AS shall populate the SIP REFER request as follows:

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20];

2. the Supported header field with value "norefersub" as specified in IETF RFC 4488 [20];

3. the Refer-To header field containing the information related to the session with an audio media other than the session associated with the SIP INVITE request due to static STI, i.e. set to the additional transferred session SCC AS URI and the following URI header fields:

A. the Target-Dialog URI header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of the session with the MSC Server;

B. the Require URI header field populated with the option tag value "tdialog";

C. if the remote UE did not request privacy then the To URI header field populated as specified in IETF RFC 3261 [19], containing the P-Asserted-Identity provided by the remote UE during the session establishment;

D. the From URI header field populated as specified in IETF RFC 3261 [19], containing the public user identity of the SC UE provided during the session establishment;

E. the Content-Type URI header field with "application/sdp"; and

F. the hname "body" URI header field populated with SDP describing the media streams as negotiated in the session with the remote UE and with directionality as used by the MSC Server;

4. the Content-Type header field with the value set to MIME type specified in the subclause D.1.3; and

5. a XML body compliant to the XML schema specified in the subclause D.1.2.

When the SCC AS receives a SIP INVITE request transferring additional session for the dialog supporting the ongoing session with a speech media component, the SCC AS shall:

– associate the SIP INVITE request transferring additional session with a previously established SIP dialog i.e. identify the Source Access Leg. The SIP dialog on the Source Access Leg is identified by matching the dialog ID present in the Target-Dialog header field (see IETF RFC 4538 [11]) of the SIP INVITE request transferring additional session with the previously established SIP dialog. By a previously established SIP dialog, it is meant a dialog for which a SIP 2xx response to the initial SIP INVITE request has been sent or received;

– send a SIP re-INVITE request towards the remote UE using the existing established dialog. The SCC AS shall populate the SIP re-INVITE request with a new SDP offer, following the rules specified in 3GPP TS 24.229 [2], containing the following media information:

a) the media characteristics as received in the SIP INVITE request transferring additional session for media streams whose port is not set to zero; and

When the SCC AS receives the SIP 200 (OK) response to the SIP re-INVITE request, the SCC AS shall send a SIP 200 (OK) response to the SIP INVITE request transferring additional session for the dialog supporting the ongoing session with a speech media component populated as follows:

1) the relevant media parameter of the SDP answer in the received response, by following the rules of 3GPP TS 24.229 [2]; and

2) the signalling elements described in subclause 6A.4.3.

The SCC AS shall release the source access leg as specified in subclause 9.3.6.

9.3.5 SCC AS procedures for PS to CS dual radio access transfer of calls in an early dialog phase

9.3.5.1 Conditions for selecting a sessions in an early dialog phase

An early session is subject for PS to CS dual radio access transfer when one of the following conditions is fulfilled:

1. if there are one or more dialogs in an early phase such that:

a. all dialogs are dialogs in an early phase are created by the same SIP INVITE request;

b. a SIP 180 (Ringing) response to SIP INVITE request was received from remote UEs in at least one of those early dialogs;

c. a g.3gpp.drvcc-alerting feature-capability indicator as described in annex C was included in a Feature-Caps header field provided by the SCC AS in the SIP 180 (Ringing) response;

d. the Contact header field provided by the SC UE towards the SCC AS in the initial SIP INVITE request included the g.3gpp.drvcc-alerting media feature tag field as described in annex C; and

e. the SIP INVITE due to PS to CS STN contains the g.3gpp.drvcc-alerting as described in annex C;

2. if there are one or more dialogs in the early phase such that:

a. all dialogs are dialogs in an early phase are created by the same SIP INVITE request;

b. a SIP 180 (Ringing) response to SIP INVITE request was received from remote UE in at least one of those early dialogs;

c. a g.3gpp.drvcc-alerting feature-capability indicator as described in annex C was included in a Feature-Caps header field provided by the SCC AS in the SIP 180 (Ringing) response;

d. the Contact header field provided by the SC UE towards the SCC AS in the initial SIP INVITE request included the g.3gpp.drvcc-alerting media feature tag field as described in annex C; and

e. no ongoing dialog supporting a session with active or inactive speech media component where a SIP 2xx response has been sent towards the SC UE exists;

NOTE 1: Transfer of one single dialog in the alerting phase does not require any MSC server support.

3. if there are one or more dialogs in an early phase such that:

a. all dialogs are in an early phase are created by the same SIP INVITE request;

b. a SIP 180 (Ringing) response to the SIP INVITE request has not been received from remote UEs yet;

c. the SCC AS included a g.3gpp.ps2cs-drvcc-orig-pre-alerting feature-capability indicator as described in annex C in a Feature-Caps header field in SIP 18x responses;

d. the Contact header field in the initial SIP INVITE request sent by the SC UE towards the SCC AS included a g.3gpp.ps2cs-drvcc-orig-pre-alerting media feature tag as described in annex C; and

e. the SIP INVITE due to PS to CS STN contains the g.3gpp.drvcc-alerting as described in annex C;

4. if there are one or more dialogs in an early phase such that:

a. all dialogs are early phase are created by the same SIP INVITE request;

b. a SIP 180 (Ringing) response to the SIP INVITE request has not been received from remote UEs yet;

c. the SCC AS included a g.3gpp.ps2cs-drvcc-orig-pre-alerting feature-capability indicator as described in annex C in a Feature-Caps header field in SIP 18x responses;

d. the Contact header field in the initial SIP INVITE request sent by the SC UE towards the SCC AS included a g.3gpp.ps2cs-drvcc-orig-pre-alerting media feature tag as described in annex C; and

e. no ongoing dialog supporting a session with active or inactive speech media component where a SIP 2xx response has been sent towards the SC UE exists;

NOTE 2: Transfer of one single dialog in the originating pre-alerting phase does not require any MSC server support.

5. if there is one dialog in an dialog phase such that:

a. a SIP 180 (Ringing) response to the SIP INVITE request has been received from the SC UE;

b. the SCC AS included a g.3gpp.drvcc-alerting feature-capability indicator as described in annex C in a Feature-Caps header field in the SIP INVITE request; and

c. the Contact header field in the SIP 180 (Ringing) response sent by the SC UE towards the SCC AS included a g.3gpp.drvcc-alerting media feature tag as described in annex C.

NOTE 3: Transfer of a dialog in the alerting phase on the terminating side does not require any MSC server support.

9.3.5.2 SCC AS procedures for PS to CS dual radio access transfer of a originating session in the alerting phase

When the SCC AS receives a SIP INVITE request due to PS to CS STN and if there are one or more dialogs in an early dialog phase supporting a session with active speech media component such that:

1) all dialogs are early dialogs created by the same SIP INVITE request;

2) a SIP 180 (Ringing) response to SIP INVITE request was received in at least one of those early dialogs;

3) a g.3gpp.drvcc-alerting feature-capability indicator as described in annex C was included in a Feature-Caps header field by the SCC AS in the SIP 180 (Ringing) response; and

4) the Contact header field in the initial SIP INVITE request sent by the SC UE towards the SCC AS included the g.3gpp.drvcc-alerting media feature tag as described in annex C,

then the SCC AS shall for each early dialog send an SIP UPDATE request towards the remote UE and populate each SIP UPDATE request as follows:

1) set the Request-URI set to the URI contained in the Contact header field returned at the creation of the dialog with the remote UE;

2) the Contact header field set to the Contact header field provided by the served UE at the creation of the dialog with the remote UE; and

3) a new SDP offer, including:

a) if the remote leg is not a precondition enabled dialog, the media characteristics as received in the SIP INVITE request due to PS to CS STN but excluding any precondition mechanism specific SDP attributes, by following the rules of 3GPP TS 24.229 [2];

b) if the remote leg is a precondition enabled dialog, include a new SDP offer including:

– the media characteristics as received in the SIP INVITE request due to PS to CS STN (including any precondition mechanism specific SDP attributes); and

For each SIP 200 (OK) response to the SIP UPDATE request (triggered by the SIP INVITE request due to PS to CS STN) from a remote UE the SCC AS shall:

1) if one of the following is true:

A) if the remote leg is not a precondition enabled dialog;

B) if the remote leg is a precondition enabled dialog, the SIP INVITE request due to PS to CS STN is a precondition enabled initial SIP INVITE request and both local and remote preconditions are met:

send a SIP provisional response to the SIP INVITE request due to PS to CS STN following the rules of 3GPP TS 24.229 [2] with the response code corresponding to the actual dialog state populated with:

– an SDP answer based on the SDP answer received from the remote UE; and

– the last received P-Early-Media header field, including the SIP 2xx response to the SIP UPDATE request, if a P-Early-Media has been received from the remote UE.

2) if the remote leg is a precondition enabled dialog but all preconditions are not met, send a SIP 183 (Session Progress) response following the rules of 3GPP TS 24.229 [2] populated with:

– if SIP INVITE request due to PS to CS STN is a precondition enabled initial SIP INVITE, an SDP answer based on the SDP answer received from the remote UE; and

– if SIP INVITE request due to PS to CS STN is not a precondition enabled initial SIP INVITE, an SDP answer based on the SDP answer received from the remote UE but excluding the precondition mechanism specific SDP attributes; and

– the last received P-Early-Media header field, including the SIP 2xx response to the SIP UPDATE request, if a P-Early-Media has been received from the remote UE.

Upon receipt of an SIP PRACK request on the target access leg send a SIP 200 (OK) response to the SIP PRACK request on the target access leg.

Upon receipt of a provisional SIP response from the remote UE forward the SIP provisional response on the target access leg following the rules of 3GPP TS 24.229 [2]. If the SIP INVITE request due to PS to CS STN is not a precondition enabled initial SIP INVITE remove any precondition mechanism specific SDP attributes from the SDP offer. Upon receipt of the SIP PRACK request on the target access leg, forward the SIP PRACK request towards the remote UE following the rules of 3GPP TS 24.229 [2].

Upon receipt of a SIP UPDATE request on the target access leg the SCC AS shall forward the SIP request to the remote UE following the rules of 3GPP TS 24.229 [2]. Upon receipt of a SIP 200 (OK) response to this SIP UPDATE request from the remote UE:

1) forward the SIP response on the target access leg following the rules of 3GPP TS 24.229 [2]; and

2) if both local and remote preconditions are met and if the remote leg is in the alerting phase, send a SIP 180 (Ringing) response following the rules of 3GPP TS 24.229 [2] with the last received P-Early-Media header field, including the SIP 2xx response to the SIP UPDATE request, if a P-Early-Media header field has been received from the remote UE.

Upon receipt of a SIP UPDATE request from the remote UE, the SCC AS shall forward the SIP request on the target access leg following the rules of 3GPP TS 24.229 [2] but if the SIP INVITE request due to PS to CS STN is not a precondition enabled initial SIP INVITE remove from the SDP answer the precondition mechanism specific SDP attributes. Upon receipt of a SIP 200 (OK) response to this SIP UPDATE request on the target access leg, the SCC AS shall:

1) forward the SIP response towards the remote UE following the rules of 3GPP TS 24.229 [2]; and

2) if both local and remote preconditions are met and if the remote leg is in the alerting phase, send a SIP 180 (Ringing) response on the target access leg with the last received P-Early-Media header field, including the SIP 2xx response to the SIP UPDATE request, if a P-Early-Media header field has been received from the remote UE.

The SCC AS shall remove non-transferred audio media components and release the source access leg as specified in subclause 9.3.6.

9.3.5.3 SCC AS procedures for PS to CS dual radio, access transfer of a originating session in the pre-alerting phase

When the SCC AS receives a SIP INVITE request due to PS to CS STN and if there are zero, one or more dialogs in an early dialog phase supporting a session with active speech media component such that:

1) all dialogs are early dialogs created by the same SIP INVITE request;

2) a SIP 180 (Ringing) response to the SIP INVITE request has not been received yet in any of the existing dialogs;

3) the SCC AS included a g.3gpp.ps2cs-drvcc-orig-pre-alerting feature-capability indicator as described in annex C in a Feature-Caps header field of SIP 18x responses; and

4) the Contact header field in the initial SIP INVITE request sent by the SC UE towards the SCC AS included a g.3gpp.ps2cs-drvcc-orig-pre-alerting media feature tag as described in annex C,

then the SCC AS shall for each early dialog send a SIP UPDATE request towards the remote UE.

NOTE 1: The SCC AS can have zero dialogs if all the early dialogs were terminated by the 199 (Early Dialog Terminated) response as described in IETF RFC 6228 [80].

Each SIP UPDATE request shall be populated as follows:

1) the Request-URI set to the URI contained in the Contact header field returned at the creation of the dialog with the remote UE;

2) the Contact header field set to the Contact header field provided by the served UE at the creation of the dialog with the remote UE; and

3) an new SDP offer, including

b) if the remote leg is a precondition enabled dialog, include a new SDP offer including:

– the media characteristics as received in the SIP INVITE request due to PS to CS STN (including any precondition mechanism specific SDP attributes); and

For each SIP 200 (OK) response to the SIP UPDATE request (triggered by the SIP INVITE request due to CS to PS STN) from a remote UE the SCC AS shall

1) if one of the following is true:

A) if the remote leg is not a precondition enabled dialog;

B) if the remote leg is a precondition enabled dialog, the SIP INVITE request due to PS to CS STN is a precondition enabled initial SIP INVITE request and both local and remote preconditions are met:

send a SIP provisional response to the SIP INVITE request due to PS to CS STN with the response code corresponding to the actual dialog state populated with:

– a SDP answer based on the SDP answer received from the remote UE; and

– the last received P-Early-Media header field, including the SIP 2xx response to the SIP UPDATE request, if a P-Early-Media has been received from the remote UE.

2) if the remote leg is a precondition enabled dialog, the SIP INVITE request due to PS to CS STN is a precondition enabled initial SIP INVITE request but all preconditions are not met, send a SIP 183 (Session Progress) response populate with:

– if SIP INVITE request due to PS to CS STN is a precondition enabled initial SIP INVITE, an SDP answer based on the SDP answer received from the remote UE; and

– the last received P-Early-Media header field, including the SIP 2xx response to the SIP UPDATE request, if a P-Early-Media has been received from the remote UE.

Upon receipt of an SIP PRACK request on the target access leg send a SIP 200 (OK) response to the SIP PRACK request on the target access leg.

Upon receipt of a SIP UPDATE request on the target access leg the SCC AS shall forward the SIP request to the remote UE. Upon receipt of a SIP 200 (OK) response to this SIP UPDATE request from the remote UE, the SCC AS shall forward the SIP response on the target access leg.

Upon receipt of a SIP UPDATE request from the remote UE, the SCC AS shall forward the SIP request on the target access leg. If the SIP INVITE request due to PS to CS STN is not a precondition enabled initial SIP INVITE remove any precondition mechanism specific SDP attributes from the SDP offer. Upon receipt of a SIP 200 (OK) response to this SIP UPDATE request on the target access leg, the SCC AS shall forward the SIP response towards the remote UE.

The SCC AS shall remove non-transferred audio media components and release the source access leg as specified in subclause 9.3.6.

9.3.5.4 SCC AS procedures for PS to CS dual radio access transfer of an additional session in an early dialog phase

In order to transfer an additional session on the originating side that can be in pre-alerting phase or in an alerting phase, the SCC AS shall send a SIP REFER request according to 3GPP TS 24.229 [2], IETF RFC 4488 [20] and IETF RFC 3515 [13] as updated by IETF RFC 6665 [81] and IETF RFC 7647 [90] and IETF RFC 4488 [20] in the dialog created by the SIP INVITE request due to PS to CS STN. The SCC AS shall populate the SIP REFER request as follows:

1. the Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20];

2. the Require header field with value "norefersub" as specified in IETF RFC 4488 [20];

3. the Refer-To header field containing the additional transferred session SCC AS URI for PS to CS dual radio, where the URI also includes the following header fields containing the information related to the additional transferred session:

A. the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of an dialog in the early phase supporting session of the SC UE;

B. the Require header field populated with the option tag value "tdialog";

C. the To header field populated as specified in IETF RFC 3261 [19], containing the value of the P-Asserted-Identity provided by the remote UE during the session establishment;

D. the From header field populated as specified in IETF RFC 3261 [19], containing the value of the P-Asserted-Identity provided by the SC UE during the session establishment;

E. the Content-Type header field with "application/sdp";

F. the URI header field with the hname "body" populated with SDP describing the media streams as negotiated in the session with the remote UE; and

G. optionally the P-Asserted-Identity URI header field containing value of the P-Asserted-Identity header field of the received SIP INVITE request; and

4. application/vnd.3gpp.state-and-event-info+xml MIME body populated as follows:

A) if a SIP 180 (Ringing) response to the SIP INVITE request has already been received in any of the early dialogs associated with the originating early session not accepted yet, with the state-info XML element containing "early" and the direction XML element containing "initiator"; and

B) if a SIP 180 (Ringing) response to the SIP INVITE request has not been received yet in any of the early dialogs associated with the originating early session not accepted yet, with the state-info XML element containing "pre-alerting" and the direction XML element containing "initiator".

When the SCC AS receives the SIP INVITE request transferring additional session for PS to CS for dual radio, the SCC AS shall:

– associate the SIP INVITE request transferring additional session for PS to CS for dual radio with an SIP dialog in early dialog phase i.e. identify the source access leg;

NOTE 1: The SIP dialog on the source access leg is identified by matching the dialog ID present in Target-Dialog header field (see IETF RFC 4538 [11]) of the SIP INVITE with a dialog in early state.

NOTE 2: By a SIP dialog in early dialog phase, it is meant an early SIP dialog which has been created by a provisional response to the initial SIP INVITE request, but for which the SIP 2xx response has not yet been sent or received;

– if the SCC AS is unable to associate the SIP INVITE with a unique dialog in early dialog phase, send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and not processes the remaining steps;

– if the number of media lines in the target access leg is less than the number of media lines in the source Access leg or the media type for the corresponding media lines is not the same as in the original session, send a SIP 4xx response to reject the SIP INVITE request relating to the access transfer and not process the remaining steps; and

– send a SIP UPDATE request(s) towards the remote UE(s) using the existing early dialog(s) which were created by the same SIP INVITE request as the source access leg. The SCC AS shall populate the SIP UPDATE request(s) following the rules specified in 3GPP TS 24.229 [2], as follows:

A) include a new SDP offer with:

a) the media characteristics as received in the SIP INVITE request transferring additional session for PS to CS for dual radio received on the target access leg for media streams whose port is not set to zero modified as follows:

i) if the remote leg is not a precondition enabled dialog and the SIP INVITE request transferring additional session for PS to CS for dual radio is a precondition enabled initial SIP INVITE request, exclude preconditions specific attributes in the new SDP offer; and

ii) if the remote leg is a precondition enabled dialog and the SIP INVITE request transferring additional session for PS to CS for dual radio is not a precondition enabled initial SIP INVITE request, indicate preconditions as met, using the segmented status type, as defined in IETF RFC 3312 [88] and IETF RFC 4032 [89], as well as the strength-tag value "mandatory" for the local segment and the strength-tag value either "optional" or as specified in RFC 3312 [88] and RFC 4032 [89] for the remote segment;

NOTE 3: If the MSC server is using the precondition mechanism, the local preconditions will always be indicated as met according to subclause 9.7.

b) for the media streams in the SIP INVITE request transferring additional session for PS to CS for dual radio whose port is set to zero, include the corresponding media characteristics of those streams from the source access leg.

When receiving SIP 2xx response(s) to the SIP UPDATE request(s) triggered by the SIP INVITE request transferring additional session for dual radio, the SCC AS shall send a SIP 18x response with the status code corresponding to the latest SIP 18x response following the rules of 3GPP TS 24.229 [2] received from remote leg in the dialog to the SIP INVITE request transferring additional session for PS to CS for dual radio containing:

1) if

a) the SIP INVITE request transferring additional session for PS to CS for dual radio is a precondition enabled initial SIP INVITE request, an SDP answer with the relevant media parameter of the SDP answer in the received SIP 2xx response;

b) the SIP INVITE request transferring additional session for PS to CS for dual radio is not a precondition enabled initial SIP INVITE request, an SDP answer with the relevant media parameter of the SDP answer in the received SIP 2xx response but excluding the precondition mechanism specific SDP attributes;

If a SIP PRACK request is received on the target access leg, send a SIP 200 (OK) response to the SIP PRACK request on the target access leg; and

2) the last received P-Early-Media header field, including the SIP 2xx response to the SIP UPDATE request, if a P-Early-Media has been received from the remote UE.

The SCC AS shall remove non-transferred audio media components and release the source access leg as specified in subclause 9.3.6.

9.3.5.5 SCC AS procedures for PS to CS dual radio access transfer of a terminating session in the alerting phase

When the SCC AS receives a SIP 488 (Not Acceptable Here) response to the SIP INVITE request creating the session in the terminating alerting phase without an SDP MIME body and if the SCC AS supports PS to CS dual radio access transfer for calls in alerting phase then the SCC AS shall:

1) if a SIP 180 (Ringing) response to the SIP INVITE request has been received from the SC UE;

2) if the SCC AS included a g.3gpp.ps2cs-drvcc-orig-pre-alerting feature-capability indicator as described in annex C in the SIP INVITE request; and

3) if the Contact header field in the SIP 180 (Ringing) response request sent by the SC UE towards the SCC AS included a g.3gpp.drvcc-alerting media feature tag as described in annex C,

terminate the call over CS as follows:

1) perform the actions according to the subclause 10.4.7 in 3GPP TS 24.292 [4] with the following clarifications:

a) the URI in the Request-URI shall be set to C-MSISDN; and

b) the P-Asserted-Identity header field set to:

– if the SIP 180 (Ringing) response contained the g.3gpp.dynamic-stn media feature tag as described in annex C in the Contact header field, the dynamic STN; and

– if the SIP 180 (Ringing) response does not contain the g.3gpp.dynamic-stn media feature tag as described in annex C in the Contact header field, the static STN.

When the SCC AS receives a SIP 1xx response with an SDP answer the SCC AS shall:

a) send a SIP PRACK request towards the CS domain; and

b) send an SIP UPDATE request to the remote UE populated as follows:

– the Request-URI set to the URI contained in the Contact header field returned at the creation of the dialog with the remote UE;

– the Contact header field set to the Contact header field provided by the served UE at the creation of the dialog with the remote UE; and

– anew SDP offer, including the media characteristics as received in the SIP 1xx response with the SDP answer, by following the rules of 3GPP TS 24.229 [2].

Upon receipt of the SIP 200 (OK) response to the SIP UPDATE request, the SC AS shall remove non-transferred audio media components and release the source access leg as specified in subclause 9.3.6.

9.3.6 Removal of non-transferred audio media components and release of source access legs

When the transfer of a session is successfully completed, then the SCC AS shall release the source legs as follows:

If:

1) the source access leg is an ongoing session containing only an active or inactive media component or a session in an early dialog phase on the terminating side, send a SIP BYE request on the source access leg in accordance with 3GPP TS 24.229 [2];

2) the session is dialog in an early dialog phase on the originating side send a SIP 480 (Temporary Unavailable) response on the source access leg in accordance with 3GPP TS 24.229 [2]; and

NOTE: In case of PS to CS dual radio access transfer of a session in an early phase, the SC UE will receive the SIP request or response only if the SC UE is using Gm after the PS-CS access transfer is completed.

3) the source access leg contains media components other than speech media component, the SCC AS should send a SIP re-INVITE request to update the source access leg in accordance with 3GPP TS 24.229 [2].

9.3.7 SCC AS procedures for CS to PS dual radio access transfer for calls in an early phase

9.3.7.1 Conditions for transferring dialog(s) in the originating pre-alerting or the alerting dialog phase

Upon receiving a SIP INVITE request due to static STI and the SCC AS support CS to PS dual radio access transfer for calls in alerting phase or CS to PS dual radio access transfer for originating calls in pre-alerting phase and one of the following conditions are fulfilled:

1) if there are one or more dialog in an early dialog phase such that:

a) all dialogs are early dialogs created by the same SIP INVITE request;

b) a SIP 180 (Ringing) response to SIP INVITE request was received from remote UEs in at least one of those early dialogs;

c) the g.3gpp.cs2ps-drvcc-alerting feature-capability indicator as described annex C in a Feature-Caps header field was included in the SIP INVITE due to static STI; and

d) the SCC AS supports CS to PS dual radio access transfer for calls in alerting phase;

2) if there are one or more dialog in an early dialog phase such that:

a) all dialogs are early dialogs created by the same SIP INVITE request;

b) a SIP 180 (Ringing) response to the SIP INVITE request has not been received from remote UEs yet;

c) a g.3gpp.cs2to-drvcc-orig-pre-alerting media feature tag as described in annex C in the Contact header field was included in the SIP INVITE request due to static STI; and

d) the SCC AS supports CS to PS dual radio access transfer for originating calls in pre-alerting phase; and

3) if there is one dialog in an early dialog phase such that:

a) a SIP 180 (Ringing) response to the SIP INVITE request has been received from the SC UE;

b) the g.3gpp.cs2ps-drvcc-alerting feature-capability indicator as described annex C in a Feature-Caps header field was included in the SIP INVITE due to static STI; and

c) the SCC AS supports CS to PS dual radio access transfer for calls in alerting phase.

then the SCC AS shall regard the session subject for PS to CS dual radio access transfer.

9.3.7.2 SCC AS procedures for CS to PS dual radio access transfer for originating calls in pre-alerting phase or in alerting phase on the originating side

When the SCC AS receives a SIP INVITE request due to static STI and if the SCC AS supports CS to PS dual radio access transfer for calls in alerting phase or CS to PS dual radio access transfer for originating calls in pre-alerting phase and:

1) if there are one or more dialog in an early dialog phase such that:

a) all dialogs are early dialogs created by the same SIP INVITE request;

b) a SIP 180 (Ringing) response to SIP INVITE request was received from remote UEs in at least one of those early dialogs;

c) the g.3gpp.cs2ps-drvcc-alerting feature-capability indicator in a Feature-Caps header field as described in annex C was included in the SIP INVITE due to static STI; and

d) if the SCC AS supports CS to PS dual radio access transfer for calls in alerting phase; or

2) if there are zero, one or more dialog in an early dialog phase such that:

a) all dialogs are early dialogs created by the same SIP INVITE request;

b) a SIP 180 (Ringing) response to the SIP INVITE request has not been received yet in any of the existing dialogs;

c) a g.3gpp.drvcc-orig-pre-alerting media feature tag as described in annex C in the Contact header field was included in the SIP INVITE due to static STI; and

d) the SCC AS supports CS to PS dual radio access transfer for originating calls in pre-alerting phase,

NOTE: The SCC AS can have zero dialogs if all the early dialogs were terminated by the SIP 199 (Early Dialog Terminated) response as described in RFC 6228 [80].

then the SCC AS shall

A) for each existing early dialog towards remote UEs send an SIP UPDATE request and populate as follows:

a) the Contact header field set to the Contact header field provided on the source leg at the creation of the dialog with the remote UE; and

b) a new SDP offer, including the media characteristics as received in the SIP INVITE request due to static STI, by following the rules of 3GPP TS 24.229 [2].For each SIP 200 (OK) response to the SIP UPDATE request on an existing dialog from a remote UE the SCC AS shall create a new early dialog by sending a SIP provisional response to the SIP INVITE request due to static STI with the response code corresponding to the actual dialog state populated with:

I) an SDP answer based on the SDP answer received from the remote UE;

II) the last received P-Early-Media header field, including the SIP 2xx response to the SIP UPDATE request, if a P-Early-Media has been received from the remote UE;

III) if the SCC AS supports CS to PS dual radio access transfer for calls in alerting phase according to operator policy,

– the g.3gpp.cs2ps-drvcc-alerting feature-capability indicator as described in annex C in a Feature-Caps header field according to IETF 6809 [60]; and

– if the SCC AS supports PS to CS dual radio access transfer for originating calls in pre-alerting phase, the g.3gpp.cs2ps-drvcc-orig-pre-alerting feature-capability indicator as described in annex C in a Feature-Caps header field according to IETF 6809 [60]; and

IV) the signalling elements described in subclause 6A.4.3 in the SIP 1xx response.

Upon receiving the SIP PRACK request from the target access leg, if the early session is an originating early session in the pre-alerting state, the SCC AS shall send a SIP INFO request towards the SC UE as specified in 3GPP TS 24.229 [2] and IETF RFC 6086 [54] in the dialog created by the SIP INVITE request due to static STI populated as follows:

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

2) include an application/vnd.3gpp.state-and-event-info+xml MIME 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 the direction XML element containing "initiator".

If the SCC AS supports the PS to CS dual radio access transfer for originating calls in pre-alerting phase and if a SIP 1xx response or SIP 2xx response establishing a new dialog is received on the remote leg of the additional transferred session where the SIP response is to the SIP INVITE request from the served user, the SCC AS shall:

1) if the SIP 1xx response is received:

a) send a SIP PRACK request on the remote leg as specified in 3GPP TS 24.229 [2] with the SDP offer received in the SIP INVITE request transferring additional session for PS to CS dual radio as specified in 3GPP TS 24.229 [2];

b) upon receiving the SIP 200 (OK) response to the SIP PRACK request, send the SIP 1xx response to the SIP INVITE request transferring additional session for PS to CS dual radio as specified in 3GPP TS 24.229 [2] populated as follows:

i) include the SDP answer received in the SIP 200 (OK) response to the SIP PRACK request as specified in 3GPP TS 24.229 [2]; and

ii) if the SIP INVITE request transferring additional session for PS to CS dual radio contains a P-Early-Media header field with the "supported" parameter and if the SCC AS has received a P-Early-Media header field in a SIP message in the dialog of the SIP PRACK request, include a P-Early-Media header field containing the value of the last P-Early-Media header field received in a SIP message in the dialog of the SIP PRACK request; and

c) include the signalling elements described in subclause 6A.4.3 in the SIP 1xx response; and

2) if the SIP 2xx response is received:

a) send a SIP ACK request on the remote leg as specified in 3GPP TS 24.229 [2];

b) send a SIP UPDATE request on the remote leg as specified in 3GPP TS 24.229 [2] populated with the SDP offer received in the SIP INVITE request transferring additional session for PS to CS dual radio as specified in 3GPP TS 24.229 [2]; and

c) upon receiving the SIP 200 (OK) response to the SIP UPDATE request, send a SIP 200 (OK) response to the SIP INVITE request transferring additional session for PS to CS dual radio as specified in 3GPP TS 24.229 [2] populated with:

i) the SDP answer received in the SIP 200 (OK) response to the SIP UPDATE request as specified in 3GPP TS 24.229 [2]; and

ii) the signalling elements described in subclause 6A.4.3 in the SIP 1xx response.

The SCC AS shall release the source access leg as specified in subclause 9.3.6.

9.3.7.3 SCC AS procedures for CS to PS dual radio access transfer for a call in the alerting phase on the terminating side

When the SCC AS receives a SIP INVITE request due to static STI and if SCC AS supports CS to PS dual radio access transfer for calls in alerting phase and:

1) if there is one dialog in an early dialog phase such that:

a) a SIP 180 (Ringing) response to the SIP INVITE request has been received from the SC UE; and

b) a g.3gpp.drvcc-alerting media feature tag as described in annex C in the Contact header field was included in the SIP INVITE request due to static STI,

then the SCC AS shall send a SIP UPDATE request towards the remote UE populated as follows:

1) include the Contact header field set to the Contact header field provided on the source leg at the creation of the dialog with the remote UE; and

2) include a new SDP offer, including the media characteristics as received in the SIP INVITE request due to static STI, by following the rules of 3GPP TS 24.229 [2].

Upon receipt of the SIP 200 (OK) response to the SIP UPDATE request from the remote UE the SCC AS shall send a SIP 180 (Ringing) response to the SIP INVITE request due to static STI with populated with:

1) an SDP answer based on the SDP answer received from the remote UE;

2) the last received P-Early-Media header field, including the SIP 2xx response to the SIP UPDATE request, if a P-Early-Media has been received from the remote UE; and

3) the g.3gpp.cs2ps-drvcc-alerting feature-capability indicator in a Feature-Caps header field according to annex C; and

4) if the SCC AS supports PS to CS dual radio access transfer for originating calls in pre-alerting phase, the g.3gpp.cs2ps-drvcc-orig-pre-alerting feature-capability indicator according to annex C in the Feature-Caps header field; and

5) the signalling elements described in subclause 6A.4.3.

Upon receiving the SIP PRACK request from the target access leg, the SCC AS shall send a SIP INFO request towards the SC UE as specified in 3GPP TS 24.229 [2] and IETF RFC 6086 [54] in the dialog created by the SIP INVITE request due to static STI populated as follows:

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

2) include an application/vnd.3gpp.state-and-event-info+xml MIME 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 "early" and the direction XML element containing "receiver".

Upon receiving the SIP INFO request which includes an Info-Package header field containing 3gpp.state-and-event info package name and an application/vnd.3gpp.state-and-event-info+xml MIME body associated with the info package according to IETF RFC 6086 [54] and compliant to the XML schema specified in the clause D.2 from the SC UE with the event XML element containing "call-accepted", the SCC AS shall send as specified in 3GPP TS 24.229 [2]:

1) a SIP 200 (OK) response to the SIP INVITE request received earlier from the remote UE indicating that the called party has answered the call; and

2) a SIP 200 (OK) response to the SIP INVITE request due to static STI towards the SC UE to indicate the successful access transfer.

The SCC AS shall release the source access leg as specified in subclause 9.3.6.

9.3.7.4 SCC AS procedures for PS to CS dual radio access transfer of an additional session in an early dialog phase

In order to transfer of an additional session that can be in originating pre-alerting phase or in an alerting phase, the SCC AS supporting CS to PS dual radio access transfer for calls in an early phase, shall send a SIP REFER request according to 3GPP TS 24.229 [2], IETF RFC 4488 [20] and IETF RFC 3515 [13] as updated by IETF RFC 6665 [81] and IETF RFC 7647 [90] in the dialog created by the SIP INVITE request due to static STI populated as follows:

1) include a Refer-Sub header field with value "false" as specified in IETF RFC 4488 [20];

2) include a Require header field with value "norefersub" as specified in IETF RFC 4488 [20];

3) include a Refer-To header field containing the additional transferred session SCC AS URI for PS to CS dual radio, where the URI also includes the following URI header fields containing the information related to the additional transferred session:

a) if an early dialog supporting the additional transferred session exists, the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier of the dialog in the early phase;

b) if the SCC AS supports the PS to CS dual radio access transfer for originating calls in pre-alerting phase, if no early dialog supporting the additional transferred session exists, there is a SIP INVITE request from the served user for which a final SIP response has not been received yet and if an early dialog supporting the additional transferred session existed and was terminated, the Target-Dialog header field populated as specified in IETF RFC 4538 [11], containing the dialog identifier on the source access leg of the early dialog supporting the additional transferred session which existed and was terminated;

NOTE 1: Early dialog can be terminated by SIP 199 (Early Dialog Terminated) response.

c) the Require header field populated with the option tag value "tdialog";

d) if an early dialog supporting the additional transferred session exists, the To header field populated as specified in IETF RFC 3261 [19], containing the value of the P-Asserted-Identity provided by the remote UE during the session establishment;

e) the From header field populated as specified in IETF RFC 3261 [19], containing the value of the P-Asserted-Identity provided by the SC UE during the session establishment;

f) the Content-Type header field with "application/sdp";

g) if an early dialog supporting the additional transferred session exists, the URI header field with hname "body" populated with SDP describing the media streams as negotiated in the session with the remote UE; and

h) if the SCC AS supports the PS to CS dual radio access transfer for originating calls in pre-alerting phase, no early dialog supporting the additional transferred session exists, there is a SIP INVITE request from the served user for which a final SIP response has not been received yet, the URI header field with the hname "body" populated with the SDP offer received in the SIP INVITE request from the served user; and

4) application/vnd.3gpp.state-and-event-info+xml MIME with:

a) if a SIP 180 (Ringing) response to the SIP INVITE request has already been received from the remote UE in any of the early dialogs associated with the originating early session not accepted yet, the state-info XML element containing "early" and the direction XML element containing "initiator";

b) if a SIP 180 (Ringing) response to the SIP INVITE request has not been received yet from the remote UE in any of the early dialogs associated with the originating early session not accepted yet and the additional transferred session was originated by the SC UE, the state-info XML element containing "pre-alerting" and the direction XML element containing "initiator"; and

c) if a SIP 180 (Ringing) response to the INVITE request has already been received on the source access leg, the state-info XML element containing "early" and the direction XML element containing "receiver"

When the SCC AS receives the SIP INVITE request transferring additional session for CS to PS for dual radio, the SCC AS shall:

1) if the Target-Dialog of the SIP INVITE request transferring additional session for PS to CS dual radio identifies an existing early dialog, associate the SIP INVITE request transferring additional session for PS to CS for dual radio with the SIP early dialog i.e. identify the source access leg;

NOTE 2: The SIP dialog on the source access leg is identified by matching the dialog ID present in Target-Dialog header field (see IETF RFC 4538 [11]) of the SIP INVITE with a dialog in early state.

NOTE 3: By a SIP dialog in early dialog phase, it is meant an early SIP dialog which has been created by a provisional response to the initial SIP INVITE request, but for which the SIP 2xx response has not yet been sent or received.

2) if the SCC AS supports the PS to CS dual radio access transfer for originating calls in pre-alerting phase, if the Target-Dialog of the SIP INVITE request transferring additional session for PS to CS dual radio identifies an early dialog which has already been terminated, associate the SIP INVITE request transferring additional session for PS to CS dual radio with the early dialog i.e. identify the source access leg;

3) if the SCC AS is unable to associate the SIP INVITE request with a unique dialog in early dialog phase, send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request relating to the access transfer and not processes the remaining steps;

4) if the number of media lines in the target access leg is less than the number of media lines in the source Access leg or the media type for the corresponding media lines is not the same as in the original session, send a SIP 4xx response to reject the SIP INVITE request relating to the access transfer and not process the remaining steps; and

5) if an early dialog exists on the remote leg of the additional transferred session, send a SIP UPDATE request(s) towards the remote UE(s) using the existing early dialog(s) which were created by the same SIP INVITE request as the source access leg populated with a new SDP offer, following the rules specified in 3GPP TS 24.229 [2], containing the following media information:

a) the media characteristics as received in the SIP INVITE request transferring additional session for CS to PS for dual radio received on the target access leg for media streams whose port is not set to zero; and

b) for the media streams in the SIP INVITE request transferring additional session for CS to PS for dual radio whose port is set to zero, include the corresponding media characteristics of those streams from the source access leg.

If an early dialog exists on the remote leg then when receiving SIP 2xx response(s) to the SIP UPDATE request(s), the SCC AS shall create a new dialog by sending a SIP 18x response with the status code corresponding to the latest SIP 18x response received from remote leg in the dialog to the SIP INVITE request transferring additional session for CS to PS for dual radio containing:

1) an SDP answer with the relevant media parameter of the SDP answer in the received SIP 2xx response;

2) if the SIP INVITE request transferring additional session for PS to CS dual radio contains a P-Early-Media header field with the "supported" parameter, the last received P-Early-Media header field, including the SIP 2xx response to the SIP UPDATE request, if a P-Early-Media has been received from the remote UE; and

3) the signalling elements described in subclause 6A.4.3.

1) if the SIP 1xx response is received:

a) send SIP PRACK request on the remote leg as specified in 3GPP TS 24.229 [2] populated with the SDP offer received in the SIP INVITE request transferring additional session for PS to CS dual;

i) include the SDP answer received in the SIP 200 (OK) response to the SIP PRACK request as specified in 3GPP TS 24.229 [2];

iii) the signalling elements described in subclause 6A.4.3; and

2) if a SIP 2xx response is received:

a) send a SIP ACK request on the remote leg as specified in 3GPP TS 24.229 [2];

b) send a SIP UPDATE request on the remote leg as specified in 3GPP TS 24.229 [2 populated with the SDP offer received in the SIP INVITE request transferring additional session for PS to CS dual radio as specified in 3GPP TS 24.229 [2]; and

i) the SDP answer received in the SIP 200 (OK) response to the SIP UPDATE request as specified in 3GPP TS 24.229 [2]; and

ii) the signalling elements described in subclause 6A.4.3.

The SCC AS shall release the source access leg as specified in subclause 9.3.6.

1) a SIP 200 (OK) response to the SIP INVITE request received earlier from the remote UE indicating that the called party has answered the call; and

2) a SIP 200 (OK) response to the SIP INVITE request due to static STI towards the SC UE to indicate the successful access transfer.

9.4 MSC server enhanced for ICS

If the MSC server enhanced for ICS has registered for the user, the MSC server shall apply the procedures as specified in 3GPP TS 29.292 [18].

If the MSC server enhanced for ICS supports the MSC server assisted mid-call feature, the MSC server shall apply the procedures specified in subclause 9.5 and subclause 9.6.

If the MSC server enhanced for ICS supports PS to CS dual radio access transfer for calls in alerting phase, the MSC server shall apply the procedures specified in subclause 9.7.

9.4.1 Void

9.4.1A Void

9.5 PS to CS session continuity with MSC server assisted mid-call feature

This subclause describes the procedures required by an MSC server in order to support the MSC server assisted mid call feature.

The MSC server shall populate the SIP INVITE request due to STN as follows:

1. the Supported header field containing the option-tag "norefersub" specified in IETF RFC 4488 [20];

2. the Accept header field containing the MIME type as specified in subclause D.1.3;

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

4. the Recv-Info header field containing the g.3gpp.mid-call package name.

NOTE 1: Since the MSC server is not able to distinguish the dual radio access transfer from the regular session set up, the information elements above are added to every SIP INVITE request sent by the MSC server.

Upon receiving a CC CONNECT ACK message related to a CC CONNECT message sent as result of receiving a SIP 2xx response to SIP INVITE request due to STN, if inactive speech media component is negotiated by the SDP answer of the SIP 2xx response to the SIP INVITE request due to STN, after handling the CC CONNECT ACK according to 3GPP TS 24.008 [8], the MSC server shall re-assign the hold auxiliary state (defined in 3GPP TS 24.083 [43]) to "call held" for the transaction identifier and TI flag value as received in the CC SETUP message.

NOTE 2: After handling the CC CONNECT ACK according to 3GPP TS 29.292 [18] and 3GPP TS 24.008 [8], the dialog created by the SIP INVITE request due to STN is associated with a CS call in the "active" (N10) state (defined in 3GPP TS 24.008 [8]), the "idle" hold auxiliary state (defined in 3GPP TS 24.083 [43]) and the "idle" multi party auxiliary state (defined in 3GPP TS 24.084 [47]) with transaction identifier and TI flag value as received in the CC SETUP message.

Upon receiving a SIP INFO request:

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

if the SIP INFO request is received after a CC CONNECT ACK message related to a CC CONNECT message sent as result of a SIP 2xx response to SIP INVITE request due to STN and if the SIP INVITE request established a session with conference focus, then the MSC server shall:

NOTE 3: If the SIP INFO request is received before the CC CONNECT ACK message, the MSC processes the contents of the SIP INFO request after reception of the CC CONNECT ACK message.

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 calculated as in the table 9.2.1A-2. The offsets 0, 2, 3, 4, 5 are assigned to the participants in their order in the list of the extracted participants; and

– with TI flag value as in mobile originated 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

NOTE 4: The transaction identifier that the MSC received in the CC SETUP message is the transaction identifier assigned to the first participant (offset 0).

NOTE 5: After handling the CC CONNECT ACK according to 3GPP TS 29.292 [18] and 3GPP TS 24.008 [8], the dialog created by the SIP INVITE request due to STN is associated with a CS call in the "active" (N10) state (defined in 3GPP TS 24.008 [8]), the "idle" hold auxiliary state (defined in 3GPP TS 24.083 [43]) and the "idle" multi party auxiliary state (defined in 3GPP TS 24.084 [47]) with transaction identifier and TI flag value as received in the CC SETUP message.

NOTE 6: The multi party auxiliary state was initially set to "idle". 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 calculated as in the table 9.2.1A-2; The offsets 0, 2, 3, 4, 5 are assigned to the participants in their order in the list of the extracted participants; and.

– with TI flag value as in mobile originated 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]) and the "call in MPTY" multi party auxiliary state (defined in 3GPP TS 24.084 [47]) for the CS calls.

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 an existing SIP dialog:

A. which was originated by the MSC server; and

B. where the g.3gpp.mid-call feature-capability indicator as described in annex C was included in the Feature-Caps header field of the SIP 2xx response to the SIP INVITE request; 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 7: 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 inactive session not using ICS capabilities in accordance with the procedures specified in 3GPP TS 24.229 [2] and IETF RFC 3515 [13]. Additionally, the MSC server shall populate the SIP INVITE request 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 hname "body" URI header field;

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

C. the SDP offer with:

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

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

e. all or subset of payload type numbers and their mapping to codecs and media parameters not conflicting with those in the hname "body" URI header field in the URI in the Refer-To header field of the received SIP REFER request; and

f. if local configuration indicates that the network is serving users supporting the precondition mechanims, indicate preconditions as met, using the segmented status type, as defined in IETF RFC 3312 [88] and IETF RFC 4032 [89], as well as the strength-tag value "mandatory" for the local segment and the strength-tag value either "optional" or as specified in RFC 3312 [88] and RFC 4032 [89] for the remote segment;

D. if local configuration indicates that the network is serving users supporting the precondition mechanism, include:

a. a "100rel" option tag as defined in IETF RFC 3262 [86] to indicate the support for reliable provisional responses; and

b. a "precondition" option tag as defined in IETF RFC 3312 [88] to indicate the support for the precondition mechanism; and

E. 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 P-Asserted-Identity header field of the SIP INVITE requests due to STN which created the dialog in which the REFER request is received.

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

1. if:

a) the SIP INVITE request for transfer of the additional inactive session 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:

associate the additional inactive session with CS call with transaction identifier calculated as in the table 9.2.1A-1 and TI flag value as in mobile originated 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 this CS call; and

2. if the SIP INVITE request for the additional inactive session established a session with 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 inactive 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 calculated as in the table 9.2.1A-2. The offsets 1, 2, 3, 4, 5 are assigned to the participants in their order in the list of the extracted participants; and

– with TI flag value as in mobile originated call;

9.6 PS to CS session continuity with MSC server assisted mid-call feature for speech and video session

This subclause describes the procedures required by an MSC server in order to support the MSC server assisted mid call feature for speech and video session.

The MSC server , upon receiving the session state information which indicates an inactive speech and video session, shall send a SIP INVITE request for the additional inactive speech and video session as described in subclause 9.5.

NOTE 1: If due to some reason (i.e. the current RAN type not supporting video, lack of resource, etc.) the video media cannot be supported in CS network for the speech and video session, then the MSC server can set the port to zero in the "m=" line for the video media in the SDP offer of the SIP INVITE request for the additional inactive session, so as to inform the SCC AS that the video media is deleted and only the audio media of the speech and video session is transferred to CS.

NOTE 2: After successful transfer of a speech and video session and a speech session from PS to CS, if messages are received from the UE to switch between the two sessions (i.e. HOLD/Release message to hold/release the active session and Retrieve message to retrieve the inactive session), the MSC server can perform the procedures as specified in 3GPP TS 29.292 [18], with the addition that the MSC server can complete the in-call modification or Redial procedures as specified in 3GPP TS 24.008 [8] to change the shared CS bearer of the two sessions from speech to multimedia, or vice versa, before sending a SIP UPDATE request or SIP re-INVITE request to the SCC AS to resume the inactive session.

9.7 MSC procedures for PS to CS dual radio access transfer of calls in an early phase

The MSC server supporting PS to CS dual radio access transfer for calls in alerting phase shall populate a SIP INVITE request due to STN as follows:

1) include the g.3gpp.drvcc-alerting media feature tag as described in annex C in the Contact header field of the SIP INVITE request according to IETF RFC 3840 [53]; and

2) if the MSC server supports the PS to CS dual radio access transfer for originating calls in pre-alerting phase, the MSC server shall include the g.3gpp.ps2cs-drvcc-orig-pre-alerting media feature tag according to annex C in the Contact header field of the SIP INVITE request according to IETF RFC 3840 [53].

Upon receiving a SIP REFER request within the SIP session established by the SIP INVITE request due to STN:

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

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

3) with the Target-Dialog URI header field in the URI of the Refer-To header field;

4) where the g.3gpp.ps2cs-drvcc-alerting feature-capability indicator or the g.3gpp.ps2cs-drvcc-originating-pre-alerting feature-capability indicator as described in annex C was included in the Feature-Caps header field of the SIP 2xx response to the SIP INVITE request due to STN; and

5) containing a MIME body of MIME type specified in the subclause D.2.4,

NOTE 2: At this point, the MSC server interacts with the MGW to provide information needed in the procedures below and to request MGW to start forwarding the audio media from the remote UE to the MSC server. The details of interaction between the MSC server and the MGC are out of scope of this document.

then 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 3: 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 early session in accordance with the procedures specified in 3GPP TS 24.229 [2] and IETF RFC 3515 [13]. The SC UE shall populate the SIP INVITE request as follows:

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

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

NOTE 4: port can be set to zero or nonzero 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.

e) if local configuration indicates that the network is serving users supporting the precondition mechanism, indicate preconditions as met, using the segmented status type, as defined in IETF RFC 3312 [88] and IETF RFC 4032 [rfc4032], as well as the strength-tag value "mandatory" for the local segment and the strength-tag value either "optional" or as specified in RFC 3312 [88] and RFC 4032 [89] for the remote segment;

C) if the MSC server supports the MSC server assisted mid-call feature, include the g.3gpp.mid-call media feature tag as described in annex C in the Contact header field according to IETF RFC 3840 [53];

D) if local configuration indicates that the network is serving users supporting SIP preconditions, include:

a) a "100rel" option tag as defined in IETF RFC 3262 [86] to indicate the support for reliable provisional responses; and

b) a "precondition" option tag as defined in IETF RFC 3312 [88] to indicate the support for the SIP precondition mechanism; and

E) 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 P-Asserted-Identity header field of the SIP INVITE requests due to STN which created the dialog in which the SIP REFER request is received.

Upon receipt of a SIP 18x response to SIP INVITE request for an additional early session, the MSC server shall:

1) associate the SIP INVITE request for an additional early session with CS call with transaction identifier calculated as in the table 9.2.1A-1 and TI flag value as in originating mobile case;

2) if the received response is a not a SIP 180 (Ringing) response enter the "mobile originating call proceeding" (N3) state as specified in 3GPP TS 24.008 [8]; and

3) if the received response is a SIP 180 (Ringing) response enter the "call delivered" (N4) state as specified in 3GPP TS 24.008 [8].

9.8 MSC server enhanced for dual radio access transfer using a SIP interface

9.8.1 General

When the MSC server enhanced for dual radio access transfer using a SIP interface receives a CC SETUP message containing the Called Party BCD number information element with the STN, the MSC server shall:

1. suppress services provided by the home network as part of the call setup procedures; and

2. not provide announcement or other in-band media for any calls that have been transferred or are in the process of being transferred.

NOTE 1: In the case of roaming the home network operator need to provide the STN as part of the bilateral operator agreement.

An MSC server enhanced for dual radio access transfer using a SIP interface shall interwork CC messages as specified in 3GPP TS 29.292 [18].

If the MSC server enhanced for dual radio access transfer using a SIP interface supports PS to CS dual radio access transfer for calls in alerting phase, the MSC server shall apply the procedures specified in subclause 9.7.

NOTE 2: An MSC server enhanced for dual radio access transfer using a SIP interface that supports PS to CS dual radio access transfer for originating calls in pre-alerting phase also supports PS to CS dual radio access transfer for calls in alerting phase.

NOTE 3: The MSC server enhanced for dual radio access transfer using a SIP interface cannot support PS to CS dual radio access transfer of calls in alerting phase on the terminating side since transfer of a waiting call requires ICS functionality. A waiting call will be transferred using CS access via MGCF when ICS functionality is not supported by the MSC server.

The MSC server enhanced for dual radio access transfer using a SIP interface supporting the MSC server assisted mid-call feature for speech sessions shall apply the procedures specified in subclause 9.5.

9.9 EATF

9.9.1 EATF procedures for PS to CS session continuity, dual radio session transfer of emergency session

The EATF needs to distinguish the following initial SIP INVITE request to provide specific functionality for dual radio session transfer of IMS emergency session:

1. SIP INVITE request routed to the EATF due to E-STN-DRVCC in the Request-URI. In the procedures below, such requests are known as "SIP INVITE requests due to E-STN-DRVCC".

Other initial SIP requests can be dealt with in any manner conformant with 3GPP TS 24.229 [2].

When the EATF receives a SIP INVITE request due to E-STN-DRVCC on the Target Access Leg, the EATF shall:

1. associate the SIP INVITE request due to E-DRVCC-SR with a source access leg, i.e. an emergency session with active speech media component anchored at the EATF.

NOTE 1: The EATF has generated the E-STN-DRVCC when the related emergency SIP INVITE requrest was received and has delivered the E-STN-DRVCC to the UE in the SIP 200 (OK) response to the UE.

If no source access leg exists, i.e. no dialog supporting a session with active speech media component exists or if multiple source access legs exist, then the EATF shall send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request due to E-STN-DRVCC; and

2. originate session modification as described in 3GPP TS 24.229 [2] towards the remote side with a new SDP offer with media characteristics as received in the SIP INVITE request due to E-STN-DRVCC.

Upon reception of the SIP ACK request to the SIP 200 (OK) response to the SIP INVITE request due to E-STN-DRVCC from the target access leg, the EATF shall release the source legs as follows:

1) if the source access leg is an ongoing session containing only an active media component, send a SIP BYE request on the source access leg in accordance with 3GPP TS 24.229 [2]; or

2) if the source access leg contains media components other than speech media component, send a SIP re-INVITE request to update the source access leg in accordance with 3GPP TS 24.229 [2].

NOTE 2: Delaying the release of the source access leg as described above allows an SC UE to reuse the PS dialog in case of PS to CS DRVCC cancellation.