Browse Prior Art Database

Guidelines for Extending the RTP Control Protocol (RTCP) (RFC5968) Disclosure Number: IPCOM000199821D
Original Publication Date: 2010-Sep-01
Included in the Prior Art Database: 2010-Sep-17
Document File: 34 page(s) / 42K

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People

J. Ott: AUTHOR [+1]


The Real-time Transport Protocol (RTP) [RFC3550] is used to carry time-dependent (often continuous) media such as audio or video across a packet network in an RTP session. RTP usually runs on top of an unreliable transport such as UDP, Datagram Transport Layer Security (DTLS), or the Datagram Congestion Control Protocol (DCCP), so that RTP packets are susceptible to loss, re-ordering, or duplication. Associated with RTP is the RTP Control Protocol (RTCP), which provides a control channel for each session: media senders provide information about their current sending activities ("feed forward"), and media receivers report on their reception statistics ("feedback") in terms of received packets, losses, and jitter. Senders and receivers provide self-descriptions allowing them to disambiguate all entities in an RTP session and correlate synchronisation source (SSRC) identifiers with specific application instances. RTCP is carried over the same transport as RTP and is inherently best-effort; hence the RTCP reports are designed for such an unreliable environment, e.g., by making them "for information only".

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 6% of the total text.

Internet Engineering Task Force (IETF)                            J. Ott Request for Comments: 5968                              Aalto University Category: Informational                                       C. Perkins ISSN: 2070-1721                                    University of Glasgow                                                           September 2010

         Guidelines for Extending the RTP Control Protocol (RTCP)


   The RTP Control Protocol (RTCP) is used along with the Real-time    Transport Protocol (RTP) to provide a control channel between media    senders and receivers.  This allows constructing a feedback loop to    enable application adaptation and monitoring, among other uses.  The    basic reporting mechanisms offered by RTCP are generic, yet quite    powerful and suffice to cover a range of uses.  This document    provides guidelines on extending RTCP if those basic mechanisms prove    insufficient.

Status of This Memo

   This document is not an Internet Standards Track specification; it is    published for informational purposes.

   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).  Not all documents    approved by the IESG are a candidate for any level of Internet    Standard; see Section 2 of RFC 5741.

   Information about the current status of this document, any errata,    and how to provide feedback on it may be obtained at

 Ott & Perkins                 Informational                     [Page 1]
 RFC 5968             Guidelines for RTCP Extensions       September 2010

 Copyright Notice

   Copyright (c) 2010 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    ( 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 ....................................................3    2. Terminology .....................................................4    3. RT...