Re: [codec] All requirements fulfilled?

Gregory Maxwell <> Thu, 28 July 2011 16:17 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3180421F8B8F for <>; Thu, 28 Jul 2011 09:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id LRKVJMHySYFL for <>; Thu, 28 Jul 2011 09:17:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 64FDF21F8B8D for <>; Thu, 28 Jul 2011 09:17:38 -0700 (PDT)
Received: from ([]) (using TLSv1) by ([]) with SMTP ID; Thu, 28 Jul 2011 09:17:38 PDT
Received: from ([fe80::c821:7c81:f21f:8bc7]) by ([::1]) with mapi; Thu, 28 Jul 2011 09:15:20 -0700
From: Gregory Maxwell <>
To: Christian Hoene <>, "" <>
Date: Thu, 28 Jul 2011 09:15:20 -0700
Thread-Topic: [codec] All requirements fulfilled?
Thread-Index: AcxNOd+Yi83fs0vWRIKjGLmIaR72bwABl5oz
Message-ID: <>
References: <005001cc4d39$ef62b580$ce282080$>
In-Reply-To: <005001cc4d39$ef62b580$ce282080$>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [codec] All requirements fulfilled?
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 28 Jul 2011 16:17:39 -0000

Christian Hoene []:
>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.