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

From: "Oren Peleg" <[email-masked]>
Date: Fri, 21 Jan 2005 12:16:47 +0200

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: Fri, 21 Jan 2005 10:02:13 -0500

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.