A.17.3 Session transfer for originating call is in alerting phase using PS to CS SRVCC procedure: 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.3-1, SC UE A has invited for an originating 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.
Figure A.17.3-1: PS-CS SRVCC, originating call in alerting phase
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 has been anchored at the SCC AS of SC UE A. Both ends have reserved the resources and SC UE A has received a SIP 180 (Ringing) response.
1a. The ringing tone is played to the originating user
The ringing tone is played by the originating UE as the locally generated ringing tone.
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 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 ringing tone is kept playing to the originating user.
3. SIP INVITE request transferring the session (MSC server to intermediate IM CN subsystem entities) – see example in table A.17.3-1
The MSC server sends an initial SIP INVITE request with STN-SR.
Table A.17.3-1: SIP INVITE request (MSC server to intermediate IM CN subsystem entities)
INVITE tel: +1-237-555-3333 SIP/2.0
Via: SIP/2.0/UDP msc1.visit1.net;branch=z9hG4bk731b87
Max-Forwards: 70
Route: <sip:icscf1.visit1.net;lr>
P-Asserted-Identity: <tel:+1-237-555-1111>
P-Charging-Vector: icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024";orig-ioi=visit1.net
Privacy: none
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
Recv-Info: g.3gpp.state-and-event
Content-Type: application/sdp
Content-Length: (…)
P-Early-Media: supported
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.
SDP: The SDP contains set of codecs supported by the MGW.
Contact: contains the +g.3gpp.srvcc-alerting feature tag.
4. SIP INVITE request transferring the session (intermediate IM CN subsystem entities to SCC AS)
The SIP INVITE is routed towards the SCC AS, based on filter criteria in S-CSCF.
4a. Remote Leg Update
The SCC AS correlates SIP INVITE request to the local and remote call legs of the existing session between the UE A and the remote end. The SCC AS performs the Remote Leg update by sending SIP UPDATE request towards the remote UE B.
5. SIP UPDATE request (SCC AS to intermediate IM CN subsystem entities)
The SCC AS acting as a B2BUA generates a SIP UPDATE request based upon the received SIP INVITE request and the information previously stored against this session.
6. SIP UPDATE request (Intermediate IM CN subsystem entities to UE B)
The intermediate IM CN subsystem entities forward the SIP UPDATE request to remote UE B.
7. SIP 200 (OK) response (UE B to Intermediate IM CN subsystem entities)
Upon receiving the SIP UPDATE request containing the SDP offer for the leg to the MSC, the far end sends a SIP 200 (OK) response.
8. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS)
The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS.
9. SIP 183 (Session Progress) response (SCC AS to Intermediate IM CN subsystem entities)
The SCC AS sends a SIP 183 (Session Progress) response containing the SDP answer as received from the far end UE. The SDP answer indicates that resources are available
10. SIP 183 (Session Progress) response (Intermediate IM CN subsystem entities to MSC server)
The intermediate IM CN subsystem entities forward the 183 (Session Progress) response to the MSC server.
11. SIP PRACK request (MSC server to Intermediate IM CN subsystem entities)
The MSC acknowledges the receipt of the SIP 183 (Session Progress) response.
12. SIP PRACK request (Intermediate IM CN subsystem entities to SCC AS)
The intermediate IM CN subsystem entities forward the SIP PRACK request to the SCC AS.
13. SIP 200 (OK) response (SCC AS to Intermediate IM CN subsystem entities)
The SCC AS acknowledges the SIP PRACK request.
14. SIP 200 (OK) response (Intermediate IM CN subsystem entities to MSC server)
The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the MSC server.
15. SIP INFO request (SCC AS to intermediate IM CN subsystem entities) – see example in table A.17.3-2
Table A.17.3-2: INFO request (SCC AS to intermediate IM CN subsystem entities)
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
Content-Disposition: Info-Package
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>
16. SIP INFO request (Intermediate IM CN subsystem entities to MSC server)
The intermediate IM CN subsystem entities forward the SIP INFO request to the MSC server. The MSC server is aware that the call that is transferred is in originating alerting phase.
17. SIP 200 (OK) response (MSC server to Intermediate IM CN subsystem entities)
The MSC Server acknowledges the receipt of the SIP INFO request.
18. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS)
The intermediate IM CN subsystem entities forward the SIP 200 (OK) response to the SCC AS.
19. MSC goes in Call delivered state
The MSC enters Call delivered state due to the information received in the SIP INFO request.
20. SIP 200 (OK) response (UE B to intermediate IM CN subsystem entities)
The UE B accepts the call and sends a SIP 200 (OK) response.
21. SIP 200 (OK) response (Intermediate IM CN subsystem entities to SCC AS)
The SIP 200 (OK) response is forwarded to SCC AS.
22 SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities)
The SCC AS sends the SIP 200 (OK) response to indicate that the terminating UE B has accepted the call.
23 SIP 200 (OK) response (Intermediate IM CN subsystem entities to MSC server)
The SIP 200 (OK) response is forwarded to the MSC server.
24 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.
24a Stop the ringing tone
The UE stops playing the locally generated ringing tone.
25 SIP ACK request (MSC server to intermediate IM CN subsystem entities)
The MSC server acknowledges the SIP 200 (OK) response received from SCC AS
26. SIP ACK request (Intermediate IM CN subsystem entities to SCC AS)
The SIP ACK request is forwarded to the SCC AS.
27 SIP ACK request (SCC AS to intermediate IM CN subsystem entities)
The SCC AS acknowledges the SIP 200 (OK) response received towards far end.
28 CC CONNECTACKNOWLEDGE (MSC server to SC UE A)
SC UE A acknowledges the CS CONNECT message.
29 SIP ACK request (Intermediate IM CN subsystem entities to far end)
The SIP ACK request is forwarded towards the far end.
30 – 33 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 31-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