Re: [AVT] Fwd: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt

[Ye-Kui Wang <yekuiwang at huawei.com>]

I fully agree that using the same term for two very different subjects is
confusing. For example, this has wasted me a bit time when looking for
emails for either subject. 

To me, the term "rapid sync" matches draft-perkins-avt-rapid-rtp-sync-03
better than draft-versteeg-avt-rapid-synchronization-for-rtp-02, as the
former is really about sync of different streams, while the latter is aboud
rapid tunning-in or channel switching. 

BR, YK 

> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On 
> Behalf Of Ali C. Begen (abegen)
> Sent: Tuesday, March 10, 2009 1:05 PM
> To: Colin Perkins; avt at ietf.org
> Subject: Re: [AVT] Fwd: I-D 
> Action:draft-perkins-avt-rapid-rtp-sync-03.txt
> 
> Hi Colin,
> 
> I read the draft and I found it informative. The funny thing 
> it shares a similar title with our draft :) I wonder whether 
> we can come up with a better, non-colliding name for any of 
> the drafts. Furthermore, we are also defining control 
> messages (3 for now), one of which is rapid (multicast) synch 
> request (RMS-R).
> Similar names can be confusing, IMO.
> 
> Others comments:
> - FYI: Section 3.1: reg. "next available FMT is 5?" We used 
> 5, 6 and 7 in the our draft. Of course, it is not reserved yet.
> - Could the draft also mention about the other useful 
> properties of having a sender report earlier? I also think a 
> more appropriate name could be found for this message.
> - Section 4.2 says "The frequency of intersing ntp header exs 
> is up to the sender." Any guidance/constraints on this?
> - There are a few inconsistent intra-document references.
> 
> Chairs:
> I support this draft to become a WG item as it has two good 
> solution for
> (timestamp) synchronization for RTP flows.
> 
> -acbegen
> 
> > -----Original Message-----
> > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On 
> Behalf Of 
> > Colin Perkins
> > Sent: Monday, March 09, 2009 12:43 PM
> > To: avt at ietf.org WG
> > Subject: [AVT] Fwd: I-D 
> Action:draft-perkins-avt-rapid-rtp-sync-03.txt
> > 
> > The changes in this version are primarily editorial; we're 
> aware that 
> > not all the open issues have been addressed yet. Any 
> further comments 
> > are welcomed.
> > 
> > Chairs: we'd like this to be considered as an AVT working 
> group draft, 
> > as indicated privately.
> > 
> > Cheers,
> > Colin
> > 
> > 
> > 
> > 
> > Begin forwarded message:
> > > From: Internet-Drafts at ietf.org
> > > Date: 9 March 2009 17:15:02 GMT
> > > To: i-d-announce at ietf.org
> > > Subject: I-D Action:draft-perkins-avt-rapid-rtp-sync-03.txt
> > > Reply-To: internet-drafts at ietf.org
> > >
> > > A New Internet-Draft is available from the on-line 
> Internet-Drafts 
> > > directories.
> > >
> > > 	Title           : Rapid Synchronisation of RTP Flows
> > > 	Author(s)       : C. Perkins, T. Schierl
> > > 	Filename        : draft-perkins-avt-rapid-rtp-sync-03.txt
> > > 	Pages           : 17
> > > 	Date            : 2009-03-09
> > >
> > > This memo outlines how RTP multimedia sessions are 
> synchronised, and 
> > > discusses how rapidly such synchronisation can occur.  We 
> show that 
> > > most RTP sessions can be synchronised immediately, but 
> that the use 
> > > of video switching multipoint conference units (MCUs) or
> > large source
> > > specific multicast (SSM) groups can greatly increase the initial 
> > > synchronisation delay.  This increase in delay can be
> > unacceptable to
> > > some applications that use layered and/or 
> multi-description codecs.
> > >
> > > This memo updates the RTP Control Protocol (RTCP) timing rules to 
> > > reduce the initial synchronisation delay for SSM sessions.  A new 
> > > feedback packet is defined for use with the Extended RTP 
> Profile for 
> > > RTCP-based Feedback (RTP/AVPF), allowing video switching MCUs to 
> > > rapidly request resynchronisation.  Two new RTP header
> > extensions are
> > > defined to allow rapid synchronisation of late joiners, and
> > guarantee
> > > correct timestamp based decoding order recovery for layered
> > codecs in
> > > the presence of clock skew.
> > >
> > > A URL for this Internet-Draft is:
> > > http://www.ietf.org/internet-drafts/draft-perkins-avt-rapid-rtp-
> > > sync-03.txt
> > >
> > > Internet-Drafts are also available by anonymous FTP at:
> > > ftp://ftp.ietf.org/internet-drafts/
> > >
> > > Below is the data which will enable a MIME compliant mail reader 
> > > implementation to automatically retrieve the ASCII version of the 
> > > Internet-Draft.
> > > Content-Type: text/plain
> > > Content-ID: <2009-03-09100610.I-D at ietf.org>
> > >
> > > _______________________________________________
> > > I-D-Announce mailing list
> > > I-D-Announce at ietf.org
> > > https://www.ietf.org/mailman/listinfo/i-d-announce
> > > Internet-Draft directories: http://www.ietf.org/shadow.html or 
> > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt at ietf.org
> > https://www.ietf.org/mailman/listinfo/avt
> > 
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>