A.17.8 Session transfer for terminating call is in alerting phase using SRVCC procedure with ATCF: PS to CS

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

In the example flow at the figure A.17.8-1, SC UE B has an incoming session with speech media component which is anchored at ATCF. The session is in alerting phase, and the CAT media is played to the originating UE A. 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.

Figure  A.17.8-1: PS-CS SRVCC, incoming call in alerting phase with CAT media

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

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

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

2. SC UE B attaches to the CS domain

UE B sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an PS to CS SRVCC handover to CS access. The MSC server initiates the session transfer with the STN-SR, refer to 3GPP TS 23.237 [9]. The UE continues ringing.

3. SIP INVITE request (MSC server to ATCF)-see example in table A.17.8-3

Table A.17.8-3: SIP INVITE request (MSC server to ATCF)

INVITE tel:+1-237-555-3333 SIP/2.0

Via: SIP/2.0/UDP msc1.visit1.net;branch=z9hG4bk731b87

Max-Forwards: 70

P-Asserted-Identity: <tel:+1-237-555-2222>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024";orig-ioi=visit1.net

Privacy: none

P-Early-Media: supported

From: <tel:+1-237-555-1111>;tag=171828

To: <tel:+1-237-555-3333>

Call-ID: cb03a0s09a2sdfglkj490334

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu, norefersub

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

Contact: <sip: msc1.visit1.net:1357>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"; +g.3gpp.srvcc-alerting

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:eee

s=

c=IN IP6 5555::aaa:bbb:ccc:eee

t=0 0

m=audio 3456 RTP/AVP 97 96

a=tcap:1 RTP/AVPF

a=pcfg:1 t=1

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=rtpmap:96 telephone-event

a=maxptime:20

Request-URI: contains the STN-SR, as routed to the ATCF.

SDP: The SDP contains preconfigured set of codecs supported by the MGW.

P-Asserted-Identity: the C-MSISDN of the served UE.

Contact: contains the +g.3gpp.srvcc-alerting feature tag.

4. SIP INVITE request (ATCF to SCC AS)-see example in table A.17.8-4

After receiving the access transfer message, the ATCF establishes a new dialog with the SCC AS by sending a new SIP INVITE request to the SCC AS using the stored ATU-STI for PS to CS SRVCC. The ATCF updates the SCC AS via the new dialog indicating that the transfer has taken place. As there is no update in the SDP information, no remote end update will be performed.

Table A.17.8-4: SIP INVITE request (ATCF to SCC AS)

INVITE sip:AUT-STI1@sccas.home1.net SIP/2.0

Via: SIP/2.0/UDP actf.visited2.net:5060;branch=z9hG4bk731b87

Max-Forwards: 70

P-Asserted-Identity: <tel:+1-237-555-2222>

P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024";orig-ioi=visit1.net

Privacy: none

P-Early-Media: supported

From: <tel:+1-237-555-3333>;tag=1888828

To: <tel:+1-237-555-4444>

Call-ID: cb03a0s09a2sdfglkj490444

Cseq: 127 INVITE

Supported: 100rel, precondition, gruu, norefersub

Require: tdialog,

Record-Route:<sip: actf.visited2.net:5060;lr>

Target-Dialog: me03a0s09a2sdfgjkl491777; remote-tag=774321; local-tag=64727891

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

P-Asserted-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel

Contact: <sip: msc1.visit1.net:1357>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:ggg

s=

c=IN IP6 5555::aaa:bbb:ccc:ggg

t=0 0

m=audio 3456 RTP/AVP 97 96

a=tcap:1 RTP/AVPF

a=pcfg:1 t=1

b=AS:25.4

a=curr:qos local sendrecv

a=curr:qos remote none

a=des:qos mandatory local sendrecv

a=des:qos none remote sendrecv

a=rtpmap:97 AMR

a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2

a=rtpmap:96 telephone-event

a=maxptime:20

Request-URI: contains the ATU-STI for PS to CS SRVCC, that resolves (e.g. via DNS access) to the IP address of the I-CSCF.

Target-Dialog: specifies that the existing dialog is related with this request.

Record-Route: contains the SIP URI of the ATCF, where the ATCF expect to receive the in-dialog request from the SCC AS.

Require: the "tdialog" option tag indicate that the support for Target-Dialog header field is required.

P-Asserted-Identity: the C-MSISDN of the served UE.

SDP: the media information at ATGW.

5-6. SIP 183 (Session Progress) response (SCC AS to MSC server)

The session achored is in alerting phase, the SCC AS sends the SIP 183Session Progress response to the MSC server.

7-8. SIP PRACK request (MSC Server to SCC AS)

9-10. SIP 200 (OK) response (ATCF to MSC Server)

11-12. SIP INFO request (SCC AS to MSC Server) – see example in table A.17.8-11

Table A.17.8-11: INFO request (SCC AS to MSC Server)

INFO sip:msc1.visit1.net:1357 SIP/2.0

Via SIP/2.0/UDP sip:sccas1.home1.net;branch=z9hG4bK332b23.1

Max-Forwards: 68

Route: <sip:scscf1.home1.net;lr>

From: <tel:+1-237-555-3333>;tag=314159

To: <tel:+1-237-555-1111>;tag=171828

Call-ID: cb03a0s09a2sdfglkj490334

Cseq: 129 INFO

Info-Package: g.3gpp.state-and-event-info

Content-Type: application/vnd.3gpp.state-and-event-info+xml

Content-Length:

<?xml version="1.0" encoding="UTF-8"?>

<state-and-event-info>

<state-info>early</state-info>

<direction>receiver</direction>

</state-and-event-info>

13-14. SIP 200 (OK) response (MSC server to ATCF)

The MSC server acknowledges the receipt of the SIP INFO request.

15. MSC goes in Call received state

The MSC enters Call received state due to the information received in the SIP INFO request.

16. The User B answers the call

17. CC CONNECT message from SC UE B to MSC server

The SC UE B accepts the call and sends CC CONNECT message.

18. CC CONNECT ACKNOWLEDGE message (MSC server to SC UE B)

19-20. SIP INFO request (MSC server to SCC AS) – see example in table A.17.8-19

Table A.17.8-19: INFO request (MSC server to SCC AS)

INFO sip:sccas1.home1.net;gr SIP/2.0

Via: SIP/2.0/UDP msc1.visit1.net;branch=z9hG4bk731b87

Max-Forwards: 68

Route: <sip:scscf1.home1.net;lr>

From: <tel:+1-237-555-1111>;tag=171828

To: <tel:+1-237-555-3333>;tag=171828

Call-ID: cb03a0s09a2sdfglkj490334

Cseq: 130 INFO

Info-Package: g.3gpp.state-and-event-info

Content-Type: application/vnd.3gpp.state-and-event-info+xml

Content-Length:

<?xml version="1.0" encoding="UTF-8"?>

<state-and-event-info>

<event>call-accepted</event>

</state-and-event-info>

21-22. SIP 200 (OK) response (SCC AS to MSC Server)

The SCC AS acknowledges the receipt of the SIP INFO request indicating that the SC UE B has accepted the call.

23. SIP 200 (OK) response (SCC AS to CAT AS)

The SIP 200 (OK) response is forwarded to the CAT AS by SCC AS.

24. The CAT AS stops the CAT media upon receving the SIP 200 (OK) response.

25. SIP 200 (OK) response (CAT AS to UE A)

The SIP 200 (OK) response is forwarded to UE A.

26-27 SIP ACK request (far end UE A to SCC AS)

The far end UE acknowledges the SIP 200 (OK) response received from SCC AS

28-29 SIP 200 (OK) response (SCC AS to MSC Server)

The SCC AS sends a SIP 200 (OK) response to indicate the successful access transfer to the MSC server.

30-31. SIP ACK request (MSC server to SCC AS)

MSC server acknowledges the SIP 200 (OK) response received from SCC AS.

32-39. SIP CANCEL Processing

The SCC AS cancels the SIP dialog towards the SC UE

NOTE: Steps 32-39 are performed only if the SC UE B uses Gm after the PS-CS access transfer in alerting phase is completed; otherwise, the SC UE B and the network release the source access leg locally, without any signalling between the SC UE B and the network.