Skip to main content

RTP Control Protocol (RTCP) Extension for a Third-Party Loss Report
draft-ietf-avtcore-feedback-supression-rtp-17

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    avtcore mailing list <avt@ietf.org>,
    avtcore chair <avtcore-chairs@tools.ietf.org>
Subject: Protocol Action: 'RTCP Extension for Third-party Loss Report' to Proposed Standard (draft-ietf-avtcore-feedback-supression-rtp-17.txt)

The IESG has approved the following document:
- 'RTCP Extension for Third-party Loss Report'
  (draft-ietf-avtcore-feedback-supression-rtp-17.txt) as a Proposed
Standard

This document is the product of the Audio/Video Transport Core
Maintenance Working Group.

The IESG contact persons are Robert Sparks and Gonzalo Camarillo.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-avtcore-feedback-supression-rtp/


Ballot Text

  Technical Summary
        In a large RTP session using the 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 SDP signalling is also defined.

    Working Group Summary
        There is strong consensus among an adequate number of WG
        participants on this solution.
       
    Document Quality
    There are not yet any reported implementations. The document
    has had reasonable review. 

Personnel

  Magnus Westerlund is the document shepherd.
  Robert Sparks is the responsible AD

RFC Editor Note