A.17.2 Session transfer for incoming 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.2-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.
Figure A.17.2-1: PS-CS SRVCC, incoming 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 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. 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 UE continues ringing.
3. SIP INVITE request transferring the session (MSC server to intermediate IM CN subsystem entities) – see example in table A.17.2-1
The MSC server sends an initial SIP INVITE request with STN-SR.
Table A.17.2-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 request 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 the SIP sending a SIP UPDATE request towards the Remote Leg.
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 (far end UE 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 B. The SDP answer indicates that resources are available. The SIP 183 (Session Progress) response will contain a Recv-Info header field set to g.3gpp.state-and-event.
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 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.2-2
Table A.17.2-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>receiver</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 terminating 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 received state
The MSC enters Call received state due to the information received in the SIP INFO request.
20a. User answers the call
20. CC CONNECT message from SC UE A to MSC server
The SC UE A accepts the call and sends CC CONNECT message.
21 CC CONNECT ACKNOWLEDGE message (MSC server to SC UE A)
22. SIP INFO request (MSC server to intermediate IM CN subsystem entities) – see example in table A.17.2-3
Table A.17.2-3: INFO request (MSC server to intermediate IM CN subsystem entities)
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
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>
<event>call-accepted</event>
</state-and-event-info>
23. SIP INFO request (Intermediate IM CN subsystem entities to SCC AS)
The intermediate IM CN subsystem entities forward the SIP INFO request to the SCC AS. The SCC AS gets informed that the SC UE A has accepted the call.
24 SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities)
The SCC AS acknowledges the receipt of the SIP INFO request indicating that the SC UE A has accepted the call
25 SIP 200 (OK) response (Intermediate IM CN subsystem entities to MSC server)
The SIP 200 (OK) response is forwarded to the MSC server.
26 SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities)
The SCC AS sends a SIP 200 (OK) response to indicate to the far end that the SC UE A has accepted the call.
27 SIP 200 (OK) response (Intermediate IM CN subsystem entities to far end)
The SIP 200 (OK) response is forwarded to the far end)
28 SIP ACK request (far end to intermediate IM CN subsystem entities)
The far end UE acknowledges the SIP 200 (OK) response received from SCC AS
29 SIP ACK request (Intermediate IM CN subsystem entities to SCC AS)
The SIP ACK request is forwarded to the SCC AS.
30 SIP 200 (OK) response (SCC AS to intermediate IM CN subsystem entities)
The SCC AS sends a SIP 200 (OK) response to indicate the successful access transfer to the MSC server.
31 SIP 200 (OK) response (Intermediate IM CN subsystem entities to far end)
The SIP 200 (OK) response is forwarded to the MSC server.
32 SIP ACK request (MSC server to intermediate IM CN subsystem entities)
MSC server acknowledges the SIP 200 (OK) response received from SCC AS
33. SIP ACK request (Intermediate IM CN subsystem entities to SCC AS)
The SIP ACK request is forwarded to the SCC AS.
34-41 SIP CANCEL Processing
The SCC AS cancels the SIP dialog towards the SC UE
NOTE: Steps 36-41 are performed only if the SC UE A usesGm after 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