Subject: RE: [AVT] Packet accumulation strategies in RFC 2833bis

From: "Mundra, Satish" <[email-masked]>
Date: Fri, 21 Jan 2005 20:11:35 -0600

To prevent break in tones and tone "getting stuck" behavior, the advise
on 
packetization or event updates is required. The regular event updates
and the timeout mechanism 
provide the intra-event redundancy which is important for relaibility.
There's addition issue of interoperability with currently deployed
systems if the event transmission behavior is changed. 

Regards,

Satish Mundra.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Tom Taylor
> Sent: Friday, January 21, 2005 10:02 AM
> To: Oren Peleg
> Cc: [email-masked]
> Subject: Re: [AVT] Packet accumulation strategies in RFC 2833bis
> 
> Perhaps you're right.  The more I can take out, the better.  
> The only thing that makes this payload type different from 
> others is the inevitability that it will be necessary to 
> transition to another payload type.  I note the issues 
> associated with that and leave it to implementors to take the 
> matter further.
> 
> Oren Peleg wrote:
> > I don't think that the Packetization Interval relevant to this RFC, 
> > some might want to send only the initial & end of the 
> event, some may 
> > be IP based applications which receives out of band the initial & 
> > start events & than send the RFC 2833 packets. Some also may not be 
> > correlated to any particular voice stream that is being 
> made at the moment.
> > 
> > Oren P. 
> > 
> > -----Original Message-----
> > From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of 
> > Tom Taylor
> > Sent: Thursday, January 20, 2005 3:24 PM
> > To: [email-masked]
> > Subject: [AVT] Packet accumulation strategies in RFC 2833bis
> > 
> > RFC 2833bis currently contains various pieces of advice about what 
> > packetization interval to use at the beginning, in the 
> middle, or at 
> > the end of events or tones respectively.  A lot of this 
> advice really 
> > depends on what sort of buffering the receiving end applies.  It 
> > occurs to me that buffer management should be solely the 
> > responsibility of the receiving end, hence there should not be 
> > suggestions for the sender to create a buffer by 
> accumulating more in 
> > the initial report of an event or tone before sending it than in 
> > subsequent reports.
> > 
> > For the events payload, I therefore propose the following policy:
> > 
> >   - The sender SHOULD report the beginning of an episode of 
> events as 
> > soon as the initial event is recognized or after one packetization 
> > period, whichever comes later.
> > 
> >   - The sender SHOULD continue reporting at the negotiated 
> > packetization interval until there are no more event reports or 
> > retransmissions of event reports to send.
> > 
> >   - The receiver will lag in playout by one packet length 
> anyway.  It 
> > SHOULD add another packet length of delay to that, to handle the 
> > length of silences
> > 
> > accurately.  (This is mainly a concern for data protocols 
> where there 
> > is little tolerance on a typical 75 ms delay between preliminary 
> > signalling and the modem
> > stream.)
> > 
> > Comments?
> > 
> 
> --
> Tom Taylor
> Carrier VoIP Standards Development
> Nortel
> Phone +1 613 763 1496  (ESN 393-1496)
> E-mail: [email-masked]
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Tom Taylor <[email-masked]>
Date: Sat, 22 Jan 2005 12:37:46 -0500

The thing is, I don't see any difference in this requirement between events and 
G.711, say.  As a compromise, could I leave such advice in the non-normative 
"Application Considerations" section?