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 on
Show full document text