4 System Description

26.2233GPPMedia handling and interactionRelease 18Telepresence using the IP Multimedia Subsystem (IMS)TS

4.1 Overview

The use cases and requirements on IMS-based telepresence are defined in TS 22.228 [3] to enable telepresence support in IMS applications.

Enabling telepresence support involves updating and enhancing the existing IMS procedures for point-to-point calls as specified in 3GPP TS 24.229 [4] and for multiparty conferences as specified 3GPP TS 24.147 [5]. This has been addressed in 3GPP TS 24.103 [6], which incorporates IETF’s ControLling mUltiple streams for tElepresence (CLUE) framework [7]-[10] with the Session Initiation Protocol (SIP), Session Description Protocol (SDP) and Binary Floor Control Protocol (BFCP) to facilitate controlling multiple spatially related media streams in an IM session supporting telepresence.

In order to provide a "being there" experience for conversational audio and video telepresence sessions between remote locations, where the users enjoy a strong sense of realism and presence, capabilities and preferences need to be co-ordinated and negotiated between local and remote participants such as:

– audio and video spatial composition information; e.g. spatial relationship of two or more objects (audio/video sources) in the same room to allow for accurate reproduction on the receiver side

– capabilities of cameras, screens, microphones and loudspeakers, and their relative spatial relationships

– meeting description, such as view information, language information, participant information, participant type, etc.

CLUE achieves media advertisement and configuration to facilitate controlling and negotiating multiple spatially related media streams in an IMS conference supporting telepresence, taking into account capability information, e.g. screen size, number of screens and cameras, codecs, etc., so that sending system, receiving system, or intermediate system can make decisions about transmitting, selecting, and rendering media streams. With the establishment of the CLUE data channel, the participants have consented to use the CLUE protocol mechanisms to determine the capabilities of the each of the endpoints with respect to multiple streams support, via the exchange of an XML-based data format. The exchange of CLUE messages of each participant’s "advertisement" and "configure" is to achieve a common view of media components sent and received in the IM session supporting telepresence.

TS 24.103 [6] specifies procedures to deal with multiple spatially related media streams according to the CLUE framework to support telepresence and to interwork with IM session as below:

1) Initiation of telepresence using IMS, which includes an initial offer/answer exchange establishes a basic media session and a CLUE channel, CLUE exchanges to "advertisement" and "configure" media components used in the session, then followed by an SDP offer/answer in Re-INVITE request to complete the session establishment (see more for the general idea in IETF RFC 8845 [7]);

2) Release or leaving of an IM session supporting telepresence, which needs remove the corresponding CLUE channel;

3) Update of an ongoing IM session supporting telepresence, triggered by CLUE exchanges modifying existing CLUE information. For example: a new participant at an endpoint may require the establishment of a specific media stream;

4) Presentation during an IM session supporting telepresence, which may also be initiated by the exchange of CLUE messages and possibly need an updated SDP offer/answer and activation of BFCP for floor control; and

5) Interworking with normal IM session, this is to let the normal IMS users be able to join telepresence using IMS.

4.2 TP UE

A TP UE shall support functional components and user plane protocol stack of an MTSI client as specified in clause 4.2 of TS 26.114 [2]. Moreover, a TP UE shall support the data channel capabilities of a DCMTSI client as described in clause 6.2.10 of TS 26.114 [2]. However, the DCMTSI client support for ‘bootstrap data channels’ described in clause 6.2.10 of TS 26.114 [2] is not expected from TP UEs.

A TP UE shall use the IMS data channel capability of a DCMTSI client for the exchange of CLUE messages based on DTLS/SCTP (Datagram Transport Layer Security over Stream Control Transmission Protocol) [13] negotiated via the initial SDP offer and answer, in order to open the CLUE data channel based on a SCTP stream in each direction, following IETF RFC 8864 [14].

A TP UE offers a DTLS/SCTP association together with the media format indicating the use of a data channel in the first SDP offer or subsequent SDP offers. A TP UE can further open the data channel via the SDP-based "SCTP over DTLS" data channel negotiation mechanism to indicate specific non-conversational application (e.g. CLUE protocol) over it.

The protocol stack of a TP UE with CLUE data channel is shown in Figure 4.1.

Figure 4.1: Protocol stack of a TP UE