[AVT] draft-begen-avt-rapid-sync-rtcp-xr-01

["Ali C. Begen (abegen)" <abegen at cisco.com>]

Hi everyone,

Based on the comments received for the initial version, we revised the XR draft. This XR report provides detailed info about the acquisition of the multicast sessions. 

In this version, the XR report can be used both with and without the RAMS method (draft-ietf-avt-rapid-acquisition-for-rtp). It is extensible enough to be used with any other approach that provides rapid acquisition as well. Thus, we changed the name of the report block to "Multicast acquisition." We completed all missing sections.

Please review it and provide your feedback. We would like to get this work adopted by AVT and have it move forward with the RAMS draft.

http://www.ietf.org/internet-drafts/draft-begen-avt-rapid-sync-rtcp-xr-01.txt

-acbegen

-----Original Message-----
From: IETF I-D Submission Tool [mailto:idsubmission at ietf.org] 
Sent: Wednesday, May 13, 2009 5:24 PM
To: Ali C. Begen (abegen)
Cc: Eric Friedrich (efriedri)
Subject: New Version Notification for draft-begen-avt-rapid-sync-rtcp-xr-01 


A new version of I-D, draft-begen-avt-rapid-sync-rtcp-xr-01.txt has been successfuly submitted by Ali Begen and posted to the IETF repository.

Filename:	 draft-begen-avt-rapid-sync-rtcp-xr
Revision:	 01
Title:		 Multicast Acquisition Report Block Type for RTCP XR
Creation_date:	 2009-05-13
WG ID:		 Independent Submission
Number_of_pages: 20

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.  One approach to reduce this delay is to use an
auxiliary unicast RTP session with a retransmission server to receive
a burst stream that facilitates rapid acquisition of the multicast
stream.  An RTP receiver may use this approach (or any other
approach) to achieve rapid acquisition.  Yet, due to various factors,
performance of the rapid acquisition methods usually varies.
Furthermore, in some cases the RTP receiver may (or may have 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 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).  This document
also defines the necessary signaling of the new MA report block type
in the Session Description Protocol (SDP).
                                                                                  


The IETF Secretariat.