15 Roles for session discovery

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

15.1 Introduction

This clause specifies the session discovery procedures of the SC UE and the SCC AS.

15.2 SC UE

15.2.1 Discovery of sessions

In order to discover sessions of a user, the SC UE shall send SIP SUBSCRIBE request according to IETF RFC 4235 [3]. The SC UE shall populate the SIP SUBSCRIBE request as follows:

1. the Request-URI set to the public user identity of the user;

2. the Event header field:

a. containing the "dialog" event package name; and

b. the "include-session-description" header field parameter if the SC UE wants to obtain session descriptions;

3. the Accept-Contact header field with the g.3gpp.iut-focus media feature tag together with explicit and require; and

4. the Expires header field set to zero.

15.2.2 Discovery of collaborative session changes

In order to get the information about the collaborative session changes, the controller UE shall send SIP SUBSCRIBE request according to IETF RFC 4235 [38]. The controller UE shall populate the SIP SUBSCRIBE request as follows:

1) the Request-URI set to the Inter UE Transfer SCC AS URI;

2) the Event header field containing the "dialog" event package name and the parameter "include-session-description";

3) the Target-Dialog header field containing the dialog information of the collaborative session; and

4) the Expires header field set to:

a) zero to receive one SIP NOTIFY request; or

b) different than zero to receive the subsequent SIP NOTIFY requests.

15.3 SCC AS

15.3.1 Distinction of requests sent to the SCC AS

The SCC AS distinguish between the following initial SIP requests:

1) SIP SUBSCRIBE request containing:

a) Request-URI containing the Inter UE Transfer SCC AS SIP URI; and

b) Target-Dialog header field containing dialog information of a collaborative session belonging to the user identified by URI in the P-Asserted-Identity header field.

In the procedures below, such request is known as "SIP SUBSCRIBE request for discovery of collaborative session changes".

2) SIP SUBSCRIBE request containing:

a) Request-URI with the public user identity of a served user;

b) the Event header field with "dialog" event package name; and

c) the Accept-Contact header field with the g.3gpp.iut-focus media feature tag along with explicit and require.

In the procedures below, such request is known as "SIP SUBSCRIBE request for session discovery".

Other SIP SUBSCRIBE requests can be dealt with in any manner conformant with 3GPP TS 24.229 [7].

15.3.2 SCC AS procedures for discovery of sessions

When the SCC AS receives a SIP SUBSCRIBE request for session discovery, the SCC AS shall:

1. if the subscriber is not authorized to receive the dialog information of the user identified by Request-URI, then reject the SIP request with a SIP 403 (Forbidden) response and do not process the remaining steps; and

2. handle the SIP request according to IETF RFC 4235 [38] and 3GPP TS 24.229 [7].

15.3.3 SCC AS procedures for discovery of collaborative session changes

When the SCC AS receives a SIP SUBSCRIBE request for discovery of collaborative session changes, the SCC AS shall handle the SIP request according to IETF RFC 4235 [38].