Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback
RFC 8861
Document | Type | RFC - Proposed Standard (January 2021; No errata) | |
---|---|---|---|
Authors | Jonathan Lennox , Magnus Westerlund , Qin Wu , Colin Perkins | ||
Last updated | 2021-01-18 | ||
Stream | Internet Engineering Task Force (IETF) | ||
Formats | plain text html xml pdf htmlized (tools) htmlized bibtex | ||
Reviews | |||
Stream | WG state | Submitted to IESG for Publication | |
Document shepherd | Roni Even | ||
Shepherd write-up | Show (last changed 2015-10-08) | ||
IESG | IESG state | RFC 8861 (Proposed Standard) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Yes | ||
Telechat date | |||
Responsible AD | Ben Campbell | ||
Send notices to | (None) | ||
IANA | IANA review state | Version Changed - Review Needed | |
IANA action state | RFC-Ed-Ack |
Internet Engineering Task Force (IETF) J. Lennox Request for Comments: 8861 8x8 / Jitsi Category: Standards Track M. Westerlund ISSN: 2070-1721 Ericsson Q. Wu Huawei C. Perkins University of Glasgow January 2021 Sending Multiple RTP Streams in a Single RTP Session: Grouping RTP Control Protocol (RTCP) Reception Statistics and Other Feedback Abstract RTP allows multiple RTP streams to be sent in a single session but requires each Synchronization Source (SSRC) to send RTP Control Protocol (RTCP) reception quality reports for every other SSRC visible in the session. This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints. In many cases, most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are normally co-located and see the same reception quality. This memo defines a Reporting Group extension to RTCP to reduce the reporting overhead in such scenarios. 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/rfc8861. 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. RTCP Reporting Groups 3.1. Semantics and Behavior of RTCP Reporting Groups 3.2. Identifying Members of an RTCP Reporting Group 3.2.1. Definition and Use of the RTCP RGRP SDES Item 3.2.2. Definition and Use of the RTCP RGRS Packet 3.3. Interactions with the RTP/AVPF Feedback Profile 3.4. Interactions with RTCP Extended Report (XR) Packets 3.5. Middlebox Considerations 3.6. SDP Signaling for Reporting Groups 4. Properties of RTCP Reporting Groups 4.1. Bandwidth Benefits of RTCP Reporting Groups 4.2. Compatibility of RTCP Reporting Groups 5. Security Considerations 6. IANA Considerations 7. References 7.1. Normative References 7.2. Informative References Authors' Addresses 1. Introduction The Real-time Transport Protocol (RTP) [RFC3550] is a protocol for group communication, supporting multiparty multimedia sessions. A single RTP session can support multiple participants sending data at once and can also support participants sending multiple simultaneous RTP streams. Examples of the latter might include a participant with multiple cameras who chooses to send multiple views of a scene, or a participant that sends audio and video flows multiplexed in a single RTP session. Rules for handling RTP sessions containing multiple RTP streams are described in [RFC3550], with some clarifications in [RFC8108]. An RTP endpoint will have one or more Synchronization Sources (SSRCs). It will have at least one RTP stream, and thus at least one SSRC, for each media source it sends, and it might use multiple SSRCs per media source when using media scalability features [RFC6190], forward error correction, RTP retransmission [RFC4588], or similar mechanisms. An endpoint that is not sending any RTP streams will have at least one SSRC to use for reporting and any feedback messages. Each SSRC has to send RTP Control Protocol (RTCP) Sender Reports (SRs) corresponding to the RTP packets it sends and Receiver Reports (RRs) for traffic it receives. (SRs and RRs are described in [RFC3550].) That is, every SSRC will send RTCP packets to report onShow full document text