[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] New Version Notification for draft-peilin-avt-rtp-burst-01
Resending, as Ali seems cannot receive the email if his email address is the
first in the To field. And more remarkably, it seems that Cisco email
servers rejects to deliver emails directly from Huawei email servers :-(
Sorry for spamming others.
BR, YK
> -----Original Message-----
> From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
> Behalf Of Ye-Kui Wang
> Sent: Thursday, March 12, 2009 1:43 PM
> To: 'Ali C. Begen (abegen)'; 'Colin Perkins'; 'Peilin YANG'
> Cc: 'IETF AVT WG'
> Subject: Re: [AVT] New Version Notification for
> draft-peilin-avt-rtp-burst-01
>
>
> You got the context of the example correctly.
>
> > - RS knows when to terminate the burst, so it will eventually stop
> > regardless.
>
> Are you saying that, the RS will termniate the onging burst
> if it receives a new RMS-R requesting a new burst?
>
> BR, YK
>
> > -----Original Message-----
> > From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> > Sent: Thursday, March 12, 2009 1:32 PM
> > To: Ye-Kui Wang; Colin Perkins; Peilin YANG
> > Cc: IETF AVT WG
> > Subject: RE: [AVT] New Version Notification for
> > draft-peilin-avt-rtp-burst-01
> >
> > > Ali,
> > >
> > > I agree that your draft has much better considerations in these
> > > aspects, which are very good. However, I think there are
> still some
> > > holes to be filled.
> > >
> > > One example. The RR has sent an RTCP BYE for the unicast
> burst, and
> > > then sent an RMS-R to request changing to another
> channel. However,
> > > due to whatever reason, the RS has not received the RTCP BYE but
> > > received the RMS-R. What does the RS do? Where is this
> specified in
> > > the draft?
> >
> > BYEs are not reliable as it is the case in any RTP
> application. So, I
> > believe you are asking what will happen to the burst when
> the client
> > is not interested in the burst any more and sends BYE to RS to stop
> > the burst but BYE gets lost:
> > There are two cases:
> > - A new BYE can also be sent when the timing rules allow for it.
> > - RS knows when to terminate the burst, so it will eventually stop
> > regardless.
> >
> > HTH,
> > -acbegen
> >
> > > BR, YK
> > >
> > > > -----Original Message-----
> > > > From: Ali C. Begen (abegen) [mailto:abegen at cisco.com]
> > > > Sent: Thursday, March 12, 2009 12:51 PM
> > > > To: Ye-Kui Wang; Colin Perkins; Peilin YANG
> > > > Cc: IETF AVT WG
> > > > Subject: RE: [AVT] New Version Notification for
> > > > draft-peilin-avt-rtp-burst-01
> > > >
> > > > In our approach, we are trying to make the system work
> > even when the
> > > > control messages get lost. The re-ordering is also
> dealt with as
> > > > much as possible.
> > > >
> > > > Please refer to section 5 in our draft:
> > > > http://tools.ietf.org/html/draft-versteeg-avt-rapid-synchroniz
> > > > ation-for-rtp-02#page-9
> > > >
> > > > BR,
> > > > -acbegen
> > > >
> > > > > -----Original Message-----
> > > > > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
> > > > Behalf Of
> > > > > Ye-Kui Wang
> > > > > Sent: Thursday, March 12, 2009 9:34 AM
> > > > > To: 'Colin Perkins'; 'Peilin YANG'
> > > > > Cc: 'IETF AVT WG'
> > > > > Subject: Re: [AVT] New Version Notification for
> > > > > draft-peilin-avt-rtp-burst-01
> > > > >
> > > > >
> > > > > I guess the authors have not done such an analysis, and
> > I think I
> > > > > share Colin's understanding that the two (probably implicit)
> > > > > assumptions are there, based on my understanding of them.
> > > To avoid
> > > > > being based on the first assumption, an (almost) exhaustive
> > > > analysis
> > > > > of all possible exceptional cases regarding the loss or
> > > > out-of-order
> > > > > delivery of RTCP messages that would affect the control
> > > > message state
> > > > > synchronisation. I guess the second is related to the
> > first, e.g.
> > > > > regarding that the issues of loss or out-of-order delivery
> > > > may remain
> > > > > even some solutions have been taken.
> > > > >
> > > > > On the other hand, I think these issues apply to
> > > > > draft-versteeg-avt-rapid-synchronization-for-rtp-02 as
> > well, and
> > > > > should be studied in the same context, e.g. through the
> > potential
> > > > > design team that may be created. I will try to have a related
> > > > > discussion to the list soon in a separate thread.
> > > > >
> > > > > BR, YK
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org]
> > > > On Behalf
> > > > > > Of Colin Perkins
> > > > > > Sent: Tuesday, March 10, 2009 7:20 PM
> > > > > > To: Peilin YANG
> > > > > > Cc: IETF AVT WG
> > > > > > Subject: Re: [AVT] New Version Notification for
> > > > > > draft-peilin-avt-rtp-burst-01
> > > > > >
> > > > > > On 8 Mar 2009, at 06:08, Peilin YANG wrote:
> > > > > > > This is the version 01 for draft-peilin-avt-rtp-burst-01.
> > > > > > > The major change compared to version 00 adds some
> > > > descrptions for
> > > > > > > exception handling, and redefines some fields of
> > > > feedback message.
> > > > > > > Welcome any comments.
> > > > > > >
> > > > > > > http://tools.ietf.org/id/draft-peilin-avt-rtp-burst-01.txt
> > > > > >
> > > > > > Have you done any analysis of how the mechanisms
> > > defined in this
> > > > > > draft relate to the guidelines in draft-ietf-avt-rtcp-
> > > > > > guidelines-01.txt? There seem to be assumptions of
> > > reliable state
> > > > > > synchronisation for the control messages, and about the
> > > > behaviour of
> > > > > > the underlying network, that aren't necessarily warranted.
> > > > > >
> > > > > > --
> > > > > > Colin Perkins
> > > > > > http://csperkins.org/
> > > > > >
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > 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
> > > > >
> > > >
> > >
> > >
> > >
> >
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> avt at ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>