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?