Re: [codec] All requirements fulfilled?
Gregory Maxwell <gmaxwell@juniper.net> Thu, 28 July 2011 16:17 UTC
Return-Path: <gmaxwell@juniper.net>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3180421F8B8F for <codec@ietfa.amsl.com>; Thu, 28 Jul 2011 09:17:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRKVJMHySYFL for <codec@ietfa.amsl.com>; Thu, 28 Jul 2011 09:17:38 -0700 (PDT)
Received: from exprod7og115.obsmtp.com (exprod7og115.obsmtp.com [64.18.2.217]) by ietfa.amsl.com (Postfix) with ESMTP id 64FDF21F8B8D for <codec@ietf.org>; Thu, 28 Jul 2011 09:17:38 -0700 (PDT)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob115.postini.com ([64.18.6.12]) with SMTP ID DSNKTjGLmuN4x5UKFaAKZeIkVwWb0rJQUE1n@postini.com; Thu, 28 Jul 2011 09:17:38 PDT
Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([::1]) with mapi; Thu, 28 Jul 2011 09:15:20 -0700
From: Gregory Maxwell <gmaxwell@juniper.net>
To: Christian Hoene <hoene@uni-tuebingen.de>, "codec@ietf.org" <codec@ietf.org>
Date: Thu, 28 Jul 2011 09:15:20 -0700
Thread-Topic: [codec] All requirements fulfilled?
Thread-Index: AcxNOd+Yi83fs0vWRIKjGLmIaR72bwABl5oz
Message-ID: <BCB3F026FAC4C145A4A3330806FEFDA93CE6698219@EMBX01-HQ.jnpr.net>
References: <005001cc4d39$ef62b580$ce282080$@uni-tuebingen.de>
In-Reply-To: <005001cc4d39$ef62b580$ce282080$@uni-tuebingen.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
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-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Jul 2011 16:17:39 -0000
Christian Hoene [hoene@uni-tuebingen.de]: >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.
- [codec] All requirements fulfilled? Christian Hoene
- Re: [codec] All requirements fulfilled? Ralph Giles
- Re: [codec] All requirements fulfilled? Gregory Maxwell
- Re: [codec] All requirements fulfilled? Christian Hoene
- Re: [codec] All requirements fulfilled? Stephen Botzko
- [codec] SDP Support for Multiple Packetisation Pe… Paul Beaumont
- Re: [codec] All requirements fulfilled? Ralph Giles
- Re: [codec] All requirements fulfilled? Stephen Botzko
- Re: [codec] SDP Support for Multiple Packetisatio… Schwarz, Albrecht (Albrecht)
- Re: [codec] [MMUSIC] SDP Support for Multiple Pac… Miguel A. Garcia