A.3 Signalling flows for Inter-UE Transfer without establishment of Collaborative Session
24.3373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) inter-UE transferRelease 17Stage 3TS
A.3.1 Introduction
The signalling flows in the subclause demonstrate how an SC UE can initiate the inter UE transfer of the complete session without Collaborative Session establishment.
The example assumes that the UE-1 and UE-2 are under the control of the same subscriber.
A.3.2 Complete transfer in services defining only originating session set up in UE
In the example flow at the figure A.3.2-1, UE-1 has an ongoing multimedia session with UE-3 anchored at SCC AS. The session is established using an IMS communication service identified by ICSI urn:urn-7:3gpp-service.ims.icsi.iptv which is an IMS communication service which defines originating session set up in the UE only.
Figure A.3.2-1: Signalling flow for inter UE transfer without Collaborative Session establishment
NOTE 1: For clarity, the SIP 100 (Trying) responses and the SIP NOTIFY requests carring the message/sipfrag with SIP 100 (Trying) response are not shown in the signalling flow.
1. UE-1 is in session with UE-3
There is a multimedia session comprising audio and video media between the UE-1 and the remote UE-3 anchored at SCC AS. The session was established using IMS communication service identified by ICSI urn:urn-7:3gpp-service.ims.icsi.iptv. The dialog identifier of the session is AB03a0s09a2sdfglkj490333, remote-tag=Afgsdfg45, local-tag=U188gg.
2. SIP REFER request initiating the inter UE transfer to UE-2 (UE-1 to Intermediate IM CN subsystem entities) – see example in table A.3.2-2
Table A.3.2-2: SIP REFER request (UE-1 to Intermediate IM CN subsystem entities)
REFER sip:user@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-222222222222 SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
P-Preferred-Identity: <sip:user@home1.net>
From: <sip:user@home1.net>;tag=171828
To: <sip:user@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-222222222222>
Call-ID: Asdasd231233
Cseq: 4127 REFER
Contact: <sip:user@home1.net;gr=gr=urn:uuid:f81d4fae-7dec-11d0-a765-111111111111>
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Length: 0
Refer-To: <sip:interUEtransfer@sccas.home1.net?Target-Dialog=AB03a0s09a2sdfglkj490333%3Bremote-tag=Afgsdfg45%3Blocal-tag=U188gg&Require=tdialog&P-Preferred-Service=urn:urn-7:3gpp-service.ims.icsi.iptv&Accept-Contact=*%3b+g.3gpp.icsi-ref%3d%22urn%253Aurn-7%253gpp-service.ims.icsi.iptv%22>
Referred-By: sip:user@home1.net
Request-URI: contains the GRUU of the UE-2
Refer-To: contains the Inter UE Transfer SCC AS URItogether with Target-Dialog URI header field containing the dialog identifier of the session with UE-3, Require URI header field containing the "tdialog" and P-Preferred-Service and Accept-Contact URI header fields containing the ICSI of the service to be requested by UE-2.
Contact: contains the GRUU of the UE-1
3. Evaluation of initial filter criteria
The S-CSCF evaluates originating initial filter criteria for the served user and as a result routes the SIP REFER request towards the SCC AS.
4. SIP REFER request (Intermediate IM CN subsystem entities to SCC AS)
5. The SCC AS authorizes the request and if authorization is passed successfully, the SCC AS forwards the SIP REFER request further
6.-7. SIP REFER request (SCC AS to UE-2)
8.-11. SIP 200 (OK) response to the SIP REFER request (UE-2 to UE-1)
12. SIP INVITE request (UE-2 to intermediate IM CN subsystem entities) – see example in table A.3.2-12
Table A.3.2-12: SIP INVITE request (UE-1 to Intermediate IM CN subsystem entities)
INVITE sip:interUEtransfer@sccas.home1.net SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:fff]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
P-Preferred-Identity: <sip:user@home1.net>
From: <sip:user@home1.net>;tag=171828
To: <sip:interUEtransfer@sccas.home1.net>
Call-ID: tq34gasgaegr
Cseq: 4127 INVITE
Contact: <sip:user@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-222222222222>
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Target-Dialog: AB03a0s09a2sdfglkj490333;remote-tag=Afgsdfg45;local-tag=U188gg
Require: tdialog
Content-Type: application/sdp
Content-Length: (…)
Supported: 100rel, precondition
P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.iptv
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.iptv"
Referred-By: sip:user@home1.net
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:fff
s=
c=IN IP6 5555::aaa:bbb:ccc:fff
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
m=video 3400 RTP/AVP 98 99
b=AS:75
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:98 H263
a=fmtp:98 profile-level-id=0
a=rtpmap:99 MP4V-ES
Request-URI: set to the URI in the Refer-To of the received SIP REFER request
Contact: contains the GRUU of the UE-2
Target-Dialog: set to the value of the Target-Dialog URI header field of the URI in the Refer-To of the received SIP REFER request
Require: set to the value of the Require URI header field of the URI in the Refer-To of the received SIP REFER request
P-Preferred-Service: set to the value of the P-Preferred-Service URI header field of the URI in the Refer-To of the received SIP REFER request
Accept-Contact: set to the value of the Accept-Contact URI header field of the URI in the Refer-To of the received SIP REFER request
13. Evaluation of initial filter criteria
The S-CSCF evaluates originating initial filter criteria for the served user and as a result routes the SIP INVITE request towards the SCC AS.
14. SIP INVITE request (Intermediate IM CN subsystem entities to SCC AS)
15. Remote Leg Update
Based on the STI in the Target-Dialog header field the SCC AS detects that the inter UE tranfer is being attempted and performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE.
16-18. SIP re-INVITE request (SCC AS to UE-3 over intermediate IM CN subsystem entities)
The SCC AS acting as a routing B2BUA generates a SIP re-INVITE request based upon the received SIP INVITE request and the information previously stored against this session and routes it towards UE-3 via the intermediate IM CN subsystem entities.
19-21. SIP 200 (OK) response (UE-3 to intermediate IM CN subsystem entities)
Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE-3 has all resources available, it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The SDP answer indicates that the resources are available.
22-24. SIP ACK request (SCC AS to UE-3 via intermediate IM CN subsystem entities)
The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request to the remote UE-3.
25-26. SIP 200 (OK) response (SCC AS to UE-2 via intermediate IM CN subsystem entities)
The SCC AS generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) response towards the UE-2.
27-28. SIP ACK request (UE-2 to SCC AS via intermediate IM CN subsystem entities)
The UE-2 generate the SIP ACK request to the SIP 200 (OK) response, and forward it to the SCC AS.
29. Media and IMS service control paths:
The media path is now established between UE-2 and UE-3 and the IMS service control between UE-2 and SCC AS.
30-33. SIP NOTIFY request (UE-2 to UE-1 over intermediate IM CN subsystem entities and SCC AS)
The UE-2 generate the SIP NOTIFY request carrying the message/sipfrag body and send it towards UE-1.
34-37. SIP 200 OK response to the SIP NOTIFY request (UE-1 to UE-2 over intermediate IM CN subsystem entities and SCC AS)
38-39: SIP BYE request (SCC AS to UE-1 via intermediate IM CN subsystem entities)
The SCC AS terminates the source access leg by sending a BYE request to the UE-1.
40-41. SIP 200 (OK) response (UE-1 to SCC AS via intermediate IM CN subsystem entities)
Upon receiving the SIP BYE request, the UE-1 sends a SIP 200 (OK) response to the SCC AS. Subsequently, the UE-1 relinquishes all resources pertaining to the session.
A.3.3 Complete transfer in services defining terminating session set up in UE
The signalling flow in figure A.3.3-1 describes the procedures for complete transfer in services defining terminating session set up in UE. UE-1 has an ongoing multimedia session with UE-3 anchored at the SCC AS. UE-1 initiate the inter UE transfer of the complete session to UE-2 without collaborative session establishment. This transferred session is an IMS communication service session which can be established by termination session set up in UE-2.
Figure A.3.3-1: Signalling flow for complete transfer in services defining terminating session set up in UE
NOTE 1: For clarity, the SIP 100 (Trying) responses and the SIP NOTIFY requests carring the message/sipfrag with SIP 100 (Trying) response are not shown in the signalling flow.
1. UE-1 is in session with UE-3
There is a multimedia session comprising audio and video media between the UE-1 and the remote UE-3 anchored at SCC AS. The dialog identifier of the session is AB03a0s09a2sdfglkj490333, remote-tag=Afgsdfg45, local-tag=U188gg.
2-4. SIP REFER request initiating the inter UE transfer to UE-2 (UE-1 to SCC AS)
Table A.3.3-2: SIP REFER request (UE-1 to Intermediate IM CN subsystem entities)
REFER sip:interUEtransfer@sccas.home1.net SIP/2.0
Via: SIP/2.0/UDP 123.45.67.89:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
P-Preferred-Identity: <sip:user@home1.net>
From: <sip:user@home1.net>;tag=171828
To: <sip:interUEtransfer@sccas.home1.net>
Call-ID: Asdasd231233
Cseq: 4127 REFER
Contact: <sip:user@home1.net;gr=gr=urn:uuid:f81d4fae-7dec-11d0-a765-111111111111>
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Length: 0
Target-dialog:AB03a0s09a2sdfglkj490333;remote-tag= Afgsdfg45;local-tag= U188gg
Refer-To: <sip:user@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-222222222222?P-Preferred-Service= urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel&Accept-Contact=*%3b+g.3gpp.icsi-ref%3d%22urn%253Aurn-7%253gpp-service.ims.icsi.mmtel%22>
Referred-By: sip:user@home1.net
Request-URI: contains the Inter UE Transfer SCC AS URI
Refer-To: contains the contains the GRUU of the UE-2 together with P-Preferred-Service and Accept-Contact URI header fields containing the ICSI of the service to be requested by SCC AS.
NOTE: P-Preferred-Service and Accept-Contact URI may not be included if the IMS communication service is multimedia telephony services,
Target-dialog: contains the dialog identifier of the session with UE-3
Contact: contains the GRUU of the UE-1
5. The SCC AS authorizes the request
6.-7. SIP 200 (OK) response to the SIP REFER request (SCC AS to UE-1)
8-9. SIP INVITE request (SCC AS to UE-2)
Table A.3.3-8: SIP INVITE request (SCC AS to UE-2)
INVITE sip:user@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-222222222222 SIP/2.0
Via: SIP/2.0/UDP sccas.home1.net; branch=z9hG4bK332b33.3;
Max-Forwards: 70
From:<sip:interUEtransfer@sccas.home1.net>; tag=171828
To: <sip:user@home1.net>;
Call-ID: tq34gasgaegr
Cseq: 4127 INVITE
Contact: <sip:interUEtransfer@sccas.home1.net>
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)
Supported: 100rel, precondition
P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mmtel
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Referred-By: sip:user@home1.net
v=0
o=- 1027933615 1027933615 IN IP4 132.54.76.98
s=
c= IN IP4 132.54.76.98
t=0 0
m=audio 3000 RTP/AVP 97
b=AS:25.4
a=rtpmap:96 AMR
a=fmtp:96 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:97 telephone-event
a=maxptime:20
m=video 3002 RTP/AVP 98 99
b=AS:75
a=rtpmap:98 H263
a=fmtp:98 profile-level-id=0
a=rtpmap:99 MP4V-ES
Request-URI: set to the URI in the Refer-To of the received SIP REFER request
Contact: contains the Inter UE Transfer SCC AS URI
P-Preferred-Service: set to the value of the P-Preferred-Service URI header field of the URI in the Refer-To of the received SIP REFER request
Accept-Contact: set to the value of the Accept-Contact URI header field of the URI in the Refer-To of the received SIP REFER request
10-11. SIP 200 (OK) response (UE-2 to SCC AS)
The UE-2 generate the the SIP 200 (OK) response to the SIP INVITE request, and forward it to the SCC AS.
Table A.3.3-10: SIP 200 (OK) response (UE-2 to SCC AS)
SIP/2.0 200 OK
Via:
To: sip<sip:user@home1.net>; tag=36527
From: <sip:interUEtransfer@sccas.home1.net>; tag=171828
Call-ID: tq34gasgaegr
CSeq:
P-Preferred-Identity:
Contact:
Allow:
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 1027933615 1027933615 IN IP4 IP4 123.112.67.87
s=
c= IN IP4 IP4 123.112.67.87
t=0 0
m=audio 1300 RTP/AVP 97
b=AS:25.4
a=rtpmap:96 AMR
a=fmtp:96 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:97 telephone-event
a=maxptime:20
m=video 1302 RTP/AVP 98 99
b=AS:75
a=rtpmap:98 H263
a=fmtp:98 profile-level-id=0
a=rtpmap:99 MP4V-ES
12. Remote Leg Update
Based on the received SDP fromUE-2, SCC AS performs the Remote Leg update by sending the SIP re-INVITE request towards the remote UE.
13-15. SIP re-INVITE request (SCC AS to UE-3)
The SCC AS acting as a routing B2BUA generates a SIP re-INVITE request based upon the received SIP INVITE request and the information previously stored against this session and routes it towards UE-3 via the intermediate IM CN subsystem entities.
Table A.3.3-13: SIP INVITE request (SCC AS to remote UE)
INVITE sip:user2@home1.net; SIP/2.0
Via:
To: sip:user2@home1.net;tag= U188gg
From: sip:user1@home1.net;tag= Afgsdfg45
Call-ID: AB03a0s09a2sdfglkj490333
CSeq:
Max-Forwards:
P-Asserted-Identity:
Require:
Contact: <sip:interUEtransfer@sccas.home1.net>
Allow:
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 1027933615 1027933615 IN IP4 123.45.67.89
s=-
t=0 0
c=IN IP4 123.112.67.87
m=audio 1300 RTP/AVP 96 97
b=AS:25.4
a=rtpmap:96 AMR
a=fmtp:96 mode-set=0,2,5,7; mode-change-period=2
a=rtpmap:97 telephone-event
a=maxptime:20
m=video 1302 RTP/AVP 98 99
b=AS:75
a=rtpmap:98 H263
a=fmtp:98 profile-level-id=0
a=rtpmap:99 MP4V-ES
16-18. SIP 200 (OK) response (UE-3 to SCC AS)
Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE-3 has all resources available, it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The SDP answer indicates that the resources are available.
19-20. SIP ACK request (SCC AS to UE-2)
The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request to the target UE, UE-2.
21-23. SIP ACK request (SCC AS to UE-3)
The SCC AS generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request to the remote UE-3.
24-25. Media and IMS service control paths:
The media path is now established between UE-2 and UE-3 and the IMS service control between UE-2 and SCC AS.
26-27: SIP BYE request (SCC AS to UE-1)
The SCC AS terminates the source access leg by sending a BYE request to the UE-1.
28-29. SIP 200 (OK) response (UE-1 to SCC AS)
Upon receiving the SIP BYE request, the UE-1 sends a SIP 200 (OK) response to the SCC AS. Subsequently, the UE-1 relinquishes all resources pertaining to the session.
30-31. SIP NOTIFY request (SCC AS to UE-1)
The SCC AS generate the SIP NOTIFY request carrying the message/sipfrag body and send it towards UE-1.
32-33. SIP 200 (OK) response(UE-1 to SCC AS)
SIP 200 OK response to the SIP NOTIFY request (UE-1 to UE-2 over intermediate IM CN subsystem entities and SCC AS)
A.3.4 Inter UE transfer triggered by SC UE not participating in the session to be transferred
In the example flow at the figure A.3.4-1, UE-1 has an ongoing multimedia session with UE-3 anchored at SCC AS-1. UE-1 and UE-2 belong to the same IMS subscriptions. The SCC AS-1 authorizes the inter UE transfer request on behalf of the UE-1.
Figure A.3.4-1: Signalling flow for inter UE transfer without collaborative session establishment triggered by UE not participating in the session
NOTE: For clarity, the SIP 100 (Trying) messages are not shown in the signalling flow.
1-2. UE-1 is in session with UE-3
There is a multimedia session comprising audio and video media between the UE-1 and the remote UE-3 anchored at SCC AS-1. The dialog identifier of the session between SCC AS-1 and UE-1 is AB03a0s09a2sdfglkj490333, remote-tag=dfg45, local-tag=444.
3. UE-2 discovers the sessions of UE-1 as shown in subclause A.23
4-5. SIP INVITE request (UE-2 to SCC AS-1) – see example in table A.3.4-4
The UE-2 sends SIP INVITE request to transfer the session to the UE-2.
Table A.3.4-4: SIP INVITE request
INVITE sip:interUEtransfer@sccas.home1.net SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:fff]:1357;comp=sigcomp;branch=z9hG4bKnashds7
Max-Forwards: 70
P-Preferred-Identity: <sip:user2@home1.net>
From: <sip:user2@home1.net>;tag=171828
To: <sip:interUEtransfer@sccas.home1.net>
Call-ID: tq34gasgaegr
Cseq: 4127 INVITE
Contact: <sip:user2@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-2222-222222222222>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.iptv"
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Replaces: AB03a0s09a2sdfglkj490333;remote-tag=dfg45;local-tag=444
Require: replaces
Content-Type: application/sdp
Content-Length: (…)
Supported: 100rel, precondition, 199
v=0
o=- 2987933615 2987933615 IN IP6 5555::aaa:bbb:ccc:fff
s=
c=IN IP6 5555::aaa:bbb:ccc:fff
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
m=video 3400 RTP/AVP 98 99
b=AS:75
a=curr:qos local none
a=curr:qos remote none
a=des:qos mandatory local sendrecv
a=des:qos none remote sendrecv
a=rtpmap:98 H263
a=fmtp:98 profile-level-id=0
a=rtpmap:99 MP4V-ES
Request-URI: contains the Inter UE Transfer SCC AS URI
Replaces: set to the dialog information of the session to be transferred
6.-8. SIP re-INVITE request (SCC AS-1 to UE3)
Since the request is addressed to SCC AS-1 and since STI in the Replaces header field identifies an dialog anchored in the SCC AS-1, the SCC AS-1 detects that the inter UE transfer is being attempted, authorizes the request of behalf of UE-1, acts as a routing B2BUA and performs remote leg update by sending the SIP re-INVITE request towards the UE-3.
9-11. SIP 200 (OK) response (UE-3 to intermediate IM CN subsystem entities)
Upon receiving the SIP re-INVITE request containing the SDP offer, since the UE-3 has all resources available, it sends immediately the SIP 200 (OK) response to the SIP re-INVITE request that contains the SDP answer. The SDP answer indicates that the resources are available.
12-14. SIP ACK request (SCC AS-1 to UE-3 via intermediate IM CN subsystem entities)
The SCC AS-1 generates the SIP ACK request to the SIP 200 (OK) response, and forwards the SIP ACK request to the remote UE-3.
15-16. SIP 200 (OK) response (SCC AS-1 to UE-2 via intermediate IM CN subsystem entities)
The SCC AS-1 generates the SIP 200 (OK) response to the SIP INVITE request, and forwards the SIP 200 (OK) response towards the UE-2.
17-18. SIP ACK request (UE-2 to SCC AS-1 via intermediate IM CN subsystem entities)
The UE-2 generates the SIP ACK request to the SIP 200 (OK) response.
19-20. SIP BYE request (SCC AS-1 to UE-1 via intermediate IM CN subsystem entities)
The SCC AS-1 terminates the source access leg by sending a BYE request to the UE-1.
21-22. SIP 200 (OK) response (UE-1 to SCC AS-1 via intermediate IM CN subsystem entities)
Upon receiving the BYE request, the UE-1 sends a SIP 200 (OK) response. Subsequently, the UE-1 releases all resources pertaining to the session.
23-24. UE-2 is now in session with UE-3