1 / 6

Improving CLUE Definitions: Streamlining Terminology and Addressing Open Issues

This document serves as a working tool for refining CLUE (Conference Language for Unified Experiences) definitions. Although initially only intended for internal alignment, key issues regarding terminology such as “stage-left” vs. “stage-right,” layout definitions, and Multipoint Control Unit (MCU) specifications have emerged. Suggestions include clarifying definitions while maintaining their abstract nature. Open issues address the spatial arrangement of media streams, the application of RFC guidelines, and whether specific controls should be included in the media definition. An update cycle is proposed following the IETF81 meeting to ensure clarity and precision.

lexi
Download Presentation

Improving CLUE Definitions: Streamlining Terminology and Addressing Open Issues

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CLUE definitions Stephan Wenger

  2. Document Usefulness • Clue definitions was intended as working tool to align various CLUE drafts • Alignment more or less reached • Doc never intended for publication • Is there a point in maintaining the doc beyond IETF81? • Suggestion: only one more update cycle right after this meeting.

  3. Open issue #1: left/right • Definitions-00 used “stage-left” and “stage right” • Was too confusing for some, to restricting for others, and generally unintuitive • Definitions-01 says “to be interpreted in context” • No one objected so far, but I note that neither requirements nor framework provide sufficient context in all cases • Suggestion • Leave definition as in 01 • Beat up document editors to be less sloppy

  4. Open issue #2: “Layout” • Layout: How rendered media streams are spatially arranged with respect to each other on a single screen/mono audio telepresence endpoint, and how rendered media streams are arranged with respect to each other on a multiple screen/loudspeaker telepresenceendpoint. Note that audio as well as video is encompassed by the term layout--in other words, included is the placement of audio streams on loudspeakers as well as video streams on video screens. • Edit. note: this is on the RENDERER side ONLY. • Could encompass stuff like binaural • Is renderer-only definition agreeable

  5. Open Issue #3: “MCU” • MCU: Multipoint Control Unit (MCU) - a device that connects two or more endpoints together into one single multimedia conference [RFC5117]. An MCU includes an [RFC4353] Mixer. • RFC4353 is tardy in requiring that media from the mixer be sent to EACH participant. I think we have practical use cases where this is not the case. Is this an issue? • Suggestion: non-issue, leave “as is”

  6. Open Issue #4: “Media” • Media: Any data that, after suitable encoding, can be conveyed over RTP, including audio, video or timed text. • Edt. note: does Media include far end camera control (which can be conveyed over RTP)? • Suggestion: abstract definition is good enough, FECC is a special case (not architecturally sound anyway), so leave definition as is, and don’t mention FECC

More Related