Advertisement:

A CLUE message a Media Provider sends to a Media Consumer describing specific aspects of the content of the Media and any restrictions it has in terms of being able to provide certain Streams simultaneously.

Audio Capture (AC):

Media Capture for audio. Denoted as "ACn" in the examples in this document.

Capture:

Same as Media Capture.

Capture Device:

A device that converts physical input, such as audio, video, or text, into an electrical signal, in most cases to be fed into a Media encoder.

Capture Encoding:

A specific Encoding of a Media Capture, to be sent by a Media Provider to a Media Consumer via RTP.

Capture Scene:

A structure representing a spatial region captured by one or more Capture Devices, each capturing Media representing a portion of the region. The spatial region represented by a Capture Scene may correspond to a real region in physical space, such as a room. A Capture Scene includes attributes and one or more Capture Scene Views, with each view including one or more Media Captures.

Capture Scene View (CSV):

A list of Media Captures of the same Media type that together form one way to represent the entire Capture Scene.

CLUE:

CLUE is an acronym for "ControLling mUltiple streams for tElepresence", which is the name of the IETF working group in which this document and certain companion documents have been developed. Often, CLUE-* refers to something that has been designed by the CLUE working group; for example, this document may be called the CLUE-framework document herein and elsewhere.

CLUE-capable device:

A device that supports the CLUE data channel [RFC 8850], the CLUE protocol [RFC 8847] and the principles of CLUE negotiation; it also seeks CLUE-enabled calls.

CLUE-enabled call:

A call in which two CLUE-capable devices have successfully negotiated support for a CLUE data channel in SDP [RFC 4566]. A CLUE-enabled call is not necessarily immediately able to send CLUE-controlled Media; negotiation of the data channel and of the CLUE protocol must complete first. Calls between two CLUE-capable devices that have not yet successfully completed negotiation of support for the CLUE data channel in SDP are not considered CLUE-enabled.

Conference:

Used as defined in "A Framework for Conferencing within the Session Initiation Protocol (SIP)" [RFC 4353].

Configure Message:

A CLUE message a Media Consumer sends to a Media Provider specifying which content and Media Streams it wants to receive, based on the information in a corresponding Advertisement message.

Consumer:

Short for Media Consumer.

Encoding:

Short for Individual Encoding.

Encoding Group:

A set of Encoding parameters representing a total Media Encoding capability to be subdivided across potentially multiple Individual Encodings.

Endpoint:

A CLUE-capable device that is the logical point of final termination through receiving, decoding and Rendering, and/or initiation through capturing, encoding, and sending of Media Streams. An Endpoint consists of one or more physical devices that source and sink Media Streams, and exactly one [RFC 4353] Participant (which, in turn, includes exactly one SIP User Agent). Endpoints can be anything from multiscreen/multicamera rooms to handheld devices.

Global View:

A set of references to one or more CSVs of the same Media type that are defined within Scenes of the same Advertisement. A Global View is a suggestion from the Provider to the Consumer for one set of CSVs that provide a useful representation of all the Scenes in the Advertisement.

Global View List:

A list of Global Views included in an Advertisement. A Global View List may include Global Views of different Media types.

Individual Encoding:

a set of parameters representing a way to encode a Media Capture to become a Capture Encoding.

Multipoint Control Unit (MCU):

a CLUE-capable device that connects two or more Endpoints into one single multimedia Conference [RFC 7667]. An MCU includes a Mixer like that described in [RFC 4353], without the requirement of [RFC 4353] to send Media to each participant.

Media:

Any data that, after suitable encoding, can be conveyed over RTP, including audio, video, or timed text.

Media Capture (MC):

A source of Media, such as from one or more Capture Devices or constructed from other Media Streams.

Media Consumer:

A CLUE-capable device that intends to receive Capture Encodings.

Media Provider:

A CLUE-capable device that intends to send Capture Encodings.

Multiple Content Capture (MCC):

A Capture that mixes and/or switches other Captures of a single type (for example, all audio or all video). Particular Media Captures may or may not be present in the resultant Capture Encoding, depending on time or space. Denoted as "MCCn" in the example cases in this document.

Plane of Interest:

The spatial plane within a Scene containing the most-relevant subject matter.

Provider:

Same as a Media Provider.

Render:

The process of generating a representation from Media, such as displayed motion video or sound emitted from loudspeakers.

Scene:

Same as a Capture Scene.

Simultaneous Transmission Set:

A set of Media Captures that can be transmitted simultaneously from a Media Provider.

Single Media Capture:

A Capture that contains Media from a single source Capture Device, e.g., an Audio Capture from a single microphone or a Video Capture from a single camera.

Spatial Relation:

The arrangement of two objects in space, in contrast to relation in time or other relationships.

Stream:

A Capture Encoding sent from a Media Provider to a Media Consumer via RTP [RFC 3550].

Stream Characteristics:

The Media Stream attributes commonly used in non-CLUE SIP/SDP environments (such as Media codec, bitrate, resolution, profile/level, etc.) as well as CLUE-specific attributes, such as the Capture ID or a spatial location.

Video Capture (VC):

Media Capture for video. Denoted as VCn in the example cases in this document.

Video Composite:

A single image that is formed, normally by an RTP mixer inside an MCU, by combining visual elements from separate sources.

(1)

Endpoints in telepresence systems typically have multiple Media Capture and Media Render devices, e.g., multiple cameras and screens. While previous system designs were able to set up calls that would capture Media using all cameras and display Media on all screens, for example, there was no mechanism that could associate these Media Captures with each other in space and time, in a cross-vendor interoperable way.

(2)

The mere fact that there are multiple Media Capture and Media Render devices, each of which may be configurable in aspects such as zoom, leads to the difficulty that a variable number of such devices can be used to capture different aspects of a region. The Capture Scene concept allows for the description of multiple setups for those multiple Media Capture devices that could represent sensible operation points of the physical Capture Devices in a room, chosen by the operator. A Consumer can pick and choose from those configurations based on its rendering abilities and then inform the Provider about its choices. Details are provided in Section 7.

(3)

In some cases, physical limitations or other reasons disallow the concurrent use of a device in more than one setup. For example, the center camera in a typical three-camera conference room can set its zoom objective to capture either the middle few seats only or all seats of a room, but not both concurrently. The Simultaneous Transmission Set concept allows a Provider to signal such limitations. Simultaneous Transmission Sets are part of the Capture Scene description and are discussed in Section 8.

(4)

Often, the devices in a room do not have the computational complexity or connectivity to deal with multiple Encoding options simultaneously, even if each of these options is sensible in certain scenarios, and even if the simultaneous transmission is also sensible (i.e., in case of multicast Media distribution to multiple Endpoints). Such constraints can be expressed by the Provider using the Encoding Group concept, which is described in Section 9.

(5)

Due to the potentially large number of RTP Streams required for a Multimedia Conference involving potentially many Endpoints, each of which can have many Media Captures and Media renderers, it has become common to multiplex multiple RTP Streams onto the same transport address, so as to avoid using the port number as a multiplexing point and the associated shortcomings such as NAT/firewall traversal. The large number of possible permutations of sensible options a Media Provider can make available to a Media Consumer makes a mechanism desirable that allows it to narrow down the number of possible options that a SIP offer/answer exchange has to consider. Such information is made available using protocol mechanisms specified in this document and companion documents. The Media Provider and Media Consumer may use information in CLUE messages to reduce the complexity of SIP offer/answer messages. Also, there are aspects of the control of both Endpoints and MCUs that dynamically change during the progress of a call, such as audio-level-based screen switching, layout changes, and so on, which need to be conveyed. Note that these control aspects are complementary to those specified in traditional SIP-based conference management, such as Binary Floor Control Protocol (BFCP). An exemplary call flow can be found in Section 5.

• Each Capture Scene has a distinct coordinate system, unrelated to the coordinate systems of other Scenes.
• Simple systems that do not have multiple Media Captures to associate spatially need not use the coordinate model, although it can still be useful to provide an Area of Capture.
• Coordinates can either be in real, physical units (millimeters), have an unknown scale, or have no physical scale. Systems that know their physical dimensions (for example, professionally installed Telepresence room systems) MUST provide those real-world measurements to enable the best user experience for advanced receiving systems that can utilize this information. Systems that don't know specific physical dimensions but still know relative distances MUST use "Unknown Scale". "No Scale" is intended to be used only where Media Captures from different devices (with potentially different scales) will be forwarded alongside one another (e.g., in the case of an MCU).
  • "Millimeters" means the scale is in millimeters.
  • "Unknown Scale" means the scale is not necessarily in millimeters, but the scale is the same for every Capture in the Capture Scene.
  • "No Scale" means the scale could be different for each Capture -- an MCU Provider that advertises two adjacent Captures and picks sources (which can change quickly) from different Endpoints might use this value; the scale could be different and changing for each Capture. But the areas of capture still represent a Spatial Relation between Captures.
• The coordinate system is right-handed Cartesian X, Y, Z with the origin at a spatial location of the Provider's choosing. The Provider MUST use the same coordinate system with the same scale and origin for all coordinates within the same Capture Scene.

• It can represent the immediate output of a physical source (e.g., camera, microphone) or 'synthetic' source (e.g., laptop computer, DVD player).
• It can represent the output of an audio mixer or video composer.
• It can represent a concept such as 'the loudest speaker'.
• It can represent a conceptual position such as 'the leftmost Stream'.

• A Media Capture is of a single Media type (e.g., audio or video).
• A Media Capture is defined in a Capture Scene and is given an Advertisement unique identity. The identity may be referenced outside the Capture Scene that defines it through an MCC.
• A Media Capture may be associated with one or more CSVs.
• A Media Capture has exactly one set of spatial information.
• A Media Capture can be the source of at most one Capture Encoding.

• Spatial information, such as Point of Capture, Point on Line of Capture, and Area of Capture, (all of which, in combination, define the capture field of, for example, a camera).
• Other descriptive information to help the Consumer choose between Captures (e.g., description, presentation, view, priority, language, person information, and type).

Room:

Captures the entire Scene

Table:

Captures the conference table with seated people

Individual:

Captures an individual person

Lectern:

Captures the region of the lectern including the presenter, for example, in a classroom-style conference room

Audience:

Captures a region showing the audience in a classroom-style conference room

Chair:

the person responsible for running the meeting according to the agenda.

Vice-Chair:

the person responsible for assisting the chair in running the meeting.

Minute Taker:

the person responsible for recording the minutes of the meeting.

Attendee:

the person has no particular responsibilities with respect to running the meeting.

Observer:

an Attendee without the right to influence the discussion.

Presenter:

the person scheduled on the agenda to make a presentation in the meeting. Note: This is not related to any "active speaker" functionality.

Translator:

the person providing some form of translation or commentary in the meeting.

Timekeeper:

the person responsible for maintaining the meeting schedule.

• A switched case occurs when MaxCaptures is set to <= 1 and the number of Captures in the MCC is greater than 1 (or not specified) in the MCC. Zero or one Captures may be switched into the Capture Encoding. Note: zero is allowed because of the "<=".
• A switched case occurs when MaxCaptures is set to = 1 and the number of Captures in the MCC is greater than 1 (or not specified) in the MCC. Only one Capture source is contained in a Capture Encoding at a time.
• A switched and composed case occurs when MaxCaptures is set to <= N (with N > 1) and the number of Captures in the MCC is greater than N (or not specified). The Capture Encoding may contain purely switched sources (i.e., <=2 allows for one source on its own), or it may contain composed and switched sources (i.e., a composition of two sources switched between the sources).
• A switched and composed case occurs when MaxCaptures is set to = N (with N > 1) and the number of Captures in the MCC is greater than N (or not specified). The Capture Encoding contains composed and switched sources (i.e., a composition of N sources switched between the sources). It is not possible to have a single source.
• A switched and composed case occurs when MaxCaptures is set <= to the number of Captures in the MCC. The Capture Encoding may contain Media switched between any number (up to the MaxCaptures) of composed sources.
• A composed case occurs when MaxCaptures is set = to the number of Captures in the MCC. All the sources are composed into a single Capture Encoding.

SoundLevel:

This indicates that the content of the MCC is determined by a sound-level-detection algorithm. The loudest (active) speaker (or a previous speaker, depending on the index value) is contained in the MCC.

RoundRobin:

This indicates that the content of the MCC is determined by a time-based algorithm. For example, the Provider provides content from a particular source for a period of time and then provides content from another source, and so on.

1. (VC0, VC1, VC2) - left, center, and right camera Video Captures
2. (MCC3) - Video Capture associated with loudest room segment
3. (VC4) - Video Capture zoomed out view of all people in the room
4. (AC0) - main audio

• Human-readable description of the Capture Scene, which could be in multiple languages;
• xCard Scene information
• Scale information ("Millimeters", "Unknown Scale", "No Scale"), as described in Section 6.

• A human-readable description (which could be in multiple languages) of the CSV.

• The ordering of Global Views in the Global View list is insignificant.
• The ordering of CSVs within each Global View is insignificant.
• A particular CSV may be used in multiple Global Views.
• The Provider must be capable of encoding and sending all Captures within the CSVs of a given Global View simultaneously.

   ........................................................
   . Advertisement                                        .
   .                                                      .
   . +--------------+         +-------------------------+ .
   . |Scene 1       |         |Global View List         | .
   . |              |         |                         | .
   . | CSV1 (v)<----------------- Global View (CSV 1)   | .
   . |         <-------.      |                         | .
   . |              |  *--------- Global View (CSV 1,5) | .
   . | CSV2 (v)     |  |      |                         | .
   . |              |  |      |                         | .
   . | CSV3 (v)<---------*------- Global View (CSV 3,5) | .
   . |              |  | |    |                         | .
   . | CSV4 (a)<----------------- Global View (CSV 4)   | .
   . |         <-----------.  |                         | .
   . +--------------+  | | *----- Global View (CSV 4,6) | .
   .                   | | |  |                         | .
   . +--------------+  | | |  +-------------------------+ .
   . |Scene 2       |  | | |                              .
   . |              |  | | |                              .
   . | CSV5 (v)<-------' | |                              .
   . |         <---------' |                              .
   . |              |      |        (v) = video           .
   . | CSV6 (a)<-----------'        (a) = audio           .
   . |              |                                     .
   . +--------------+                                     .
   `......................................................'

• Maximum bandwidth;
• Maximum picture size in pixels;
• Maximum number of pixels to be processed per second;

• Maximum bitrate for all Encodings in the group combined;
• A list of identifiers for the Individual Encodings belonging to the group.

,-------------------------------------------------.
|             Media Provider                      |
|                                                 |
|  ,--------------------------------------.       |
|  | ,--------------------------------------.     |
|  | | ,--------------------------------------.   |
|  | | |          Encoding Group              |   |
|  | | | ,-----------.                        |   |
|  | | | |           | ,---------.            |   |
|  | | | |           | |         | ,---------.|   |
|  | | | | Encoding1 | |Encoding2| |Encoding3||   |
|  `.| | |           | |         | `---------'|   |
|    `.| `-----------' `---------'            |   |
|      `--------------------------------------'   |
`-------------------------------------------------'

• The Consumer would understand that the MCC is a Capture that includes the referenced individual Captures (or any Captures, if none are referenced) and that these individual Captures are delivered as part of the MCC's Capture Encoding.
• The Consumer may utilize any of the attributes associated with the referenced individual Captures and any Capture Scene attributes from where the individual Captures were defined to choose Captures and for Rendering decisions.
• If the MCC attribute Allow Subset Choice is true, then the Consumer may or may not choose to receive all the indicated Captures. It can choose to receive a subset of Captures indicated by the MCC.

• If the Consumer is an Endpoint, it is likely that it would choose, where possible, to receive Video and Audio Captures that match the number of display devices and audio system it has.
• If the Consumer is an MCU, it may choose to receive loudest speaker Streams (in order to perform its own Media composition) and avoid pre-composed Video Captures.
• User choice (for instance, selection of a new layout) may result in a different set of Captures, or different Encoding characteristics, being required by the Consumer.

• Adding more types of Media, such as telemetry, can done by defining additional types of Captures in addition to audio and video.
• Adding new functionalities, such as 3-D Video Captures, may require additional attributes describing the Captures.

• Each camera can provide one Capture for each 1/3-section of the table.
• A single Capture representing the active speaker can be provided (voice-activity-based camera selection to a given encoder input port implemented locally in the Endpoint).
• A single Capture representing the active speaker with the other two Captures shown picture in picture (PiP) within the Stream can be provided (again, implemented inside the Endpoint).
• A Capture showing a zoomed out view of all six seats in the room can be provided.

VC0

(the left camera Stream), Encoding Group=EG0, view=table

VC1

(the center camera Stream), Encoding Group=EG1, view=table

VC2

(the right camera Stream), Encoding Group=EG2, view=table

MCC3

(the loudest panel Stream), Encoding Group=EG1, view=table, MaxCaptures=1, policy=SoundLevel

MCC4

(the loudest panel Stream with PiPs), Encoding Group=EG1, view=room, MaxCaptures=3, policy=SoundLevel

VC5

(the zoomed out view of all people in the room), Encoding Group=EG1, view=room

VC6

(presentation Stream), Encoding Group=EG1, presentation

   ,-. d
  (   )`--.__        +---+
   `-' /     `--.__  |   |
 ,-.  |            `-.._ |_-+Camera 2 (VC2)
(   ).'     <--(AC1)-+-''`+-+
 `-' |_...---''      |   |
 ,-.c+-..__          +---+
(   )|     ``--..__  |   |
 `-' |             ``+-..|_-+Camera 1 (VC1)
 ,-. |      <--(AC2)..--'|+-+                          ^
(   )|     __..--'   |   |                             |
 `-'b|..--'          +---+                             |X
 ,-. |``---..___     |   |                             |
(   )\          ```--..._|_-+Camera 0 (VC0)            |
 `-'  \     <--(AC0) ..-''`-+                          |
  ,-. \      __.--'' |   |                  <----------+
 (   ) |..-''        +---+                     Y
  `-' a                          (0,0,0) origin is under Camera 1

    bottom left    bottom right  top left         top right
VC0 (-2011,2850,0) (-673,3000,0) (-2011,2850,757) (-673,3000,757)
VC1 ( -673,3000,0) ( 673,3000,0) ( -673,3000,757) ( 673,3000,757)
VC2 (  673,3000,0) (2011,2850,0) (  673,3000,757) (2011,3000,757)
MCC3(-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757)
MCC4(-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757)
VC5 (-2011,2850,0) (2011,2850,0) (-2011,2850,757) (2011,3000,757)
VC6 none

VC0 (-1678,0,800)
VC1 (0,0,800)
VC2 (1678,0,800)
MCC3 none
MCC4 none
VC5 (0,0,800)
VC6 none

• AC0 (left), Encoding Group=EG3
• AC1 (right), Encoding Group=EG3
• AC2 (center), Encoding Group=EG3
• AC3 being a simple pre-mixed audio Stream from the room (mono), Encoding Group=EG3
• AC4 audio Stream associated with the presentation video (mono) Encoding Group=EG3, presentation

Point of Capture:           Point on Line of Capture:
AC0 (-1342,2000,800)       (-1342,2925,379)
AC1 ( 1342,2000,800)       ( 1342,2925,379)
AC2 (    0,2000,800)       (    0,3000,379)
AC3 (    0,2000,800)       (    0,3000,379)
AC4 none

encodeGroupID=EG0, maxGroupBandwidth=6000000
    encodeID=ENC0, maxWidth=1920, maxHeight=1088, maxFrameRate=60,
                   maxPps=124416000, maxBandwidth=4000000
    encodeID=ENC1, maxWidth=1280, maxHeight=720, maxFrameRate=30,
                   maxPps=27648000, maxBandwidth=4000000
    encodeID=ENC2, maxWidth=960, maxHeight=544, maxFrameRate=30,
                   maxPps=15552000, maxBandwidth=4000000
encodeGroupID=EG1  maxGroupBandwidth=6000000
    encodeID=ENC3, maxWidth=1920, maxHeight=1088, maxFrameRate=60,
                   maxPps=124416000, maxBandwidth=4000000
    encodeID=ENC4, maxWidth=1280, maxHeight=720, maxFrameRate=30,
                   maxPps=27648000, maxBandwidth=4000000
    encodeID=ENC5, maxWidth=960, maxHeight=544, maxFrameRate=30,
                   maxPps=15552000, maxBandwidth=4000000
encodeGroupID=EG2  maxGroupBandwidth=6000000
    encodeID=ENC6, maxWidth=1920, maxHeight=1088, maxFrameRate=60,
                   maxPps=124416000, maxBandwidth=4000000
    encodeID=ENC7, maxWidth=1280, maxHeight=720, maxFrameRate=30,
                   maxPps=27648000, maxBandwidth=4000000
    encodeID=ENC8, maxWidth=960, maxHeight=544, maxFrameRate=30,
                   maxPps=15552000, maxBandwidth=4000000

encodeGroupID=EG3, maxGroupBandwidth=320000
    encodeID=ENC9, maxBandwidth=64000
    encodeID=ENC10, maxBandwidth=64000
    encodeID=ENC11, maxBandwidth=64000
    encodeID=ENC12, maxBandwidth=64000
    encodeID=ENC13, maxBandwidth=64000

1. Fall back to receiving just a single Stream (MCC3, MCC4, or VC5 as per the one-screen Consumer case above) and either leave one screen blank or use it for presentation if/when a presentation becomes active.
2. Receive three Streams (VC0, VC1, and VC2) and display across two screens (either with each Capture being scaled to 2/3 of a screen and the center Capture being split across two screens), or, as would be necessary if there were large bezels on the screens, with each Stream being scaled to 1/2 the screen width and height and there being a fourth "blank" panel. This fourth panel could potentially be used for any presentation that became active during the call.
3. Receive three Streams, decode all three, and use control information indicating which was the most active to switch between showing the left and center Streams (one per screen) and the center and right Streams.

Endpoint A -

4 screens, 3 cameras

Endpoint B -

3 screens, 3 cameras

Endpoint C -

3 screens, 3 cameras

Endpoint D -

3 screens, 3 cameras

Endpoint E -

1 screen, 1 camera

Endpoint F -

2 screens, 1 camera

Endpoint G -

1 screen, 1 camera

   +---+---+---+ +-------------+ +-------------+ +-------------+
   |   |   |   | |             | |             | |             |
   +---+---+---+ |             | |             | |             |
   |   |   |   | |             | |             | |             |
   +---+---+---+ |             | |             | |             |
   |   |   |   | |             | |             | |             |
   +---+---+---+ +-------------+ +-------------+ +-------------+

           +-------------+ +-------------+ +-------------+
           |             | |             | |             |
           |             | |             | |             |
           |             | |             | |             |
           | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ |
           | +-+ +-+ +-+ | | +-+ +-+ +-+ | | +-+ +-+ +-+ |
           +-------------+ +-------------+ +-------------+

Endpoint A -

3 screens, 3 cameras

Endpoint B -

3 screens, 3 cameras

Endpoint C -

1 screen, 1 camera

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC3261]

J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002,
<https://www.rfc-editor.org/info/rfc3261>.

[RFC3264]

J. Rosenberg, and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, June 2002,
<https://www.rfc-editor.org/info/rfc3264>.

[RFC3550]

H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, July 2003,
<https://www.rfc-editor.org/info/rfc3550>.

[RFC4566]

M. Handley, V. Jacobson, and C. Perkins, "SDP: Session Description Protocol", RFC 4566, DOI 10.17487/RFC4566, July 2006,
<https://www.rfc-editor.org/info/rfc4566>.

[RFC4579]

A. Johnston, and O. Levin, "Session Initiation Protocol (SIP) Call Control - Conferencing for User Agents", BCP 119, RFC 4579, DOI 10.17487/RFC4579, August 2006,
<https://www.rfc-editor.org/info/rfc4579>.

[RFC5239]

M. Barnes, C. Boulton, and O. Levin, "A Framework for Centralized Conferencing", RFC 5239, DOI 10.17487/RFC5239, June 2008,
<https://www.rfc-editor.org/info/rfc5239>.

[RFC5646]

A. Phillips, and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009,
<https://www.rfc-editor.org/info/rfc5646>.

[RFC6350]

S. Perreault, "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011,
<https://www.rfc-editor.org/info/rfc6350>.

[RFC6351]

S. Perreault, "xCard: vCard XML Representation", RFC 6351, DOI 10.17487/RFC6351, August 2011,
<https://www.rfc-editor.org/info/rfc6351>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8846]

R Presta, and S P. Romano, "An XML Schema for the Controlling Multiple Streams for Telepresence (CLUE) Data Model", RFC 8846, DOI 10.17487/RFC8846, January 2021,
<http://www.rfc-editor.org/info/rfc8846>.

[RFC8847]

R Presta, and S P. Romano, "Protocol for Controlling Multiple Streams for Telepresence (CLUE)", RFC 8847, DOI 10.17487/RFC8847, January 2021,
<https://www.rfc-editor.org/info/rfc8847>.

[RFC8848]

R Hanton, P Kyzivat, L Xiao, and C Groves, "Session Signaling for Controlling Multiple Streams for Telepresence (CLUE)", RFC 8848, DOI 10.17487/RFC8848, January 2021,
<https://www.rfc-editor.org/info/rfc8848>.

[RFC8850]

C. Holmberg, "Controlling Multiple Streams for Telepresence (CLUE) Protocol Data Channel", RFC 8850, DOI 10.17487/RFC8850, January 2021,
<https://www.rfc-editor.org/info/rfc8850>.

[RFC4353]

J. Rosenberg, "A Framework for Conferencing with the Session Initiation Protocol (SIP)", RFC 4353, DOI 10.17487/RFC4353, February 2006,
<https://www.rfc-editor.org/info/rfc4353>.

[RFC7201]

M. Westerlund, and C. Perkins, "Options for Securing RTP Sessions", RFC 7201, DOI 10.17487/RFC7201, April 2014,
<https://www.rfc-editor.org/info/rfc7201>.

[RFC7202]

C. Perkins, and M. Westerlund, "Securing the RTP Framework: Why RTP Does Not Mandate a Single Media Security Solution", RFC 7202, DOI 10.17487/RFC7202, April 2014,
<https://www.rfc-editor.org/info/rfc7202>.

[RFC7205]

A. Romanow, S. Botzko, M. Duckworth, and R. Even, "Use Cases for Telepresence Multistreams", RFC 7205, DOI 10.17487/RFC7205, April 2014,
<https://www.rfc-editor.org/info/rfc7205>.

[RFC7262]

A. Romanow, S. Botzko, and M. Barnes, "Requirements for Telepresence Multistreams", RFC 7262, DOI 10.17487/RFC7262, June 2014,
<https://www.rfc-editor.org/info/rfc7262>.

[RFC7667]

M. Westerlund, and S. Wenger, "RTP Topologies", RFC 7667, DOI 10.17487/RFC7667, November 2015,
<https://www.rfc-editor.org/info/rfc7667>.

[RFC8849]

R Even, and J Lennox, "Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures", RFC 8849, DOI 10.17487/RFC8849, January 2021,
<https://www.rfc-editor.org/info/rfc8849>.

Mark Duckworth

Andrew Pepperell

Stephan Wenger