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