Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)
Draft of message to be sent after approval:
From: The IESG <firstname.lastname@example.org> To: IETF-Announce <email@example.com> Cc: RFC Editor <firstname.lastname@example.org>, avtext mailing list <email@example.com>, avtext chair <firstname.lastname@example.org> Subject: Protocol Action: 'Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)' to Proposed Standard (draft-ietf-avtext-multicast-acq-rtcp-xr-06.txt) The IESG has approved the following document: - 'Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs)' (draft-ietf-avtext-multicast-acq-rtcp-xr-06.txt) as a Proposed Standard This document is the product of the Audio/Video Transport Extensions Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-avtext-multicast-acq-rtcp-xr/
Technical Summary In most RTP-based multicast applications, the RTP source sends inter- related data. Due to this interdependency, randomly joining RTP receivers usually cannot start consuming the multicast data right after they join the session. Thus, they often experience a random acquisition delay. An RTP receiver can use one ore more different approaches to achieve rapid acquisition. Yet, due to various factors, performance of the rapid acquisition methods usually varies. Furthermore, in some cases the RTP receiver can do a simple multicast join (in other cases it is compelled to do so). For quality reporting, monitoring and diagnostics purposes, it is important to collect detailed information from the RTP receivers about their acquisition and presentation experiences. This document addresses this issue by defining a new report block type, called Multicast Acquisition (MA) Report Block, within the framework of RTP Control Protocol (RTCP) Extended Reports (XR) (RFC 3611). This document also defines the necessary signaling of the new MA report block type in the Session Description Protocol (SDP). Working Group Summary There was nothing contentious about this document. Document Quality Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type, or other Expert Review, what was its course (briefly)? In the case of a Media Type Review, on what date was the request posted? At the moment the shepherd is not aware of any protocol implementations, and no vendors have directly indicated they plan to implement, although he assumes that all RAMs implementations will ultimately include this, as it is essentially a mandatory part of RAMs. The reviewers are listed elsewhere in the PROTO writeup. There were no external reviews of the types mentioned, because there is no material requiring such review. Personnel Keith Drage is the document shepherd Gonzalo Camarillo is the responsible area director.