A.9 Signalling flows for for establishment of a collaborative session during session setup

24.3373GPPIP Multimedia (IM) Core Network (CN) subsystem IP Multimedia Subsystem (IMS) inter-UE transferRelease 17Stage 3TS

Tools: ARFCN - Frequency Conversion for 5G NR/LTE/UMTS/GSM

A.9.1 Introduction

The signalling flows in this subclause demonstrate how a UE-1 can establish a Collaborative Session during originating and terminating session setup.

A.9.2 Collaborative session establishment upon originating session setup

In the example flow at the figure A.9.2-1, UE-1 wants to establish a collaborative session without the pre-requisite of having an IMS session established. The UE-1 wants to setup a collaborative session with audio media flow in UE-1 and video media flow in UE-2, and wants to control the collaborative session through UE-1.

Figure A.9.2-1: Signalling flow for establishment of collaborative session upon originating IMS session

NOTE: For clarity, the SIP 100 (Trying) messages are not shown in the signalling flow.

1-2. SIP INVITE request (UE-1 to SCC AS) – see example in table A.9.2-1

The UE-1 sends SIP INVITE request to SCC AS to setup the collaborative session.

Table A.9.2-1: SIP INVITE request (UE-1 to intermediate IM CN subsystem entities)

INVITE SIP: user3@example1.net; SIP/2.0

Via: SIP/2.0/UDP 192.0.2.5;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: sip:pcscf1.home1.net:7531;lr;comp=sigcomp>, <sip:orig@scscf1.home1.net;lr>

P-Preferred-Identity: <sip:uesr1@example1.net>

P-Access-Network-Info:

Privacy: none

From: <sip:user1@example1.net>; tag=171828

To: <sip:user3@example1.net>

Call-ID: cb03a0s09a2sdfglkj490237

Cseq: 127 INVITE

Supported: 100rel; precondition, gruu, 199

Require: sec-agree, replaces

Proxy-Require: sec-agree

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port1=7531

Contact:<sip:user1@example1.net;gr= urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE

Accept: application/sdp; application/3gpp-ims+xml

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP4 192.0.2.5

t=0 0

c=IN IP4 192.0.2.5

m=audio 49170 RTP/AVP 0 8 3

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 9 RTP/AVP 98

c=IN IP4 0.0.0.0

a=3gpp.iut.controllee sip:user2@example2.net; gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

b=AS:75

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

SDP: The first media stream (audio) will be terminated by UE-1 of which the IP address is indicated in the c-line in the SDP.

The port number of the remote side, i.e. UE-3 for the video media is currently not known to UE-1, therefore the port number for the video media stream is set to the discard port number "9".

3-4. SIP INVITE request (SCC AS to UE-2) – see example in table A.9.2-3

Upon receiving the SIP INVITE request, the SCC AS sends a SIP INVITE request to UE-2 to establish the media between UE-2 and the remote UE-3.

Table A.9.2-3: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities)

INVITE sip:user2@example1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6; SIP/2.0

Via:

Record-Route: sip:sccas1.home1.example.net

To: <sip:user2@example1.net>

From: sip:user1@example1.net;tag=acegi

Call-ID:

CSeq:

Max-Forwards:

P-Asserted-Identity: sip:user1@example1.net

Require:

Contact: <sip:user1@example1.net;gr= urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;

Allow:

Content-Type: application/sdp

Content-Length:(…)

v=0

o=- 2987933615 2987933615 IN IP4 192.0.2.5

t=0 0

c=IN IP4 192.0.2.5

a=creq:ccap-v0

m=audio 0 RTP/AVP 0 8 3

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 9 RTP/AVP 98

C=IN IP4 0.0.0.0

b=AS:75

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

5-6. SIP 200(OK) response to SIP INVITE request (UE-2 to SCC AS) – see example in table A.9.2-5

Table A.9.2-5: SIP 200 (OK) response (UE-2 to intermediate IM CN subsystem entities)

SIP/2.0 200 OK

Via:

To: <sip:user2@example1.net>;tag=xyzwv

From: <sip:user1@example1.net>; tag=171828

Call-ID:

CSeq:

P-Preferred-Identity:

Contact: sip:user2@example1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

Allow: INVITE, PRACK, UPDATE

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 1027933615 1027933615 IN IP4 192.0.2.5

s=-

t=0 0

m=audio 0 RTP/AVP 0 8 3

m=video 1300 RTP/AVP 98

a=inactive

c=IN IP4 145.23.77.88

b=AS:75

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

SDP: The connection information now indicates the IP address of UE-2.

7-8. SIP INVITE request (SCC AS to UE-3)

The SCC AS sends the SIP INVITE request towards the remote UE-3 containg the SDP information of UE-1 and UE-2.

9-12. SIP 200 (OK) reponse to SIP INVITE request(UE-3 to UE-1)

UE-3 acknowledges the SIP INVITE request by sending SIP 200 (OK) response with the SDP answer to UE-1.

13-16. SIP ACK request (UE-1 to UE-3)

UE-1 sends SIP ACK request to the remote UE.

17-18. SIP re-INVITE request (SCC AS to UE-2)

SCC AS-2 sends SIP re-INVITE request to UE-2 to update the media in UE-2.

19-20. SIP 200 (OK) response to SIP re-INVITE request (UE-2 to SCC AS)

The UE-2 confirms the SIP re-INVITE request by sending SIP 200 (OK) response to SCC AS.

21-22. SIP ACK request (SCC AS to UE-2)

SCC AS sends SIP ACK request to the remote UE.

23-24. Media path:

The audio media is between controller UE-1 and remote UE-3, and the video media is established between controllee UE-2 and the remote UE. The collaborative session control is in the controller UE-1.

A.9.3 Collaborative session establishment upon originating session setup with forked responses

In the information flow at the figure A.9.2a-1, UE-1 wants to establish a collaborative session without the pre-requisite of having an IMS session established. The UE-1 wants to setup a collaborative session with audio media flow in UE-1 and video media flow in UE-2, and wants to control the collaborative session through UE-1.

The SIP INVITE request is forked to the remote party. This flow assumes that the second Remote UE accepts the call.

Figure A.9.3-1: Signalling flow for establishment of collaborative session upon originating IMS session with forked response

NOTE: For clarity, the SIP 100 (Trying), SIP PRACK requests to 183 (Session Progress) responses and SIP 200 (OK) responses to SIP PRACK requests are not shown in the signalling flow.

1-2. SIP INVITE request (UE-1 to SCC AS) – see example in table A.9.3-1

The UE-1 sends SIP INVITE request to SCC AS to setup the collaborative session.

Table A.9.3-1: SIP INVITE request (UE-1 to intermediate IM CN subsystem entities)

INVITE SIP: user3@example1.net; SIP/2.0

Via: SIP/2.0/UDP 192.0.2.5;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: sip:pcscf1.home1.net:7531;lr;comp=sigcomp>, <sip:orig@scscf1.home1.net;lr>

P-Preferred-Identity: <sip:uesr1@example1.net>

P-Access-Network-Info:

Privacy: none

From: <sip:user1@example1.net>; tag=171828

To: <sip:user3@example1.net>

Call-ID: cb03a0s09a2sdfglkj490237

Cseq: 127 INVITE

Supported: 100rel; precondition, gruu, 199

Require: sec-agree, replaces

Proxy-Require: sec-agree

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port1=7531

Contact:<sip:user1@example1.net;gr= urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE

Accept: application/sdp; application/3gpp-ims+xml

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP4 192.0.2.5

t=0 0

c=IN IP4 192.0.2.5

a=creq:ccap-v0

m=audio 49170 RTP/AVP 0 8 3

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 9 RTP/AVP 98

c=IN IP4 0.0.0.0

a=3gpp.iut.controllee SIPURI sip:user2@example2.net; gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6

b=AS:75

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

SDP: The first media stream (audio) will be terminated by UE-1 of which the IP address is indicated in the c-line in the SDP header. The second media stream (video) will be terminated by UE-2.

The port number of the UE-2 for the video media is currently not known to UE-1, therefore the port number for the video media stream is set to the discard port number "9".

3-4. SIP INVITE request (SCC AS to UE-2) – see example in table A.9.2-3

Upon receiving the SIP INVITE request, the SCC AS sends a SIP INVITE request to UE-2 to establish the media between UE-2 and the remote UE-3.

Table A.9.3-3: SIP INVITE request (SCC AS to intermediate IM CN subsystem entities)

INVITE sip:uesr2@example1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6; SIP/2.0

Via:

Record-Route: sip:sccas1.home1.example.net

To: <sip:user2@example1.net>

From: sip:user1@example1.net;tag=acegi

Call-ID:

CSeq:

Max-Forwards:

P-Asserted-Identity: sip:user1@example1.net

Require:

Contact: <sip:user1@example1.net;gr= urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;

Allow:

Content-Type: application/sdp

Content-Length:(…)

v=0

o=- 2987933615 2987933615 IN IP4 192.0.2.5

t=0 0

m=audio 0 RTP/AVP 0 8 3

m=video 9 RTP/AVP 98

C=IN IP4 0.0.0.0

b=AS:75

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

5-6. SIP 183 (Session Progress) response to SIP INVITE request (UE-2 to SCC AS)

The UE-2 responds with SIP 183 (Session Progress) response containing the SDP answer of UE-2.

Table A.9.3-5: SIP 183 (Session Progress) response (UE-2 to Intermediate IM CN subsystem entities)

SIP/2.0 183 Session Progress

Via:

Record-Route: sip:sccas1.home1.example.net

To: <sip:user2@example1.net>;tag=edfcb

From: sip:user1@example1.net;tag=acegi

Call-ID:

CSeq:

Max-Forwards:

P-Asserted-Identity: sip:user1@example1.net

Require:

Contact: <sip:user1@example1.net;gr= urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;

Allow:

Content-Type: application/sdp

Content-Length:(…)

v=0

o=- 2987933615 2987933615 IN IP4 192.0.2.5

t=0 0

m=audio 0 RTP/AVP 0 8 3

m=video 1300 RTP/AVP 98

a=inactive

C=IN IP4 145.23.77.88

b=AS:75

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

7. SIP INVITE request (SCC AS to Intermediate IM CN subsystem entities) – see example in table A.9.3-7

The SCC AS sends the SIP INVITE request, which contains the SDP information of UE-1 and UE-2, towards the Intermediate IM CN subsystem entities, i.e. S-CSCF serving for remote UE.

8a. SIP INVITE request (Intermediate IM CN subsystem entities to UE-3)

Intermediate IM CN subsystem entities, i.e. S-CSCF serving for remote UE, determine that the SIP INVITE request should be forked, and send the SIP INVITE request to UE-3.

8b. SIP INVITE request (Intermediate IM CN subsystem entities to UE-4)

Intermediate IM CN subsystem entities, i.e. S-CSCF serving for remote UE, determine that the SIP INVITE request should be forked, and send the SIP INVITE request to UE-4.

9a-10a. SIP 183 (Session Progress) response to SIP INVITE request (UE-3 to SCC AS)

The remote UE-3 responds with SIP 183 (Session Progress) response containing the SDP answer of the remote UE-3.

Table A.9.3-9a: SIP 183 (Session Progress) response (UE-3 to Intermediate IM CN subsystem entities)

SIP/2.0 183 Session Progress

Via:

Record-Route: sip:sccas1.home1.example.net

To: sip:user3@example1.net;tag = 66666

From: sip:user1@example1.net;tag=acegi

Call-ID:

CSeq:

Max-Forwards:

P-Asserted-Identity:

Require:

Contact: <sip:user3@example1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;

Allow:

Content-Type: application/sdp

Content-Length:(…)

v=0

o=- 2987933615 2987933615 IN IP4 192.1.3.9

c=IN IP4 192.1.3.9

a=creq:ccap-v0

m=audio 3370 RTP/AVP 0 8 3

b=AS:25.4

a=curr:qos local none

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 4390 RTP/AVP 98

C=IN IP4 192.1.3.9

b=AS:75

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

11a-12a. SIP 183 (Session Progress) response to SIP INVITE request (SCC AS to UE-1)

The SCC AS responds UE-1 with SIP 183 (Session Progress) response containing the SDP answer of UE-3.

13a-14a. SIP UPDATE request (SCC AS to UE-2) – see example in table A.9.3-9a

The SCC AS sends a SIP UPDATE request to UE-2 based on the SIP 183 (Session Progress) response from UE-3.

Table A.9.3-13a: SIP UPDATE request (SCC AS to UE-2)

UPDATE sip:user2@example1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0

Via:

Record-Route:

To: sip:user2@example1.net; tag=edfcb

From: sip:user1@example1.net;tag=acegi

Call-ID:

CSeq:

Max-Forwards:

P-Asserted-Identity: "remote user" sip:user3@example1.net

Require:

Contact: sip:user3@example1.net;gr=urn:uuid:f81d4fae-17oct-11a1-a678-0054c91eabcd

Allow:

Content-Type: application/sdp

Content-Length:(…)

v=0

o=- 1027933615 1027933615 IN IP4 192.0.2.23

s=-

t=0 0

m=audio 0 RTP/AVP 0 8 3

m=video 4390 RTP/AVP 34

a= sendrecv

c=IN IP4 192.0.2.23

b=AS:75

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

15a-16a. SIP 200 (OK) response to SIP UPDATE request (UE-2 to SCC AS)

UE-2 sends the SIP 200 (OK) response to SIP UPDATE request towards the SCC AS.

9b-10b. SIP 183 (Session Progress) response to SIP INVITE request (UE-4 to SCC AS)

The remote UE-4 responds with SIP 183 (Session Progress) response containing the SDP answer of the remote UE-4.

Table A.9.3-9b: SIP 183 (Session Progress) response (UE-4 to Intermediate IM CN subsystem entities)

SIP/2.0 183 Session Progress

Via:

Record-Route:

To: sip:user3@example1.net;tag=77777

From: sip:user1@example1.net;tag=acegi

Call-ID:

CSeq:

Max-Forwards:

P-Asserted-Identity:

Require:

Contact: sip:user3@example1.net;gr=urn:uuid:f81d4fae-17oct-11a1-a678-0054c91eabcd

Allow:

Content-Type: application/sdp

Content-Length:(…)

v=0

o=- 2987933615 2987933615 IN IP4 192.1.4.8

c=IN IP4 192.1.4.8

a=creq:ccap-v0

m=audio 3570 RTP/AVP 0 8 3

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 3580 RTP/AVP 98

C=IN IP4 192.1.4.8

b=AS:75

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

11b-12b. SIP 183 (Session Progress) response to SIP INVITE request (SCC AS to UE-1)

The SCC AS responds UE-1 with SIP 183 (Session Progress) response containing the SDP answer of UE-4.

13b. The SCC AS saves the SIP 183 (Session Progress) response when determining that the session is forked

The SCC AS determines that the call is forked according to step 10a and 10b and saves the SIP 183 message of step 10b.

14-15. SIP 200 (OK) response to the initial SIP INVITE request (UE-4 to SCC AS)

When the remote UE answers the call, UE-4 sends the SIP 200 (OK) response back to UE-1 via the SCC AS.

16-17. SIP 200 (OK) response to the initial SIP INVITE request (SCC AS to UE-1)

The SCC AS sends the SIP 200 (OK) response to UE-1.

18-19. SIP ACK request (UE-1 to SCC AS)

UE-1 sends the SIP ACK request to confirm the establishment of call to SCC AS.

20-21. SIP ACK request (SCC AS to UE-4)

SCC AS sends the SIP ACK request to UE-4.

22-23. SIP UPDATE request (SCC AS to UE-2) – see example in table A.9.3-22a

The SCC AS sends to UE-2 a SIP UPDATE request with the saved information in SIP 183 (Session Progress) response in step 13b to control the renegotiation of the video media when determining that the UE-4 has answered the call.

Table A.9.3-22a: SIP UPDATE request (SCC AS to UE-2)

UPDATE sip:user2@example1.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0

Via:

Record-Route:

To: sip:user2@example1.net;

From: sip:user1@example1.net;tag=acegi

Call-ID:

CSeq:

Max-Forwards:

P-Asserted-Identity: "remote user" sip:user3@example1.net

Require:

Contact: sip:user3@example1.net;gr=urn:uuid:f81d4fae-17oct-11a1-a678-0054c91eabcd

Allow:

Content-Type: application/sdp

Content-Length:(…)

v=0

o=- 1027933615 1027933615 IN IP4 192.0.2.23

s=-

t=0 0

m=audio 0 RTP/AVP 0 8 3

m=video 3580 RTP/AVP 98

a= sendrecv

c=IN IP4 192.1.4.8

b=AS:75

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

24-25. SIP 200 (OK) response to SIP UPDATE request (UE-2 to SCC AS)

UE-2 sends the SIP 200 (OK) response towards SCC AS.

26-27. SIP 200 (OK) response to SIP INVITE request (UE-2 to SCC AS)

UE-2 sends the SIP 200 (OK) response to the SIP INVITE request in step 4 towards SCC AS.

28-29. SIP ACK request (SCC AS to UE-2)

SCC AS sends the SIP ACK request to UE-2.

30-32. SIP CANCEL request ( Intermediate IM CN subsystem entities to UE-3)

The intermediate IM CN subsystem entities sends the SIP CANCEL request to UE-3.

33-35. SIP 200 (OK) response to SIP CANCEL request (UE-3 to Intermediate IM CN subsystem entities)

UE-3 responds SIP 200 (OK) response to the SIP CANCEL request

A.9.4 Collaborative session establishment upon terminating session setup

Figure A.9.4-1: Call flows for establishment of collaborative session upon terminating IMS session setup using SIP 300 (Multiple Choices) response

NOTE: For clarity, the SIP 100 (Trying) responses are not shown in the signalling flow.

1-2. SIP INVITE request (UE-3 to SCC AS) – see example in table A.9.4-1

The UE-3 sends SIP INVITE request to UE-1 to setup the session.

Table A.9.4-1: SIP INVITE request (UE-3 to Intermediate IM CN subsystem entities)

INVITE sip:user1@example1.net SIP/2.0

Via: SIP/2.0/UDP 192.0.2.5;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

Route: sip:pcscf1.home1.net:7531;lr;comp=sigcomp>, <sip:orig@scscf1.home1.net;lr>

P-Preferred-Identity: <sip:uesr3@example1.net>

P-Access-Network-Info:

Privacy: none

From: <sip:user3@example1.net>; tag=171828

To: <sip:user1@example1.net>

Call-ID: cb03a0s09a2sdfglkj490237

Cseq: 127 INVITE

Supported: 100rel; precondition, gruu, 199

Require: sec-agree, replaces

Proxy-Require: sec-agree

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port1=7531

Contact:<sip:user3@example1.net;gr= urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE

Accept: application/sdp; application/3gpp-ims+xml

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP4 192.0.2.5

t=0 0

c=IN IP4 192.0.2.5

m=audio 49170 RTP/AVP 0 8 3

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 28540 RTP/AVP 98

b=AS:75

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

3-4. SIP INVITE request (SCC AS to UE-1) – see example in table A.9.4-3

The SCC AS adds an Accept-Contact header field containing the media feature tag g.3gpp.iut-controller along with the explicit parameter to indicate a preference to reach a controller capable UE and also includes the MIME type application/vnd.3gpp.iut+xml to indicate that it supports the MIME type and then sends the SIP INVITE request to UE-1 to setup the session.

Table A.9.4-3: SIP INVITE request (SCC AS to Intermediate IM CN subsystem entities)

INVITE sip:user1@example1.net SIP/2.0

Via:

Max-Forwards:

Route:

P-Asserted-Identity: <sip:uesr3@example1.net>

Privacy: none

From:

To:

Cseq:

Supported:

Require:

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"

Accept-Contact: *;+g.3gpp.iut-controller;explicit

Contact:

Allow:

Accept: application/sdp; application/3gpp-ims+xml; application/vnd.3gpp.iut+xml

Content-Type:

Content-Length: (…)

5-6. SIP 300 (Multiple Choices) response to SIP INVITE request (UE-1 to SCC AS) see example in table A.18.3-5

The UE-1 responds with SIP 300 (Multiple choices) response to SCC AS including in the body the media characteristics (Audio and Video) associated with the contact addresses of UE-1 and UE-2 respectively.

Table A.9.4-5: SIP 300 (Multiple Choices) response (UE-1 to SCC-AS)

SIP/2.0 300 Multiple Choices

Via:

To:

From:

Call-ID:

CSeq:

P-Asserted-Identity: sip:user1@example.net

Contact: <sip:user1@example.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91ewxyz>,

<sip:user1@example.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>

Allow:

Content-Type=application/vnd.3gpp.iut+xml

Content-Length: (…)

<activeController=<sip:user1@example.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91ewxyz?body=m%3Daudio%2049170%20RTP%2FAVP%97%0D>/>

<controllee=<sip:user1@example.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6?body=m%3Dvideo%2028540%20RTP%2FAVP%98%0D>/>

</controlTransfer>

7-8. SIP ACK request (SCC AS to UE-1)

9. SCC AS authorizes the request for the collaborative session setup involving UE-2.

10-11. SIP 183 (session progress) response to SIP INVITE request (SCC AS to UE-3)

The SCC AS responds with SIP 183 (session progress) response to UE-3 including an SDP answer based on the media types contained in the SIP 300 (Multiple choices) response and containing the discard port number "9" for those media lines with "a=inactive".

Table A.9.4-10: SIP 183 (Session Progress) response (SCC-AS to UE-3)

SIP/2.0 183 Session Progress

Via:

To:

From:

Call-ID:

CSeq:

P-Asserted-Identity: sip:user1@example.net

Privacy:

Require:

Supported:

Contact: <sip:user1@example.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91ewxyz>

Allow:

Content-Type=application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP4 0.0.0.0

t=0 0

c=IN IP4 0.0.0.0

m=audio 9 RTP/AVP 0 8 3

a=inactive

m=video 9 RTP/AVP 98

a=inactive

12-13. SIP INVITE request (SCC AS to UE-1)- – see example in table A.9.4-12

The SCC AS sends the SIP INVITE request to initiate the audio media setup in UE-1.

Table A.9.4-12: SIP INVITE request (SCC AS to Intermediate IM CN subsystem entities)

INVITE sip:user1@example.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91ewxyz SIP/2.0

Via: SIP/2.0/UDP 192.0.2.5;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

Route:

P-Preferred-Identity: <sip:uesr3@example1.net>

P-Access-Network-Info:

Privacy: none

From: <sip:user3@example1.net>; tag=171828

To: <sip:user1@example1.net>

Call-ID: cb03a0s09a2sdfglkj490237

Cseq: 127 INVITE

Supported: 100rel; precondition, gruu, 199

Require: sec-agree, replaces

Proxy-Require: sec-agree

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port1=7531

Contact:<sip:user3@example1.net;gr= urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE

Accept: application/sdp; application/3gpp-ims+xml

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP4 192.0.2.5

t=0 0

c=IN IP4 192.0.2.5

m=audio 49170 RTP/AVP 0 8 3

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 0 RTP/AVP 98

14-15. SIP INVITE request (SCC AS to UE-2)- – see example in table A.9.4-14

The SCC AS sends the SIP INVITE request to initiate the video media setup in UE-2.

Table A.9.4-14: SIP INVITE request (SCC AS to Intermediate IM CN subsystem entities)

INVITE sip:user1@example.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6 SIP/2.0

Via: SIP/2.0/UDP 192.0.2.5;comp=sigcomp;branch=z9hG4bKnashds7

Max-Forwards: 70

Route:

P-Preferred-Identity: <sip:uesr3@example1.net>

P-Access-Network-Info:

Privacy: none

From: <sip:user3@example1.net>; tag=171828

To: <sip:user1@example1.net>

Call-ID: cb03a0s09a2sdfglkj490237

Cseq: 127 INVITE

Supported: 100rel; precondition, gruu, 199

Require: sec-agree, replaces

Proxy-Require: sec-agree

Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3gpp-service.ims.icsi.mmtel"

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-1-96; spi=87654321; port1=7531

Contact:<sip:user3@example1.net;gr= urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>;

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE

Accept: application/sdp; application/3gpp-ims+xml

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 2987933615 2987933615 IN IP4 192.0.2.5

t=0 0

c=IN IP4 192.0.2.5

m=audio 0 RTP/AVP 97

m=video 28540 RTP/AVP 98

b=AS:75

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

20-21. SIP UPDATE request (SCC AS to UE-3)- – see example in table A.9.4-20

The SCC AS then sends the SIP UPDATE request to UE-3 with the SDP answer of UE-1 and UE-2 received in the SIP 183 (session progress) responses.

Table A.9.4-20: SIP UPDATE request (SCC AS to Intermediate IM CN subsystem entities)

UPDATE sip:user3@example1.net SIP/2.0

Via:

To: sip:user3@example.net;tag = 66666

From: sip:user1@example.net; tag=33333

Call-ID:

CSeq:

Max-Forwards:

P-Asserted-Identity:

Require:

Contact: sip:user1@example.net;gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91ewxyz

Allow:

Content-Type: application/sdp

Content-Length: (…)

v=0

o=- 1027933615 1027933615 IN IP4 123.45.67.89

s=-

t=0 0

m=audio 1300 RTP/AVP 96 97

c=IN IP4 123.45.67.89

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 1500 RTP/AVP 98

c=IN IP4 123.45.67.42

b=AS:75

a=rtpmap:98 H263

a=fmtp:98 profile-level-id=0

a=rtpmap:99 MP4V-ES

22-23. SIP 200 (OK) response to SIP UPDATE request (UE-3 to SCC AS)

UE-3 sends the SIP 200 (OK) response to the SIP UPDATE request.

24-25. SIP UPDATE request (SCC AS to UE-1)

The SCC AS sends the SIP INVITE request to the UE-1 based on the SDP content in the SIP 200 (OK) response to the SIP UPDATE request received from UE-3.

26-27. SIP UPDATE request (SCC AS to UE-2)

The SCC AS sends the SIP INVITE request to the UE-2 based on the SDP content in the SIP 200 (OK) response to the SIP UPDATE request received from UE-3.

28-29. SIP 200 (OK) response to SIP UPDATE request (UE-1 to SCC AS)

30-31. SIP 200 (OK) response to SIP UPDATE request (UE-2 to SCC AS)

32-33. SIP 200 (OK) response to SIP INVITE request (UE-1 to SCC AS)

When the UE-1 answers the call, it sends the SIP 200 (OK) response to the initial SIP INVITE request.

34-35. SIP 200 (OK) response to SIP INVITE request (UE-2 to SCC AS)

When the UE-2 answers the call, it sends the SIP 200 (OK) response to the initial SIP INVITE request.

36-37. SIP 200 (OK) response to SIP INVITE request (SCC AS to UE-3)

The SCC AS sends the SIP 200 (OK) response to the UE-3.

38-39. SIP ACK request (UE-3 to SCC AS)

40-41. SIP ACK request (SCC AS to UE-1)

42-43. SIP ACK request (SCC AS to UE-2)