--- 1/draft-ietf-avtext-multicast-acq-rtcp-xr-03.txt 2011-04-12 16:16:32.000000000 +0200 +++ 2/draft-ietf-avtext-multicast-acq-rtcp-xr-04.txt 2011-04-12 16:16:32.000000000 +0200 @@ -1,56 +1,56 @@ AVT A. Begen Internet-Draft E. Friedrich Intended status: Standards Track Cisco -Expires: October 13, 2011 April 11, 2011 +Expires: October 14, 2011 April 12, 2011 Multicast Acquisition Report Block Type for RTP Control Protocol (RTCP) Extended Reports (XRs) - draft-ietf-avtext-multicast-acq-rtcp-xr-03 + draft-ietf-avtext-multicast-acq-rtcp-xr-04 Abstract 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 (or be compelled to) - do a simple multicast join. 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). + 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). Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on October 13, 2011. + This Internet-Draft will expire on October 14, 2011. Copyright Notice Copyright (c) 2011 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 (http://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 @@ -478,22 +478,20 @@ A new unilateral parameter is defined for the MA report block to be used with the Session Description Protocol (SDP) [RFC4566] using the Augmented Backus-Naur Form (ABNF) [RFC5234]. It has the following syntax within the 'rtcp-xr' attribute [RFC3611]: xr-format = xr-format /= multicast-acq-ext multicast-acq-ext = "multicast-acq" - Figure 4 - Refer to Section 5.1 of [RFC3611] for a detailed description and the full syntax of the "rtcp-xr" attribute. The "multicast-acq-ext" parameter is compatible with the definition of "format-ext" in the "rtcp-xr" attribute. 6. Security Considerations The security considerations of [RFC3611] apply in this document as well. @@ -516,22 +514,22 @@ Using the MA reports to provide feedback into the acquisition of the multicast streams can introduce possible additional security implications. If a forged or otherwise modified MA report is received for an earlier acquisition attempt, invalid data can be used as input in later rapid acquisition attempts. For example, incorrectly small SFGMP join times could cause the unicast burst to be too short, leading to gaps in sequence numbers in the approach discussed in [I-D.ietf-avt-rapid-acquisition-for-rtp]. Additionally, forged reports could give the appearance that rapid acquisition is performing correctly, when it is in fact failing, or vice versa. - However, the MA reports are believed not to introduce any additional - risks from a confidentiality viewpoint. + While integrity protection can be achieved through different ways, we + RECOMMEND the use of SRTCP [RFC3711]. 7. IANA Considerations The following contact information is provided for all registrations in this document: Ali Begen abegen@cisco.com Note to the RFC Editor: In the following, please replace "XXXX" with