A.17.7 Session transfer for originating 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.7-1, SC UE A has invited for an originating session with a CAT media component which is anchored at ATGW. 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 SRVCC handover to CS access.
Figure A.17.7-1: PS-CS SRVCC, outgoing call in alerting phase with CAT media anchored at ATGW
NOTE 1: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow.
1. SC UE A has setup an outgoing call
The outgoing call with the CAT media has been anchored at the ATGW. Both ends have reserved the resources and SC UE A has received a SIP 180 (Ringing) response.
2. SC UE A attaches to the CS domain
UE A sends the measurement reports to E-UTRAN, and the source E-UTRAN decides to trigger an SRVCC handover to CS access.
3. SIP INVITE request (MSC server to ATCF)-see example in table A.17.7-3
Table A.17.7-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.7-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.7-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 reqeust (MSC Server to SCC AS)
9-10. SIP 200 (OK) response (SCC AS to MSC Server)
11. The CAT media is transferred to the CS access, and kept playing to the originating user.
9. SIP 183 (Session Progress) response (SCC AS to ATCF)
10. SIP PRACK request (ATCF to SCC AS)
11. SIP 200 (OK) response (SCC AS to ATCF)
12-13. SIP INFO request (SCC AS to MSC Server) – see example in table A.17.7-12
Table A.17.7-12: 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>initiator</direction>
</state-and-event-info>
14-15. SIP 200 (OK) response (MSC server to SCC AS)
The MSC Server acknowledges the receipt of the SIP INFO request.
16. MSC goes in Call delivered state
The MSC enters Call delivered state due to the information received in the SIP INFO request.
17. The User B answers the call
18. SIP 200 (OK) response (UE B to CAT AS B)
The UE B accepts the call and sends a SIP 200 (OK) response.
19. The CAT AS stops the CAT media upon receving the SIP 200 (OK) response.
20-22. SIP 200 (OK) response (CAT AS to MSC Server)
The SIP 200 (OK) response is forwarded to MSC Server.
23. CC CONNECT message (MSC server to SC UE A)
The MSC server indicates to the SC UA A that the far end has accepted the call.
24-27. SIP ACK request (MSC server to UE B)
The MSC server acknowledges the SIP 200 (OK) response.
28. CC CONNECTACKNOWLEDGE (SC UE A to MSC server)
SC UE A acknowledges the CS CONNECT message.
29–32. The SCC AS releases the original source leg towards the SC UE A
The SCC AS sends a SIP 404 (Not Found) response in order to release to original source dialog towards the SC UE A
NOTE: Steps 29-32 are performed only if the SC UE A uses Gm the PS-CS access transfer in alerting phase is completed; otherwise, the SC UE A and the network release the source access leg locally, without any signalling between the SC UE A and the network.