A.17.5 User answers in PS domain; Handover to CS not successful

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

In the example flow in figure A.17.5-1, SC UE A has an incoming session with speech media component which is anchored at SCC AS. The session is in alerting phase. Based upon measurement reports sent from the UE to E-UTRAN, the source E-UTRAN decides to trigger a PS to CS SRVCC handover to CS access. However the user answers the call in E-UTRAN and the SC UE sends a SIP 200 (OK) response to the SCC AS. In this scenario the handover to CS is not successful because the source E-UTRAN decides to terminate the handover procedure before its completion. In a similar scenario, the UE can also encounter a failure after it receives the handover command but does not successfully transition to 3GPP UTRAN/GERAN.

Figure A.17.5-1: SIP 200 (OK) response from SC UE received by SCC AS: Handover cancelled

NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow.

1 SC UE A has received an incoming call and is in Ringing State

The incoming call has been anchored at the SCC AS of SC UE A. Both ends have reserved the resources and SC UE A has sent a SIP 180 (Ringing) response.

2-18 Continuation of procedure for PS to CS SRVCC in Alerting Phase

These steps are identical to steps 3-19 in subclause A.17.2.

19 User answers the call when the UE is still in the source E-UTRAN access

20-21 SIP 200 (OK) response (SC UE to intermediate IM CN subsystem entities to SCC AS)

The SCC AS performs no additional actions on receipt of the SIP 200 (OK) response i.e. the SCC AS does not confirm reception of the SIP 200 (OK) response with SIP ACK request and performs no actions on dialogs with UE B and with MSC server.

9-21 Continuation of procedure for PS to CS SRVCC in Alerting Phase

These steps are identical to steps 7-19 in subclause A.17.2.

22 SC UE A receives PS to CS SRVCC Handover Cancelled command from source E-UTRAN

23-26 SIP UPDATE request (SC UE to intermediate IM CN subsystem entities to SCC AS to UE B)

SC UE A sends a SIP UPDATE request with a SDP offer, including the media characteristics as used in the existing dialog and with a Reason header field containing protocol "SIP" and reason parameter "cause" with value "487" as specified in IETF RFC 3326 [57] and with reason-text set to "handover cancelled".

NOTE 2: In the case that the handover command was received but the UE did not transition to the CS domain, the UE sends the SIP UPDATE request as described above, but with reason-text set to "failure to transition to CS domain".

27-30 SIP 200 (OK) response to the SIP UPDATE request (UE B to SCC AS to intermediate IM CN subsystem entities to SC UE A)

31-32 SIP 480 (Temporary Unavailable) response (SCC AS to intermediate IM CN subsystem entities to MSC server)

The SCC AS responds to the MSC server with a SIP 480 (Temporary Unavailable) response which indicates that it is unable to go ahead with the session transfer.

33-36 Continuation of procedure for PS to CS SRVCC in Alerting Phase

These steps are identical to steps 25-28 in subclause A.17.2. The SCC AS sends SIP 200 (OK) response to UE B as final confirmation to the original session and UE B sends SIP ACK request back to the SCC AS.

37-38 SIP ACK request (SCC AS to intermediate IM CN subsystem entities to SC UE)

The SCC AS confirms reception of the SIP 200 (OK) response received in message 21.