RTP Stream Identifier Source Description (SDES)
RFC 8852
Document | Type | RFC - Proposed Standard (January 2021; No errata) | |
---|---|---|---|
Authors | Adam Roach , Suhas Nandakumar , Peter Thatcher | ||
Last updated | 2021-01-19 | ||
Replaces | draft-roach-avtext-rid | ||
Stream | IETF | ||
Formats | plain text html xml pdf htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Jonathan Lennox | ||
Shepherd write-up | Show (last changed 2016-07-07) | ||
IESG | IESG state | RFC 8852 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Ben Campbell | ||
Send notices to | "Jonathan Lennox" <jonathan@vidyo.com> | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | RFC-Ed-Ack |
Internet Engineering Task Force (IETF) A.B. Roach Request for Comments: 8852 Mozilla Category: Standards Track S. Nandakumar ISSN: 2070-1721 Cisco Systems P. Thatcher Google January 2021 RTP Stream Identifier Source Description (SDES) Abstract This document defines and registers two new Real-time Transport Control Protocol (RTCP) Stream Identifier Source Description (SDES) items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream is to be repaired using a redundancy RTP stream. 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/rfc8852. 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. Usage of RtpStreamId and RepairedRtpStreamId in RTP and RTCP 3.1. RTCP "RtpStreamId" SDES Extension 3.2. RTCP "RepairedRtpStreamId" SDES Extension 3.3. RTP "RtpStreamId" and "RepairedRtpStreamId" Header Extensions 4. IANA Considerations 4.1. New RtpStreamId SDES Item 4.2. New RepairRtpStreamId SDES Item 4.3. New RtpStreamId Header Extension URI 4.4. New RepairRtpStreamId Header Extension URI 5. Security Considerations 6. References 6.1. Normative References 6.2. Informative References Acknowledgements Authors' Addresses 1. Introduction RTP sessions frequently consist of multiple streams, each of which is identified at any given time by its synchronization source (SSRC); however, the SSRC associated with a stream is not guaranteed to be stable over its lifetime. Within a session, these streams can be tagged with a number of identifiers, including CNAMEs and MediaStream Identification (MSID) [RFC8830]. Unfortunately, none of these have the proper ordinality to refer to an individual stream; all such identifiers can appear in more than one stream at a time. While approaches that use unique payload types (PTs) per stream have been used in some applications, this is a semantic overloading of that field, and one for which its size is inadequate: in moderately complex systems that use PT to uniquely identify every potential combination of codec configuration and unique stream, it is possible to simply run out of values. To address this situation, we define a new RTCP Stream Identifier Source Description (SDES) identifier, RtpStreamId, that uniquely identifies a single RTP stream. A key motivator for defining this identifier is the ability to differentiate among different encodings of a single source stream that are sent simultaneously (i.e., simulcast). This need for unique identification extends to dependent streams (e.g., where layers used by a layered codec are transmitted on separate streams). At the same time, when redundancy RTP streams are in use, we also need an identifier that connects such streams to the RTP stream for which they are providing redundancy. For this purpose, we define an additional SDES identifier, RepairedRtpStreamId. This identifier can appear only in packets associated with a redundancy RTP stream. They carry the same value as the RtpStreamId of the RTP stream that the redundant RTP stream is correcting. 2. Terminology In this document, the terms "source stream", "RTP stream", "source RTP stream", "dependent stream", "received RTP stream", and "redundancy RTP stream" are used as defined in [RFC7656].Show full document text