A.12 Signalling flows for session replication / media replication performed by the SCC AS
24.3373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) inter-UE transferRelease 17Stage 3TS
A.12.1 Introduction
The signalling flows for session replication/media replication performed by the SCC AS demonstrate how the session is replicated by the SCC AS. The following signalling flows are included:
– subclause A.12.2 shows an example using the pull mode; and
– subclause A.12.3 shows an example using the push mode.
A.12.2 Signalling flows for session replication / media replication performed by the SCC AS – pull mode
In the example flow of figure A.12.2-1, UE-1 has an ongoing multimedia session with UE-3 anchored at the SCC AS. After successful replication, the media flow between UE-1 and UE-3 is not impacted. The replicated media component(s) are sent towards UE-2. UE-2 cannot send media flows towards UE-1 or UE-3 during this session.
Figure A.12.2-1: Signalling flows for session replication by SCC AS from controller to another UE – pull mode
NOTE: For clarity, the SIP 100 (Trying) responses 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 UE-1 and the remote UE-3 anchored at the SCC AS.
2. UE-2 decides to replicate the session from UE-1 to UE-2.
3. UE-2 fetches the dialog information of UE-1 from SCC AS.
4-5. SIP INVITE request (UE-2 to UE-1) – see example in table A.12.2-4
UE-2 sends a SIP INVITE request to UE-1 to perform the session replication.
Table A.12.2-4: SIP INVITE request (UE-2 to Intermediate IM CN subsystem entities)
INVITE sip:user1@example.net; SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:eee]:1357;comp=sigcomp;branch=z9hG4bKnashds7dfdsdq
Max-Forwards: 70
P-Preferred-Identity: <sip:user2@home1.net>
From: <sip:user2@home1.net>;tag=171828
To: <sip:user1transfer@example.net>
Call-ID: Asdasd23123366
Cseq: 41277 INVITE
Contact: <sip:user2@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-2222-222222222222>
Accept-Contact:+g.3gpp.iut-focus;explicit;require
Target-dialog: cb03a0s09a2sdfglkj11111;remote-tag=27364;local-tag=11928
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP6 4444::aaa:bbb:ccc:eee
s=-
c=IN IP6 4444::aaa:bbb:ccc:eee
t=0 0
m=audio 4444 RTP/AVP 97
a=rtpmap:97 PCMU/8000
m=video 6666 RTP/AVP 98
a=rtpmap:98 MPV/90000
a=3gpp.iut.replication
The SDP attribute "a= 3gpp.iut.replicationindicates that the replication request is sent from the controllee UE and it uses the network based solution.
6. SCC AS sends information to MRF to allocate the media resource for the media to be replicated.
7-8. SIP 200 (OK) response for the SIP INVITE request (SCC AS to UE-2)
The SCC AS responds with a SIP 200 (OK) response to UE-2.
9-10. SIP ACK request (UE-2 to SCC AS)
UE-2 sends a SIP ACK request to the SCC AS.
11-12. SIP re-INVITE request (SCC-AS to UE-1) – see example in table A.12.2-11
The SCC AS updates the access leg on Controller UE-1 for the replicated media flow with the MRF.
Table A.12.2-11: SIP re-INVITE request (SCC AS to Intermediate IM CN subsystem entities)
INVITE sip:user1@home1.net; SIP/2.0
Via: SIP/2.0/UDP
Max-Forwards:
P-Preferred-Identity:
From: <sip:interUEtransfer@example.net>;tag=171828
To: <sip:user1@home1.net>; tag=297786
Call-ID:
Cseq: 41278 INVITE
Contact:
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP6 4444::aaa:bbb:ccc:fff
s=-
c=IN IP6 4444::aaa:bbb:ccc:fff
t=0 0
m=audio 4444 RTP/AVP 97
a=rtpmap:97 PCMU/8000
m=video 6666 RTP/AVP 98
a=rtpmap:98 MPV/90000
a=3gpp.iut.replication
13-14. SIP 200 (OK) response to re-INVITE request (UE-1 to SCC AS) – see example in table A.12.1-13
After successful media update, UE-1 sends a SIP 200 (OK) reponse towards the SCC AS.
Table A.12.3-13: SIP 200 (OK) response (UE-1 to Intermediate IM CN subsystem entities)
SIP/2.0 200 OK
Via:
Max-Forwards:
P-Preferred-Identity:
From: <sip:interUEtransfer@example.net>;tag=171828
To: <sip:user1@home1.net>; tag=297786
Call-ID:
Cseq:
Contact:
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP6 4444::aaa:bbb:ccc:fff
s=-
c=IN IP6 4444::aaa:bbb:ccc:fff
t=0 0
m=audio 4444 RTP/AVP 97
a=rtpmap:97 PCMU/8000
m=video 6666 RTP/AVP 98
a=rtpmap:98 MPV/90000
a=3gpp.iut.replication
15-16. SIP ACK request (SCC AS to UE-1)
The SCC AS sends a SIP ACK request to UE-1.
17-18. SIP re-INVITE request (SCC AS to UE-3)
The SCC AS sends a SIP re-INVITE request towards the remote UE to update the remote leg to communicate media with the MRF.
20-22. SIP 200 (OK) response to re-INVITE request (UE-3 to SCC AS)
After successful media update, remote UE-3 sends a SIP 200 (OK) response towards the SCC AS.
23-25. SIP ACK request (SCC AS to UE-3)
The SCC AS sends a SIP ACK request to remote UE-3.
A.12.3 Signalling flows for session replication / media replication performed by the SCC AS – push mode
In the example flow of figure A.12.3-1, UE-1 has an ongoing multimedia session with UE-3 anchored at the SCC AS. After successful replication, the media flow between UE-1 and UE-3 is not impacted. The replicated media component(s) are sent towards UE-2. UE-2 cannot send media flows towards UE-1 or UE-3 during this session.
Figure A.12.3-1: Signalling flow for replicating media in network from controller to another UE- push mode
NOTE: For clarity, the SIP 100 (Trying) responses 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 UE-1 and the remote UE-3 anchored at the SCC AS.
2. UE-1 decides to replicate the session from UE-1 to UE-2.
3-4. SIP REFER request (UE-1 to SCC AS) – see example in table A.12.3-3
UE-1 sends a SIP REFER request to the SCC AS to request the session replication. When the SCC AS receives the SIP REFER request, the SCC AS authorizes the request.
Table A.12.3-3: SIP REFER request (UE-1 to Intermediate IM CN subsystem entities)
REFER sip:interUEtransfer@example.net; SIP/2.0
Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:ddd]:1357;comp=sigcomp;branch=z9hG4bKnashds7dfdsdq
Max-Forwards: 70
P-Preferred-Identity: <sip:user1@home1.net>
From: <sip:user1@home1.net>;tag=171828
To: <sip:user2@home1.net; >
Call-ID: Asdasd23123366
Cseq: 41277 REFER
Contact: <sip:user1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-1111-111111111111>
Accept-Contact:+g.3gpp.iut-focuss;explicit;require
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Refer-To: <sip:user3@home1.net?;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6?body= m%3Dvedio%209%20RTP%2FAVP%98%0Dm% a=3gpp.iut.replication>
Referred-by: sip:user1@home1.net
Target-dialog: cb03a0s09a2sdfglkj11111;remote-tag=27364;local-tag=11928
Content-Type: application/
Content-Length: (…)
The SDP attribute "The SDP attribute "a= 3gpp.iut.replication" indicates that the replication request was sent from the controller UE and it uses the network based solution.
5-6. SIP 200 (OK) response for the SIP REFER request (SCC AS to UE-1)
7. SCC AS sends information to MRF to allocate the media resource for the media to be replicated.
Editor’s Note: There is a need to understand what functionality the MRF is providing. This can either be done by showing the instructions to the MRF or by showing the SDP in other messages thus enabling the activity of the MRF to be seen.
8-9. SIP INVITE request (SCC AS to UE-2) – See example in table A.12.3-8
The SCC AS sends a SIP INVITE request towards UE-2 to establish a session based on the information provided in the SIP REFER request.
Table A.12.3-8: SIP INVITE request (SCC AS to UE-2)
INVITE sip:user2@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-2222-222222222222 SIP/2.0
Via: SIP/2.0/UDP
Max-Forwards: 70
From: <sip:user1@home1.net>;tag=171828
To: <sip:user2@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-2222-222222222222>
Referred-By: sip: user1@example1.net
Call-ID: duie4hr3896
Cseq: 41 INVITE-
Contact: <sip:user1@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-1111-111111111111>
Accept-Contact:+g.3gpp.iut-focus;explicit;require
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE
Content-Length: 0
Content-Type: application/sdp
Content-Length: (…)
v=0
o=- 2987933615 2987933615 IN IP6 4444::aaa:bbb:ccc:eee
s=-
c=IN IP6 4444::aaa:bbb:ccc:eee
t=0 0
m=audio 4444 RTP/AVP 97
a=rtpmap:97 PCMU/8000
m=video 6666 RTP/AVP 98
a=rtpmap:98 MPV/90000
a=g.3gpp.iut.replication
The SCC AS adds the Referred-By header in order to indicate to UE-2 that this collaborative session request was triggered by UE-1.
The SDP attribute "a= 3gpp.iut.replication" indicates that the replication request is sent by the SCC AS and it uses the network based solution.
10-11. SIP 200 (OK) reponse to SIP INVITE request (UE-2 to SCC AS)
UE-2 establishes the session by sending a SIP 200 (OK) response towards the SCC AS.
12-13. SIP ACK request (SCC AS to UE-2)
The SCC AS sends a SIP ACK request to UE-2.
14-15. SIP re-INVITE request (SCC AS to UE-1)
The SCC AS updates the access leg on Controller UE-1 for the replicated media flow with the MRF.
16-17. SIP 200 (OK) response to re-INVITE request (UE-1 to SCC AS)
After successful media update, UE-1 sends a SIP 200 (OK) reponse towards the SCC AS.
18-19. SIP ACK request (SCC AS to UE-1)
The SCC AS sends a SIP ACK request to UE-1.
20-22. SIP re-INVITE request (SCC AS to UE-3)
The SCC AS sends a SIP re-INVITE request towards the remote UE to update the remote leg to communicate media with the MRF.
23-25. SIP 200 (OK) response to re-INVITE request (UE-3 to SCC AS)
After successful media update, UE-3 sends a SIP 200 (OK) response towards the SCC AS.
26-27. SIP ACK request (SCC AS to UE-3)
The SCC AS sends a SIP ACK request to remote UE-3.
29-30. SIP NOTIFY request (SCC AS to UE-1)
The SCC AS informs UE-1 that the action triggered by the SIP REFER request was successfully completed.
31-32. SIP 200 (OK) response to SIP NOTIFY request (UE-1 to SCC AS)
UE-1 confirms the SIP NOTIFY request by sending a SIP 200 (OK) response to the SIP NOTIFY request.