Re: [codec] All requirements fulfilled?

[Gregory Maxwell <[e-mail]>]

Christian Hoene [[e-mail]]:
>I just went thru the list of requirements to see which of them have been met and have been tested. I marked them with colors.

Thank you for the point by point, however at some points your comparison appears to be more or less completely uncorrelated with the requirements draft.

For example,

7 Delay tolerant networking
1.      high delays >120ms                                      => needs to be defined payload draft


The text in the requirements draft states (in entirety):

3.7. Delay Tolerant Networking or Push-to-Talk Services

   Internet transmissions are subjected to interruptions of connectivity
   that severely disturb a phone call.  This may happen in cases of
   route changes, handovers, slow fading, or device failures.  To
   overcome this distortion, the phone call can be halted and resumed
   after the connectivity has been reestablished again.

   Also, if transmission capacity is lower than the minimal coding rate,
   switching to a push-to-talk mode still allows for effective
   communication.  In that situation, voice is transmitted at slower-
   than-real-time bitrate and conversations are interrupted until the
   speech has been transmitted.

   These modes require interrupting the audio playout and continuing
   after a pause of arbitrary duration.


In what universe is _adding_ enormous amounts of delay
in the codec a requirement of being delay tolerant?

I would have stridently objected to a requirement of having high 
delays in the codec as a requirement (though it might make
sense as a consequence of some other worth-while tradeoff or
as something simply permitted where it doesn't add overhead).  

It's also worth pointing out that the packet duration will usually
translate to a one way delay of at 3x or more larger due to
buffering at various points.  Even if you are already on the moon
I doubt you would welcome an additional one second round trip
delay from the codec.