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