12.5 EATF
24.2373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) service continuityRelease 17Stage 3TS
12.5.1 EATF procedures for PS to CS session continuity, E-SR-VCC
The EATF needs to distinguish between the following initial SIP INVITE requests to provide specific functionality for E-SR-VCC:
1. SIP INVITE request routed to the EATF due to E-STN-SR in the Request-URI. In the procedures below, such requests are known as "SIP INVITE requests due to E-STN-SR".
NOTE 1: The same E-STN-SR is used for all the emergency session access transfers within one PLMN.
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-SR on the Target Access Leg, the EATF shall:
1) identify the transferable set which are dialogs supporting a session with speech media component anchored at the EATF with the sip.instance media feature tag provided by the SC UE in the Contact header field at session establishment equal to the sip.instance media feature tag included in the Contact header field of the received SIP INVITE request due to E-STN-SR; and
NOTE 2: When the sip.instance media feature tag contains an IMEI URN as specified in IETF RFC 7254 [82], the spare digit (i.e. the digit matching the spare ABNF rule) is required to be set to zero. If the spare digit is set to non zero value, the spare digit can be ignored.
2) if a confirmed dialog supporting a sessions with active speech media component exists in the transferable set:
A) associate the SIP INVITE request due to E-STN-SR with the confirmed dialog supporting a session with active speech media component; and
B) originate session modification as described in 3GPP TS 24.229 [2] towards the remote UE by sending a SIP re-INVITE request with a new SDP offer with media characteristics as received in the SIP INVITE request due to E-STN-SR. If the SIP INVITE request due to E-STN-SR does not contain a Recv-Info header field, the EATF shall include an empty Recv-Info header field in the SIP re-INVITE request as defined in IETF RFC 6086 [54]. If the SIP INVITE request due to E-STN-SR contains a Recv-Info header field, the EATF shall remove the info package names of info packages that terminate at the EATF, if any, and include the remaining info package names in a Recv-Info header field in the SIP re-INVITE request.
12.5.2 EATF procedures for PS to CS SRVCC, abnormal case
12.5.2.1 PS to CS SRVCC cancelled by MME/SGSN or release of the target access leg for ongoing emergency session
If the EATF receives a SIP BYE request containing a Reason header field containing the protocol value "Q.850" and the "cause" header field parameter with the value of "31" (normal unspecified) on the target access leg after having initiated an access transfer that was triggered by a SIP INVITE request due to E-STN-SR and when the operator specific timer is still running, the EATF shall:
1) send the SIP 200 (OK) response to the SIP BYE request;
2) wait until the operator specific timer expires or until a SIP re-INVITE request from the SC UE containing the protocol value "SIP" and the "cause" header field parameter with the value "487" is received; and
3) if the operator specific timer expires and no SIP re-INVITE request from the SC UE containing the protocol value "SIP" and the "cause" header field parameter with the value "487" is received, release the call according to procedures in 3GPP TS 24.229 [2].
NOTE 1: All protocol values in the Reason header field other than "Q.850" and all values of the "cause" header field parameter other than "31" (normal unspecified) will result in an immediate release of the source access leg and the remote UE leg.
NOTE 2: The EATF assigns an operator specific timer to delay the release of the source access leg for PS to CS SRVCC access transfers.
When the EATF receives SIP re-INVITE request(s) from the SC UE containing the Reason header field with the protocol value "SIP" and the "cause" header field parameter with the value "487" after having performed an access transfer that was triggered by a SIP INVITE request due to E-STN-SR and after receiving a SIP BYE request containing the Reason header field containing the protocol value "Q.850" and the "cause" header field parameter with the value "31" (normal unspecified) on the target access leg, then the EATF shall:
1) not release the original source access leg on expiry of the timer described in subclause 12.5.1; and
2) send the SIP re-INVITE request towards the remote leg by following the rules of 3GPP TS 24.229 [2].
When the EATF receives a SIP response to the SIP re-INVITE request, the EATF shall forward the SIP response to the SC UE.
12.5.2.2 PS to CS SRVCC cancelled by MME/SGSN or failure by UE to transition to CS domain for ongoing session
When the EATF receives a SIP re-INVITE request containing the Reason header field with the protocol value "SIP" and the "cause" header field parameter with the value "487" on the original source access leg after having initiated an access transfer that was triggered by a SIP INVITE request due to E-STN-SR and the SIP INVITE request due to E-STN-SR transaction is not yet completed then the EATF shall wait until this transaction has completed and then continue with the steps 1) to 3) described below.
When the EATF receives a SIP re-INVITE request containing the Reason header field with the protocol value "SIP" and header field parameter "cause" with the value "487" on the original source access leg after having performed an access transfer that was triggered by a SIP INVITE request due to E-STN-SR, then the EATF shall:
1) send a SIP BYE request on the target access leg, by following the rules of 3GPP TS 24.229 [2];
2) not release the original access leg on the expiration of the timer described in subclause 12.5.1; and
3) send the SIP re-INVITE request towards the remote leg by following the rules of 3GPP TS 24.229 [2].
NOTE: The EATF assigns an operator specific timer to delay the release of the source access leg for PS to CS SRVCC access transfer.
When the EATF receives a SIP response to the SIP re-INVITE request, the EATF shall forward the SIP response to the SC UE.
12.5.2.3 P-CSCF releasing the source access leg during PS to CS SRVCC
When EATF receives a SIP BYE request on the source access leg with any Reason header field containing protocol "SIP" and reason parameter "cause" with value "503" then:
NOTE 1: The SIP BYE request can contain more than one Reason header field.
– if the EATF receives an initial SIP INVITE request due to E-STN-SR on the target access leg associated with the established dialog on the source access leg, within a time defined by the operator policy after the SIP BYE request reception, then the EATF shall not initiate release of the remote leg; and
– if the EATF does not receive an initial SIP INVITE request due to E-STN-SR on the target access leg associated with the established dialog on the source access leg, within a time defined by the operator policy after the SIP BYE request reception then the EATF shall initiate release of the remote leg.
NOTE 2: 8 seconds is an appropriate value for the operator policy.
12.5.2.3 PS to CS SRVCC cancelled by MME/SGSN or failure by UE to transition to CS domain for session in early dialog state
If the EATF applies the procedures for the PS to CS access transfer for originating call in alerting phase or pre-alerting phase using PS to CS SRVCC procedure (as specified in subclause 12.5.3.2), then when the EATF receives a SIP UPDATE request containing a Reason header field containing protocol "SIP" and reason parameter "cause" with value "487" on the original source access leg after having initiated an access transfer that was triggered by a SIP INVITE request due to E-STN-SR for an emergency session which is still in early dialog state, the EATF shall:
1) stop the operator specific timer and not release the original access leg as described in subclause 12.5.4; and
2) forward the SIP UPDATE request on the remote leg according to 3GPP TS 24.229 [2].
The EATF shall now start forwarding SIP messages from the remote UE to the SC UE on each dialog created by the SIP INVITE on the original source access leg as specified in 3GPP TS 24.229 [2] and the present document.
When the EATF receives a SIP 200 (OK) response to the SIP UPDATE request, then the EATF shall:
1) if the EATF has already sent a SIP 200 (OK) response to a SIP INVITE request due to E-STN-SR then send a SIP BYE request on this dialog, and send a SIP 200 (OK) response to the SIP INVITE on the original source access leg; and
2) if the EATF has not sent a SIP 200 (OK) response to a SIP INVITE request due to E-STN-SR then send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request due to E-STN-SR.
12.5.3 EATF procedures for PS to CS access transfer when emergency session is in alerting phase or pre-alerting phase
12.5.3.1 General
The EATF shall apply the procedures as described in subclause 12.5.3.2 if:
1) the Contact header field of the SIP INVITE request routed to the EATF due to a E-STN-SR includes the g.3gpp.srvcc-alerting media feature tag as specified in annex C; and
2) there are one or more dialogs supporting sessions with speech media component existing in the transferable set, such that:
A) all dialogs are early dialogs;
B) SIP 180 (Ringing) response to SIP INVITE request was received in at least one of those early dialogs, all such SIP 180 (Ringing) responses are responses to the same SIP INVITE request and at least one of such SIP 180 (Ringing) responses was received in an early dialog supporting session with active speech media component;
C) the Contact header field provided by the SC UE includes the g.3gpp.srvcc-alerting media feature tag as described in annex C;
E) the following is true:
– the Contact header field provided by the SC UE does not include the g.3gpp.mid-call media feature tag; or
– the Contact header field provided by the SC UE includes both the g.3gpp.mid-call media feature tag and the g.3gpp.ps2cs-srvcc-mid-call-emergency media feature tag; and
F) the Feature-Caps header field provided by the EATF towards the SC UE includes the g.3gpp.srvcc-alerting feature-capability indicator as described in annex C.
Additionally, the EATF shall apply the procedures as described in subclauses 12.5.3.2 if:
1) the Contact header field of the SIP INVITE request due to a E-STN-SR includes the g.3gpp.ps2cs-srvcc-orig-pre-alerting media feature tag as described in annex C; and
2) there are zero, one or more dialogs supporting a session with speech media component in the transferable set and a SIP INVITE request was received from SC UE with the sip.instance media feature tag in the Contact header field to the sip.instance media feature tag included in the Contact header field of the received SIP INVITE request due to E-STN-SR, 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 sent yet;
C) a SIP 180 (Ringing) response to the SIP INVITE request has not been sent yet in any existing early dialog created by a SIP response to the SIP INVITE request;
D) the SIP INVITE request included a Contact header field containing the g.3gpp.ps2cs-srvcc-orig-pre-alerting media feature tag as described in annex C;
E) the following is true:
– the Contact header field provided by the SC UE does not include the g.3gpp.mid-call media feature tag; or
– the Contact header field provided by the SC UE includes both the g.3gpp.mid-call media feature tag and the g.3gpp.ps2cs-srvcc-mid-call-emergency media feature tag; and
F) a SIP 1xx response to the SIP INVITE request was sent where the SIP 1xx response contained a Feature-Caps header field with the g.3gpp.ps2cs-srvcc-orig-pre-alerting feature-capability indicator as described in annex C.
NOTE: EATF can have zero dialogs if all the early dialogs were terminated by 199 (Early Dialog Terminated) as described in RFC 6228 [80].
12.5.3.2 EATF procedures for PS to CS access transfer for originating call in alerting phase or pre-alerting phase using PS to CS SRVCC procedure
When the session in the transferable session set is an originating call not accepted yet the EATF shall associate the SIP INVITE request due to E-STN-SR with an early dialog or early dialogs related to the originating call.
If the EATF receives a SIP 18x response on the remote leg after receiving a SIP INVITE request due to E-STN-SR, and this SIP 18x response does not require use of reliable provisional responses, the EATF shall:
1) store this SIP 18x response; and
2) if a P-Early-Media header field is received in the SIP 18x response, store the P-Early-Media header field.
The EATF shall store the received SIP 18x responses separately for each early dialog. If the EATF has already stored a SIP 18x response for an early dialog and receives another SIP 18x response for the same early dialog, the EATF may remove the stored SIP 18x response for that early dialog and shall store the new SIP 18x response for that early dialog.
The EATF shall store the received P-Early-Media header field separately for each early dialog. If the EATF has already stored a P-Early-Media header field received in a SIP 18x response for an early dialog, and receives another SIP 18x response for the same early dialog containing a P-Early-Media header field, the EATF may remove the stored P-Early-Media header field for that early dialog and shall store the new P-Early-Media header field for that early dialog,
NOTE: The P-Early-Media header field is stored separately to prepare for the case that a subsequent SIP 18x response does not contain a P-Early-Media header field.
If there is only one early dialog related to the originating call not accepted yet available for the served user, the remote UE has provided an Allow header field listing the SIP UPDATE method or has not provided Allow header field, the remote UE has provided the SDP answer, the EATF shall update the remote leg by sending a SIP UPDATE request towards the remote UE using the existing early dialog as specified in 3GPP TS 24.229 [2]. The EATF shall populate the SIP UPDATE request with the SDP offer received in the SIP INVITE request due to E-STN-SR.
Upon receiving the SIP 200 (OK) response to the SIP UPDATE request from the remote UE, the EATF shall send a SIP 183 (Session Progress) response in response to the SIP INVITE request due to E-STN-SR towards the MSC server. The EATF shall populate the SIP 183 (Session Progress) response to the SIP INVITE request due to E-STN-SR with:
1) the SDP answer received in the SIP 200 (OK) response to the SIP UPDATE request; and
2) if the SIP INVITE request due to E-STN-SR contains a P-Early-Media header field with the "supported" parameter and if the EATF has received a P-Early-Media header field in a SIP message in the dialog of the SIP UPDATE 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 UPDATE request.
If there are more than one early dialog related to the originating call not accepted yet available for the served user due to forking as described in 3GPP TS 24.229 [2], the remote UE has provided an Allow header field listing SIP UPDATE method or has not provided Allow header field, and the remote UE provided SDP answer, the EATF shall update the remote leg(s) by sending SIP UPDATE request(s) simultaneously towards remote UE(s) using such early dialog(s) as specified in 3GPP TS 24.229 [2]. The EATF shall populate each SIP UPDATE request with the SDP offer received in the SIP INVITE request due to E-STN-SR. Upon receiving each SIP 200 (OK) response to the SIP UPDATE request from the remote UE, the EATF shall create a new early dialog by sending a SIP 183 (Session Progress) response in response to the SIP INVITE request due to E-STN-SR towards the MSC server. The EATF shall populate the SIP 183 (Session Progress) response to the SIP INVITE request due to E-STN-SR with:
1) the SDP answer received in the SIP 200 (OK) response to the SIP UPDATE request; and
2) If the SIP INVITE request due to E-STN-SR contains a P-Early-Media header field with the "supported" parameter and if the EATF has received a P-Early-Media header field in a SIP message in the dialog of the SIP UPDATE 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 UPDATE request.
If one or more early dialogs related to the originating call not accepted yet are available for the served user, and in each such early dialog:
1) the remote UE of the early dialog has provided an Allow header field not listing the SIP UPDATE method; or
2) SIP 405 (Method Not Allowed) response was received to the SIP UPDATE sent towards the remote UE in the early dialog;
the EATF shall create a new dialog by sending a SIP 183 (Session Progress) response to the SIP INVITE request due to E-STN-SR. The EATF shall populate the SIP 183 (Session Progress) response with an SDP answer:
1) with c-line set to the unspecified address (0.0.0.0) if IPv4 or to a domain name within the ".invalid" DNS top-level domain in case of IPv6 as described in IETF RFC 6157 [74]; and
2) including media of media types received in SDP offer of the SIP INVITE request due to E-STN-SR, which are also offered in the SIP INVITE request from the served user.
If the EATF supports the PS to CS SRVCC for originating emergency sessions in pre-alerting phase and if there are no early dialogs related to the originating call not accepted yet available for the served user and there is a SIP INVITE request from the served user for which a final SIP response has not been received yet, the EATF shall send a SIP 183 (Session Progress) response to the SIP INVITE request due to E-STN-SR. The EATF shall populate the SIP 183 (Session Progress) response with an SDP answer:
1) with c-line set to the unspecified address (0.0.0.0) if IPv4 or to a domain name within the ".invalid" DNS top-level domain in case of IPv6 as described in IETF RFC 6157 [74]; and
2) including media of media types received in SDP offer of the SIP INVITE request due to E-STN-SR, which are also offered in the SIP INVITE request from the served user.
Upon receiving the first SIP PRACK request from the target access leg, the EATF shall send a 200 (OK) to the PRACK response and then 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 E-STN-SR. The EATF shall populate the SIP INFO request 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 application/vnd.3gpp.state-and-event-info+xml XML body associated with the info package according to IETF RFC 6086 [54] and containing an XML body compliant to the XML schema specified in clause D.2:
A) if a SIP 180 (Ringing) response to the SIP INVITE request has already been forwarded to the served SC UE before receiving the INVITE due to E-STN-SR, with the state-info XML element containing "early" the direction XML element containing "initiator"; and
B) if the EATF supports the PS to CS SRVCC for originating emergency sessions in pre-alerting phase and if a SIP 180 (Ringing) response to the SIP INVITE request has not beenforwarded to the served SC UE before receiving the INVITE due to E-STN-SR, with the state-info XML element containing "pre-alerting" and the direction XML element containing "initiator".
Upon receiving the 200 (OK) response to the SIP INFO request the EATF shall:
1) start forwarding SIP messages from the remote UE to the MSC server as specified in 3GPP TS 24.229 [2] and the present specification for dialogs where a PRACK request is received from the MSC server; and
2) if SIP 18x responses were stored after receiving the SIP INVITE request due to E-STN-SR, then for each early dialog where a PRACK request is received from the MSC server:
A) forward all stored SIP 18x responses to the MSC server; and
B) if a P-Early-Media header field is stored, include the P-Early-Media header field that was stored most recently in the SIP 18x response.
If a reliable SIP 1xx response or a SIP 2xx response is received on the remote leg, the SIP response is to the SIP INVITE request from the served user, the SIP response contains an SDP answer, and an SDP answer has not been received from the remote UE on the dialog of the SIP response yet, the EATF shall:
1) if the SIP 1xx response is received, send a SIP PRACK request on the remote leg as specified in 3GPP TS 24.229 [2]. The EATF shall populate the SIP PRACK request with the SDP offer received in the SIP INVITE request due to E-STN-SR as specified in 3GPP TS 24.229 [2]. Upon receiving the SIP 200 (OK) response to the SIP PRACK request, the EATF shall send a SIP 183 (Session Progress) response to the SIP INVITE request due to E-STN-SR as specified in 3GPP TS 24.229 [2]. The EATF shall populate the SIP 183 (Session Progress) response with:
A) the SDP answer received in the SIP 200 (OK) response to the SIP PRACK request as specified in 3GPP TS 24.229 [2]; and
B) if the SIP INVITE request due to E-STN-SR contains a P-Early-Media header field with the "supported" parameter and if the EATF has received a P-Early-Media header field in a SIP message in the dialog of the SIP PRACK request, 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
2) if the SIP 2xx response is received, send a SIP ACK request on the remote leg as specified in 3GPP TS 24.229 [2] and send a SIP UPDATE request or SIP re-INVITE request on the remote leg as specified in 3GPP TS 24.229 [2]. The EATF shall populate the SIP UPDATE request or SIP re-INVITE request with the SDP offer received in the SIP INVITE request due to E-STN-SR as specified in 3GPP TS 24.229 [2]. Upon receiving the SIP 200 (OK) response to the SIP UPDATE request or SIP re-INVITE request, the EATF shall send a SIP 200 (OK) response to the SIP INVITE request due to E-STN-SR as specified in 3GPP TS 24.229 [2]. The EATF shall populate the SIP 200 (OK) response with the SDP answer received in the SIP 200 (OK) response to the SIP UPDATE request or SIP re-INVITE request as specified in 3GPP TS 24.229 [2].
If a SIP 2xx response is received on the remote leg, the SIP response is to the SIP INVITE request from the served user, and an SDP answer has already been received from the remote UE on the dialog of the SIP response:
1) if the SDP offer received in the SIP INVITE request due to E-STN-SR has already been sent to the remote UE on the dialog of the SIP 2xx response, accepted with a subsequent SDP answer, the subsequent SDP answer was sent in a 183 (Session Progress) response on a target access leg, and the SIP 2xx response does not contain an SDP answer, then forward the SIP 2xx response on the target access leg as a SIP response to the SIP INVITE request due to E-STN-SR;
2) if the SDP offer received in the SIP INVITE request due to E-STN-SR has already been sent to the remote UE on the dialog of the SIP 2xx response, accepted with a subsequent SDP answer, the subsequent SDP answer was sent in a 183 (Session Progress) response on a target access leg, and the SIP 2xx response contains an SDP answer, then remove the SDP body from the SIP 2xx response or replace the SDP body in the SIP 2xx response with the subsequent SDP answer, and forward the SIP 2xx response as specified in 3GPP TS 24.229 [2] on the target access leg as a SIP response to the SIP INVITE request due to E-STN-SR; and
3) if:
A) the SDP offer received in the SIP INVITE request due to E-STN-SR has not been sent to the remote UE on the dialog of the SIP response yet; or
B) the SDP offer received in the SIP INVITE request due to E-STN-SR has already been sent to the remote UE in a SIP UPDATE request within the dialog of the SIP response and the SIP UPDATE request was rejected with SIP 405 (Method Not Allowed) response;
send a SIP ACK request on the remote leg as specified in 3GPP TS 24.229 [2] and send a SIP re-INVITE request on the remote leg as specified in 3GPP TS 24.229 [2]. The EATF shall populate the SIP re-INVITE request with the SDP offer received in the SIP INVITE request due to E-STN-SR as specified in 3GPP TS 24.229 [2]. Upon receiving the SIP 200 (OK) response to the SIP re-INVITE request, the EATF shall send a SIP ACK request on the remote leg as specified in 3GPP TS 24.229 [2] and shall send a SIP 200 (OK) response to the SIP INVITE request due to E-STN-SR as specified in 3GPP TS 24.229 [2] using a dialog different to the dialog of SIP 183 (Session Progress) response to the SIP INVITE request due to E-STN-SR. The EATF shall populate the SIP 200 (OK) response with the SDP answer received in the SIP 200 (OK) response to the SIP re-INVITE request as specified in 3GPP TS 24.229 [2].
The EATF shall remove non-transferred audio and video media components and superfluous sessions as specified in subclause 12.5.4.
12.5.4 Removal of non-transferred audio media components and superfluous sessions
If no dialog was associated with the SIP INVITE request due to E-STN-SR, the EATF shall send a SIP 480 (Temporarily Unavailable) response to reject the SIP INVITE request due to E-STN-SR.
Upon receiving the SIP ACK request from the Target Access Leg, and after an operator specific timer has expired, the EATF:
1) shall release the source access leg of the session associated with the SIP INVITE request due to E-STN-SR, as described in 3GPP TS 24.229 [2]; and
NOTE 1: If non-speech media was part of the original emergency session, the non-speech media will be released.
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 SRVCC cancellation.
2) for each session in the transferable set which was not transferred, shall release remote leg and source access leg.