Mapping RTP Streams to Controlling Multiple Streams for Telepresence (CLUE) Media Captures
RFC 8849

Document Type RFC - Proposed Standard (January 2021; No errata)
Authors Roni Even  , Jonathan Lennox 
Last updated 2021-01-18
Stream IETF
Formats plain text html xml pdf htmlized bibtex
Reviews
Stream WG state Submitted to IESG for Publication
Document shepherd Paul Kyzivat
Shepherd write-up Show (last changed 2017-02-27)
IESG IESG state RFC 8849 (Proposed Standard)
Action Holders
(None)
Consensus Boilerplate Yes
Telechat date
Responsible AD Alissa Cooper
Send notices to "Paul Kyzivat" <pkyzivat@alum.mit.edu>
IANA IANA review state Version Changed - Review Needed
IANA action state RFC-Ed-Ack


Internet Engineering Task Force (IETF)                           R. Even
Request for Comments: 8849                                              
Category: Standards Track                                      J. Lennox
ISSN: 2070-1721                                              8x8 / Jitsi
                                                            January 2021

  Mapping RTP Streams to Controlling Multiple Streams for Telepresence
                         (CLUE) Media Captures

Abstract

   This document describes how the Real-time Transport Protocol (RTP) is
   used in the context of the Controlling Multiple Streams for
   Telepresence (CLUE) protocol.  It also describes the mechanisms and
   recommended practice for mapping RTP media streams, as defined in the
   Session Description Protocol (SDP), to CLUE Media Captures and
   defines a new RTP header extension (CaptureID).

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 7841.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   https://www.rfc-editor.org/info/rfc8849.

Copyright Notice

   Copyright (c) 2021 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (https://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  RTP Topologies for CLUE
   4.  Mapping CLUE Capture Encodings to RTP Streams
   5.  MCC Constituent CaptureID Definition
     5.1.  RTCP CaptureID SDES Item
     5.2.  RTP Header Extension
   6.  Examples
   7.  Communication Security
   8.  IANA Considerations
   9.  Security Considerations
   10. References
     10.1.  Normative References
     10.2.  Informative References
   Acknowledgments
   Authors' Addresses

1.  Introduction

   Telepresence systems can send and receive multiple media streams.
   The CLUE Framework [RFC8845] defines Media Captures (MCs) as a source
   of Media, from one or more Capture Devices.  A Media Capture may also
   be constructed from other Media streams.  A middlebox can express
   conceptual Media Captures that it constructs from Media streams it
   receives.  A Multiple Content Capture (MCC) is a special Media
   Capture composed of multiple Media Captures.

   SIP Offer/Answer [RFC3264] uses SDP [RFC4566] to describe the RTP
   media streams [RFC3550].  Each RTP stream has a unique
   Synchronization Source (SSRC) within its RTP session.  The content of
   the RTP stream is created by an encoder in the endpoint.  This may be
   an original content from a camera or a content created by an
   intermediary device like a Multipoint Control Unit (MCU).

   This document makes recommendations for the CLUE architecture about
   how RTP and RTP Control Protocol (RTCP) streams should be encoded and
   transmitted and how their relation to CLUE Media Captures should be
   communicated.  The proposed solution supports multiple RTP topologies
   [RFC7667].

   With regards to the media (audio, video, and timed text), systems
   that support CLUE use RTP for the media, SDP for codec and media
   transport negotiation (CLUE individual encodings), and the CLUE
   protocol for Media Capture description and selection.  In order to
   associate the media in the different protocols, there are three
   mappings that need to be specified:

   1.  CLUE individual encodings to SDP

   2.  RTP streams to SDP (this is not a CLUE-specific mapping)

   3.  RTP streams to MC to map the received RTP stream to the current
       MC in the MCC.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   Definitions from the CLUE Framework (see Section 3 of [RFC8845]) are
   used by this document as well.

3.  RTP Topologies for CLUE

   The typical RTP topologies used by CLUE telepresence systems specify
   different behaviors for RTP and RTCP distribution.  A number of RTP
Show full document text