-----Original Message-----
From: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
Behalf Of Tom Taylor
Sent: Friday, January 21, 2005 10:02 AM
To: Oren Peleg
Cc: avt at ietf.org
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: avt-bounces at ietf.org [mailto:avt-bounces at ietf.org] On
Behalf Of
Tom Taylor
Sent: Thursday, January 20, 2005 3:24 PM
To: avt at ietf.org
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: taylor at nortelnetworks.com
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt