A.14 Signalling flows for session discovery

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.14.1 Introduction

The signalling flows for discovery of sessions demonstrate how a UE can discover sessions of other subscriber. The following signalling flows are included:

– subclause A.14.2 shows an example when a UE discovers sessions of other subscriber of the same PLMN.

– subclause A.14.3 shows an example when a UE discovers sessions of other subscriber of the same PLMN including session descriptions.

A.14.2 Discovery of sessions of another user of different IMS subscription

In the example flow at the figure A.14.2-1, UE-1 has an ongoing multimedia session with UE-3 anchored at SCC AS-1. UE-1 and UE-2 belong to different subscribers.

Figure A.14.2-1: Discovery of sessions of user at other UE

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 decides to discover sessions of user at UE-1

4-7. SIP SUBSCRIBE request (from UE-2 to SCC AS-1) – see example in table A.14.2-4

The UE-2 sends a SIP SUBSCRIBE request to fetch the dialog information of the dialogs of user at UE-1. SCC AS-2 is invoked upon originating initial filter criteria but since Request-URI does not contain a URI owned by SCC AS-2, the SCC AS-2 forwards the request.

Table A.14.2-4: SIP SUBSCRIBE request

SUBSCRIBE sip:user1@home1.net SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:fff]:1357;comp=sigcomp;branch=z9hG4bKnashds7664

P-Preferred-Identity: <sip:user2@home1.net>

From: <sip:user2@home1.net>;tag=171828

To: <sip:user1@home1.net>

Call-ID: tq34gasgaeg335r

Event: dialog

CSeq: 145454 SUBSCRIBE

Max-Forwards: 70

Expires: 0

Contact: <sip:user2@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-2222-222222222222>

Accept: application/dialog-info+xml

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

Content-Length: 0

8-11. SIP 202 (Accepted) response (from SCC AS-1 to UE-2)

Since the request is addressed to a user served by SCC AS-1 and since the request contains the g.3gpp.iut-focus media feature tag in the Accept-Contact header field, the SCC AS-1 acknowledges the SIP SUBSCRIBE request by sending a SIP 202 (Accepted) response.

12-15. SIP NOTIFY request (from SCC AS-1 to UE-2) – see example in table A.14.2-12

The SCC AS-1 sends a SIP NOTIFY request containing the dialog information related to dialogs between the SCC AS-1 and the UEs of the subscribed user.

Table A.14.2-12: SIP NOTIFY request

NOTIFY sip:user2@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-2222-222222222222 SIP/2.0

Via:

To: <sip:user2@home1.net>;tag=171828

From: <sip:user1@home1.net>;tag=eerr

Call-ID:

CSeq:

Max-Forwards:

P-Asserted-Identity:

Require:

Contact: sip:sccas1.home1.example.net

Allow:

Event: dialog

Content-Type: application/dialog-info+xml

Content-Length: (…)

<?xml version="1.0"?>

<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"

version="0"

state="full"

entity="sip:user1@home1.net">

<state>confirmed</state>

<local>

<identity>sip:remoteuser@home2.net</identity>

</target>

</local>

</target>

</remote>

</dialog>

</dialog-info>

16-19. SIP 200 (OK) response (from UE-2 to SCC AS-1)

The UE-2 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to SCC AS-1.

A.14.3 Discovery of sessions of another user of different IMS subscription including session descriptions

In the example flow at the figure A.14.3-1, UE-1 has an ongoing multimedia session with UE-3 anchored at SCC AS-1. UE-1 and UE-2 belong to different subscribers.

Figure A.14.3-1: Discovery of sessions of user at other UE including session descriptions

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

3. UE-2 decides to discover sessions of user at UE-1 including session descriptions

4-7. SIP SUBSCRIBE request (from UE-2 to SCC AS-1) – see example in table A.14.3-4

The UE-2 sends a SIP SUBSCRIBE request to fetch the dialog information of the dialogs of user at UE-1. The UE-2 adds the ‘include-session-description’ header field parameter to the Event header field. SCC AS-2 is invoked upon originating initial filter criteria but since Request-URI does not contain a URI owned by SCC AS-2, the SCC AS-2 forwards the request.

Table A.14.3-4: SIP SUBSCRIBE request

SUBSCRIBE sip:user1@home1.net SIP/2.0

Via: SIP/2.0/UDP [5555::aaa:bbb:ccc:fff]:1357;comp=sigcomp;branch=z9hG4bKnashds7664

P-Preferred-Identity: <sip:user2@home1.net>

From: <sip:user2@home1.net>;tag=171828

To: <sip:user1@home1.net>

Call-ID: tq34gasgaeg335r

Event: dialog; include-session-description

CSeq: 145454 SUBSCRIBE

Max-Forwards: 70

Expires: 0

Contact: <sip:user2@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-2222-222222222222>

Accept: application/dialog-info+xml

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

Content-Length: 0

8-11. SIP 202 (Accepted) response (from SCC AS-1 to UE-2)

12-15. SIP NOTIFY request (from SCC AS-1 to UE-2) – see example in table A.14.3-12

The SCC AS-1 sends a SIP NOTIFY request containing the dialog information related to dialogs between the SCC AS-1 and the UEs of the subscribed user.

Table A.14.3-12: SIP NOTIFY request

NOTIFY sip:user2@home1.net;gr=urn:uuid:f81d4fae-7dec-11d0-2222-222222222222 SIP/2.0

Via:

To: <sip:user2@home1.net>;tag=171828

From: <sip:user1@home1.net>;tag=eerr

Call-ID:

CSeq:

Max-Forwards:

P-Asserted-Identity:

Require:

Contact: sip:sccas1.home1.example.net

Allow:

Event: dialog

Content-Type: application/dialog-info+xml

Content-Length: (…)

<?xml version="1.0"?>

<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"

version="0"

state="full"

entity="sip:user1@home1.net">

<state>confirmed</state>

<local>

<identity>sip:remoteuser@home2.net</identity>

</target>

<session-description type="application/sdp">

v=0

o=- 1027933615 1027933615 IN IP4 132.54.76.98

s=-

t=0 0

m=audio 49174 RTP/AVP 96 97

c=IN IP4 132.54.76.98

b=AS:25.4

a=rtpmap:96 AMR

a=fmtp:96mode-set=0,2,5,7; mode-change-period=2

a=rtpmap:97 telephone-event

a=maxptime:20

m=video 1009 RTP/AVP 98 99

c=IN IP4 132.54.76.98

a=sendonly

b=AS:75

a=rtpmap:98 H263

a=fmtp:98 H263

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

a=rtpmap:99 MP4V-ES

</session-description>

</local>

</target>

<session-description type="application/sdp">

v=0

o=- 1027933615 1027933615 IN IP4 123.45.67.89

s=-

t=0 0

m=audio 49174 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 1009 RTP/AVP 98 99

c=IN IP4 123.45.67.89

a=sendonly

b=AS:75

a=rtpmap:98 H263

a=fmtp:98 H263

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

a=rtpmap:99 MP4V-ES

</session-description>

</remote>

</dialog>

</dialog-info>

16-19. SIP 200 (OK) response (from UE-2 to SCC AS-1)

The UE-2 acknowledges the SIP NOTIFY request by sending a SIP 200 (OK) response to SCC AS-1.