RFC 6642: RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report
In plain English — editorial summary, not part of the RFC
In a large RTP session using the RTP Control Protocol (RTCP) feedback mechanism defined in RFC 4585, a feedback target may experience transient overload if some event causes a large number of receivers to send feedback at once. This overload is usually avoided by ensuring that feedback reports are forwarded to all receivers, allowing them to avoid sending duplicate feedback reports. However, there are cases where it is not recommended to forward feedback reports, and this may allow feedback implosion. This memo discusses these cases and defines a new RTCP Third-Party Loss Report that can be used to inform receivers that the feedback target is aware of some loss event, allowing them to suppress feedback. Associated Session Description Protocol (SDP) signaling is also defined. [STANDARDS-TRACK]
Document record
- Document ID
- RFC6642
- Published
- June 2012
- Authors
- Q. Wu; F. Xia; R. Even
- Status
- PROPOSED STANDARD
- Stream
- IETF
- Area
- wit
- Pages
- 13
- Also known as
- —
Topics
Related documents
Ranked automatically by shared keywords, IETF area and stream — not by editorial selection.
- RFC 6675A Conservative Loss Recovery Algorithm Based on Selective Acknowledgment (SACK) for TCPCurrent
August 2012
- RFC 3517A Conservative Selective Acknowledgment (SACK)-based Loss Recovery Algorithm for TCPObsoleted
April 2003
- RFC 6659Considerations for Deploying the Rapid Acquisition of Multicast RTP Sessions (RAMS) MethodCurrent
July 2012
- RFC 6026Correct Transaction Handling for 2xx Responses to Session Initiation Protocol (SIP) INVITE RequestsCurrent
September 2010
- RFC 5725Post-Repair Loss RLE Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)Current
February 2010
- RFC 3941Negative-Acknowledgment (NACK)-Oriented Reliable Multicast (NORM) Building BlocksObsoleted
November 2004
- RFC 3940Negative-acknowledgment (NACK)-Oriented Reliable Multicast (NORM) ProtocolObsoleted
November 2004
- RFC 6641Using DNS SRV to Specify a Global File Namespace with NFS Version 4Current
June 2012
Also filed under
About this page
The document record above — title, authors, date, status, stream, area, relationships, DOI and errata — is imported verbatim from the public RFC Editor index. The “in plain English” section is editorial: written by The metasystema editorial team, not part of the RFC. Where the two differ, the RFC text governs.
Last checked against the RFC Editor index on . RFCs are never revised after publication; changes are issued as new documents.
Data sources · Editorial policy · Report a correction · What is an RFC?