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 RTPShow full document text