Dear Lars Eggert, Dean Bogdanovic and Mikael Abrahamsson,

allow me to raise my voice on the issues of supporting a good voice
transmission even under harsh conditions.

> > I have earlier proposed that the full solution should be able to
> > cope with
> > 10% packet loss and 1.5-2 seconds of jitter.
> 
> I'm not aware of any Internet paths where such conditions would be
> considered normal. As such I question why such cases should be
> supported as a requirement. (Obviously, if a solution happened to work
> under such conditions *while also* having negligible overhead under
> normal conditions, that'd be fine - but I'm simply not sure this can
> be done.)

Probably there are about a billion phone calls each days world-wide. If the
phone systems works well only on for normal conditions (e.g. 99,9% of them),
this would result in about one million unhappy users each day. In addition,
service centers would kept busy. Thus, if possible one should concentrate on
providing a well working solution even for most of remaining 0,099...%
percentage of conditions---as long as the technical overhead is not too
high.

Let me point out a recent research project by Prof. Dr. Jörg Ott, HKK
Helsinki called DT Talkie. http://www.netlab.tkk.fi/tutkimus/dtn/dttalkie/
It is a phone application for delay tolerant networks and Jörg told me that
it was the job of a student during a seminar. 

Knowing these results, I described the requirements for a reliable system
and sketched a rough technical solution in
http://www.ietf.org/id/draft-hoene-avt-acs-requirements-00.txt 
Please read Section 2.4 and 3.2.

Having such as Push-To-Talk like solution would also help to address other
problems described by Mikael and Koes,

Mikael:
> But the two major types I see that needs to be handled are:
> 
> Wireless networks with ARQ such as 802.11, 3GPP and alike. These typically
> can induce 1-2 seconds of jitter, but with low or no packet loss.
> 
> Routers/switches that do buffering and which use either FIFO/taildrop or
> some kind of more intelligent buffer management such as (W)RED or alike.
> These might drop a few percent of packets (usually never more as TCP backs
> off a lot at these packet drop rates and thus the links are usually not
> loaded more than what causes a few percent packet loss) plus induce jitter
> as other traffic affects this. Routers typically never buffer packets more
> than 600ms, often much lower, thus jitter is less unless there are
> multiple congested links in a row.
Koen:
> All this is relevant and important. For example, 3G networks exhibit
> delay spikes of several seconds. Every few minutes the network just
> stops delivering packets, and then releases them in short order. Same
> for WiFi with delay spikes of up to a second (caused by the radio
> scanning for available access points). Quickly-adapting jitter
> buffering greatly helps with such non-stationary jitter.

Of course, providing a DT-Talkie or Push-To-Talk application is not the task
of a codec. Rather, it should be standardized in the AVT/transport group.
However, a codec could support those applications with two features:

1. A highly bandwidth-efficient transmission of speech (while taking
advantage of high algorithmic delays and very large frame sizes)
2. Support of discontinues transmission modes to detect voice activity and
compress silence and background noise.

With best regards,

 Christian Hoene