From steveu@coppice.org Thu Apr 1 23:23:59 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5EA8E3A6899 for ; Thu, 1 Apr 2010 23:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY03LWpMW0Fu for ; Thu, 1 Apr 2010 23:23:57 -0700 (PDT) Received: from cwb.pacific.net.hk (cwb.pacific.net.hk [202.14.67.92]) by core3.amsl.com (Postfix) with ESMTP id 13F323A6A61 for ; Thu, 1 Apr 2010 23:23:30 -0700 (PDT) Received: from i7.coppice.org (93.176.64.202.dyn.pacific.net.hk [202.64.176.93]) by cwb.pacific.net.hk with ESMTP id o326O27d009330 for ; Fri, 2 Apr 2010 14:24:03 +0800 Message-ID: <4BB58D82.5010508@coppice.org> Date: Fri, 02 Apr 2010 14:24:02 +0800 From: Steve Underwood User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc11 Thunderbird/3.0.3 MIME-Version: 1.0 To: codec@ietf.org References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <001d01cace82$1c8a0c80$559e2580$@de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [codec] #5: Mention DTMF in requirements, Testing DTMF? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 06:23:59 -0000 Hi, I'm the author of the SpanDSP library people have referenced. People seem to have only mentioned DTMF talk-off in these discussions, but the issue of corrupting the DTMF so it is less detectable is probably more of an issue. Over the years there have been two reference data sets for testing DTMF talk off - the one from Mitel, and the one from Bellcore. Both started out as audio cassette tape products. The files I use for DTMF testing with SpanDSP are: - A wave file produced by resampling to 8k samples/second the MP3 version of the Mitel tape, which Mitel's heirs provide freely. If this is fed to TDM equipment it seems to give pretty much the same hits and near misses as the original Mitel cassette tape version. It seems, therefore, that aging of the original tape and transcription to MP3 have no unduly affected he signal. - A set of wave files which were produced years ago from a pristine set of the Bellcore test tapes, using a cassette player with speed adjustment, so the pitch could be tweaked to be bang on target. Later, Telcordia/Bellcore stopped selling the tapes, and they gave me permission to hand out these files to a couple of people. Since they are transcribed from copyright tapes, I only handed them out where permission was sought. Now they seem to have introduced an audio CD version of the tapes. You could use almost any long passages of speech for this kind of testing, but the above two data sets are the industry accepted ones, as you can compare different DTMF detectors reasonably well by comparing their false hits on this data. The Bellcore tapes are about 3 hours of audio, taken from the PSTN, where the call changes several times per seond. This is quite a tough test. The Mitel tape is about 30 minutes of audio passages recorded from the PSTN. Here they change the call every sentance or two, so the character os the test is somewhat different. It is much easier to get a good result with the Mitel tape, for various reasons, although I have found the Mitel tape a pretty good one for exercising talk-off issues in things like 2280Hz and 2600Hz signalling tone detectors. The detection performance of DTMF detectors is usually quoted by their performance against the other data Mitel provided - a set of DTMF digits with various distortions of level, frequency and noise component. I took the spec for that data, and built a test suite which synthesises the relevant signals more precisely than the recordings on the Mitel tape. I encourage anyone interested in DTMF to make use of that work. Regards, Steve On 03/29/2010 06:17 AM, Wyss, Felix wrote: > > Christian, > > Telcordia sells the "Bellcore tape" DTMF talk-off immunity test > recordings as a set of 3 CDs: > > http://telecom-info.telcordia.com/site-cgi/ido/docs.cgi?ID=SEARCH&DOCUMENT=FR-763-01 > > > --Felix > > *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On > Behalf Of *Christian Hoene > *Sent:* Sunday, March 28, 2010 10:22 > *To:* codec@ietf.org > *Subject:* Re: [codec] #5: Mention DTMF in requirements, Testing DTMF? > > Hi, > > I found some open source DTMF code at > > http://www.soft-switch.org/spandsp-modules.html > > Does anybody has access to nice DTMF sample files such as those > describe in > > http://www.soft-switch.org/spandsp_faq/ar01s13.html ? > > Christian > > --------------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of Tübingen > > Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > *From:* Michael Knappe [mailto:mknappe@juniper.net] > *Sent:* Friday, March 26, 2010 11:38 PM > *To:* stephen.botzko@gmail.com; hoene@uni-tuebingen.de > *Cc:* codec@ietf.org > *Subject:* Re: [codec] #5: Mention DTMF in requirements > > I would agree with 'should'. Lot's of dtmf out there still, but also > out of band options (rfc 2833 / 4733) that make in-band carriage less > a concern for SIP telephony applications. > > Mik > > ------------------------------------------------------------------------ > > *From*: codec-bounces@ietf.org > *To*: Christian Hoene > *Cc*: codec@ietf.org > *Sent*: Fri Mar 26 18:10:31 2010 > *Subject*: Re: [codec] #5: Mention DTMF in requirements > > Perhaps analog DTMF carriage is a SHOULD? > > I agree that out-of-band is preferable, however, there still are > scenarios where coded DTMF tones will be sent. It would be nice > (though IMHO not essential) for this carriage to work. > > Stephen Botzko > > On Fri, Mar 26, 2010 at 3:04 PM, Christian Hoene > > wrote: > > Hi, > > > > If the point of this issue to allow this codec to be used to > successfully > > transit an IP network between two TDM networks, > > which is not the primary use-case. > > > > I'd suggest that out-of- > > band tone transport is far preferable to trying to ensure that the codec > > will carry the tones adequately to allow them to be detected after > > regeneration. > > I totally agree. Out-of-band is much better than inband. > > Sorry for my radical view but I believe that analog DTMF is an old and > obsolete technology not worth considering anymore. > > Christian > > From steveu@coppice.org Thu Apr 1 23:26:25 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B81B43A688E for ; Thu, 1 Apr 2010 23:26:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IS9JOrj94cJg for ; Thu, 1 Apr 2010 23:26:25 -0700 (PDT) Received: from cwb.pacific.net.hk (cwb.pacific.net.hk [202.14.67.92]) by core3.amsl.com (Postfix) with ESMTP id B9D8F3A680E for ; Thu, 1 Apr 2010 23:26:24 -0700 (PDT) Received: from i7.coppice.org (93.176.64.202.dyn.pacific.net.hk [202.64.176.93]) by cwb.pacific.net.hk with ESMTP id o326QvLC011573 for ; Fri, 2 Apr 2010 14:26:57 +0800 Message-ID: <4BB58E31.2050809@coppice.org> Date: Fri, 02 Apr 2010 14:26:57 +0800 From: Steve Underwood User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100301 Fedora/3.0.3-1.fc11 Thunderbird/3.0.3 MIME-Version: 1.0 To: codec@ietf.org References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <4BAF776D.20904@acm.org> <6e9223711003281100q7e1f7ac0pd548a2ab40e95ba4@mail.gmail.com> <4BAF9E7B.1070708@acm.org> In-Reply-To: <4BAF9E7B.1070708@acm.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 06:26:25 -0000 On 03/29/2010 02:22 AM, Marc Petit-Huguenin wrote: > On 03/28/2010 11:00 AM, stephen botzko wrote: > >> I would agree with this if I saw reasonable evidence that a >> preponderance of gateways and sending systems provide the signaling in >> these RFCs. >> >> Since I am not sure that this is the case, I am unconvinced that we can >> totally remove the requirement. >> >> I'd also say that an encoder that detects the DTMF tones and outputs the >> RFC 4733/34 events would fully meet the requirement. >> > As former CTO of a VoIP provider, I never saw a PSTN provider not supporting at > least RFC 2833 (even if one of them did not declare it in its SDP) > > Perhaps the question can be asked at the next SIPit event. > Its true that RFC2833 is widely deployed. Its even true that many systems have updated to RFC4733. Sadly, its also true that there are still many quirky implementations widely deployed, and a lot of people still need to interwork with audio DTMF. Steve From James.Rafferty@dialogic.com Fri Apr 2 06:48:03 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36E0C3A688F for ; Fri, 2 Apr 2010 06:48:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.68 X-Spam-Level: X-Spam-Status: No, score=0.68 tagged_above=-999 required=5 tests=[AWL=-0.451, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ej7zluq7EQL for ; Fri, 2 Apr 2010 06:48:02 -0700 (PDT) Received: from outbound.dialogic.com (outbound.dialogic.com [65.220.90.252]) by core3.amsl.com (Postfix) with ESMTP id 480A33A67AD for ; Fri, 2 Apr 2010 06:48:02 -0700 (PDT) Received: from MBX.dialogic.com ([fe80::d09:39e:8fa1:c2a3]) by pysxht01.dialogic.com ([::1]) with mapi; Fri, 2 Apr 2010 09:48:36 -0400 From: James Rafferty To: Steve Underwood , "codec@ietf.org" Date: Fri, 2 Apr 2010 09:48:35 -0400 Thread-Topic: [codec] #5: Mention DTMF in requirements Thread-Index: AcrSLYICzpKzCZEHRI6teFMrwXQ4wQAPUESw Message-ID: <617DF0128820F9458AC39149A627EE6C01A2A21146@MBX.dialogic.com> References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <4BAF776D.20904@acm.org> <6e9223711003281100q7e1f7ac0pd548a2ab40e95ba4@mail.gmail.com> <4BAF9E7B.1070708@acm.org> <4BB58E31.2050809@coppice.org> In-Reply-To: <4BB58E31.2050809@coppice.org> 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] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 13:48:03 -0000 I'd agree with Steve that are still many deployments which do not use RFC 2= 833 or RFC 4733. In our gateways, we've had to support interworking variati= ons of tone support such as INFO and in-band, in addition to the RFC 2833 /= RFC 4733. =20 James -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of S= teve Underwood Sent: Friday, April 02, 2010 2:27 AM To: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements On 03/29/2010 02:22 AM, Marc Petit-Huguenin wrote: > On 03/28/2010 11:00 AM, stephen botzko wrote: > =20 >> I would agree with this if I saw reasonable evidence that a >> preponderance of gateways and sending systems provide the signaling in >> these RFCs. >> >> Since I am not sure that this is the case, I am unconvinced that we can >> totally remove the requirement. >> >> I'd also say that an encoder that detects the DTMF tones and outputs the >> RFC 4733/34 events would fully meet the requirement. >> =20 > As former CTO of a VoIP provider, I never saw a PSTN provider not support= ing at > least RFC 2833 (even if one of them did not declare it in its SDP) > > Perhaps the question can be asked at the next SIPit event. > =20 Its true that RFC2833 is widely deployed. Its even true that many=20 systems have updated to RFC4733. Sadly, its also true that there are=20 still many quirky implementations widely deployed, and a lot of people=20 still need to interwork with audio DTMF. Steve _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From stephen.botzko@gmail.com Fri Apr 2 06:53:27 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E412D3A67DF for ; Fri, 2 Apr 2010 06:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.632 X-Spam-Level: X-Spam-Status: No, score=0.632 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfZCuxYgi9Mo for ; Fri, 2 Apr 2010 06:53:27 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id EC5CB3A67FA for ; Fri, 2 Apr 2010 06:53:24 -0700 (PDT) Received: by gwj15 with SMTP id 15so1388274gwj.31 for ; Fri, 02 Apr 2010 06:53:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=gz1j5U62TLm890sxteus2ctMmyXCIXVTClSOmvx1WGk=; b=Ao0Wiq+fyKM6cd1msfeRQPMwXVGemrCt84X2Dr7NxMV+UbncBmy3vUtmCpdwB3jDYr xqSBzIua+a/TMpTHl/rDeImSnT1srsn6vKHwQ49BQ1fIFmmq5iVDLgC07yM/FCrBMHwI K/qUcOiOLCu93RYTUe9D4tvh0DysjP3FtTz+c= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=p4eVIBsWG+RvV3P0TruSmpd3fpEEvDcjiSBEdMbRee8CMBy45trnbnjycuttyNlXZF cCxPDQxZ+Uh7AUOGU+XTaMucBpgA4gj7CWD7GShxVcFeAkwLOzjeDK/z5IQYC0K9A3lG wxhW15UB/VPAt765ltIlVXWcC8WAAqNubAoR4= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Fri, 2 Apr 2010 06:53:55 -0700 (PDT) In-Reply-To: <617DF0128820F9458AC39149A627EE6C01A2A21146@MBX.dialogic.com> References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <4BAF776D.20904@acm.org> <6e9223711003281100q7e1f7ac0pd548a2ab40e95ba4@mail.gmail.com> <4BAF9E7B.1070708@acm.org> <4BB58E31.2050809@coppice.org> <617DF0128820F9458AC39149A627EE6C01A2A21146@MBX.dialogic.com> Date: Fri, 2 Apr 2010 09:53:55 -0400 Received: by 10.100.235.11 with SMTP id i11mr5677613anh.128.1270216435932; Fri, 02 Apr 2010 06:53:55 -0700 (PDT) Message-ID: From: stephen botzko To: James Rafferty Content-Type: multipart/alternative; boundary=001636b2b05473a2f50483414f63 Cc: "codec@ietf.org" Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 13:53:28 -0000 --001636b2b05473a2f50483414f63 Content-Type: text/plain; charset=ISO-8859-1 Are you two suggesting that in-band DTMF is a MUST? Or alternatively a SHOULD? Stephen Botzko On Fri, Apr 2, 2010 at 9:48 AM, James Rafferty wrote: > I'd agree with Steve that are still many deployments which do not use RFC > 2833 or RFC 4733. In our gateways, we've had to support interworking > variations of tone support such as INFO and in-band, in addition to the RFC > 2833 / RFC 4733. > > James > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > Steve Underwood > Sent: Friday, April 02, 2010 2:27 AM > To: codec@ietf.org > Subject: Re: [codec] #5: Mention DTMF in requirements > > On 03/29/2010 02:22 AM, Marc Petit-Huguenin wrote: > > On 03/28/2010 11:00 AM, stephen botzko wrote: > > > >> I would agree with this if I saw reasonable evidence that a > >> preponderance of gateways and sending systems provide the signaling in > >> these RFCs. > >> > >> Since I am not sure that this is the case, I am unconvinced that we can > >> totally remove the requirement. > >> > >> I'd also say that an encoder that detects the DTMF tones and outputs the > >> RFC 4733/34 events would fully meet the requirement. > >> > > As former CTO of a VoIP provider, I never saw a PSTN provider not > supporting at > > least RFC 2833 (even if one of them did not declare it in its SDP) > > > > Perhaps the question can be asked at the next SIPit event. > > > Its true that RFC2833 is widely deployed. Its even true that many > systems have updated to RFC4733. Sadly, its also true that there are > still many quirky implementations widely deployed, and a lot of people > still need to interwork with audio DTMF. > > Steve > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636b2b05473a2f50483414f63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Are you two suggesting that in-band DTMF is a MUST?=A0 Or alternatively a S= HOULD?

Stephen Botzko

On Fri, Apr = 2, 2010 at 9:48 AM, James Rafferty <James.Rafferty@dialogic.com> wro= te:
I'd agree wit= h Steve that are still many deployments which do not use RFC 2833 or RFC 47= 33. In our gateways, we've had to support interworking variations of to= ne support such as INFO and in-band, in addition to the RFC 2833 / RFC 4733= .

James
-----Original Message-----
From: codec-bounces@ietf.org = [mailto:codec-bounces@ietf.org] On Behalf Of Steve Underwood
Sent: Friday, April 02, 2010 2:27 AM
To: codec@ietf.org
Subject: Re: [codec] #5: Mention DTMF in requirements

On 03/29/2010 02:22 AM, Marc Petit-= Huguenin wrote:
> On 03/28/2010 11:00 AM, stephen botzko wrote:
>
>> I would agree with this if I saw reasonable evidence that a
>> preponderance of gateways and sending systems provide the signalin= g in
>> these RFCs.
>>
>> Since I am not sure that this is the case, I am unconvinced that w= e can
>> totally remove the requirement.
>>
>> I'd also say that an encoder that detects the DTMF tones and o= utputs the
>> RFC 4733/34 events would fully meet the requirement.
>>
> As former CTO of a VoIP provider, I never saw a PSTN provider not supp= orting at
> least RFC 2833 (even if one of them did not declare it in its SDP)
>
> Perhaps the question can be asked at the next SIPit event.
>
Its true that RFC2833 is widely deployed. Its even true that many
systems have updated to RFC4733. Sadly, its also true that there are
still many quirky implementations widely deployed, and a lot of people
still need to interwork with audio DTMF.

Steve

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec
_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--001636b2b05473a2f50483414f63-- From stpeter@stpeter.im Fri Apr 2 06:56:41 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05C403A689F for ; Fri, 2 Apr 2010 06:56:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.063 X-Spam-Level: X-Spam-Status: No, score=0.063 tagged_above=-999 required=5 tests=[AWL=-1.068, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0FVYBCc-4oUv for ; Fri, 2 Apr 2010 06:56:40 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 2480C3A6886 for ; Fri, 2 Apr 2010 06:56:40 -0700 (PDT) Received: from squire.local (dsl-228-252.dynamic-dsl.frii.net [216.17.228.252]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 3DEE840E15 for ; Fri, 2 Apr 2010 07:57:13 -0600 (MDT) Message-ID: <4BB5F7B6.1080808@stpeter.im> Date: Fri, 02 Apr 2010 07:57:10 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: codec@ietf.org References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <4BAF776D.20904@acm.org> <6e9223711003281100q7e1f7ac0pd548a2ab40e95ba4@mail.gmail.com> <4BAF9E7B.1070708@acm.org> <4BB58E31.2050809@coppice.org> <617DF0128820F9458AC39149A627EE6C01A2A21146@MBX.dialogic.com> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms080907050306010707000305" Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 13:56:41 -0000 This is a cryptographically signed message in MIME format. --------------ms080907050306010707000305 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable How is the never-ending debate among DTMF signalling *methods* in-scope for the Codec WG? I think that Henning brought this up in Anaheim only to make sure that we test some DTMF tones. The signalling method is out of scope for the codec itself. On 4/2/10 7:53 AM, stephen botzko wrote: > Are you two suggesting that in-band DTMF is a MUST? Or alternatively a= > SHOULD? >=20 > Stephen Botzko >=20 > On Fri, Apr 2, 2010 at 9:48 AM, James Rafferty > > wrot= e: >=20 > I'd agree with Steve that are still many deployments which do not > use RFC 2833 or RFC 4733. In our gateways, we've had to support > interworking variations of tone support such as INFO and in-band, i= n > addition to the RFC 2833 / RFC 4733. >=20 > James > -----Original Message----- > From: codec-bounces@ietf.org > [mailto:codec-bounces@ietf.org ] On > Behalf Of Steve Underwood > Sent: Friday, April 02, 2010 2:27 AM > To: codec@ietf.org > Subject: Re: [codec] #5: Mention DTMF in requirements >=20 > On 03/29/2010 02:22 AM, Marc Petit-Huguenin wrote: > > On 03/28/2010 11:00 AM, stephen botzko wrote: > > > >> I would agree with this if I saw reasonable evidence that a > >> preponderance of gateways and sending systems provide the > signaling in > >> these RFCs. > >> > >> Since I am not sure that this is the case, I am unconvinced that= > we can > >> totally remove the requirement. > >> > >> I'd also say that an encoder that detects the DTMF tones and > outputs the > >> RFC 4733/34 events would fully meet the requirement. > >> > > As former CTO of a VoIP provider, I never saw a PSTN provider not= > supporting at > > least RFC 2833 (even if one of them did not declare it in its SDP= ) > > > > Perhaps the question can be asked at the next SIPit event. > > > Its true that RFC2833 is widely deployed. Its even true that many > systems have updated to RFC4733. Sadly, its also true that there ar= e > still many quirky implementations widely deployed, and a lot of peo= ple > still need to interwork with audio DTMF. >=20 > Steve --------------ms080907050306010707000305 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDQwMjEzNTcxMFowIwYJKoZIhvcNAQkEMRYEFKB7NcqZ7/9B3CGUm6ae 44dkJJT+MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAhT87f10AK/rnCJRy+Ov1DbtASXIrJuvsblE9xtB0 e6R+bGCaV7tivtLmP9+0bbS+vTJHfOxiRliHtRLZ9qZpfgZIYhENc6uVJQ4aQo+A2AZJrPqc xcoIzwZ9wU1evMfoYvTUufM8+JuEAVSC5I0yCXcw3SH03YTYaU9/fDp1QvOkUbvCKtvoH+dp XnZeskMibbhhIzfcvI/3SVZqri457bGSn/7fYwnIvYaklQL2QW4w3c0pKfgdzI33gpPS7p5t 9JO+bqDC5WqjKyFJzOiUO+CBVb7nsgZxDRJB9RtqDAdOO3z8qsKY9wxSlNH4P1KRn48pJl5Y DpzALUq1CC86ygAAAAAAAA== --------------ms080907050306010707000305-- From James.Rafferty@dialogic.com Fri Apr 2 06:58:39 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F1FE3A63EC for ; Fri, 2 Apr 2010 06:58:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.737 X-Spam-Level: X-Spam-Status: No, score=0.737 tagged_above=-999 required=5 tests=[AWL=-0.395, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WnIQpiOHSl48 for ; Fri, 2 Apr 2010 06:58:33 -0700 (PDT) Received: from outbound.dialogic.com (outbound.dialogic.com [65.220.90.252]) by core3.amsl.com (Postfix) with ESMTP id 721C83A62C1 for ; Fri, 2 Apr 2010 06:58:33 -0700 (PDT) Received: from MBX.dialogic.com ([fe80::d09:39e:8fa1:c2a3]) by pysxht02.dialogic.com ([::1]) with mapi; Fri, 2 Apr 2010 09:59:08 -0400 From: James Rafferty To: stephen botzko Date: Fri, 2 Apr 2010 09:59:06 -0400 Thread-Topic: [codec] #5: Mention DTMF in requirements Thread-Index: AcrSa/FKN5fRPsMJST6b6mYl8f1ciAAAHXDw Message-ID: <617DF0128820F9458AC39149A627EE6C01A2A2115B@MBX.dialogic.com> References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <4BAF776D.20904@acm.org> <6e9223711003281100q7e1f7ac0pd548a2ab40e95ba4@mail.gmail.com> <4BAF9E7B.1070708@acm.org> <4BB58E31.2050809@coppice.org> <617DF0128820F9458AC39149A627EE6C01A2A21146@MBX.dialogic.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_617DF0128820F9458AC39149A627EE6C01A2A2115BMBXdialogicco_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 13:58:39 -0000 --_000_617DF0128820F9458AC39149A627EE6C01A2A2115BMBXdialogicco_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Stephen, I'd suggest SHOULD. Using RFC 2833 / RFC 4733 is preferred to ensure passa= ge, but if the DTMF can be passed in native form and still be detectable, t= hat would be a big plus. James From: stephen botzko [mailto:stephen.botzko@gmail.com] Sent: Friday, April 02, 2010 9:54 AM To: James Rafferty Cc: Steve Underwood; codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements Are you two suggesting that in-band DTMF is a MUST? Or alternatively a SHO= ULD? Stephen Botzko On Fri, Apr 2, 2010 at 9:48 AM, James Rafferty > wrote: I'd agree with Steve that are still many deployments which do not use RFC 2= 833 or RFC 4733. In our gateways, we've had to support interworking variati= ons of tone support such as INFO and in-band, in addition to the RFC 2833 /= RFC 4733. James -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-b= ounces@ietf.org] On Behalf Of Steve Underwoo= d Sent: Friday, April 02, 2010 2:27 AM To: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements On 03/29/2010 02:22 AM, Marc Petit-Huguenin wrote: > On 03/28/2010 11:00 AM, stephen botzko wrote: > >> I would agree with this if I saw reasonable evidence that a >> preponderance of gateways and sending systems provide the signaling in >> these RFCs. >> >> Since I am not sure that this is the case, I am unconvinced that we can >> totally remove the requirement. >> >> I'd also say that an encoder that detects the DTMF tones and outputs the >> RFC 4733/34 events would fully meet the requirement. >> > As former CTO of a VoIP provider, I never saw a PSTN provider not support= ing at > least RFC 2833 (even if one of them did not declare it in its SDP) > > Perhaps the question can be asked at the next SIPit event. > Its true that RFC2833 is widely deployed. Its even true that many systems have updated to RFC4733. Sadly, its also true that there are still many quirky implementations widely deployed, and a lot of people still need to interwork with audio DTMF. Steve _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_617DF0128820F9458AC39149A627EE6C01A2A2115BMBXdialogicco_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Stephen,

 

I’d suggest SHOULD.  Using RFC 2833 / RFC 4733 is= preferred to ensure passage, but if the DTMF can be passed in native form and still be detectable, that would be a big plus. 

 

James

From: stephen botzk= o [mailto:stephen.botzko@gmail.com]
Sent: Friday, April 02, 2010 9:54 AM
To: James Rafferty
Cc: Steve Underwood; codec@ietf.org
Subject: Re: [codec] #5: Mention DTMF in requirements

 

Are you two suggesting = that in-band DTMF is a MUST?  Or alternatively a SHOULD?

Stephen Botzko

On Fri, Apr 2, 2010 at 9:48 AM, James Rafferty <James.Rafferty@dialogic.com= > wrote:

I'd agree with Steve that are still many deployments w= hich do not use RFC 2833 or RFC 4733. In our gateways, we've had to support interworking variations of tone support such as INFO and in-band, in additi= on to the RFC 2833 / RFC 4733.

James

-----Original Message--= ---
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Steve Underwood
Sent: Friday, April 02, 2010 2:27 AM
To: codec@ietf.org
Subject: Re: [codec] #5: Mention DTMF in requirements

On 03/29/2010 02:22 AM, Marc Petit-Huguenin wrote:
> On 03/28/2010 11:00 AM, stephen botzko wrote:
>
>> I would agree with this if I saw reasonable evidence that a
>> preponderance of gateways and sending systems provide the signalin= g in
>> these RFCs.
>>
>> Since I am not sure that this is the case, I am unconvinced that w= e can
>> totally remove the requirement.
>>
>> I'd also say that an encoder that detects the DTMF tones and outpu= ts the
>> RFC 4733/34 events would fully meet the requirement.
>>
> As former CTO of a VoIP provider, I never saw a PSTN provider not supporting at
> least RFC 2833 (even if one of them did not declare it in its SDP)
>
> Perhaps the question can be asked at the next SIPit event.
>
Its true that RFC2833 is widely deployed. Its even true that many
systems have updated to RFC4733. Sadly, its also true that there are
still many quirky implementations widely deployed, and a lot of people
still need to interwork with audio DTMF.

Steve

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec
_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

 

--_000_617DF0128820F9458AC39149A627EE6C01A2A2115BMBXdialogicco_-- From stephen.botzko@gmail.com Fri Apr 2 07:01:13 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30A1C3A63EC for ; Fri, 2 Apr 2010 07:01:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.799 X-Spam-Level: X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[AWL=-0.333, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0LjAvFSP6TWQ for ; Fri, 2 Apr 2010 07:01:12 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 016123A62C1 for ; Fri, 2 Apr 2010 07:01:11 -0700 (PDT) Received: by gwj15 with SMTP id 15so1392131gwj.31 for ; Fri, 02 Apr 2010 07:01:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=soj+aJShL6vTFqiEwb3ToHAYeEaqh+iARj/XYih8PKs=; b=IUmJ8wSZscEtIP2qcnRSjhHXQK+UVIM1qR97U/Eh9bmbVyESYWv9R5gJGl8b+ayPHa JXzkYO8C5YpDfGnW3n/H472qsiwOl7h99NGZTqbUcxgmFvXczbtXU5iXj8v96iV9AlP0 Yq1XxEelt6921IE5OIkJWxW3xNb1gwP2qLZqI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=UyO7DnTzyGVOyRIwj6/Q4KbzN9Y8GqWOecKVIXjtl7X7su0IWO+59GlwiZcvem4/5g ATfltSc4gM/5EMorjqm2o1CHJa5CUKhEuIjZKmTScQhDIWea6GR8jI0XR0UNBYs0E7i4 6TZ0V05UKlkUUYoZZpIEU611t+vYQY9mc/Qm8= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Fri, 2 Apr 2010 07:01:42 -0700 (PDT) In-Reply-To: <4BB5F7B6.1080808@stpeter.im> References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <4BAF776D.20904@acm.org> <6e9223711003281100q7e1f7ac0pd548a2ab40e95ba4@mail.gmail.com> <4BAF9E7B.1070708@acm.org> <4BB58E31.2050809@coppice.org> <617DF0128820F9458AC39149A627EE6C01A2A21146@MBX.dialogic.com> <4BB5F7B6.1080808@stpeter.im> Date: Fri, 2 Apr 2010 10:01:42 -0400 Received: by 10.151.16.4 with SMTP id t4mr2668194ybi.107.1270216902578; Fri, 02 Apr 2010 07:01:42 -0700 (PDT) Message-ID: From: stephen botzko To: Peter Saint-Andre Content-Type: multipart/alternative; boundary=000e0cd5c66e44141c0483416b68 Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 14:01:13 -0000 --000e0cd5c66e44141c0483416b68 Content-Type: text/plain; charset=ISO-8859-1 I heard no decision as to DTMF tone encoding. As far as I am concerned, the question of whether the codec MUST encode DTMF tones accurately enough to be detected at the decoder output (or SHOULD or non-requirement) is still open. That question clearly is in-scope, and has nothing to do with signaling. Stephen Botzko On Fri, Apr 2, 2010 at 9:57 AM, Peter Saint-Andre wrote: > How is the never-ending debate among DTMF signalling *methods* in-scope > for the Codec WG? I think that Henning brought this up in Anaheim only > to make sure that we test some DTMF tones. The signalling method is out > of scope for the codec itself. > > On 4/2/10 7:53 AM, stephen botzko wrote: > > Are you two suggesting that in-band DTMF is a MUST? Or alternatively a > > SHOULD? > > > > Stephen Botzko > > > > On Fri, Apr 2, 2010 at 9:48 AM, James Rafferty > > > > wrote: > > > > I'd agree with Steve that are still many deployments which do not > > use RFC 2833 or RFC 4733. In our gateways, we've had to support > > interworking variations of tone support such as INFO and in-band, in > > addition to the RFC 2833 / RFC 4733. > > > > James > > -----Original Message----- > > From: codec-bounces@ietf.org > > [mailto:codec-bounces@ietf.org ] On > > Behalf Of Steve Underwood > > Sent: Friday, April 02, 2010 2:27 AM > > To: codec@ietf.org > > Subject: Re: [codec] #5: Mention DTMF in requirements > > > > On 03/29/2010 02:22 AM, Marc Petit-Huguenin wrote: > > > On 03/28/2010 11:00 AM, stephen botzko wrote: > > > > > >> I would agree with this if I saw reasonable evidence that a > > >> preponderance of gateways and sending systems provide the > > signaling in > > >> these RFCs. > > >> > > >> Since I am not sure that this is the case, I am unconvinced that > > we can > > >> totally remove the requirement. > > >> > > >> I'd also say that an encoder that detects the DTMF tones and > > outputs the > > >> RFC 4733/34 events would fully meet the requirement. > > >> > > > As former CTO of a VoIP provider, I never saw a PSTN provider not > > supporting at > > > least RFC 2833 (even if one of them did not declare it in its SDP) > > > > > > Perhaps the question can be asked at the next SIPit event. > > > > > Its true that RFC2833 is widely deployed. Its even true that many > > systems have updated to RFC4733. Sadly, its also true that there are > > still many quirky implementations widely deployed, and a lot of > people > > still need to interwork with audio DTMF. > > > > Steve > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > --000e0cd5c66e44141c0483416b68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I heard no decision as to DTMF tone encoding.

As far as I am concer= ned, the question of whether the codec MUST encode DTMF tones accurately en= ough to be detected at the decoder output (or SHOULD or non-requirement) is= still open.

That question clearly is in-scope, and has nothing to do with signaling= .

Stephen Botzko

On Fri, Apr 2, 20= 10 at 9:57 AM, Peter Saint-Andre <stpeter@stpeter.im> wrote:
How is the never-= ending debate among DTMF signalling *methods* in-scope
for the Codec WG? I think that Henning brought this up in Anaheim only
to make sure that we test some DTMF tones. The signalling method is out
of scope for the codec itself.

On 4/2/10 7:53 AM, stephen botzko wrote:
> Are you two suggesting that in-band DTMF is a MUST? =A0Or alternativel= y a
> SHOULD?
>
> Stephen Botzko
>
> On Fri, Apr 2, 2010 at 9:48 AM, James Rafferty
> <James.Rafferty@dialogic.com <mailto:James.Rafferty@dialogic.com>> wrote:
>
> =A0 =A0 I'd agree with Steve that are still many deployments which= do not
> =A0 =A0 use RFC 2833 or RFC 4733. In our gateways, we've had to su= pport
> =A0 =A0 interworking variations of tone support such as INFO and in-ba= nd, in
> =A0 =A0 addition to the RFC 2833 / RFC 4733.
>
> =A0 =A0 James
> =A0 =A0 -----Original Message-----
> =A0 =A0 From: codec-bounces@= ietf.org <mailto:codec-bou= nces@ietf.org>
> =A0 =A0 [mailto:codec-bounces@ietf.org <mailto:codec-bounces@ietf.org>] On
> =A0 =A0 Behalf Of Steve Underwood
> =A0 =A0 Sent: Friday, April 02, 2010 2:27 AM
> =A0 =A0 To: codec@ietf.org <mailto:codec@ietf.org>
> =A0 =A0 Subject: Re: [codec] #5: Mention DTMF in requirements
>
> =A0 =A0 On 03/29/2010 02:22 AM, Marc Petit-Huguenin wrote:
> =A0 =A0 > On 03/28/2010 11:00 AM, stephen botzko wrote:
> =A0 =A0 >
> =A0 =A0 >> I would agree with this if I saw reasonable evidence = that a
> =A0 =A0 >> preponderance of gateways and sending systems provide= the
> =A0 =A0 signaling in
> =A0 =A0 >> these RFCs.
> =A0 =A0 >>
> =A0 =A0 >> Since I am not sure that this is the case, I am uncon= vinced that
> =A0 =A0 we can
> =A0 =A0 >> totally remove the requirement.
> =A0 =A0 >>
> =A0 =A0 >> I'd also say that an encoder that detects the DTM= F tones and
> =A0 =A0 outputs the
> =A0 =A0 >> RFC 4733/34 events would fully meet the requirement.<= br> > =A0 =A0 >>
> =A0 =A0 > As former CTO of a VoIP provider, I never saw a PSTN prov= ider not
> =A0 =A0 supporting at
> =A0 =A0 > least RFC 2833 (even if one of them did not declare it in= its SDP)
> =A0 =A0 >
> =A0 =A0 > Perhaps the question can be asked at the next SIPit event= .
> =A0 =A0 >
> =A0 =A0 Its true that RFC2833 is widely deployed. Its even true that m= any
> =A0 =A0 systems have updated to RFC4733. Sadly, its also true that the= re are
> =A0 =A0 still many quirky implementations widely deployed, and a lot o= f people
> =A0 =A0 still need to interwork with audio DTMF.
>
> =A0 =A0 Steve


_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec


--000e0cd5c66e44141c0483416b68-- From brian@freeswitch.org Fri Apr 2 07:07:06 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9619B3A6808 for ; Fri, 2 Apr 2010 07:07:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1PB--96v-62 for ; Fri, 2 Apr 2010 07:07:05 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id DC3D53A67FC for ; Fri, 2 Apr 2010 07:07:05 -0700 (PDT) Received: by pwj2 with SMTP id 2so355273pwj.31 for ; Fri, 02 Apr 2010 07:07:37 -0700 (PDT) Received: by 10.114.250.6 with SMTP id x6mr283561wah.33.1270217256981; Fri, 02 Apr 2010 07:07:36 -0700 (PDT) Received: from [192.168.1.221] (adsl-99-58-246-250.dsl.tul2ok.sbcglobal.net [99.58.246.250]) by mx.google.com with ESMTPS id 22sm8213012iwn.4.2010.04.02.07.07.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 07:07:35 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Brian West In-Reply-To: Date: Fri, 2 Apr 2010 09:07:34 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <4BAF776D.20904@acm.org> <6e9223711003281100q7e1f7ac0pd548a2ab40e95ba4@mail.gmail.com> <4BAF9E7B.1070708@acm.org> <4BB58E31.2050809@coppice.org> <617DF0128820F9458AC39149A627EE6C01A2A21146@MBX.dialogic.com> To: stephen botzko X-Mailer: Apple Mail (2.1078) Cc: "codec@ietf.org" , James Rafferty Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 14:07:06 -0000 I think SHOULD and MAY must not be used in any DRAFT or RFC it leaves = room for argument and ambiguous interpretations which lead to = incompatibilities (case in point SIP). As for DTMF, I would note that = any method that works could be used and mandating anything is really = outside the scope of the codec itself. You have INFO, KPML, 2833 or = In-Band. Granted if the codec is too lossy in-band is pointless and = unreliable. And if you wish this to scale to any degree server side = in-band should be DISALLOWED. And you would think 2833 is the wise = choice... but then again the MAY and SHOULD word screwed that up. /b On Apr 2, 2010, at 8:53 AM, stephen botzko wrote: > Are you two suggesting that in-band DTMF is a MUST? Or alternatively = a SHOULD? >=20 > Stephen Botzko From brian@freeswitch.org Fri Apr 2 07:07:46 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E0D83A63EC for ; Fri, 2 Apr 2010 07:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.038 X-Spam-Level: * X-Spam-Status: No, score=1.038 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-fs4-Jba6qx for ; Fri, 2 Apr 2010 07:07:45 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id C99143A62C1 for ; Fri, 2 Apr 2010 07:07:45 -0700 (PDT) Received: by pwj2 with SMTP id 2so355567pwj.31 for ; Fri, 02 Apr 2010 07:08:16 -0700 (PDT) Received: by 10.141.187.12 with SMTP id o12mr1568754rvp.43.1270217296075; Fri, 02 Apr 2010 07:08:16 -0700 (PDT) Received: from [192.168.1.221] (adsl-99-58-246-250.dsl.tul2ok.sbcglobal.net [99.58.246.250]) by mx.google.com with ESMTPS id 22sm8213012iwn.4.2010.04.02.07.08.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 07:08:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Brian West In-Reply-To: <4BB5F7B6.1080808@stpeter.im> Date: Fri, 2 Apr 2010 09:08:14 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2A471ED2-AEC9-4800-B2CE-A9CE9B5E2380@freeswitch.org> References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <4BAF776D.20904@acm.org> <6e9223711003281100q7e1f7ac0pd548a2ab40e95ba4@mail.gmail.com> <4BAF9E7B.1070708@acm.org> <4BB58E31.2050809@coppice.org> <617DF0128820F9458AC39149A627EE6C01A2A21146@MBX.dialogic.com> <4BB5F7B6.1080808@stpeter.im> To: Peter Saint-Andre X-Mailer: Apple Mail (2.1078) Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 14:07:46 -0000 I couldn't agree more. That was my first thought when the thread = initially started. /b On Apr 2, 2010, at 8:57 AM, Peter Saint-Andre wrote: > How is the never-ending debate among DTMF signalling *methods* = in-scope > for the Codec WG? I think that Henning brought this up in Anaheim only > to make sure that we test some DTMF tones. The signalling method is = out > of scope for the codec itself. From brian@freeswitch.org Fri Apr 2 07:08:09 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 252C63A67FC for ; Fri, 2 Apr 2010 07:08:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.085 X-Spam-Level: * X-Spam-Status: No, score=1.085 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I+TQTzvBuLKO for ; Fri, 2 Apr 2010 07:08:08 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 69B7F3A62C1 for ; Fri, 2 Apr 2010 07:08:08 -0700 (PDT) Received: by pvd12 with SMTP id 12so549877pvd.31 for ; Fri, 02 Apr 2010 07:08:38 -0700 (PDT) Received: by 10.142.210.15 with SMTP id i15mr763522wfg.256.1270217317870; Fri, 02 Apr 2010 07:08:37 -0700 (PDT) Received: from [192.168.1.221] (adsl-99-58-246-250.dsl.tul2ok.sbcglobal.net [99.58.246.250]) by mx.google.com with ESMTPS id 22sm8213012iwn.4.2010.04.02.07.08.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 07:08:37 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-10--147659670 From: Brian West In-Reply-To: <617DF0128820F9458AC39149A627EE6C01A2A2115B@MBX.dialogic.com> Date: Fri, 2 Apr 2010 09:08:36 -0500 Message-Id: References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <4BAF776D.20904@acm.org> <6e9223711003281100q7e1f7ac0pd548a2ab40e95ba4@mail.gmail.com> <4BAF9E7B.1070708@acm.org> <4BB58E31.2050809@coppice.org> <617DF0128820F9458AC39149A627EE6C01A2A21146@MBX.dialogic.com> <617DF0128820F9458AC39149A627EE6C01A2A2115B@MBX.dialogic.com> To: James Rafferty X-Mailer: Apple Mail (2.1078) Cc: "codec@ietf.org" , stephen botzko Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 14:08:09 -0000 --Apple-Mail-10--147659670 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 There is that word again... SHOULD. strike that from the draft along = with MAY. /b On Apr 2, 2010, at 8:59 AM, James Rafferty wrote: > Stephen, > =20 > I=92d suggest SHOULD. Using RFC 2833 / RFC 4733 is preferred to = ensure passage, but if the DTMF can be passed in native form and still = be detectable, that would be a big plus.=20 > =20 > James --Apple-Mail-10--147659670 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 There = is that word again... SHOULD.  strike that from the draft along = with MAY.

/b

On Apr 2, 2010, = at 8:59 AM, James Rafferty wrote:

I=92d = suggest SHOULD.  Using RFC 2833 / RFC 4733 is preferred to ensure = passage, but if the DTMF can be passed in native form and still be = detectable, that would be a big plus. 
, "stpeter@stpeter.im" Date: Fri, 2 Apr 2010 07:19:49 -0700 Thread-Topic: [codec] #5: Mention DTMF in requirements Thread-Index: AcrSbQpsirGh3cEjSOW6u2qaUrLm0gAAoG1h Message-ID: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_05542EC42316164383B5180707A489EE1D0AA5F58EEMBX02HQjnprn_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 14:20:44 -0000 --_000_05542EC42316164383B5180707A489EE1D0AA5F58EEMBX02HQjnprn_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWdyZWVkLg0KDQpNaWtlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpGcm9t OiBjb2RlYy1ib3VuY2VzQGlldGYub3JnIDxjb2RlYy1ib3VuY2VzQGlldGYub3JnPg0KVG86IFBl dGVyIFNhaW50LUFuZHJlIDxzdHBldGVyQHN0cGV0ZXIuaW0+DQpDYzogY29kZWNAaWV0Zi5vcmcg PGNvZGVjQGlldGYub3JnPg0KU2VudDogRnJpIEFwciAwMiAxMDowMTo0MiAyMDEwDQpTdWJqZWN0 OiBSZTogW2NvZGVjXSAjNTogTWVudGlvbiBEVE1GIGluIHJlcXVpcmVtZW50cw0KDQpJIGhlYXJk IG5vIGRlY2lzaW9uIGFzIHRvIERUTUYgdG9uZSBlbmNvZGluZy4NCg0KQXMgZmFyIGFzIEkgYW0g Y29uY2VybmVkLCB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciB0aGUgY29kZWMgTVVTVCBlbmNvZGUg RFRNRiB0b25lcyBhY2N1cmF0ZWx5IGVub3VnaCB0byBiZSBkZXRlY3RlZCBhdCB0aGUgZGVjb2Rl ciBvdXRwdXQgKG9yIFNIT1VMRCBvciBub24tcmVxdWlyZW1lbnQpIGlzIHN0aWxsIG9wZW4uDQoN ClRoYXQgcXVlc3Rpb24gY2xlYXJseSBpcyBpbi1zY29wZSwgYW5kIGhhcyBub3RoaW5nIHRvIGRv IHdpdGggc2lnbmFsaW5nLg0KDQpTdGVwaGVuIEJvdHprbw0KDQpPbiBGcmksIEFwciAyLCAyMDEw IGF0IDk6NTcgQU0sIFBldGVyIFNhaW50LUFuZHJlIDxzdHBldGVyQHN0cGV0ZXIuaW08bWFpbHRv OnN0cGV0ZXJAc3RwZXRlci5pbT4+IHdyb3RlOg0KSG93IGlzIHRoZSBuZXZlci1lbmRpbmcgZGVi YXRlIGFtb25nIERUTUYgc2lnbmFsbGluZyAqbWV0aG9kcyogaW4tc2NvcGUNCmZvciB0aGUgQ29k ZWMgV0c/IEkgdGhpbmsgdGhhdCBIZW5uaW5nIGJyb3VnaHQgdGhpcyB1cCBpbiBBbmFoZWltIG9u bHkNCnRvIG1ha2Ugc3VyZSB0aGF0IHdlIHRlc3Qgc29tZSBEVE1GIHRvbmVzLiBUaGUgc2lnbmFs bGluZyBtZXRob2QgaXMgb3V0DQpvZiBzY29wZSBmb3IgdGhlIGNvZGVjIGl0c2VsZi4NCg0KT24g NC8yLzEwIDc6NTMgQU0sIHN0ZXBoZW4gYm90emtvIHdyb3RlOg0KPiBBcmUgeW91IHR3byBzdWdn ZXN0aW5nIHRoYXQgaW4tYmFuZCBEVE1GIGlzIGEgTVVTVD8gIE9yIGFsdGVybmF0aXZlbHkgYQ0K PiBTSE9VTEQ/DQo+DQo+IFN0ZXBoZW4gQm90emtvDQo+DQo+IE9uIEZyaSwgQXByIDIsIDIwMTAg YXQgOTo0OCBBTSwgSmFtZXMgUmFmZmVydHkNCj4gPEphbWVzLlJhZmZlcnR5QGRpYWxvZ2ljLmNv bTxtYWlsdG86SmFtZXMuUmFmZmVydHlAZGlhbG9naWMuY29tPiA8bWFpbHRvOkphbWVzLlJhZmZl cnR5QGRpYWxvZ2ljLmNvbTxtYWlsdG86SmFtZXMuUmFmZmVydHlAZGlhbG9naWMuY29tPj4+IHdy b3RlOg0KPg0KPiAgICAgSSdkIGFncmVlIHdpdGggU3RldmUgdGhhdCBhcmUgc3RpbGwgbWFueSBk ZXBsb3ltZW50cyB3aGljaCBkbyBub3QNCj4gICAgIHVzZSBSRkMgMjgzMyBvciBSRkMgNDczMy4g SW4gb3VyIGdhdGV3YXlzLCB3ZSd2ZSBoYWQgdG8gc3VwcG9ydA0KPiAgICAgaW50ZXJ3b3JraW5n IHZhcmlhdGlvbnMgb2YgdG9uZSBzdXBwb3J0IHN1Y2ggYXMgSU5GTyBhbmQgaW4tYmFuZCwgaW4N Cj4gICAgIGFkZGl0aW9uIHRvIHRoZSBSRkMgMjgzMyAvIFJGQyA0NzMzLg0KPg0KPiAgICAgSmFt ZXMNCj4gICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ICAgICBGcm9tOiBjb2RlYy1i b3VuY2VzQGlldGYub3JnPG1haWx0bzpjb2RlYy1ib3VuY2VzQGlldGYub3JnPiA8bWFpbHRvOmNv ZGVjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNvZGVjLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KPiAg ICAgW21haWx0bzpjb2RlYy1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpjb2RlYy1ib3VuY2VzQGll dGYub3JnPiA8bWFpbHRvOmNvZGVjLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmNvZGVjLWJvdW5j ZXNAaWV0Zi5vcmc+Pl0gT24NCj4gICAgIEJlaGFsZiBPZiBTdGV2ZSBVbmRlcndvb2QNCj4gICAg IFNlbnQ6IEZyaWRheSwgQXByaWwgMDIsIDIwMTAgMjoyNyBBTQ0KPiAgICAgVG86IGNvZGVjQGll dGYub3JnPG1haWx0bzpjb2RlY0BpZXRmLm9yZz4gPG1haWx0bzpjb2RlY0BpZXRmLm9yZzxtYWls dG86Y29kZWNAaWV0Zi5vcmc+Pg0KPiAgICAgU3ViamVjdDogUmU6IFtjb2RlY10gIzU6IE1lbnRp b24gRFRNRiBpbiByZXF1aXJlbWVudHMNCj4NCj4gICAgIE9uIDAzLzI5LzIwMTAgMDI6MjIgQU0s IE1hcmMgUGV0aXQtSHVndWVuaW4gd3JvdGU6DQo+ICAgICA+IE9uIDAzLzI4LzIwMTAgMTE6MDAg QU0sIHN0ZXBoZW4gYm90emtvIHdyb3RlOg0KPiAgICAgPg0KPiAgICAgPj4gSSB3b3VsZCBhZ3Jl ZSB3aXRoIHRoaXMgaWYgSSBzYXcgcmVhc29uYWJsZSBldmlkZW5jZSB0aGF0IGENCj4gICAgID4+ IHByZXBvbmRlcmFuY2Ugb2YgZ2F0ZXdheXMgYW5kIHNlbmRpbmcgc3lzdGVtcyBwcm92aWRlIHRo ZQ0KPiAgICAgc2lnbmFsaW5nIGluDQo+ICAgICA+PiB0aGVzZSBSRkNzLg0KPiAgICAgPj4NCj4g ICAgID4+IFNpbmNlIEkgYW0gbm90IHN1cmUgdGhhdCB0aGlzIGlzIHRoZSBjYXNlLCBJIGFtIHVu Y29udmluY2VkIHRoYXQNCj4gICAgIHdlIGNhbg0KPiAgICAgPj4gdG90YWxseSByZW1vdmUgdGhl IHJlcXVpcmVtZW50Lg0KPiAgICAgPj4NCj4gICAgID4+IEknZCBhbHNvIHNheSB0aGF0IGFuIGVu Y29kZXIgdGhhdCBkZXRlY3RzIHRoZSBEVE1GIHRvbmVzIGFuZA0KPiAgICAgb3V0cHV0cyB0aGUN Cj4gICAgID4+IFJGQyA0NzMzLzM0IGV2ZW50cyB3b3VsZCBmdWxseSBtZWV0IHRoZSByZXF1aXJl bWVudC4NCj4gICAgID4+DQo+ICAgICA+IEFzIGZvcm1lciBDVE8gb2YgYSBWb0lQIHByb3ZpZGVy LCBJIG5ldmVyIHNhdyBhIFBTVE4gcHJvdmlkZXIgbm90DQo+ICAgICBzdXBwb3J0aW5nIGF0DQo+ ICAgICA+IGxlYXN0IFJGQyAyODMzIChldmVuIGlmIG9uZSBvZiB0aGVtIGRpZCBub3QgZGVjbGFy ZSBpdCBpbiBpdHMgU0RQKQ0KPiAgICAgPg0KPiAgICAgPiBQZXJoYXBzIHRoZSBxdWVzdGlvbiBj YW4gYmUgYXNrZWQgYXQgdGhlIG5leHQgU0lQaXQgZXZlbnQuDQo+ICAgICA+DQo+ICAgICBJdHMg dHJ1ZSB0aGF0IFJGQzI4MzMgaXMgd2lkZWx5IGRlcGxveWVkLiBJdHMgZXZlbiB0cnVlIHRoYXQg bWFueQ0KPiAgICAgc3lzdGVtcyBoYXZlIHVwZGF0ZWQgdG8gUkZDNDczMy4gU2FkbHksIGl0cyBh bHNvIHRydWUgdGhhdCB0aGVyZSBhcmUNCj4gICAgIHN0aWxsIG1hbnkgcXVpcmt5IGltcGxlbWVu dGF0aW9ucyB3aWRlbHkgZGVwbG95ZWQsIGFuZCBhIGxvdCBvZiBwZW9wbGUNCj4gICAgIHN0aWxs IG5lZWQgdG8gaW50ZXJ3b3JrIHdpdGggYXVkaW8gRFRNRi4NCj4NCj4gICAgIFN0ZXZlDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCmNvZGVjIG1h aWxpbmcgbGlzdA0KY29kZWNAaWV0Zi5vcmc8bWFpbHRvOmNvZGVjQGlldGYub3JnPg0KaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb2RlYw0KDQoNCg== --_000_05542EC42316164383B5180707A489EE1D0AA5F58EEMBX02HQjnprn_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PHA+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD4NCkFncmVlZC48YnI+PGJyPk1p a2U8L2ZvbnQ+PC9wPg0KPHA+PGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRh YmluZGV4PS0xPg0KPGZvbnQgZmFjZT1UYWhvbWEgc2l6ZT0yPg0KPGI+RnJvbTwvYj46IGNvZGVj LWJvdW5jZXNAaWV0Zi5vcmcgJmx0O2NvZGVjLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7DTxicj48Yj5U bzwvYj46IFBldGVyIFNhaW50LUFuZHJlICZsdDtzdHBldGVyQHN0cGV0ZXIuaW0mZ3Q7DTxicj48 Yj5DYzwvYj46IGNvZGVjQGlldGYub3JnICZsdDtjb2RlY0BpZXRmLm9yZyZndDsNPGJyPjxiPlNl bnQ8L2I+OiBGcmkgQXByIDAyIDEwOjAxOjQyIDIwMTA8YnI+PGI+U3ViamVjdDwvYj46IFJlOiBb Y29kZWNdICM1OiBNZW50aW9uIERUTUYgaW4gcmVxdWlyZW1lbnRzDTxicj48L2ZvbnQ+PC9wPg0K SSBoZWFyZCBubyBkZWNpc2lvbiBhcyB0byBEVE1GIHRvbmUgZW5jb2RpbmcuIDxicj48YnI+QXMg ZmFyIGFzIEkgYW0gY29uY2VybmVkLCB0aGUgcXVlc3Rpb24gb2Ygd2hldGhlciB0aGUgY29kZWMg TVVTVCBlbmNvZGUgRFRNRiB0b25lcyBhY2N1cmF0ZWx5IGVub3VnaCB0byBiZSBkZXRlY3RlZCBh dCB0aGUgZGVjb2RlciBvdXRwdXQgKG9yIFNIT1VMRCBvciBub24tcmVxdWlyZW1lbnQpIGlzIHN0 aWxsIG9wZW4uPGJyPg0KPGJyPlRoYXQgcXVlc3Rpb24gY2xlYXJseSBpcyBpbi1zY29wZSwgYW5k IGhhcyBub3RoaW5nIHRvIGRvIHdpdGggc2lnbmFsaW5nLjxicj48YnI+U3RlcGhlbiBCb3R6a288 YnI+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX3F1b3RlIj5PbiBGcmksIEFwciAyLCAyMDEwIGF0IDk6 NTcgQU0sIFBldGVyIFNhaW50LUFuZHJlIDxzcGFuIGRpcj0ibHRyIj4mbHQ7PGEgaHJlZj0ibWFp bHRvOnN0cGV0ZXJAc3RwZXRlci5pbSI+c3RwZXRlckBzdHBldGVyLmltPC9hPiZndDs8L3NwYW4+ IHdyb3RlOjxicj4NCjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5bGU9Im1hcmdp bjogMHB0IDBwdCAwcHQgMC44ZXg7IGJvcmRlci1sZWZ0OiAxcHggc29saWQgcmdiKDIwNCwgMjA0 LCAyMDQpOyBwYWRkaW5nLWxlZnQ6IDFleDsiPkhvdyBpcyB0aGUgbmV2ZXItZW5kaW5nIGRlYmF0 ZSBhbW9uZyBEVE1GIHNpZ25hbGxpbmcgKm1ldGhvZHMqIGluLXNjb3BlPGJyPg0KZm9yIHRoZSBD b2RlYyBXRz8gSSB0aGluayB0aGF0IEhlbm5pbmcgYnJvdWdodCB0aGlzIHVwIGluIEFuYWhlaW0g b25seTxicj4NCnRvIG1ha2Ugc3VyZSB0aGF0IHdlIHRlc3Qgc29tZSBEVE1GIHRvbmVzLiBUaGUg c2lnbmFsbGluZyBtZXRob2QgaXMgb3V0PGJyPg0Kb2Ygc2NvcGUgZm9yIHRoZSBjb2RlYyBpdHNl bGYuPGJyPg0KPGRpdiBjbGFzcz0iaW0iPjxicj4NCk9uIDQvMi8xMCA3OjUzIEFNLCBzdGVwaGVu IGJvdHprbyB3cm90ZTo8YnI+DQomZ3Q7IEFyZSB5b3UgdHdvIHN1Z2dlc3RpbmcgdGhhdCBpbi1i YW5kIERUTUYgaXMgYSBNVVNUPyDCoE9yIGFsdGVybmF0aXZlbHkgYTxicj4NCiZndDsgU0hPVUxE Pzxicj4NCiZndDs8YnI+DQomZ3Q7IFN0ZXBoZW4gQm90emtvPGJyPg0KJmd0Ozxicj4NCiZndDsg T24gRnJpLCBBcHIgMiwgMjAxMCBhdCA5OjQ4IEFNLCBKYW1lcyBSYWZmZXJ0eTxicj4NCjwvZGl2 PjxkaXYgY2xhc3M9ImltIj4mZ3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86SmFtZXMuUmFmZmVydHlA ZGlhbG9naWMuY29tIj5KYW1lcy5SYWZmZXJ0eUBkaWFsb2dpYy5jb208L2E+ICZsdDttYWlsdG86 PGEgaHJlZj0ibWFpbHRvOkphbWVzLlJhZmZlcnR5QGRpYWxvZ2ljLmNvbSI+SmFtZXMuUmFmZmVy dHlAZGlhbG9naWMuY29tPC9hPiZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDs8YnI+DQomZ3Q7IMKg IMKgIEkmIzM5O2QgYWdyZWUgd2l0aCBTdGV2ZSB0aGF0IGFyZSBzdGlsbCBtYW55IGRlcGxveW1l bnRzIHdoaWNoIGRvIG5vdDxicj4NCiZndDsgwqAgwqAgdXNlIFJGQyAyODMzIG9yIFJGQyA0NzMz LiBJbiBvdXIgZ2F0ZXdheXMsIHdlJiMzOTt2ZSBoYWQgdG8gc3VwcG9ydDxicj4NCiZndDsgwqAg wqAgaW50ZXJ3b3JraW5nIHZhcmlhdGlvbnMgb2YgdG9uZSBzdXBwb3J0IHN1Y2ggYXMgSU5GTyBh bmQgaW4tYmFuZCwgaW48YnI+DQomZ3Q7IMKgIMKgIGFkZGl0aW9uIHRvIHRoZSBSRkMgMjgzMyAv IFJGQyA0NzMzLjxicj4NCiZndDs8YnI+DQomZ3Q7IMKgIMKgIEphbWVzPGJyPg0KJmd0OyDCoCDC oCAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLTxicj4NCiZndDsgwqAgwqAgRnJvbTogPGEgaHJl Zj0ibWFpbHRvOmNvZGVjLWJvdW5jZXNAaWV0Zi5vcmciPmNvZGVjLWJvdW5jZXNAaWV0Zi5vcmc8 L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmNvZGVjLWJvdW5jZXNAaWV0Zi5vcmciPmNv ZGVjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjwvZGl2PjxkaXYgY2xhc3M9ImltIj4m Z3Q7IMKgIMKgIFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmNvZGVjLWJvdW5jZXNAaWV0Zi5vcmci PmNvZGVjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOmNv ZGVjLWJvdW5jZXNAaWV0Zi5vcmciPmNvZGVjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0O10gT248 YnI+DQomZ3Q7IMKgIMKgIEJlaGFsZiBPZiBTdGV2ZSBVbmRlcndvb2Q8YnI+DQomZ3Q7IMKgIMKg IFNlbnQ6IEZyaWRheSwgQXByaWwgMDIsIDIwMTAgMjoyNyBBTTxicj4NCjwvZGl2PjxkaXY+PGRp dj48L2Rpdj48ZGl2IGNsYXNzPSJoNSI+Jmd0OyDCoCDCoCBUbzogPGEgaHJlZj0ibWFpbHRvOmNv ZGVjQGlldGYub3JnIj5jb2RlY0BpZXRmLm9yZzwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWls dG86Y29kZWNAaWV0Zi5vcmciPmNvZGVjQGlldGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7IMKgIMKg IFN1YmplY3Q6IFJlOiBbY29kZWNdICM1OiBNZW50aW9uIERUTUYgaW4gcmVxdWlyZW1lbnRzPGJy Pg0KJmd0Ozxicj4NCiZndDsgwqAgwqAgT24gMDMvMjkvMjAxMCAwMjoyMiBBTSwgTWFyYyBQZXRp dC1IdWd1ZW5pbiB3cm90ZTo8YnI+DQomZ3Q7IMKgIMKgICZndDsgT24gMDMvMjgvMjAxMCAxMTow MCBBTSwgc3RlcGhlbiBib3R6a28gd3JvdGU6PGJyPg0KJmd0OyDCoCDCoCAmZ3Q7PGJyPg0KJmd0 OyDCoCDCoCAmZ3Q7Jmd0OyBJIHdvdWxkIGFncmVlIHdpdGggdGhpcyBpZiBJIHNhdyByZWFzb25h YmxlIGV2aWRlbmNlIHRoYXQgYTxicj4NCiZndDsgwqAgwqAgJmd0OyZndDsgcHJlcG9uZGVyYW5j ZSBvZiBnYXRld2F5cyBhbmQgc2VuZGluZyBzeXN0ZW1zIHByb3ZpZGUgdGhlPGJyPg0KJmd0OyDC oCDCoCBzaWduYWxpbmcgaW48YnI+DQomZ3Q7IMKgIMKgICZndDsmZ3Q7IHRoZXNlIFJGQ3MuPGJy Pg0KJmd0OyDCoCDCoCAmZ3Q7Jmd0Ozxicj4NCiZndDsgwqAgwqAgJmd0OyZndDsgU2luY2UgSSBh bSBub3Qgc3VyZSB0aGF0IHRoaXMgaXMgdGhlIGNhc2UsIEkgYW0gdW5jb252aW5jZWQgdGhhdDxi cj4NCiZndDsgwqAgwqAgd2UgY2FuPGJyPg0KJmd0OyDCoCDCoCAmZ3Q7Jmd0OyB0b3RhbGx5IHJl bW92ZSB0aGUgcmVxdWlyZW1lbnQuPGJyPg0KJmd0OyDCoCDCoCAmZ3Q7Jmd0Ozxicj4NCiZndDsg wqAgwqAgJmd0OyZndDsgSSYjMzk7ZCBhbHNvIHNheSB0aGF0IGFuIGVuY29kZXIgdGhhdCBkZXRl Y3RzIHRoZSBEVE1GIHRvbmVzIGFuZDxicj4NCiZndDsgwqAgwqAgb3V0cHV0cyB0aGU8YnI+DQom Z3Q7IMKgIMKgICZndDsmZ3Q7IFJGQyA0NzMzLzM0IGV2ZW50cyB3b3VsZCBmdWxseSBtZWV0IHRo ZSByZXF1aXJlbWVudC48YnI+DQomZ3Q7IMKgIMKgICZndDsmZ3Q7PGJyPg0KJmd0OyDCoCDCoCAm Z3Q7IEFzIGZvcm1lciBDVE8gb2YgYSBWb0lQIHByb3ZpZGVyLCBJIG5ldmVyIHNhdyBhIFBTVE4g cHJvdmlkZXIgbm90PGJyPg0KJmd0OyDCoCDCoCBzdXBwb3J0aW5nIGF0PGJyPg0KJmd0OyDCoCDC oCAmZ3Q7IGxlYXN0IFJGQyAyODMzIChldmVuIGlmIG9uZSBvZiB0aGVtIGRpZCBub3QgZGVjbGFy ZSBpdCBpbiBpdHMgU0RQKTxicj4NCiZndDsgwqAgwqAgJmd0Ozxicj4NCiZndDsgwqAgwqAgJmd0 OyBQZXJoYXBzIHRoZSBxdWVzdGlvbiBjYW4gYmUgYXNrZWQgYXQgdGhlIG5leHQgU0lQaXQgZXZl bnQuPGJyPg0KJmd0OyDCoCDCoCAmZ3Q7PGJyPg0KJmd0OyDCoCDCoCBJdHMgdHJ1ZSB0aGF0IFJG QzI4MzMgaXMgd2lkZWx5IGRlcGxveWVkLiBJdHMgZXZlbiB0cnVlIHRoYXQgbWFueTxicj4NCiZn dDsgwqAgwqAgc3lzdGVtcyBoYXZlIHVwZGF0ZWQgdG8gUkZDNDczMy4gU2FkbHksIGl0cyBhbHNv IHRydWUgdGhhdCB0aGVyZSBhcmU8YnI+DQomZ3Q7IMKgIMKgIHN0aWxsIG1hbnkgcXVpcmt5IGlt cGxlbWVudGF0aW9ucyB3aWRlbHkgZGVwbG95ZWQsIGFuZCBhIGxvdCBvZiBwZW9wbGU8YnI+DQom Z3Q7IMKgIMKgIHN0aWxsIG5lZWQgdG8gaW50ZXJ3b3JrIHdpdGggYXVkaW8gRFRNRi48YnI+DQom Z3Q7PGJyPg0KJmd0OyDCoCDCoCBTdGV2ZTxicj4NCjxicj4NCjwvZGl2PjwvZGl2Pjxicj5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmNvZGVjIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpjb2RlY0BpZXRmLm9yZyI+Y29kZWNAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jb2RlYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY29kZWM8L2E+PGJyPg0KPGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+DQo= --_000_05542EC42316164383B5180707A489EE1D0AA5F58EEMBX02HQjnprn_-- From hoene@uni-tuebingen.de Fri Apr 2 07:21:14 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 227503A67DF for ; Fri, 2 Apr 2010 07:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.519 X-Spam-Level: X-Spam-Status: No, score=-2.519 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zVZxV6MszM1S for ; Fri, 2 Apr 2010 07:21:12 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 0E8DE3A68E9 for ; Fri, 2 Apr 2010 07:20:47 -0700 (PDT) Received: from hoeneT60 ([178.2.210.31]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o32DisFt003127 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 2 Apr 2010 16:21:20 +0200 From: "Christian Hoene" To: References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <4BAF776D.20904@acm.org> <6e9223711003281100q7e1f7ac0pd548a2ab40e95ba4@mail.gmail.com> <4BAF9E7B.1070708@acm.org> <4BB58E31.2050809@coppice.org> <617DF0128820F9458AC39149A627EE6C01A2A21146@MBX.dialogic.com> <4BB5F7B6.1080808@stpeter.im> <0BD7AE28-298A-4586-9FB4-33925A8F8B8C@freeswitch.org> In-Reply-To: <0BD7AE28-298A-4586-9FB4-33925A8F8B8C@freeswitch.org> Date: Fri, 2 Apr 2010 16:21:18 +0200 Message-ID: <003601cad26f$c376b520$4a641f60$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrSbkNA5SPM6/VSQxSAGnqDUxe/FAAAMCEQ Content-Language: de X-AntiVirus-Spam-Check: failed (checked by Avira MailGate: version: 3.0.0-4; spam filter version: unknown; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.210; VDF: 7.10.6.23; host: mx05); id=10834-UrsyZ7 Subject: Re: [codec] #5: Mention in requirements, FAX? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 14:21:14 -0000 Hi guys, just for the notes. Testing Fax = (http://en.wikipedia.org/wiki/Fax#History) is definitely out of scope? Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Brian West >Sent: Friday, April 02, 2010 4:10 PM >To: stephen botzko >Cc: codec@ietf.org >Subject: Re: [codec] #5: Mention DTMF in requirements > >But Codecs themselves do not detect DTMF. Thats the job of the DTMF = detector. NOT the codec. In all >my work with codecs I have not once seen one that knows anything about = DTMF. And if the codec is too >lossy inband is out of the question. > >/b > >On Apr 2, 2010, at 9:01 AM, stephen botzko wrote: > >> I heard no decision as to DTMF tone encoding. >> >> As far as I am concerned, the question of whether the codec MUST = encode DTMF tones accurately enough >to be detected at the decoder output (or SHOULD or non-requirement) is = still open. >> >> That question clearly is in-scope, and has nothing to do with = signaling. >> >> Stephen Botzko > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From mknappe@juniper.net Fri Apr 2 07:26:14 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2DB123A67FA for ; Fri, 2 Apr 2010 07:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.081 X-Spam-Level: X-Spam-Status: No, score=-5.081 tagged_above=-999 required=5 tests=[AWL=0.388, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E8G2KGk3J1df for ; Fri, 2 Apr 2010 07:26:13 -0700 (PDT) Received: from exprod7og106.obsmtp.com (exprod7og106.obsmtp.com [64.18.2.165]) by core3.amsl.com (Postfix) with ESMTP id D50AA3A679C for ; Fri, 2 Apr 2010 07:26:12 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob106.postini.com ([64.18.6.12]) with SMTP ID DSNKS7X+oOANo41CzjdPIV2r63aAFiqXohru@postini.com; Fri, 02 Apr 2010 07:26:47 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Fri, 2 Apr 2010 07:24:41 -0700 From: Michael Knappe To: "hoene@uni-tuebingen.de" , "codec@ietf.org" Date: Fri, 2 Apr 2010 07:24:40 -0700 Thread-Topic: [codec] #5: Mention in requirements, FAX? Thread-Index: AcrSbkNA5SPM6/VSQxSAGnqDUxe/FAAAMCEQAABNmOI= Message-ID: <05542EC42316164383B5180707A489EE1D0AA5F58F@EMBX02-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] #5: Mention in requirements, FAX? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 14:26:14 -0000 Please, no fax! :-) >From someone who has dealt with fax carriage for years.... Mike ----- Original Message ----- From: codec-bounces@ietf.org To: codec@ietf.org Sent: Fri Apr 02 10:21:18 2010=0A= Subject: Re: [codec] #5: Mention in requirements, FAX? Hi guys, just for the notes. Testing Fax (http://en.wikipedia.org/wiki/Fax#History) = is definitely out of scope? Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Brian West >Sent: Friday, April 02, 2010 4:10 PM >To: stephen botzko >Cc: codec@ietf.org >Subject: Re: [codec] #5: Mention DTMF in requirements > >But Codecs themselves do not detect DTMF. Thats the job of the DTMF detec= tor. NOT the codec. In all >my work with codecs I have not once seen one that knows anything about DTM= F. And if the codec is too >lossy inband is out of the question. > >/b > >On Apr 2, 2010, at 9:01 AM, stephen botzko wrote: > >> I heard no decision as to DTMF tone encoding. >> >> As far as I am concerned, the question of whether the codec MUST encode = DTMF tones accurately enough >to be detected at the decoder output (or SHOULD or non-requirement) is sti= ll open. >> >> That question clearly is in-scope, and has nothing to do with signaling. >> >> Stephen Botzko > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From James.Rafferty@dialogic.com Fri Apr 2 07:26:27 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D23843A679C for ; Fri, 2 Apr 2010 07:26:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.52 X-Spam-Level: X-Spam-Status: No, score=-0.52 tagged_above=-999 required=5 tests=[AWL=0.949, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hN6tdYo2y5iE for ; Fri, 2 Apr 2010 07:26:27 -0700 (PDT) Received: from outbound.dialogic.com (outbound.dialogic.com [65.220.90.252]) by core3.amsl.com (Postfix) with ESMTP id C38943A688D for ; Fri, 2 Apr 2010 07:26:26 -0700 (PDT) Received: from MBX.dialogic.com ([fe80::d09:39e:8fa1:c2a3]) by pysxht01.dialogic.com ([::1]) with mapi; Fri, 2 Apr 2010 10:27:01 -0400 From: James Rafferty To: Christian Hoene , "codec@ietf.org" Date: Fri, 2 Apr 2010 10:26:59 -0400 Thread-Topic: [codec] #5: Mention in requirements, FAX? Thread-Index: AcrSbkNA5SPM6/VSQxSAGnqDUxe/FAAAMCEQAABQrAA= Message-ID: <617DF0128820F9458AC39149A627EE6C01A2A21196@MBX.dialogic.com> References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <4BAF776D.20904@acm.org> <6e9223711003281100q7e1f7ac0pd548a2ab40e95ba4@mail.gmail.com> <4BAF9E7B.1070708@acm.org> <4BB58E31.2050809@coppice.org> <617DF0128820F9458AC39149A627EE6C01A2A21146@MBX.dialogic.com> <4BB5F7B6.1080808@stpeter.im> <0BD7AE28-298A-4586-9FB4-33925A8F8B8C@freeswitch.org> <003601cad26f$c376b520$4a641f60$@de> In-Reply-To: <003601cad26f$c376b520$4a641f60$@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] #5: Mention in requirements, FAX? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 14:26:27 -0000 Christian,=20 I'd agree that testing fax should be out of scope. =20 Lots of reasons why, but I won't get into that here. =20 James -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of C= hristian Hoene Sent: Friday, April 02, 2010 10:21 AM To: codec@ietf.org Subject: Re: [codec] #5: Mention in requirements, FAX? Hi guys, just for the notes. Testing Fax (http://en.wikipedia.org/wiki/Fax#History) = is definitely out of scope? Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Brian West >Sent: Friday, April 02, 2010 4:10 PM >To: stephen botzko >Cc: codec@ietf.org >Subject: Re: [codec] #5: Mention DTMF in requirements > >But Codecs themselves do not detect DTMF. Thats the job of the DTMF detec= tor. NOT the codec. In all >my work with codecs I have not once seen one that knows anything about DTM= F. And if the codec is too >lossy inband is out of the question. > >/b > >On Apr 2, 2010, at 9:01 AM, stephen botzko wrote: > >> I heard no decision as to DTMF tone encoding. >> >> As far as I am concerned, the question of whether the codec MUST encode = DTMF tones accurately enough >to be detected at the decoder output (or SHOULD or non-requirement) is sti= ll open. >> >> That question clearly is in-scope, and has nothing to do with signaling. >> >> Stephen Botzko > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From hoene@uni-tuebingen.de Fri Apr 2 07:26:40 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61C223A679C for ; Fri, 2 Apr 2010 07:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.819 X-Spam-Level: X-Spam-Status: No, score=-3.819 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PJZ9EEb8VRYU for ; Fri, 2 Apr 2010 07:26:38 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id EEFDB3A67FA for ; Fri, 2 Apr 2010 07:26:37 -0700 (PDT) Received: from hoeneT60 ([178.2.210.31]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o32ER1PP005386 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Apr 2010 16:27:06 +0200 From: "Christian Hoene" To: "'Michael Knappe'" , , References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> In-Reply-To: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> Date: Fri, 2 Apr 2010 16:26:59 +0200 Message-ID: <003d01cad270$91acee00$b506ca00$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01CAD281.5535BE00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrSbQpsirGh3cEjSOW6u2qaUrLm0gAAoG1hAAAaRHA= Content-Language: de X-AntiVirus-Spam-Check: failed (checked by Avira MailGate: version: 3.0.0-4; spam filter version: unknown; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.210; VDF: 7.10.6.23; host: mx05); id=10834-UtnRNY Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 14:26:40 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_003E_01CAD281.5535BE00 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I would vote for a =20 The DTMF transmission performance MUST be tested and characterized (via = an automatic open source testing tool)=20 but it MUST NOT work well under all operational conditions. Especially = at low coding rates under the presence of packet losses it might not = work reliable. =20 Christian =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=C3=BCbingen=20 Sand 13, 72076 T=C3=BCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Michael Knappe Sent: Friday, April 02, 2010 4:20 PM To: stephen.botzko@gmail.com; stpeter@stpeter.im Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements =20 Agreed. Mike _____ =20 From: codec-bounces@ietf.org =20 To: Peter Saint-Andre =20 Cc: codec@ietf.org =20 Sent: Fri Apr 02 10:01:42 2010 Subject: Re: [codec] #5: Mention DTMF in requirements=20 I heard no decision as to DTMF tone encoding.=20 As far as I am concerned, the question of whether the codec MUST encode = DTMF tones accurately enough to be detected at the decoder output (or = SHOULD or non-requirement) is still open. That question clearly is in-scope, and has nothing to do with signaling. Stephen Botzko On Fri, Apr 2, 2010 at 9:57 AM, Peter Saint-Andre = wrote: How is the never-ending debate among DTMF signalling *methods* in-scope for the Codec WG? I think that Henning brought this up in Anaheim only to make sure that we test some DTMF tones. The signalling method is out of scope for the codec itself. On 4/2/10 7:53 AM, stephen botzko wrote: > Are you two suggesting that in-band DTMF is a MUST? Or alternatively = a > SHOULD? > > Stephen Botzko > > On Fri, Apr 2, 2010 at 9:48 AM, James Rafferty > > = wrote: > > I'd agree with Steve that are still many deployments which do not > use RFC 2833 or RFC 4733. In our gateways, we've had to support > interworking variations of tone support such as INFO and in-band, = in > addition to the RFC 2833 / RFC 4733. > > James > -----Original Message----- > From: codec-bounces@ietf.org > [mailto:codec-bounces@ietf.org ] On > Behalf Of Steve Underwood > Sent: Friday, April 02, 2010 2:27 AM > To: codec@ietf.org > Subject: Re: [codec] #5: Mention DTMF in requirements > > On 03/29/2010 02:22 AM, Marc Petit-Huguenin wrote: > > On 03/28/2010 11:00 AM, stephen botzko wrote: > > > >> I would agree with this if I saw reasonable evidence that a > >> preponderance of gateways and sending systems provide the > signaling in > >> these RFCs. > >> > >> Since I am not sure that this is the case, I am unconvinced = that > we can > >> totally remove the requirement. > >> > >> I'd also say that an encoder that detects the DTMF tones and > outputs the > >> RFC 4733/34 events would fully meet the requirement. > >> > > As former CTO of a VoIP provider, I never saw a PSTN provider = not > supporting at > > least RFC 2833 (even if one of them did not declare it in its = SDP) > > > > Perhaps the question can be asked at the next SIPit event. > > > Its true that RFC2833 is widely deployed. Its even true that many > systems have updated to RFC4733. Sadly, its also true that there = are > still many quirky implementations widely deployed, and a lot of = people > still need to interwork with audio DTMF. > > Steve _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =20 ------=_NextPart_000_003E_01CAD281.5535BE00 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

I would = vote for = a

 

The DTMF = transmission performance MUST be tested and characterized (via an automatic open source testing = tool)

but it MUST NOT = work well under all operational conditions. =C2=A0Especially at low coding rates under the presence of packet losses it might not = work reliable.

 

Christian=

 

---------------------------------------------------------------=

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of = T=C3=BCbingen

Sand 13, 72076 T=C3=BCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen= .de/

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On = Behalf Of Michael Knappe
Sent: Friday, April 02, = 2010 4:20 PM
To: = stephen.botzko@gmail.com; stpeter@stpeter.im
Cc: codec@ietf.org
Subject: Re: [codec] #5: = Mention DTMF in requirements

 

Agreed.

Mike

From: codec-bounces@ietf.org <codec-bounces@ietf.org>
To: Peter Saint-Andre = <stpeter@stpeter.im>
Cc: codec@ietf.org <codec@ietf.org>
Sent: Fri Apr 02 10:01:42 = 2010
Subject: Re: [codec] #5: = Mention DTMF in requirements

I heard no = decision as to DTMF tone encoding.

As far as I am concerned, the question of whether the codec MUST encode = DTMF tones accurately enough to be detected at the decoder output (or SHOULD = or non-requirement) is still open.

That question clearly is in-scope, and has nothing to do with = signaling.

Stephen Botzko

On Fri, Apr 2, 2010 at 9:57 AM, Peter Saint-Andre <stpeter@stpeter.im> = wrote:

How is the never-ending debate among DTMF signalling *methods* = in-scope
for the Codec WG? I think that Henning brought this up in Anaheim = only
to make sure that we test some DTMF tones. The signalling method is = out
of scope for the codec itself.


On 4/2/10 7:53 AM, stephen botzko wrote:
> Are you two suggesting that in-band DTMF is a MUST?  Or = alternatively a
> SHOULD?
>
> Stephen Botzko
>
> On Fri, Apr 2, 2010 at 9:48 AM, James = Rafferty

>     [mailto:codec-bounces@ietf.org <mailto:codec-bounces@ietf.org>] On
>     Behalf Of Steve Underwood
>     Sent: Friday, April 02, 2010 2:27 = AM

>   =   To: codec@ietf.org <mailto:codec@ietf.org>
>     Subject: Re: [codec] #5: Mention DTMF in = requirements
>
>     On 03/29/2010 02:22 AM, Marc Petit-Huguenin = wrote:
>     > On 03/28/2010 11:00 AM, stephen botzko = wrote:
>     >
>     >> I would agree with this if I saw reasonable evidence that a
>     >> preponderance of gateways and sending = systems provide the
>     signaling in
>     >> these RFCs.
>     >>
>     >> Since I am not sure that this is the case, I = am unconvinced that
>     we can
>     >> totally remove the requirement.
>     >>
>     >> I'd also say that an encoder that detects = the DTMF tones and
>     outputs the
>     >> RFC 4733/34 events would fully meet the requirement.
>     >>
>     > As former CTO of a VoIP provider, I never saw a = PSTN provider not
>     supporting at
>     > least RFC 2833 (even if one of them did not = declare it in its SDP)
>     >
>     > Perhaps the question can be asked at the next = SIPit event.
>     >
>     Its true that RFC2833 is widely deployed. Its even = true that many
>     systems have updated to RFC4733. Sadly, its also true = that there are
>     still many quirky implementations widely deployed, = and a lot of people
>     still need to interwork with audio DTMF.
>
>     Steve


_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec

 

------=_NextPart_000_003E_01CAD281.5535BE00-- From petithug@acm.org Fri Apr 2 07:32:47 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BB333A6784 for ; Fri, 2 Apr 2010 07:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.392 X-Spam-Level: X-Spam-Status: No, score=-100.392 tagged_above=-999 required=5 tests=[AWL=0.743, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v9LE2IPuKx3I for ; Fri, 2 Apr 2010 07:32:46 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id BC4103A688D for ; Fri, 2 Apr 2010 07:32:45 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 436B9DC0401A; Fri, 2 Apr 2010 14:33:19 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id EE8FCDC04018; Fri, 2 Apr 2010 14:33:17 +0000 (UTC) Message-ID: <4BB6002C.9090303@acm.org> Date: Fri, 02 Apr 2010 07:33:16 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100307 Iceowl/1.0b1 Icedove/3.0.3 MIME-Version: 1.0 To: codec@ietf.org References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <4BAF776D.20904@acm.org> <6e9223711003281100q7e1f7ac0pd548a2ab40e95ba4@mail.gmail.com> <4BAF9E7B.1070708@acm.org> <4BB58E31.2050809@coppice.org> <617DF0128820F9458AC39149A627EE6C01A2A21146@MBX.dialogic.com> <4BB5F7B6.1080808@stpeter.im> <0BD7AE28-298A-4586-9FB4-33925A8F8B8C@freeswitch.org> <003601cad26f$c376b520$4a641f60$@de> In-Reply-To: <003601cad26f$c376b520$4a641f60$@de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: [codec] #5: Mention in requirements, FAX? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 14:32:47 -0000 On 04/02/2010 07:21 AM, Christian Hoene wrote: > Hi guys, > > just for the notes. Testing Fax (http://en.wikipedia.org/wiki/Fax#History) is definitely out of scope? And V8bis? V.21? V.25? V.32/V32bis? V.18? SS5? All this stuff should be out of scope and the text should say that terminals that needs this MUST do it out of band, so no tests are needed. > > Christian > > --------------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of Tübingen > Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Brian West >> Sent: Friday, April 02, 2010 4:10 PM >> To: stephen botzko >> Cc: codec@ietf.org >> Subject: Re: [codec] #5: Mention DTMF in requirements >> >> But Codecs themselves do not detect DTMF. Thats the job of the DTMF detector. NOT the codec. In all >> my work with codecs I have not once seen one that knows anything about DTMF. And if the codec is too >> lossy inband is out of the question. >> >> /b >> >> On Apr 2, 2010, at 9:01 AM, stephen botzko wrote: >> >>> I heard no decision as to DTMF tone encoding. >>> >>> As far as I am concerned, the question of whether the codec MUST encode DTMF tones accurately enough >> to be detected at the decoder output (or SHOULD or non-requirement) is still open. >>> >>> That question clearly is in-scope, and has nothing to do with signaling. >>> >>> Stephen Botzko >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From mknappe@juniper.net Fri Apr 2 07:48:24 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D70A03A6951 for ; Fri, 2 Apr 2010 07:48:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.111 X-Spam-Level: X-Spam-Status: No, score=-5.111 tagged_above=-999 required=5 tests=[AWL=0.358, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHO6IQbwx6Dk for ; Fri, 2 Apr 2010 07:48:23 -0700 (PDT) Received: from exprod7og124.obsmtp.com (exprod7og124.obsmtp.com [64.18.2.26]) by core3.amsl.com (Postfix) with ESMTP id 516403A6808 for ; Fri, 2 Apr 2010 07:48:15 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob124.postini.com ([64.18.6.12]) with SMTP ID DSNKS7YD0BclSPuiPVHiZ8ZjXp3V0tJjuhHm@postini.com; Fri, 02 Apr 2010 07:48:49 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Fri, 2 Apr 2010 07:48:27 -0700 From: Michael Knappe To: Marc Petit-Huguenin , "codec@ietf.org" Date: Fri, 2 Apr 2010 07:48:25 -0700 Thread-Topic: [codec] #5: Mention in requirements, FAX? Thread-Index: AcrScXLwBIENFpB4TkOb/WJ4BOyG2wAAhlW0 Message-ID: In-Reply-To: <4BB6002C.9090303@acm.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] #5: Mention in requirements, FAX? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 14:48:24 -0000 Agreed. In-band fax carriage should not be in the scope of the codec, and the automated switchover to mechanisms like T.38 should also be outside the scope of our work. Mike On 4/2/10 7:33 AM, "Marc Petit-Huguenin" wrote: > On 04/02/2010 07:21 AM, Christian Hoene wrote: >> Hi guys, >>=20 >> just for the notes. Testing Fax (http://en.wikipedia.org/wiki/Fax#Histor= y) is >> definitely out of scope? >=20 > And V8bis? V.21? V.25? V.32/V32bis? V.18? SS5? >=20 > All this stuff should be out of scope and the text should say that termin= als > that needs this MUST do it out of band, so no tests are needed. >=20 >>=20 >> Christian >>=20 >> --------------------------------------------------------------- >> Dr.-Ing. Christian Hoene >> Interactive Communication Systems (ICS), University of T=FCbingen >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >> http://www.net.uni-tuebingen.de/ >>=20 >>=20 >>> -----Original Message----- >>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of >>> Brian West >>> Sent: Friday, April 02, 2010 4:10 PM >>> To: stephen botzko >>> Cc: codec@ietf.org >>> Subject: Re: [codec] #5: Mention DTMF in requirements >>>=20 >>> But Codecs themselves do not detect DTMF. Thats the job of the DTMF >>> detector. NOT the codec. In all >>> my work with codecs I have not once seen one that knows anything about = DTMF. >>> And if the codec is too >>> lossy inband is out of the question. >>>=20 >>> /b >>>=20 >>> On Apr 2, 2010, at 9:01 AM, stephen botzko wrote: >>>=20 >>>> I heard no decision as to DTMF tone encoding. >>>>=20 >>>> As far as I am concerned, the question of whether the codec MUST encod= e >>>> DTMF tones accurately enough >>> to be detected at the decoder output (or SHOULD or non-requirement) is = still >>> open. >>>>=20 >>>> That question clearly is in-scope, and has nothing to do with signalin= g. >>>>=20 >>>> Stephen Botzko >>>=20 >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>=20 >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >>=20 >=20 From stephen.botzko@gmail.com Fri Apr 2 07:49:11 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74FF43A6868 for ; Fri, 2 Apr 2010 07:49:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.017 X-Spam-Level: X-Spam-Status: No, score=-1.017 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7+L7XIW4z6P for ; Fri, 2 Apr 2010 07:49:10 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id DBD683A6951 for ; Fri, 2 Apr 2010 07:49:09 -0700 (PDT) Received: by gyh4 with SMTP id 4so1019543gyh.31 for ; Fri, 02 Apr 2010 07:49:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=ffIruSSwRixGMUQvYsEUkdqC3CPmyhx2I9LSCWEIh60=; b=BDY/KmJ0RCALv6JscAR4alKDoK0zUAEunMFVEzFW3mG+9NLX9SRKqvMka1ro8+iMH4 i4o5pf2TAlAXVWeY5lMA7oAGnDZLi4pMj61G+Af/I+kCFGUm5Oo7K6wPtZ8GuwT3Wnde 4NKxNV8EoJ1HuesdRI9CcXR0ddyZAlS0/6Hmo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=SwMUZFYOeUlfw6I1izfcpW44lGCXcDln/vI4tzkBCFi2Df6SvcuyuKHkXO3tqTKEbw 1+8EP6bU2QCN0w+aL0BlGoDv9RPW3G46+XHJxECw5P8RVRve2THQq2MYqVtY5qR/kM6B OC3S2AIVyanx8nOJB9jsnVx7Cvo/P3ce2uFC0= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Fri, 2 Apr 2010 07:49:35 -0700 (PDT) In-Reply-To: <003d01cad270$91acee00$b506ca00$@de> References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> Date: Fri, 2 Apr 2010 10:49:35 -0400 Received: by 10.150.47.15 with SMTP id u15mr3019225ybu.102.1270219775965; Fri, 02 Apr 2010 07:49:35 -0700 (PDT) Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=000e0cd70618887d5c04834216d3 Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 14:49:11 -0000 --000e0cd70618887d5c04834216d3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (a) "MUST NOT" means that it must fail. Perhaps you meant "need not" or "might not"? (b) SHOULD is commonly used in establishing requirements, and it certainly was used in MARTINI and other working groups at IETF77 in requirements presentations with no confusion. It has a clear meaning in the requirements context (desirable but not essential) and I see no reason to avoid its use at this phase. There will certainly be other things that are "nice to have", and it is appropriate to track them and consider them in the selection/standardization process. I agree that language about DTMF might not need to be in the final RFC. Though if DTMF quality is known to be inadequate, it probably makes sense t= o tell people that. I also agree to the obvious comment that DTMF detection methods are out of scope. But there is no point in testing DTMF at all unless there is a MUST or SHOULD requirement. The fact that folks suggested that it be tested indicates that they believe there *is* a requirement. And some others are saying that explicitly. Perhaps they are wrong. But I see no justification for making the discussion off limits to this list, it is clearly in scope. Stephen Botzko On Fri, Apr 2, 2010 at 10:26 AM, Christian Hoene wr= ote: > I would vote for a > > > > The DTMF transmission performance MUST be tested and characterized (via a= n > automatic open source testing tool) > > but it MUST NOT work well under all operational conditions. Especially a= t > low coding rates under the presence of packet losses it might not work > reliable. > > > > Christian > > > > --------------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of T=FCbingen > > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > > > *From**:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On > Behalf Of *Michael Knappe > *Sent:* Friday, April 02, 2010 4:20 PM > *To:* stephen.botzko@gmail.com; stpeter@stpeter.im > *Cc:* codec@ietf.org > > *Subject:* Re: [codec] #5: Mention DTMF in requirements > > > > Agreed. > > Mike > ------------------------------ > > *From*: codec-bounces@ietf.org > *To*: Peter Saint-Andre > *Cc*: codec@ietf.org > *Sent*: Fri Apr 02 10:01:42 2010 > *Subject*: Re: [codec] #5: Mention DTMF in requirements > > I heard no decision as to DTMF tone encoding. > > As far as I am concerned, the question of whether the codec MUST encode > DTMF tones accurately enough to be detected at the decoder output (or SHO= ULD > or non-requirement) is still open. > > That question clearly is in-scope, and has nothing to do with signaling. > > Stephen Botzko > > On Fri, Apr 2, 2010 at 9:57 AM, Peter Saint-Andre > wrote: > > How is the never-ending debate among DTMF signalling *methods* in-scope > for the Codec WG? I think that Henning brought this up in Anaheim only > to make sure that we test some DTMF tones. The signalling method is out > of scope for the codec itself. > > > On 4/2/10 7:53 AM, stephen botzko wrote: > > Are you two suggesting that in-band DTMF is a MUST? Or alternatively a > > SHOULD? > > > > Stephen Botzko > > > > On Fri, Apr 2, 2010 at 9:48 AM, James Rafferty > > > > > wrote: > > > > I'd agree with Steve that are still many deployments which do not > > use RFC 2833 or RFC 4733. In our gateways, we've had to support > > interworking variations of tone support such as INFO and in-band, i= n > > addition to the RFC 2833 / RFC 4733. > > > > James > > -----Original Message----- > > From: codec-bounces@ietf.org > > > [mailto:codec-bounces@ietf.org ] On > > Behalf Of Steve Underwood > > Sent: Friday, April 02, 2010 2:27 AM > > > To: codec@ietf.org > > Subject: Re: [codec] #5: Mention DTMF in requirements > > > > On 03/29/2010 02:22 AM, Marc Petit-Huguenin wrote: > > > On 03/28/2010 11:00 AM, stephen botzko wrote: > > > > > >> I would agree with this if I saw reasonable evidence that a > > >> preponderance of gateways and sending systems provide the > > signaling in > > >> these RFCs. > > >> > > >> Since I am not sure that this is the case, I am unconvinced that > > we can > > >> totally remove the requirement. > > >> > > >> I'd also say that an encoder that detects the DTMF tones and > > outputs the > > >> RFC 4733/34 events would fully meet the requirement. > > >> > > > As former CTO of a VoIP provider, I never saw a PSTN provider not > > supporting at > > > least RFC 2833 (even if one of them did not declare it in its SDP= ) > > > > > > Perhaps the question can be asked at the next SIPit event. > > > > > Its true that RFC2833 is widely deployed. Its even true that many > > systems have updated to RFC4733. Sadly, its also true that there ar= e > > still many quirky implementations widely deployed, and a lot of > people > > still need to interwork with audio DTMF. > > > > Steve > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > --000e0cd70618887d5c04834216d3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable (a) "MUST NOT" means that it must fail.=A0 Perhaps you meant &quo= t;need not" or "might not"?

(b) SHOULD is commonly us= ed in establishing requirements, and it certainly was used in MARTINI and o= ther working groups at IETF77 in requirements presentations with no confusi= on. It has a clear meaning in the requirements context (desirable but not e= ssential) and I see no reason to avoid its use at this phase.=A0 There will= certainly be other things that are "nice to have", and it is app= ropriate to track them and consider them in the selection/standardization p= rocess.

I agree that language about DTMF might not need to be in the final RFC.= =A0 Though if DTMF quality is known to be inadequate, it probably makes sen= se to tell people that.

I also agree to the obvious comment that DTM= F detection methods are out of scope.

But there is no point in testing DTMF at all unless there is a MUST or = SHOULD requirement.=A0 The fact that folks suggested that it be tested indi= cates that they believe there is a requirement.=A0 And some others a= re saying that explicitly.

Perhaps they are wrong.=A0 But I see no justification for making the di= scussion off limits to this list, it is clearly in scope.

Stephen Bo= tzko





--000e0cd70618887d5c04834216d3-- From stephen.botzko@gmail.com Fri Apr 2 07:58:34 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16EC23A6A2D for ; Fri, 2 Apr 2010 07:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.052 X-Spam-Level: X-Spam-Status: No, score=-1.052 tagged_above=-999 required=5 tests=[AWL=0.416, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cBzQuc-rr7uQ for ; Fri, 2 Apr 2010 07:58:32 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id 12AB23A6A0E for ; Fri, 2 Apr 2010 07:58:31 -0700 (PDT) Received: by ywh38 with SMTP id 38so1443693ywh.29 for ; Fri, 02 Apr 2010 07:59:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=kKRM9r03IIhHqU9WFdNbVUSnK/tshZb8U64MqPA0naE=; b=YOwRCPtLMg6C6Z+Mkf2i8q4D2km1g3VsjpAwnFm4NEdyxNChdHMDT76mqja2sUtVQp 0mcqA6CeWzUcgCA5BTy3teJq7ypFyFv4ReifvVYXPWA7a5zjZXCveR7pYcTqsD0jZCL2 Xt7RmTFuc1DBAQY2nHrxYPkEiYZsbDgdskQtg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=DkWo187wWcoR2aDXK1/AqWeiqiV3GS3iBJid9UqtGJGGy/utpDtNKExo8E0ppuvmI1 W02UfpXYhODTIIcwSk6UXJYeJsUdLADE312Onu5V+zMR2mU7WmN7zAmq3QixPngZJC5L FLKAXAg5mlbQP1T/ElTihxl36mc5wDv3JytiA= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Fri, 2 Apr 2010 07:59:01 -0700 (PDT) In-Reply-To: References: <4BB6002C.9090303@acm.org> Date: Fri, 2 Apr 2010 10:59:01 -0400 Received: by 10.101.184.7 with SMTP id l7mr6070477anp.214.1270220342093; Fri, 02 Apr 2010 07:59:02 -0700 (PDT) Message-ID: From: stephen botzko To: Michael Knappe Content-Type: multipart/alternative; boundary=001636988b1747dfe5048342380f Cc: "codec@ietf.org" Subject: Re: [codec] #5: Mention in requirements, FAX? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 14:58:34 -0000 --001636988b1747dfe5048342380f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Perhaps we are using "scope" for two different things? For me, "out of scope" means outside the working group charter. "in-band fax carriage" is in scope from a charter perspective, though I agree it is a non-requirement for the codec. Automated switchover is clearly outside the charter, so it is out of scope (in my definition). The reason this might matter: Things that are "out of scope" of the charte= r shouldn't be discussed on the list at all. Debates about non-requirements and requirements of course should be on the list. Stephen Botzko On Fri, Apr 2, 2010 at 10:48 AM, Michael Knappe wrote= : > Agreed. In-band fax carriage should not be in the scope of the codec, and > the automated switchover to mechanisms like T.38 should also be outside t= he > scope of our work. > > Mike > > > On 4/2/10 7:33 AM, "Marc Petit-Huguenin" wrote: > > > On 04/02/2010 07:21 AM, Christian Hoene wrote: > >> Hi guys, > >> > >> just for the notes. Testing Fax ( > http://en.wikipedia.org/wiki/Fax#History) is > >> definitely out of scope? > > > > And V8bis? V.21? V.25? V.32/V32bis? V.18? SS5? > > > > All this stuff should be out of scope and the text should say that > terminals > > that needs this MUST do it out of band, so no tests are needed. > > > >> > >> Christian > >> > >> --------------------------------------------------------------- > >> Dr.-Ing. Christian Hoene > >> Interactive Communication Systems (ICS), University of T=FCbingen > >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > >> http://www.net.uni-tuebingen.de/ > >> > >> > >>> -----Original Message----- > >>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behal= f > Of > >>> Brian West > >>> Sent: Friday, April 02, 2010 4:10 PM > >>> To: stephen botzko > >>> Cc: codec@ietf.org > >>> Subject: Re: [codec] #5: Mention DTMF in requirements > >>> > >>> But Codecs themselves do not detect DTMF. Thats the job of the DTMF > >>> detector. NOT the codec. In all > >>> my work with codecs I have not once seen one that knows anything abou= t > DTMF. > >>> And if the codec is too > >>> lossy inband is out of the question. > >>> > >>> /b > >>> > >>> On Apr 2, 2010, at 9:01 AM, stephen botzko wrote: > >>> > >>>> I heard no decision as to DTMF tone encoding. > >>>> > >>>> As far as I am concerned, the question of whether the codec MUST > encode > >>>> DTMF tones accurately enough > >>> to be detected at the decoder output (or SHOULD or non-requirement) i= s > still > >>> open. > >>>> > >>>> That question clearly is in-scope, and has nothing to do with > signaling. > >>>> > >>>> Stephen Botzko > >>> > >>> _______________________________________________ > >>> codec mailing list > >>> codec@ietf.org > >>> https://www.ietf.org/mailman/listinfo/codec > >> > >> _______________________________________________ > >> codec mailing list > >> codec@ietf.org > >> https://www.ietf.org/mailman/listinfo/codec > >> > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636988b1747dfe5048342380f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Perhaps we are using "scope" for two different things?=A0 For me,= "out of scope" means outside the working group charter.=A0
<= br>"in-band fax carriage" is in scope from a charter perspective,= though I agree it is a non-requirement for the codec.

Automated switchover is clearly outside the charter, so it is out of sc= ope (in my definition).

The reason this might matter:=A0 Things that= are "out of scope" of the charter shouldn't be discussed on = the list at all.=A0 Debates about non-requirements and requirements of cour= se should be on the list.

Stephen Botzko


On Fri, Apr 2, 201= 0 at 10:48 AM, Michael Knappe <mknappe@juniper.net> wrote:
Agreed. In-band fax carriage should not be in the scope of the codec, and the automated switchover to mechanisms like T.38 should also be outside the=
scope of our work.

Mike


On 4/2/10 7:33 AM, "Marc Petit-Huguenin" <petithug@acm.org> wrote:

> On 04/02/2010 07:21 AM, Christian Hoene wrote:
>> Hi guys,
>>
>> just for the notes. Testing Fax (http://en.wikipedia.org/wiki/Fax#Hist= ory) is
>> definitely out of scope?
>
> And V8bis? V.21? V.25? V.32/V32bis? =A0V.18? =A0SS5?
>
> All this stuff should be out of scope and the text should say that ter= minals
> that needs this MUST do it out of band, so no tests are needed.
>
>>
>> Christian
>>
>> --------------------------------------------------------------- >> Dr.-Ing. Christian Hoene
>> Interactive Communication Systems (ICS), University of T=FCbingen<= br> >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
>> htt= p://www.net.uni-tuebingen.de/
>>
>>
>>> -----Original Message-----
>>> From: codec-bounces@= ietf.org [mailto:codec-bounce= s@ietf.org] On Behalf Of
>>> Brian West
>>> Sent: Friday, April 02, 2010 4:10 PM
>>> To: stephen botzko
>>> Cc: codec@ietf.org
>>> Subject: Re: [codec] #5: Mention DTMF in requirements
>>>
>>> But Codecs themselves do not detect DTMF. =A0Thats the job of = the DTMF
>>> detector. =A0NOT the codec. =A0In all
>>> my work with codecs I have not once seen one that knows anythi= ng about DTMF.
>>> And if the codec is too
>>> lossy inband is out of the question.
>>>
>>> /b
>>>
>>> On Apr 2, 2010, at 9:01 AM, stephen botzko wrote:
>>>
>>>> I heard no decision as to DTMF tone encoding.
>>>>
>>>> As far as I am concerned, the question of whether the code= c MUST encode
>>>> DTMF tones accurately enough
>>> to be detected at the decoder output (or SHOULD or non-require= ment) is still
>>> open.
>>>>
>>>> That question clearly is in-scope, and has nothing to do w= ith signaling.
>>>>
>>>> Stephen Botzko
>>>
>>> _______________________________________________
>>> codec mailing list
>>> codec@ietf.org
>>> https://www.ietf.org/mailman/listinfo/codec
>>
>> _______________________________________________
>> codec mailing list
>> codec@ietf.org
>> https://www.ietf.org/mailman/listinfo/codec
>>
>

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--001636988b1747dfe5048342380f-- From mknappe@juniper.net Fri Apr 2 08:03:23 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BB9C3A6980 for ; Fri, 2 Apr 2010 08:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.137 X-Spam-Level: X-Spam-Status: No, score=-5.137 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xK+317YD3a+k for ; Fri, 2 Apr 2010 08:03:21 -0700 (PDT) Received: from exprod7og101.obsmtp.com (exprod7og101.obsmtp.com [64.18.2.155]) by core3.amsl.com (Postfix) with ESMTP id 955AB3A6951 for ; Fri, 2 Apr 2010 08:03:21 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob101.postini.com ([64.18.6.12]) with SMTP ID DSNKS7YHWTerP9MpUa4iV7Og3L0qRStGF+B3@postini.com; Fri, 02 Apr 2010 08:03:56 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Fri, 2 Apr 2010 08:01:36 -0700 From: Michael Knappe To: stephen botzko Date: Fri, 2 Apr 2010 08:01:29 -0700 Thread-Topic: [codec] #5: Mention in requirements, FAX? Thread-Index: AcrSdQl93mGI3royQ9uffMIzRowu2QAAFYV8 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] #5: Mention in requirements, FAX? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 15:03:23 -0000 Yes, excellent clarification, agreed. Mike On 4/2/10 7:59 AM, "stephen botzko" wrote: Perhaps we are using "scope" for two different things? For me, "out of sco= pe" means outside the working group charter. "in-band fax carriage" is in scope from a charter perspective, though I agr= ee it is a non-requirement for the codec. Automated switchover is clearly outside the charter, so it is out of scope = (in my definition). The reason this might matter: Things that are "out of scope" of the charte= r shouldn't be discussed on the list at all. Debates about non-requirement= s and requirements of course should be on the list. Stephen Botzko On Fri, Apr 2, 2010 at 10:48 AM, Michael Knappe wrote= : Agreed. In-band fax carriage should not be in the scope of the codec, and the automated switchover to mechanisms like T.38 should also be outside the scope of our work. Mike On 4/2/10 7:33 AM, "Marc Petit-Huguenin" wrote: > On 04/02/2010 07:21 AM, Christian Hoene wrote: >> Hi guys, >> >> just for the notes. Testing Fax (http://en.wikipedia.org/wiki/Fax#Histor= y) is >> definitely out of scope? > > And V8bis? V.21? V.25? V.32/V32bis? V.18? SS5? > > All this stuff should be out of scope and the text should say that termin= als > that needs this MUST do it out of band, so no tests are needed. > >> >> Christian >> >> --------------------------------------------------------------- >> Dr.-Ing. Christian Hoene >> Interactive Communication Systems (ICS), University of T=FCbingen >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >> http://www.net.uni-tuebingen.de/ >> >> >>> -----Original Message----- >>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of >>> Brian West >>> Sent: Friday, April 02, 2010 4:10 PM >>> To: stephen botzko >>> Cc: codec@ietf.org >>> Subject: Re: [codec] #5: Mention DTMF in requirements >>> >>> But Codecs themselves do not detect DTMF. Thats the job of the DTMF >>> detector. NOT the codec. In all >>> my work with codecs I have not once seen one that knows anything about = DTMF. >>> And if the codec is too >>> lossy inband is out of the question. >>> >>> /b >>> >>> On Apr 2, 2010, at 9:01 AM, stephen botzko wrote: >>> >>>> I heard no decision as to DTMF tone encoding. >>>> >>>> As far as I am concerned, the question of whether the codec MUST encod= e >>>> DTMF tones accurately enough >>> to be detected at the decoder output (or SHOULD or non-requirement) is = still >>> open. >>>> >>>> That question clearly is in-scope, and has nothing to do with signalin= g. >>>> >>>> Stephen Botzko >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> > _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From hoene@uni-tuebingen.de Fri Apr 2 10:43:27 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B33DA3A6B5F for ; Fri, 2 Apr 2010 10:43:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.469 X-Spam-Level: X-Spam-Status: No, score=-4.469 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzQ88epm-JWW for ; Fri, 2 Apr 2010 10:43:26 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id B46683A6B61 for ; Fri, 2 Apr 2010 10:34:15 -0700 (PDT) Received: from hoeneT60 ([178.2.210.31]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o32HYeOo015325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 2 Apr 2010 19:34:46 +0200 From: "Christian Hoene" To: "'stephen botzko'" References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> In-Reply-To: Date: Fri, 2 Apr 2010 19:34:39 +0200 Message-ID: <000301cad28a$ca0c6450$5e252cf0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrSc7yO/mr9S2ynRJyVELLOmqrCkQAFWVMg Content-Language: de X-AntiVirus-Spam-Check: failed (checked by Avira MailGate: version: 3.0.0-4; spam filter version: unknown; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.210; VDF: 7.10.6.23; host: mx05); id=10834-kf9GZn Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 17:43:27 -0000 Hi Stephan, Comments inline: --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ From: stephen botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Friday, April 02, 2010 4:50 PM To: Christian Hoene Cc: Michael Knappe; stpeter@stpeter.im; codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements (a) "MUST NOT" means that it must fail.=A0 Perhaps you meant "need not" = or "might not"? CH: Yes, I meant need not (or the German =84muss nicht=93) (b) SHOULD is commonly used in establishing requirements, and it = certainly was used in MARTINI and other working groups at IETF77 in requirements presentations with no confusion. It has a clear meaning in = the requirements context (desirable but not essential) and I see no reason to avoid its use at this phase.=A0 There will certainly be = other things that are "nice to have", and it is appropriate to track them and consider them in the selection/standardization = process. CH: Better? "The codec SHOULD support the transmission DTMF at most = transmission conditions." I agree that language about DTMF might not need to be in the final = RFC.=A0 Though if DTMF quality is known to be inadequate, it probably makes sense to tell people that. CH: Agreed. The limits of the codec shall be clearly stated. I also agree to the obvious comment that DTMF detection methods are out = of scope. CH: Agreed. =20 CH: Isn't time to include the MUST requirement for DTMF testing and = SHOULD requirement for transmission support into the requirements document.=20 Then, we could close issue #5 and continue with other things. Christian From stephen.botzko@gmail.com Fri Apr 2 11:43:59 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E5A1F3A6B02 for ; Fri, 2 Apr 2010 11:43:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.418 X-Spam-Level: X-Spam-Status: No, score=-0.418 tagged_above=-999 required=5 tests=[AWL=1.050, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gl4A3XXNKl3a for ; Fri, 2 Apr 2010 11:43:58 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 8B5663A6B1A for ; Fri, 2 Apr 2010 11:17:48 -0700 (PDT) Received: by pvd12 with SMTP id 12so642822pvd.31 for ; Fri, 02 Apr 2010 11:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=0ts0YXuyfuZJhKA/d5PfHT/uRpcMpc+sxdWj93QK5b4=; b=eqhZAHvdGhbmzdLjGkJH/YAAoWTR8n1XHnd3sgUKn26capmy0T7AJrGDjCS4VDu30C IUrD2JVrH9doyR2miRqoAFavIN6TR/ChIKsnu1nnu212dk7fDeyaJv+rz+eZpWcQJnCi /eaVMqsDi7gv8FWYKW/C+WPplSO8h647Pq8Cw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=V7iG7QnltZO357G/iMQIBpmLASG//YQvQuqm/PfHyjm43q1IQsUkDUBQkO310rfJCS q7GLvpD/Bjg7e6AjXw6se+iKN8E8H/4LglbhyOlrWONgxlHB0SGI4aMQo3t4iE7ii3hr 6jqjzBDamtyNx4bdJZ20OBDrrLMjr1IpNMybU= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Fri, 2 Apr 2010 11:18:19 -0700 (PDT) In-Reply-To: <000301cad28a$ca0c6450$5e252cf0$@de> References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> Date: Fri, 2 Apr 2010 14:18:19 -0400 Received: by 10.143.24.11 with SMTP id b11mr885967wfj.347.1270232299736; Fri, 02 Apr 2010 11:18:19 -0700 (PDT) Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=001636e0b603020e3004834501ea Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 18:44:00 -0000 --001636e0b603020e3004834501ea Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am fine with your suggestions. Stephen Botzko On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene wro= te: > Hi Stephan, > > Comments inline: > > > --------------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of T=FCbingen > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > From: stephen botzko [mailto:stephen.botzko@gmail.com] > Sent: Friday, April 02, 2010 4:50 PM > To: Christian Hoene > Cc: Michael Knappe; stpeter@stpeter.im; codec@ietf.org > Subject: Re: [codec] #5: Mention DTMF in requirements > > (a) "MUST NOT" means that it must fail. Perhaps you meant "need not" or > "might not"? > > CH: Yes, I meant need not (or the German =84muss nicht=93) > > (b) SHOULD is commonly used in establishing requirements, and it certainl= y > was used in MARTINI and other working groups at IETF77 in > requirements presentations with no confusion. It has a clear meaning in t= he > requirements context (desirable but not essential) and I > see no reason to avoid its use at this phase. There will certainly be > other things that are "nice to have", and it is appropriate > to track them and consider them in the selection/standardization process. > > CH: Better? "The codec SHOULD support the transmission DTMF at most > transmission conditions." > > I agree that language about DTMF might not need to be in the final RFC. > Though if DTMF quality is known to be inadequate, it > probably makes sense to tell people that. > > CH: Agreed. The limits of the codec shall be clearly stated. > > I also agree to the obvious comment that DTMF detection methods are out o= f > scope. > > CH: Agreed. > > CH: Isn't time to include the MUST requirement for DTMF testing and SHOUL= D > requirement for transmission support into the > requirements document. > Then, we could close issue #5 and continue with other things. > > Christian > > > > --001636e0b603020e3004834501ea Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I am fine with your suggestions.

Stephen Botzko

On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene <hoene@uni-tuebingen.de> wrote:
Hi Stephan,

Comments inline:


---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.n= et.uni-tuebingen.de/

From: stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Friday, April 02, 2010 4:50 PM
To: Christian Hoene
Cc: Michael Knappe; stpeter@stpeter.i= m; codec@ietf.org
Subject: Re: [codec] #5: Mention DTMF in requirements

(a) "MUST NOT" means that it must fail.= =A0 Perhaps you meant "need not" or "might not"?

CH: Yes, I meant need not (or the German =84muss nicht=93)

(b) SHOULD is commonly used in establishing requirements, and it certainly = was used in MARTINI and other working groups at IETF77 in
requirements presentations with no confusion. It has a clear meaning in the= requirements context (desirable but not essential) and I
see no reason to avoid its use at this phase.=A0 There will certainly be ot= her things that are "nice to have", and it is appropriate
to track them and consider them in the selection/standardization process.
CH: Better? "The codec SHOULD support the transmission DTMF at m= ost transmission conditions."

I agree that language about DTMF might not need to be in the final RFC.=A0 = Though if DTMF quality is known to be inadequate, it
probably makes sense to tell people that.

CH: Agreed. The limits of the codec shall be clearly stated.

I also agree to the obvious comment that DTMF detection methods are out of = scope.

CH: Agreed.

CH: Isn't time to include the MUST requirement for DTMF testing and SHO= ULD requirement for transmission support into the
requirements document.
Then, we could close issue #5 and continue with other things.

=A0Christian




--001636e0b603020e3004834501ea-- From James.Rafferty@dialogic.com Fri Apr 2 12:22:02 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3048E3A6C24 for ; Fri, 2 Apr 2010 12:22:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.614 X-Spam-Level: X-Spam-Status: No, score=-0.614 tagged_above=-999 required=5 tests=[AWL=0.854, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IkamINMM-jed for ; Fri, 2 Apr 2010 12:21:56 -0700 (PDT) Received: from outbound.dialogic.com (outbound.dialogic.com [65.220.90.252]) by core3.amsl.com (Postfix) with ESMTP id AEDC53A6B9C for ; Fri, 2 Apr 2010 11:47:47 -0700 (PDT) Received: from MBX.dialogic.com ([fe80::d09:39e:8fa1:c2a3]) by pysxht02.dialogic.com ([::1]) with mapi; Fri, 2 Apr 2010 14:48:22 -0400 From: James Rafferty To: stephen botzko , Christian Hoene Date: Fri, 2 Apr 2010 14:48:18 -0400 Thread-Topic: [codec] #5: Mention DTMF in requirements Thread-Index: AcrSlIz6TfvUQu/ATeSsiqID9NFxcwAAHFjw Message-ID: <617DF0128820F9458AC39149A627EE6C01A2A9FF9C@MBX.dialogic.com> References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_617DF0128820F9458AC39149A627EE6C01A2A9FF9CMBXdialogicco_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 19:22:02 -0000 --_000_617DF0128820F9458AC39149A627EE6C01A2A9FF9CMBXdialogicco_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable +1 James Rafferty From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of s= tephen botzko Sent: Friday, April 02, 2010 2:18 PM To: Christian Hoene Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements I am fine with your suggestions. Stephen Botzko On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene > wrote: Hi Stephan, Comments inline: --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ From: stephen botzko [mailto:stephen.botzko@gmail.com] Sent: Friday, April 02, 2010 4:50 PM To: Christian Hoene Cc: Michael Knappe; stpeter@stpeter.im; codec@ie= tf.org Subject: Re: [codec] #5: Mention DTMF in requirements (a) "MUST NOT" means that it must fail. Perhaps you meant "need not" or "m= ight not"? CH: Yes, I meant need not (or the German "muss nicht") (b) SHOULD is commonly used in establishing requirements, and it certainly = was used in MARTINI and other working groups at IETF77 in requirements presentations with no confusion. It has a clear meaning in the= requirements context (desirable but not essential) and I see no reason to avoid its use at this phase. There will certainly be othe= r things that are "nice to have", and it is appropriate to track them and consider them in the selection/standardization process. CH: Better? "The codec SHOULD support the transmission DTMF at most transmi= ssion conditions." I agree that language about DTMF might not need to be in the final RFC. Th= ough if DTMF quality is known to be inadequate, it probably makes sense to tell people that. CH: Agreed. The limits of the codec shall be clearly stated. I also agree to the obvious comment that DTMF detection methods are out of = scope. CH: Agreed. CH: Isn't time to include the MUST requirement for DTMF testing and SHOULD = requirement for transmission support into the requirements document. Then, we could close issue #5 and continue with other things. Christian --_000_617DF0128820F9458AC39149A627EE6C01A2A9FF9CMBXdialogicco_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

+1

James Ra= fferty

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = stephen botzko
Sent: Friday, April 02, 2010 2:18 PM
To: Christian Hoene
Cc: codec@ietf.org
Subject: Re: [codec] #5: Mention DTMF in requirements

 

I am fine with your suggestions.

Stephen Botzko

On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene <hoene@uni-tuebingen.de> wrote= :

Hi Stephan,

Comments inline:



---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.n= et.uni-tuebingen.de/

From: stephen botzko [mailto:stephen.botzko@gmail.com]=

Sent: Friday, April 02, 2010 4:50 PM
To: Christian Hoene
Cc: Michael Knappe; stpeter@stpeter.i= m; codec@ietf.org

Subject: Re: [codec] #5= : Mention DTMF in requirements

(a) "MUST NOT"= ; means that it must fail.  Perhaps you meant "need not" or "mi= ght not"?

CH: Yes, I meant need not (or the German „muss n= icht“)


(b) SHOULD is commonly used in establishing requirements, and it certainly = was used in MARTINI and other working groups at IETF77 in
requirements presentations with no confusion. It has a clear meaning in the requirements context (desirable but not essential) and I
see no reason to avoid its use at this phase.  There will certainly be other things that are "nice to have", and it is appropriate
to track them and consider them in the selection/standardization process.

CH: Better? "The codec SHOULD support the transmi= ssion DTMF at most transmission conditions."


I agree that language about DTMF might not need to be in the final RFC.&nbs= p; Though if DTMF quality is known to be inadequate, it
probably makes sense to tell people that.

CH: Agreed. The limits of the codec shall be clearly s= tated.


I also agree to the obvious comment that DTMF detection methods are out of scope.

CH: Agreed.

CH: Isn't time to include the MUST requirement for DTMF testing and SHOULD requirement for transmission support into the
requirements document.
Then, we could close issue #5 and continue with other things.

 Christian


 

--_000_617DF0128820F9458AC39149A627EE6C01A2A9FF9CMBXdialogicco_-- From rchen@broadcom.com Fri Apr 2 12:26:52 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AE333A6B6B for ; Fri, 2 Apr 2010 12:26:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWLYe4nDa3BL for ; Fri, 2 Apr 2010 12:26:50 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 7F57A3A6B0D for ; Fri, 2 Apr 2010 11:53:44 -0700 (PDT) Received: from [10.9.200.133] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 02 Apr 2010 11:54:08 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Fri, 2 Apr 2010 11:55:33 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Brian West" , "stephen botzko" Date: Fri, 2 Apr 2010 11:54:00 -0700 Thread-Topic: [codec] #5: Mention DTMF in requirements Thread-Index: AcrSbkLl/+OtG4IbRliwMoqBvakvvgAIBaGQ Message-ID: References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <4BAF776D.20904@acm.org> <6e9223711003281100q7e1f7ac0pd548a2ab40e95ba4@mail.gmail.com> <4BAF9E7B.1070708@acm.org> <4BB58E31.2050809@coppice.org> <617DF0128820F9458AC39149A627EE6C01A2A21146@MBX.dialogic.com> <4BB5F7B6.1080808@stpeter.im> <0BD7AE28-298A-4586-9FB4-33925A8F8B8C@freeswitch.org> In-Reply-To: <0BD7AE28-298A-4586-9FB4-33925A8F8B8C@freeswitch.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: CYZN C38P E3kT GTRY Lqae MMLu RpaN TKzq Te1B UAdf XYlA Xew6 Xk7D Y7kt bYj6 fjTJ; 3; YgByAGkAYQBuAEAAZgByAGUAZQBzAHcAaQB0AGMAaAAuAG8AcgBnADsAYwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAcwB0AGUAcABoAGUAbgAuAGIAbwB0AHoAawBvAEAAZwBtAGEAaQBsAC4AYwBvAG0A; Sosha1_v1; 7; {F5EDFD7D-EBF9-4E12-906E-545B904C48D2}; cgBjAGgAZQBuAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0A; Fri, 02 Apr 2010 18:54:00 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAIwA1ADoAIABNAGUAbgB0AGkAbwBuACAARABUAE0ARgAgAGkAbgAgAHIAZQBxAHUAaQByAGUAbQBlAG4AdABzAA== x-cr-puzzleid: {F5EDFD7D-EBF9-4E12-906E-545B904C48D2} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67A8E2DA38O161155616-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 19:26:52 -0000 (Responding to an earlier email on this topic...) I think the issue here is not for a codec to detect DTMF, but for a codec t= o encode and decode the DTMF waveform with sufficient fidelity so it will n= ot cause DTMF detection problems later in a DTMF detector. =20 Although most codecs do not explicitly make use of DTMF properties to impro= ve their coding fidelity with DTMF waveforms, a codec developer can indeed = test a codec by passing DTMF tones through the codec followed by a DTMF det= ector and try to tune or otherwise improve the codec so that it minimizes t= he DTMF detection error rate as seen by the DTMF detector. In fact, this i= s exactly what we have done when we developed the BV16 codec, and as a resu= lt of such testing and tuning, we were indeed able to modify the BV16 codec= algorithm to improve the DTMF detection error rate after DTMF tones were p= assed through BV16 and then detected by a commercial DTMF detector. Such D= TMF pass-through test results of BV16, G.711, G.728, G.729E, and G.729 are = described in our BroadVoice16 paper in the Proceedings of the 40th Asilomar= Conference on Signals, Systems and Computers, 2006, available at our Broad= Voice website www.broadcom.com/broadvoice. That's why I could answer with = confidence the DTMF pass-through question raised right after my BroadVoice = codec presentation at our IETF 77 codec WG meeting on March 22. I think in those conditions where out-of-band DTMF signaling is not availab= le or is not implemented properly, it is crucial for the codec to pass DTMF= tones through without causing significant increase of the DMTF detection e= rror rate in a DTMF detector downstream, otherwise you may not even be able= to get the correct telephone number through, or a credit card number or ke= y press responses to a voice response system (press 1 for this, press 2 for= that,...) may not go through correctly. That's why we went through the tro= uble of testing BV16 with DTMF tones and modifying BV16 to minimize the DTM= F detection error rate, and that's why I agree with Stephen's comments belo= w. Raymond -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of B= rian West Sent: Friday, April 02, 2010 7:10 AM To: stephen botzko Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements But Codecs themselves do not detect DTMF. Thats the job of the DTMF detect= or. NOT the codec. In all my work with codecs I have not once seen one th= at knows anything about DTMF. And if the codec is too lossy inband is out = of the question. /b On Apr 2, 2010, at 9:01 AM, stephen botzko wrote: > I heard no decision as to DTMF tone encoding.=20 >=20 > As far as I am concerned, the question of whether the codec MUST encode D= TMF tones accurately enough to be detected at the decoder output (or SHOULD= or non-requirement) is still open. >=20 > That question clearly is in-scope, and has nothing to do with signaling. >=20 > Stephen Botzko _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From roman@telurix.com Fri Apr 2 12:35:16 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B3153A6C3F for ; Fri, 2 Apr 2010 12:35:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fKt9HuLDnq2N for ; Fri, 2 Apr 2010 12:35:15 -0700 (PDT) Received: from mail-pz0-f195.google.com (mail-pz0-f195.google.com [209.85.222.195]) by core3.amsl.com (Postfix) with ESMTP id 9CC213A6B21 for ; Fri, 2 Apr 2010 12:02:12 -0700 (PDT) Received: by pzk33 with SMTP id 33so2297293pzk.17 for ; Fri, 02 Apr 2010 12:02:44 -0700 (PDT) Received: by 10.114.6.13 with SMTP id 13mr2532214waf.58.1270234964001; Fri, 02 Apr 2010 12:02:44 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by mx.google.com with ESMTPS id 23sm21422pzk.14.2010.04.02.12.02.41 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 12:02:43 -0700 (PDT) Received: by ywh38 with SMTP id 38so50972ywh.29 for ; Fri, 02 Apr 2010 12:02:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.12.12 with HTTP; Fri, 2 Apr 2010 12:02:39 -0700 (PDT) In-Reply-To: <000301cad28a$ca0c6450$5e252cf0$@de> References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> Date: Fri, 2 Apr 2010 15:02:39 -0400 Received: by 10.101.211.36 with SMTP id n36mr6644696anq.120.1270234960151; Fri, 02 Apr 2010 12:02:40 -0700 (PDT) Message-ID: From: Roman Shpount To: codec@ietf.org Content-Type: multipart/alternative; boundary=001636c92ede94c52d0483459f9b Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 19:35:16 -0000 --001636c92ede94c52d0483459f9b Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This is all wonderful, but what seems to be missing here is any type of standard test for DTMF tone detection. We have a number of tests for things that should not be detected as DTMF (various talk-off tapes), but there is no test with samples of valid DTMF signals. In real world you get quite a variety of tones that different handsets or telephone devices generate when a digit is pressed. Some of those tones are almost at border line condition= s for a valid DTMF tone. Second issue, which was already mentioned here, would be performance of DTM= F tone detector in the presence of packet loss or time stretching caused by jitter buffer. Those things, even if they do not prevent DTMF detection, ar= e almost guaranteed to split a single long tone in two. Finally, we seemed to concentrate on DTMF tones only, but in reality all th= e signaling/special tones are quite important. Fax Send/Receive tones come to mind almost immediately as tones that are typically detected inband (very few gateways encode those tones using RFC 4733/2833) I think we should formulate this requirement not in terms of DTMF tone but in terms of accuracy of reproduction of periodic signals in specified frequency ranges. To be honest, the most robust solution would be to incorporate RFC4733/4744 as a part of the codec in a manner similar to comfort noise frames. _____________________________ Roman Shpount - www.telurix.com On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene wro= te: > Hi Stephan, > > Comments inline: > > > --------------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of T=FCbingen > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > From: stephen botzko [mailto:stephen.botzko@gmail.com] > Sent: Friday, April 02, 2010 4:50 PM > To: Christian Hoene > Cc: Michael Knappe; stpeter@stpeter.im; codec@ietf.org > Subject: Re: [codec] #5: Mention DTMF in requirements > > (a) "MUST NOT" means that it must fail. Perhaps you meant "need not" or > "might not"? > > CH: Yes, I meant need not (or the German =84muss nicht=93) > > (b) SHOULD is commonly used in establishing requirements, and it certainl= y > was used in MARTINI and other working groups at IETF77 in > requirements presentations with no confusion. It has a clear meaning in t= he > requirements context (desirable but not essential) and I > see no reason to avoid its use at this phase. There will certainly be > other things that are "nice to have", and it is appropriate > to track them and consider them in the selection/standardization process. > > CH: Better? "The codec SHOULD support the transmission DTMF at most > transmission conditions." > > I agree that language about DTMF might not need to be in the final RFC. > Though if DTMF quality is known to be inadequate, it > probably makes sense to tell people that. > > CH: Agreed. The limits of the codec shall be clearly stated. > > I also agree to the obvious comment that DTMF detection methods are out o= f > scope. > > CH: Agreed. > > CH: Isn't time to include the MUST requirement for DTMF testing and SHOUL= D > requirement for transmission support into the > requirements document. > Then, we could close issue #5 and continue with other things. > > Christian > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636c92ede94c52d0483459f9b Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This is all wonderful, but what seems to be missing here is any type of sta= ndard test for DTMF tone detection. We have a number of tests for things th= at should not be detected as DTMF (various talk-off tapes), but there is no= test with samples of valid DTMF signals. In real world you get quite a var= iety of tones that different handsets or telephone devices generate when a = digit is pressed. Some of those tones are almost at border line conditions = for a valid DTMF tone.

Second issue, which was already mentioned here, would be performance of= DTMF tone detector in the presence of packet loss or time stretching cause= d by jitter buffer. Those things, even if they do not prevent DTMF detectio= n, are almost guaranteed to split a single long tone in two.

Finally, we seemed to concentrate on DTMF tones only, but in reality al= l the signaling/special tones are quite important. Fax Send/Receive tones c= ome to mind almost immediately as tones that are typically detected inband = (very few gateways encode those tones using RFC 4733/2833)

I think we should formulate this requirement not in terms of DTMF tone = but in terms of accuracy of reproduction of=A0 periodic signals in specifie= d frequency ranges. To be honest, the most robust solution would be to inco= rporate RFC4733/4744 as a part of the codec in a manner similar to comfort = noise frames.
_____________________________
Roman Shpount - www.telurix.com


On Fri, Apr 2, 2010 at 1:34 PM, Christia= n Hoene <hoe= ne@uni-tuebingen.de> wrote:
Hi Stephan,

Comments inline:


---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.n= et.uni-tuebingen.de/

From: stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Friday, April 02, 2010 4:50 PM
To: Christian Hoene
Cc: Michael Knappe; stpeter@stpeter.i= m; codec@ietf.org
Subject: Re: [codec] #5: Mention DTMF in requirements

(a) "MUST NOT" means that it must fail.= =A0 Perhaps you meant "need not" or "might not"?

CH: Yes, I meant need not (or the German =84muss nicht=93)

(b) SHOULD is commonly used in establishing requirements, and it certainly = was used in MARTINI and other working groups at IETF77 in
requirements presentations with no confusion. It has a clear meaning in the= requirements context (desirable but not essential) and I
see no reason to avoid its use at this phase.=A0 There will certainly be ot= her things that are "nice to have", and it is appropriate
to track them and consider them in the selection/standardization process.
CH: Better? "The codec SHOULD support the transmission DTMF at m= ost transmission conditions."

I agree that language about DTMF might not need to be in the final RFC.=A0 = Though if DTMF quality is known to be inadequate, it
probably makes sense to tell people that.

CH: Agreed. The limits of the codec shall be clearly stated.

I also agree to the obvious comment that DTMF detection methods are out of = scope.

CH: Agreed.

CH: Isn't time to include the MUST requirement for DTMF testing and SHO= ULD requirement for transmission support into the
requirements document.
Then, we could close issue #5 and continue with other things.

=A0Christian



_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--001636c92ede94c52d0483459f9b-- From petithug@acm.org Fri Apr 2 13:14:19 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE2F03A6C94 for ; Fri, 2 Apr 2010 13:14:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.174 X-Spam-Level: X-Spam-Status: No, score=-99.174 tagged_above=-999 required=5 tests=[AWL=-0.640, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDGt-hWAiKt0 for ; Fri, 2 Apr 2010 13:14:18 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 2864A3A6C99 for ; Fri, 2 Apr 2010 12:48:40 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 85832DC0401A; Fri, 2 Apr 2010 19:49:14 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id C18D8DC04018; Fri, 2 Apr 2010 19:49:13 +0000 (UTC) Message-ID: <4BB64A39.80509@acm.org> Date: Fri, 02 Apr 2010 12:49:13 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100307 Iceowl/1.0b1 Icedove/3.0.3 MIME-Version: 1.0 To: Roman Shpount References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 20:14:20 -0000 On 04/02/2010 12:02 PM, Roman Shpount wrote: > This is all wonderful, but what seems to be missing here is any type of > standard test for DTMF tone detection. We have a number of tests for > things that should not be detected as DTMF (various talk-off tapes), but > there is no test with samples of valid DTMF signals. In real world you > get quite a variety of tones that different handsets or telephone > devices generate when a digit is pressed. Some of those tones are almost > at border line conditions for a valid DTMF tone. > > Second issue, which was already mentioned here, would be performance of > DTMF tone detector in the presence of packet loss or time stretching > caused by jitter buffer. Those things, even if they do not prevent DTMF > detection, are almost guaranteed to split a single long tone in two. > > Finally, we seemed to concentrate on DTMF tones only, but in reality all > the signaling/special tones are quite important. Fax Send/Receive tones > come to mind almost immediately as tones that are typically detected > inband (very few gateways encode those tones using RFC 4733/2833) > > I think we should formulate this requirement not in terms of DTMF tone > but in terms of accuracy of reproduction of periodic signals in > specified frequency ranges. To be honest, the most robust solution would > be to incorporate RFC4733/4744 as a part of the codec in a manner > similar to comfort noise frames. Why would you want to do that, when there is perfectly good *Internet* codecs for telephony signals (RFC 4733, RFC 4734 and RFC 5244) and comfort noise (RFC 3389)? > _____________________________ > Roman Shpount - www.telurix.com > > > On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene > wrote: > > Hi Stephan, > > Comments inline: > > > --------------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of Tübingen > Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > From: stephen botzko [mailto:stephen.botzko@gmail.com > ] > Sent: Friday, April 02, 2010 4:50 PM > To: Christian Hoene > Cc: Michael Knappe; stpeter@stpeter.im ; > codec@ietf.org > Subject: Re: [codec] #5: Mention DTMF in requirements > > (a) "MUST NOT" means that it must fail. Perhaps you meant "need > not" or "might not"? > > CH: Yes, I meant need not (or the German „muss nicht“) > > (b) SHOULD is commonly used in establishing requirements, and it > certainly was used in MARTINI and other working groups at IETF77 in > requirements presentations with no confusion. It has a clear meaning > in the requirements context (desirable but not essential) and I > see no reason to avoid its use at this phase. There will certainly > be other things that are "nice to have", and it is appropriate > to track them and consider them in the selection/standardization > process. > > CH: Better? "The codec SHOULD support the transmission DTMF at most > transmission conditions." > > I agree that language about DTMF might not need to be in the final > RFC. Though if DTMF quality is known to be inadequate, it > probably makes sense to tell people that. > > CH: Agreed. The limits of the codec shall be clearly stated. > > I also agree to the obvious comment that DTMF detection methods are > out of scope. > > CH: Agreed. > > CH: Isn't time to include the MUST requirement for DTMF testing and > SHOULD requirement for transmission support into the > requirements document. > Then, we could close issue #5 and continue with other things. > > Christian -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From Felix.Wyss@inin.com Fri Apr 2 13:24:34 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C9D43A6AA5 for ; Fri, 2 Apr 2010 13:24:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.576 X-Spam-Level: X-Spam-Status: No, score=0.576 tagged_above=-999 required=5 tests=[AWL=-0.555, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id avZFtUF3ANQf for ; Fri, 2 Apr 2010 13:24:33 -0700 (PDT) Received: from inin.com (smtpgw.inin.com [209.43.1.24]) by core3.amsl.com (Postfix) with ESMTP id DCE0F3A6B69 for ; Fri, 2 Apr 2010 13:00:08 -0700 (PDT) Received: from ININHUB2 [172.16.1.157] by smtpgw.inin.com - Websense Email Security (6.1.1); Fri, 02 Apr 2010 16:00:41 -0400 Received: from ININMAIL.i3domain.inin.com ([172.16.1.186]) by ininhub2.i3domain.inin.com ([172.16.1.157]) with mapi; Fri, 2 Apr 2010 16:00:41 -0400 From: "Wyss, Felix" To: "'Raymond (Juin-Hwey) Chen'" , Brian West , stephen botzko Date: Fri, 2 Apr 2010 16:00:41 -0400 Thread-Topic: [codec] #5: Mention DTMF in requirements Thread-Index: AcrSbkLl/+OtG4IbRliwMoqBvakvvgAIBaGQAAN48QA= Message-ID: References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <4BAF776D.20904@acm.org> <6e9223711003281100q7e1f7ac0pd548a2ab40e95ba4@mail.gmail.com> <4BAF9E7B.1070708@acm.org> <4BB58E31.2050809@coppice.org> <617DF0128820F9458AC39149A627EE6C01A2A21146@MBX.dialogic.com> <4BB5F7B6.1080808@stpeter.im> <0BD7AE28-298A-4586-9FB4-33925A8F8B8C@freeswitch.org> In-Reply-To: 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 X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1 X-SEF-ZeroHour-RefID: fgs=4 X-SEF-Processed: 6_1_1_105__2010_04_02_16_00_41 Cc: "codec@ietf.org" Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 20:24:34 -0000 I agree with those who question the value of catering to in-band DTMF for t= his codec. Doing so will invariably require compromises somewhere else (qu= ality/birate, CPU cost, coding delay, development/testing effort, code comp= lexity, etc.) Do we really expect that by the time this codec will be stan= dardized and in wide use there will still be VoIP providers or devices that= do not support RFC#2833 -- yet who do support this new codec?=20 --Felix > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > Raymond (Juin-Hwey) Chen > Sent: Friday, April 02, 2010 14:54 > To: Brian West; stephen botzko > Cc: codec@ietf.org > Subject: Re: [codec] #5: Mention DTMF in requirements >=20 > (Responding to an earlier email on this topic...) >=20 > I think the issue here is not for a codec to detect DTMF, but for a codec > to encode and decode the DTMF waveform with sufficient fidelity so it wil= l > not cause DTMF detection problems later in a DTMF detector. >=20 > Although most codecs do not explicitly make use of DTMF properties to > improve their coding fidelity with DTMF waveforms, a codec developer can > indeed test a codec by passing DTMF tones through the codec followed by a > DTMF detector and try to tune or otherwise improve the codec so that it > minimizes the DTMF detection error rate as seen by the DTMF detector. In > fact, this is exactly what we have done when we developed the BV16 codec, > and as a result of such testing and tuning, we were indeed able to modify > the BV16 codec algorithm to improve the DTMF detection error rate after > DTMF tones were passed through BV16 and then detected by a commercial DTM= F > detector. Such DTMF pass-through test results of BV16, G.711, G.728, > G.729E, and G.729 are described in our BroadVoice16 paper in the > Proceedings of the 40th Asilomar Conference on Signals, Systems and > Computers, 2006, available at our BroadVoice website > www.broadcom.com/broadvoice. That's why I could answer with confidence > the > DTMF pass-through question raised right after my BroadVoice codec > presentation at our IETF 77 codec WG meeting on March 22. >=20 > I think in those conditions where out-of-band DTMF signaling is not > available or is not implemented properly, it is crucial for the codec to > pass DTMF tones through without causing significant increase of the DMTF > detection error rate in a DTMF detector downstream, otherwise you may not > even be able to get the correct telephone number through, or a credit car= d > number or key press responses to a voice response system (press 1 for > this, press 2 for that,...) may not go through correctly. That's why we > went through the trouble of testing BV16 with DTMF tones and modifying > BV16 to minimize the DTMF detection error rate, and that's why I agree > with Stephen's comments below. >=20 > Raymond >=20 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > Brian West > Sent: Friday, April 02, 2010 7:10 AM > To: stephen botzko > Cc: codec@ietf.org > Subject: Re: [codec] #5: Mention DTMF in requirements >=20 > But Codecs themselves do not detect DTMF. Thats the job of the DTMF > detector. NOT the codec. In all my work with codecs I have not once see= n > one that knows anything about DTMF. And if the codec is too lossy inband > is out of the question. >=20 > /b >=20 > On Apr 2, 2010, at 9:01 AM, stephen botzko wrote: >=20 > > I heard no decision as to DTMF tone encoding. > > > > As far as I am concerned, the question of whether the codec MUST encode > DTMF tones accurately enough to be detected at the decoder output (or > SHOULD or non-requirement) is still open. > > > > That question clearly is in-scope, and has nothing to do with signaling= . > > > > Stephen Botzko >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From stephen.botzko@gmail.com Fri Apr 2 13:34:16 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E04F83A6944 for ; Fri, 2 Apr 2010 13:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.125 X-Spam-Level: X-Spam-Status: No, score=0.125 tagged_above=-999 required=5 tests=[AWL=-0.821, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Ajp7eqNG8uL for ; Fri, 2 Apr 2010 13:34:15 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id EC4363A6B99 for ; Fri, 2 Apr 2010 13:12:08 -0700 (PDT) Received: by ywh38 with SMTP id 38so81968ywh.29 for ; Fri, 02 Apr 2010 13:12:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=mAzjaeHZV4MMvyEt9xxYY3L3Nb6UbXMpyFIWgU0Dgx8=; b=lrEy7yhLqW9PBRUnoaV2m7rsjsq3UNHPJ+Jwb0EwR/NqRZmkXZokuNzRdYUmKBpRbg sY151i7l0AlQ3quZp4D3HSDjifgsa4XWlwEEb7TRA5I6TswrGs8GKSWh2zNoWgKf+Gaw y2xZx5+VMkr/nr3HoiRP9YWnI5SAh+FfOpHZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ml/wZEn18jysxnZ7WI0zvKIO67oJO4HomsIF62u7dMgzD54EuJ1gOvtQbOyGVzV81e 4j7qwd+7IH8woa8enOyXxqVL5OZpD1N7HKnDRw1igBq6VtvGEBo1thPqMe/Zi4zo6eLC 0S5R0vxSYsexaKT8GqvW6aM28X8eNir7DsEEY= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Fri, 2 Apr 2010 13:12:40 -0700 (PDT) In-Reply-To: References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> Date: Fri, 2 Apr 2010 16:12:40 -0400 Received: by 10.151.25.8 with SMTP id c8mr3277261ybj.258.1270239160593; Fri, 02 Apr 2010 13:12:40 -0700 (PDT) Message-ID: From: stephen botzko To: Roman Shpount Content-Type: multipart/alternative; boundary=000e0cd256d2f26e31048346999c Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 20:34:17 -0000 --000e0cd256d2f26e31048346999c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable We don't have agreed-upon tests for anything. I've been assuming (possibly incorrectly) that after the requirements are understood the group will need to develop a test plan that indicates how we will test against the various requirements. Stephen Botzko On Fri, Apr 2, 2010 at 3:02 PM, Roman Shpount wrote: > This is all wonderful, but what seems to be missing here is any type of > standard test for DTMF tone detection. We have a number of tests for thin= gs > that should not be detected as DTMF (various talk-off tapes), but there i= s > no test with samples of valid DTMF signals. In real world you get quite a > variety of tones that different handsets or telephone devices generate wh= en > a digit is pressed. Some of those tones are almost at border line conditi= ons > for a valid DTMF tone. > > Second issue, which was already mentioned here, would be performance of > DTMF tone detector in the presence of packet loss or time stretching caus= ed > by jitter buffer. Those things, even if they do not prevent DTMF detectio= n, > are almost guaranteed to split a single long tone in two. > > Finally, we seemed to concentrate on DTMF tones only, but in reality all > the signaling/special tones are quite important. Fax Send/Receive tones c= ome > to mind almost immediately as tones that are typically detected inband (v= ery > few gateways encode those tones using RFC 4733/2833) > > I think we should formulate this requirement not in terms of DTMF tone bu= t > in terms of accuracy of reproduction of periodic signals in specified > frequency ranges. To be honest, the most robust solution would be to > incorporate RFC4733/4744 as a part of the codec in a manner similar to > comfort noise frames. > _____________________________ > Roman Shpount - www.telurix.com > > > On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene w= rote: > >> Hi Stephan, >> >> Comments inline: >> >> >> --------------------------------------------------------------- >> Dr.-Ing. Christian Hoene >> Interactive Communication Systems (ICS), University of T=FCbingen >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >> http://www.net.uni-tuebingen.de/ >> >> From: stephen botzko [mailto:stephen.botzko@gmail.com] >> Sent: Friday, April 02, 2010 4:50 PM >> To: Christian Hoene >> Cc: Michael Knappe; stpeter@stpeter.im; codec@ietf.org >> Subject: Re: [codec] #5: Mention DTMF in requirements >> >> (a) "MUST NOT" means that it must fail. Perhaps you meant "need not" or >> "might not"? >> >> CH: Yes, I meant need not (or the German =84muss nicht=93) >> >> (b) SHOULD is commonly used in establishing requirements, and it certain= ly >> was used in MARTINI and other working groups at IETF77 in >> requirements presentations with no confusion. It has a clear meaning in >> the requirements context (desirable but not essential) and I >> see no reason to avoid its use at this phase. There will certainly be >> other things that are "nice to have", and it is appropriate >> to track them and consider them in the selection/standardization process= . >> >> CH: Better? "The codec SHOULD support the transmission DTMF at most >> transmission conditions." >> >> I agree that language about DTMF might not need to be in the final RFC. >> Though if DTMF quality is known to be inadequate, it >> probably makes sense to tell people that. >> >> CH: Agreed. The limits of the codec shall be clearly stated. >> >> I also agree to the obvious comment that DTMF detection methods are out = of >> scope. >> >> CH: Agreed. >> >> CH: Isn't time to include the MUST requirement for DTMF testing and SHOU= LD >> requirement for transmission support into the >> requirements document. >> Then, we could close issue #5 and continue with other things. >> >> Christian >> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > --000e0cd256d2f26e31048346999c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable We don't have agreed-upon tests for anything.=A0 I've been assuming= (possibly incorrectly) that after the requirements are understood the grou= p will need to develop a test plan that indicates how we will test against = the various requirements.

Stephen Botzko

On Fri, Apr 2, 2010 at= 3:02 PM, Roman Shpount <roman@telurix.com> wrote:
This is all wonderful, but what seems to be missing here is any type of sta= ndard test for DTMF tone detection. We have a number of tests for things th= at should not be detected as DTMF (various talk-off tapes), but there is no= test with samples of valid DTMF signals. In real world you get quite a var= iety of tones that different handsets or telephone devices generate when a = digit is pressed. Some of those tones are almost at border line conditions = for a valid DTMF tone.

Second issue, which was already mentioned here, would be performance of= DTMF tone detector in the presence of packet loss or time stretching cause= d by jitter buffer. Those things, even if they do not prevent DTMF detectio= n, are almost guaranteed to split a single long tone in two.

Finally, we seemed to concentrate on DTMF tones only, but in reality al= l the signaling/special tones are quite important. Fax Send/Receive tones c= ome to mind almost immediately as tones that are typically detected inband = (very few gateways encode those tones using RFC 4733/2833)

I think we should formulate this requirement not in terms of DTMF tone = but in terms of accuracy of reproduction of=A0 periodic signals in specifie= d frequency ranges. To be honest, the most robust solution would be to inco= rporate RFC4733/4744 as a part of the codec in a manner similar to comfort = noise frames.
_____________________________
Roman Shpount - www.telurix.com


On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene <hoene@uni-tuebingen= .de> wrote:
=
Hi Stephan,

Comments inline:


---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.n= et.uni-tuebingen.de/

From: stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Friday, April 02, 2010 4:50 PM
To: Christian Hoene
Cc: Michael Knappe; stpeter@stpeter.im; codec@ietf.org
Subject: Re: [codec] #5: Mention DTMF in requirements

(a) "MUST NOT" means that it must fail.=A0 Perhaps you= meant "need not" or "might not"?

CH: Yes, I meant need not (or the German =84muss nicht=93)

(b) SHOULD is commonly used in establishing requirements, and it certainly = was used in MARTINI and other working groups at IETF77 in
requirements presentations with no confusion. It has a clear meaning in the= requirements context (desirable but not essential) and I
see no reason to avoid its use at this phase.=A0 There will certainly be ot= her things that are "nice to have", and it is appropriate
to track them and consider them in the selection/standardization process.
CH: Better? "The codec SHOULD support the transmission DTMF at m= ost transmission conditions."

I agree that language about DTMF might not need to be in the final RFC.=A0 = Though if DTMF quality is known to be inadequate, it
probably makes sense to tell people that.

CH: Agreed. The limits of the codec shall be clearly stated.

I also agree to the obvious comment that DTMF detection methods are out of = scope.

CH: Agreed.

CH: Isn't time to include the MUST requirement for DTMF testing and SHO= ULD requirement for transmission support into the
requirements document.
Then, we could close issue #5 and continue with other things.

=A0Christian



_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec


_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec


--000e0cd256d2f26e31048346999c-- From roman@telurix.com Fri Apr 2 13:44:01 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6483D3A6AB0 for ; Fri, 2 Apr 2010 13:44:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wkhzuOphCCAF for ; Fri, 2 Apr 2010 13:43:59 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id 603B53A6B5B for ; Fri, 2 Apr 2010 13:25:33 -0700 (PDT) Received: by ywh38 with SMTP id 38so87741ywh.29 for ; Fri, 02 Apr 2010 13:26:03 -0700 (PDT) Received: by 10.90.155.3 with SMTP id c3mr2997051age.9.1270239961666; Fri, 02 Apr 2010 13:26:01 -0700 (PDT) Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by mx.google.com with ESMTPS id 21sm2192518iwn.11.2010.04.02.13.26.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 13:26:00 -0700 (PDT) Received: by iwn29 with SMTP id 29so1777670iwn.17 for ; Fri, 02 Apr 2010 13:25:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.12.12 with HTTP; Fri, 2 Apr 2010 13:25:59 -0700 (PDT) In-Reply-To: <4BB64A39.80509@acm.org> References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> <4BB64A39.80509@acm.org> Date: Fri, 2 Apr 2010 16:25:59 -0400 Received: by 10.231.157.208 with SMTP id c16mr1034429ibx.81.1270239959308; Fri, 02 Apr 2010 13:25:59 -0700 (PDT) Message-ID: From: Roman Shpount To: Marc Petit-Huguenin Content-Type: multipart/alternative; boundary=0050450160728dd972048346c959 Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 20:44:01 -0000 --0050450160728dd972048346c959 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This was somewhat my point: instead of figuring out how to encode telephone signals in the CODEC encode them using these standards. If we need to make this robust in situations when these CODECs are not available we can includ= e a pass though mechanism for their content in the CODEC itself (even though = I really think this is a bad idea). Whatever we are going to do to encode telephony signals would probably be worse quality, less robust and consume more bandwidth then the existing work. Not sure why we need to recreate it. Comfort noise is a different animal altogether. First of all, I think CN is covered by IPR licensing from G.729. Furthermore, unless I am mistaken, it is narrow band. I heard suggestions about using AMR-WB comfort noise for wide band, but this once again might be covered by AMR-WB IPR. _____________________________ Roman Shpount - www.telurix.com On Fri, Apr 2, 2010 at 3:49 PM, Marc Petit-Huguenin wrote= : > On 04/02/2010 12:02 PM, Roman Shpount wrote: > > This is all wonderful, but what seems to be missing here is any type of > > standard test for DTMF tone detection. We have a number of tests for > > things that should not be detected as DTMF (various talk-off tapes), bu= t > > there is no test with samples of valid DTMF signals. In real world you > > get quite a variety of tones that different handsets or telephone > > devices generate when a digit is pressed. Some of those tones are almos= t > > at border line conditions for a valid DTMF tone. > > > > Second issue, which was already mentioned here, would be performance of > > DTMF tone detector in the presence of packet loss or time stretching > > caused by jitter buffer. Those things, even if they do not prevent DTMF > > detection, are almost guaranteed to split a single long tone in two. > > > > Finally, we seemed to concentrate on DTMF tones only, but in reality al= l > > the signaling/special tones are quite important. Fax Send/Receive tones > > come to mind almost immediately as tones that are typically detected > > inband (very few gateways encode those tones using RFC 4733/2833) > > > > I think we should formulate this requirement not in terms of DTMF tone > > but in terms of accuracy of reproduction of periodic signals in > > specified frequency ranges. To be honest, the most robust solution woul= d > > be to incorporate RFC4733/4744 as a part of the codec in a manner > > similar to comfort noise frames. > > Why would you want to do that, when there is perfectly good *Internet* > codecs > for telephony signals (RFC 4733, RFC 4734 and RFC 5244) and comfort noise > (RFC > 3389)? > > > _____________________________ > > Roman Shpount - www.telurix.com > > > > > > On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene > > wrote: > > > > Hi Stephan, > > > > Comments inline: > > > > > > --------------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of T=FCbingen > > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > > http://www.net.uni-tuebingen.de/ > > > > From: stephen botzko [mailto:stephen.botzko@gmail.com > > ] > > Sent: Friday, April 02, 2010 4:50 PM > > To: Christian Hoene > > Cc: Michael Knappe; stpeter@stpeter.im ; > > codec@ietf.org > > Subject: Re: [codec] #5: Mention DTMF in requirements > > > > (a) "MUST NOT" means that it must fail. Perhaps you meant "need > > not" or "might not"? > > > > CH: Yes, I meant need not (or the German =84muss nicht=93) > > > > (b) SHOULD is commonly used in establishing requirements, and it > > certainly was used in MARTINI and other working groups at IETF77 in > > requirements presentations with no confusion. It has a clear meanin= g > > in the requirements context (desirable but not essential) and I > > see no reason to avoid its use at this phase. There will certainly > > be other things that are "nice to have", and it is appropriate > > to track them and consider them in the selection/standardization > > process. > > > > CH: Better? "The codec SHOULD support the transmission DTMF at most > > transmission conditions." > > > > I agree that language about DTMF might not need to be in the final > > RFC. Though if DTMF quality is known to be inadequate, it > > probably makes sense to tell people that. > > > > CH: Agreed. The limits of the codec shall be clearly stated. > > > > I also agree to the obvious comment that DTMF detection methods are > > out of scope. > > > > CH: Agreed. > > > > CH: Isn't time to include the MUST requirement for DTMF testing and > > SHOULD requirement for transmission support into the > > requirements document. > > Then, we could close issue #5 and continue with other things. > > > > Christian > > -- > Marc Petit-Huguenin > Personal email: marc@petit-huguenin.org > Professional email: petithug@acm.org > Blog: http://blog.marc.petit-huguenin.org > --0050450160728dd972048346c959 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable This was somewhat my point: instead of figuring out how to encode telephone= signals in the CODEC encode them using these standards. If we need to make= this robust in situations when these CODECs are not available we can inclu= de a pass though mechanism for their content in the CODEC itself (even thou= gh I really think this is a bad idea). Whatever we are going to do to encod= e telephony signals would probably be worse quality, less robust and consum= e more bandwidth then the existing work. Not sure why we need to recreate i= t.

Comfort noise is a different animal altogether. First of all, I think C= N is covered by IPR licensing from G.729. Furthermore, unless I am mistaken= , it is narrow band. I heard suggestions about using AMR-WB comfort noise f= or wide band, but this once again might be covered by AMR-WB IPR.
_____________________________
Roman Shpount - www.telurix.com


On Fri, Apr 2, 2010 at 3:49 PM, Marc Pet= it-Huguenin <petit= hug@acm.org> wrote:
On 04/02/2010 12:02 PM, Roman Shpount wrote:
> This is all wonderful, but what seems to be missing here is any type o= f
> standard test for DTMF tone detection. We have a number of tests for > things that should not be detected as DTMF (various talk-off tapes), b= ut
> there is no test with samples of valid DTMF signals. In real world you=
> get quite a variety of tones that different handsets or telephone
> devices generate when a digit is pressed. Some of those tones are almo= st
> at border line conditions for a valid DTMF tone.
>
> Second issue, which was already mentioned here, would be performance o= f
> DTMF tone detector in the presence of packet loss or time stretching > caused by jitter buffer. Those things, even if they do not prevent DTM= F
> detection, are almost guaranteed to split a single long tone in two. >
> Finally, we seemed to concentrate on DTMF tones only, but in reality a= ll
> the signaling/special tones are quite important. Fax Send/Receive tone= s
> come to mind almost immediately as tones that are typically detected > inband (very few gateways encode those tones using RFC 4733/2833)
>
> I think we should formulate this requirement not in terms of DTMF tone=
> but in terms of accuracy of reproduction of =A0periodic signals in
> specified frequency ranges. To be honest, the most robust solution wou= ld
> be to incorporate RFC4733/4744 as a part of the codec in a manner
> similar to comfort noise frames.

Why would you want to do that, when there is perfectly good *Internet* code= cs
for telephony signals (RFC 4733, RFC 4734 and RFC 5244) and comfort noise (= RFC
3389)?

> _____________________________
> Roman Shpount - w= ww.telurix.com <http://www.telurix.com>
>
>
> On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene <hoene@uni-tuebingen.de
> <mailto:hoene@uni-tuebing= en.de>> wrote:
>
> =A0 =A0 Hi Stephan,
>
> =A0 =A0 Comments inline:
>
>
> =A0 =A0 --------------------------------------------------------------= -
> =A0 =A0 Dr.-Ing. Christian Hoene
> =A0 =A0 Interactive Communication Systems (ICS), University of T=FCbin= gen
> =A0 =A0 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
> =A0 =A0 http://www.net.uni-tuebingen.de/
>
> =A0 =A0 From: stephen botzko [mailto:stephen.botzko@gmail.com
> =A0 =A0 <mailto:stephen= .botzko@gmail.com>]
> =A0 =A0 Sent: Friday, April 02, 2010 4:50 PM
> =A0 =A0 To: Christian Hoene
> =A0 =A0 Cc: Michael Knappe; stpe= ter@stpeter.im <mailto:stpeter= @stpeter.im>;
> =A0 =A0 codec@ietf.org <mailt= o:codec@ietf.org>
> =A0 =A0 Subject: Re: [codec] #5: Mention DTMF in requirements
>
> =A0 =A0 (a) "MUST NOT" means that it must fail. =A0Perhaps y= ou meant "need
> =A0 =A0 not" or "might not"?
>
> =A0 =A0 CH: Yes, I meant need not (or the German =84muss nicht=93)
>
> =A0 =A0 (b) SHOULD is commonly used in establishing requirements, and = it
> =A0 =A0 certainly was used in MARTINI and other working groups at IETF= 77 in
> =A0 =A0 requirements presentations with no confusion. It has a clear m= eaning
> =A0 =A0 in the requirements context (desirable but not essential) and = I
> =A0 =A0 see no reason to avoid its use at this phase. =A0There will ce= rtainly
> =A0 =A0 be other things that are "nice to have", and it is a= ppropriate
> =A0 =A0 to track them and consider them in the selection/standardizati= on
> =A0 =A0 process.
>
> =A0 =A0 CH: Better? "The codec SHOULD support the transmission DT= MF at most
> =A0 =A0 transmission conditions."
>
> =A0 =A0 I agree that language about DTMF might not need to be in the f= inal
> =A0 =A0 RFC. =A0Though if DTMF quality is known to be inadequate, it > =A0 =A0 probably makes sense to tell people that.
>
> =A0 =A0 CH: Agreed. The limits of the codec shall be clearly stated. >
> =A0 =A0 I also agree to the obvious comment that DTMF detection method= s are
> =A0 =A0 out of scope.
>
> =A0 =A0 CH: Agreed.
>
> =A0 =A0 CH: Isn't time to include the MUST requirement for DTMF te= sting and
> =A0 =A0 SHOULD requirement for transmission support into the
> =A0 =A0 requirements document.
> =A0 =A0 Then, we could close issue #5 and continue with other things.<= br> >
> =A0 =A0 =A0Christian

--
Marc Petit-Huguenin
Personal email: marc@petit-hugue= nin.org
Professional email: petithug@acm.org
Blog: htt= p://blog.marc.petit-huguenin.org

--0050450160728dd972048346c959-- From roman@telurix.com Fri Apr 2 13:49:47 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5F2E3A6BC7 for ; Fri, 2 Apr 2010 13:49:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IeMdPNOuDfhC for ; Fri, 2 Apr 2010 13:49:46 -0700 (PDT) Received: from mail-qy0-f195.google.com (mail-qy0-f195.google.com [209.85.221.195]) by core3.amsl.com (Postfix) with ESMTP id 9BC753A6B0D for ; Fri, 2 Apr 2010 13:32:26 -0700 (PDT) Received: by qyk33 with SMTP id 33so2546312qyk.28 for ; Fri, 02 Apr 2010 13:32:58 -0700 (PDT) Received: by 10.229.190.129 with SMTP id di1mr4513529qcb.75.1270240377792; Fri, 02 Apr 2010 13:32:57 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by mx.google.com with ESMTPS id y41sm1429986qce.17.2010.04.02.13.32.56 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 13:32:57 -0700 (PDT) Received: by gwj20 with SMTP id 20so60863gwj.31 for ; Fri, 02 Apr 2010 13:32:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.12.12 with HTTP; Fri, 2 Apr 2010 13:32:53 -0700 (PDT) In-Reply-To: References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> Date: Fri, 2 Apr 2010 16:32:53 -0400 Received: by 10.101.131.15 with SMTP id i15mr6037984ann.13.1270240373577; Fri, 02 Apr 2010 13:32:53 -0700 (PDT) Message-ID: From: Roman Shpount To: stephen botzko Content-Type: multipart/alternative; boundary=001636c924213fa9cc048346e29c Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 20:49:47 -0000 --001636c924213fa9cc048346e29c Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I have a feeling that this requirement as it stands right now is non-enforceable since there is no industry accepted test on DTMF pass through. Creating such test will not be trivial since it will require collection of the large amount of real life DTMF and other telephony signal recordings. So, we cannot make this a requirement for a new codec unless we define this in a form of some minimum frequency fidelity or some other independently verifiable quality requirement. _____________ Roman Shpount On Fri, Apr 2, 2010 at 4:12 PM, stephen botzko wr= ote: > We don't have agreed-upon tests for anything. I've been assuming (possib= ly > incorrectly) that after the requirements are understood the group will ne= ed > to develop a test plan that indicates how we will test against the variou= s > requirements. > > Stephen Botzko > > On Fri, Apr 2, 2010 at 3:02 PM, Roman Shpount wrote: > >> This is all wonderful, but what seems to be missing here is any type of >> standard test for DTMF tone detection. We have a number of tests for thi= ngs >> that should not be detected as DTMF (various talk-off tapes), but there = is >> no test with samples of valid DTMF signals. In real world you get quite = a >> variety of tones that different handsets or telephone devices generate w= hen >> a digit is pressed. Some of those tones are almost at border line condit= ions >> for a valid DTMF tone. >> >> Second issue, which was already mentioned here, would be performance of >> DTMF tone detector in the presence of packet loss or time stretching cau= sed >> by jitter buffer. Those things, even if they do not prevent DTMF detecti= on, >> are almost guaranteed to split a single long tone in two. >> >> Finally, we seemed to concentrate on DTMF tones only, but in reality all >> the signaling/special tones are quite important. Fax Send/Receive tones = come >> to mind almost immediately as tones that are typically detected inband (= very >> few gateways encode those tones using RFC 4733/2833) >> >> I think we should formulate this requirement not in terms of DTMF tone b= ut >> in terms of accuracy of reproduction of periodic signals in specified >> frequency ranges. To be honest, the most robust solution would be to >> incorporate RFC4733/4744 as a part of the codec in a manner similar to >> comfort noise frames. >> _____________________________ >> Roman Shpount - www.telurix.com >> >> >> On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene = wrote: >> >>> Hi Stephan, >>> >>> Comments inline: >>> >>> >>> --------------------------------------------------------------- >>> Dr.-Ing. Christian Hoene >>> Interactive Communication Systems (ICS), University of T=FCbingen >>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >>> http://www.net.uni-tuebingen.de/ >>> >>> From: stephen botzko [mailto:stephen.botzko@gmail.com] >>> Sent: Friday, April 02, 2010 4:50 PM >>> To: Christian Hoene >>> Cc: Michael Knappe; stpeter@stpeter.im; codec@ietf.org >>> >>> Subject: Re: [codec] #5: Mention DTMF in requirements >>> >>> (a) "MUST NOT" means that it must fail. Perhaps you meant "need not" o= r >>> "might not"? >>> >>> CH: Yes, I meant need not (or the German =84muss nicht=93) >>> >>> (b) SHOULD is commonly used in establishing requirements, and it >>> certainly was used in MARTINI and other working groups at IETF77 in >>> requirements presentations with no confusion. It has a clear meaning in >>> the requirements context (desirable but not essential) and I >>> see no reason to avoid its use at this phase. There will certainly be >>> other things that are "nice to have", and it is appropriate >>> to track them and consider them in the selection/standardization proces= s. >>> >>> CH: Better? "The codec SHOULD support the transmission DTMF at most >>> transmission conditions." >>> >>> I agree that language about DTMF might not need to be in the final RFC. >>> Though if DTMF quality is known to be inadequate, it >>> probably makes sense to tell people that. >>> >>> CH: Agreed. The limits of the codec shall be clearly stated. >>> >>> I also agree to the obvious comment that DTMF detection methods are out >>> of scope. >>> >>> CH: Agreed. >>> >>> CH: Isn't time to include the MUST requirement for DTMF testing and >>> SHOULD requirement for transmission support into the >>> requirements document. >>> Then, we could close issue #5 and continue with other things. >>> >>> Christian >>> >>> >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> > --001636c924213fa9cc048346e29c Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I have a feeling that this requirement as it stands right now is non-enforc= eable since there is no industry accepted test on DTMF pass through.=A0 Cre= ating such test will not be trivial since it will require collection of the= large amount of real life DTMF and other telephony signal recordings. So, = we cannot make this a requirement for a new codec unless we define this in = a form of some minimum frequency fidelity or some other independently verif= iable quality requirement.
_____________
Roman Shpount


On Fri, Apr 2, 2010 at 4:12 PM, stephen = botzko <st= ephen.botzko@gmail.com> wrote:
We don't have agreed-upon tests for anything.=A0 I've been assuming= (possibly incorrectly) that after the requirements are understood the grou= p will need to develop a test plan that indicates how we will test against = the various requirements.

Stephen Botzko

On F= ri, Apr 2, 2010 at 3:02 PM, Roman Shpount <roman@telurix.com> wrote:
This is all wonderful, but what seems to be missing here is any type of sta= ndard test for DTMF tone detection. We have a number of tests for things th= at should not be detected as DTMF (various talk-off tapes), but there is no= test with samples of valid DTMF signals. In real world you get quite a var= iety of tones that different handsets or telephone devices generate when a = digit is pressed. Some of those tones are almost at border line conditions = for a valid DTMF tone.

Second issue, which was already mentioned here, would be performance of= DTMF tone detector in the presence of packet loss or time stretching cause= d by jitter buffer. Those things, even if they do not prevent DTMF detectio= n, are almost guaranteed to split a single long tone in two.

Finally, we seemed to concentrate on DTMF tones only, but in reality al= l the signaling/special tones are quite important. Fax Send/Receive tones c= ome to mind almost immediately as tones that are typically detected inband = (very few gateways encode those tones using RFC 4733/2833)

I think we should formulate this requirement not in terms of DTMF tone = but in terms of accuracy of reproduction of=A0 periodic signals in specifie= d frequency ranges. To be honest, the most robust solution would be to inco= rporate RFC4733/4744 as a part of the codec in a manner similar to comfort = noise frames.
_____________________________
Roman Shpount - www.telurix.com


On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene <hoene@un= i-tuebingen.de> wrote:
Hi Stephan,

Comments inline:


---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.n= et.uni-tuebingen.de/

From: stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Friday, April 02, 2010 4:50 PM
To: Christian Hoene
Cc: Michael Knappe; stpeter@stpeter.im; codec@ietf.org

Subject: Re: [codec] #5: Mention DTMF in requirements

(a) "MUST NOT" means that it must fail.=A0 Perhaps you= meant "need not" or "might not"?

CH: Yes, I meant need not (or the German =84muss nicht=93)

(b) SHOULD is commonly used in establishing requirements, and it certainly = was used in MARTINI and other working groups at IETF77 in
requirements presentations with no confusion. It has a clear meaning in the= requirements context (desirable but not essential) and I
see no reason to avoid its use at this phase.=A0 There will certainly be ot= her things that are "nice to have", and it is appropriate
to track them and consider them in the selection/standardization process.
CH: Better? "The codec SHOULD support the transmission DTMF at m= ost transmission conditions."

I agree that language about DTMF might not need to be in the final RFC.=A0 = Though if DTMF quality is known to be inadequate, it
probably makes sense to tell people that.

CH: Agreed. The limits of the codec shall be clearly stated.

I also agree to the obvious comment that DTMF detection methods are out of = scope.

CH: Agreed.

CH: Isn't time to include the MUST requirement for DTMF testing and SHO= ULD requirement for transmission support into the
requirements document.
Then, we could close issue #5 and continue with other things.

=A0Christian



_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec


_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec


On Fri, Apr 2, 2010 at 1= 0:26 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:

= I would vote for a

= =A0=

= Th= e DTMF transmission performance MUST be tested and characterized (via an automatic open source testing tool= )

= bu= t it MUST NOT work well under all operational conditions. =A0Especially at low coding rates under the presence of packet losses it might not work r= eliable.

= = =A0

= Ch= ristian

= = =A0

---------------------------------------------------= ------------

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University= of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 = 2970532
= http://www.net.uni-tu= ebingen.de/

= = =A0

From<= font size=3D"2" face=3D"Tahoma">: codec-bounces@ietf.org [mailto:codec-b= ounces@ietf.org] On Behalf Of Michael Knappe
Sent: Friday, April 02, 20= 10 4:20 PM
To: stephen.botzko@gmail.com; stpeter@stpeter.im<= /a>
Cc: codec@ietf.org


Subject: Re: [codec] #5: M= ention DTMF in requirements

=A0

Agreed.

Mike

From: codec-bounces@i= etf.org <codec-bounces@ietf.org>
To: Peter Saint-Andre <= stpeter@stpeter.im<= /a>>
Cc: codec@ietf.org <codec@ietf.org&= gt;
Sent: Fri Apr 02 10:01:42 = 2010
Subject: Re: [codec] #5: M= ention DTMF in requirements

I heard no decision a= s to DTMF tone encoding.

As far as I am concerned, the question of whether the codec MUST encode DTM= F tones accurately enough to be detected at the decoder output (or SHOULD or non-requirement) is still open.

That question clearly is in-scope, and has nothing to do with signaling.
Stephen Botzko

On Fri, Apr 2, 2010 at 9:57 AM, Peter Saint-Andre &l= t;stpeter@stpeter.i= m> wrote:

How is the never-ending debate among DTMF signalling= *methods* in-scope
for the Codec WG? I think that Henning brought this up in Anaheim only
to make sure that we test some DTMF tones. The signalling method is out
of scope for the codec itself.


On 4/2/10 7:53 AM, stephen botzko wrote:
> Are you two suggesting that in-band DTMF is a MUST? =A0Or alternativel= y a
> SHOULD?
>
> Stephen Botzko
>
> On Fri, Apr 2, 2010 at 9:48 AM, James Rafferty

> <James.Rafferty@dialogic.com <mailto:James.Rafferty@dialogic.com>> wrote:
>
> =A0 =A0 I'd agree with Steve that are still many deployments which do not
> =A0 =A0 use RFC 2833 or RFC 4733. In our gateways, we've had to support
> =A0 =A0 interworking variations of tone support such as INFO and in-band, in
> =A0 =A0 addition to the RFC 2833 / RFC 4733.
>
> =A0 =A0 James
> =A0 =A0 -----Original Message-----
> =A0 =A0 From: codec-bounces@ietf.org <mailto:code= c-bounces@ietf.org>

> =A0 =A0 [mailto:codec-bounces@ietf.org <mailto:code= c-bounces@ietf.org>] On
> =A0 =A0 Behalf Of Steve Underwood
> =A0 =A0 Sent: Friday, April 02, 2010 2:27 AM

> =A0 =A0 To: codec@ietf.org <mail= to:codec@ietf.org&g= t;
> =A0 =A0 Subject: Re: [codec] #5: Mention DTMF in requirements
>
> =A0 =A0 On 03/29/2010 02:22 AM, Marc Petit-Huguenin wrote:
> =A0 =A0 > On 03/28/2010 11:00 AM, stephen botzko wrote:
> =A0 =A0 >
> =A0 =A0 >> I would agree with this if I saw reasonable evidence that a
> =A0 =A0 >> preponderance of gateways and sending systems provide the
> =A0 =A0 signaling in
> =A0 =A0 >> these RFCs.
> =A0 =A0 >>
> =A0 =A0 >> Since I am not sure that this is the case, I am unconvinced that
> =A0 =A0 we can
> =A0 =A0 >> totally remove the requirement.
> =A0 =A0 >>
> =A0 =A0 >> I'd also say that an encoder that detects the DTM= F tones and
> =A0 =A0 outputs the
> =A0 =A0 >> RFC 4733/34 events would fully meet the requirement.
> =A0 =A0 >>
> =A0 =A0 > As former CTO of a VoIP provider, I never saw a PSTN provider not
> =A0 =A0 supporting at
> =A0 =A0 > least RFC 2833 (even if one of them did not declare it in its SDP)
> =A0 =A0 >
> =A0 =A0 > Perhaps the question can be asked at the next SIPit event.
> =A0 =A0 >
> =A0 =A0 Its true that RFC2833 is widely deployed. Its even true that many
> =A0 =A0 systems have updated to RFC4733. Sadly, its also true that there are
> =A0 =A0 still many quirky implementations widely deployed, and a lot of people
> =A0 =A0 still need to interwork with audio DTMF.
>
> =A0 =A0 Steve


_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

=A0


--001636c924213fa9cc048346e29c-- From stephen.botzko@gmail.com Fri Apr 2 13:56:07 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 422D23A698A for ; Fri, 2 Apr 2010 13:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.273 X-Spam-Level: X-Spam-Status: No, score=0.273 tagged_above=-999 required=5 tests=[AWL=-0.859, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tbajn2h7X-3X for ; Fri, 2 Apr 2010 13:56:05 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id 03A6F3A6989 for ; Fri, 2 Apr 2010 13:40:42 -0700 (PDT) Received: by ywh38 with SMTP id 38so94146ywh.29 for ; Fri, 02 Apr 2010 13:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=Y4IgQGcizJrbRQOMLa2SAhs7xGtKx/5PYJ3RUA/bVOk=; b=EQL+jkVaN8pUzZgCZ9hCoYBEieA58RtnyHV20RKkIkDpCbLvDzoEm1ZPMKuXMdNJFd wFsMxRBSnQViNyywdkpAdl0JPkJV2ryjo456ReuVrTPI+mJd9MRsRNL7Y9feXcIbiUYp IO47tR4xvpNDRnfxME+f6aVZR2ZdK7eN8eifY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XnsP7YXW4GMu/rO/yxAblL0uY+5Ns/hxfuO+6mrr8KEiGS8QjjYLWZJIHwdYF3HTvw DSIjBhFY6GbRdCc+h193u1677e3XC1d3o32/6R6dJR9S2QG30CX73saJh9Is+JhjMY66 8ezJGvwKoGaClC0wOu5fCjwyJHBWWdZvk6hxA= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Fri, 2 Apr 2010 13:41:13 -0700 (PDT) In-Reply-To: References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> Date: Fri, 2 Apr 2010 16:41:13 -0400 Received: by 10.151.92.11 with SMTP id u11mr3049490ybl.205.1270240873848; Fri, 02 Apr 2010 13:41:13 -0700 (PDT) Message-ID: From: stephen botzko To: Roman Shpount Content-Type: multipart/alternative; boundary=000e0cd2578e109f9e0483470070 Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 20:56:07 -0000 --000e0cd2578e109f9e0483470070 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Its my understanding that several other standardized codecs have had requirements like this one (and have somehow been tested). I agree that we will need a more precise and testable statement, and a corresponding test method. Though that will be true for *every* requirement we agree upon in this phase. Stephen Botzko On Fri, Apr 2, 2010 at 4:32 PM, Roman Shpount wrote: > I have a feeling that this requirement as it stands right now is > non-enforceable since there is no industry accepted test on DTMF pass > through. Creating such test will not be trivial since it will require > collection of the large amount of real life DTMF and other telephony sign= al > recordings. So, we cannot make this a requirement for a new codec unless = we > define this in a form of some minimum frequency fidelity or some other > independently verifiable quality requirement. > _____________ > Roman Shpount > > > > On Fri, Apr 2, 2010 at 4:12 PM, stephen botzko = wrote: > >> We don't have agreed-upon tests for anything. I've been assuming >> (possibly incorrectly) that after the requirements are understood the gr= oup >> will need to develop a test plan that indicates how we will test against= the >> various requirements. >> >> Stephen Botzko >> >> On Fri, Apr 2, 2010 at 3:02 PM, Roman Shpount wrote: >> >>> This is all wonderful, but what seems to be missing here is any type of >>> standard test for DTMF tone detection. We have a number of tests for th= ings >>> that should not be detected as DTMF (various talk-off tapes), but there= is >>> no test with samples of valid DTMF signals. In real world you get quite= a >>> variety of tones that different handsets or telephone devices generate = when >>> a digit is pressed. Some of those tones are almost at border line condi= tions >>> for a valid DTMF tone. >>> >>> Second issue, which was already mentioned here, would be performance of >>> DTMF tone detector in the presence of packet loss or time stretching ca= used >>> by jitter buffer. Those things, even if they do not prevent DTMF detect= ion, >>> are almost guaranteed to split a single long tone in two. >>> >>> Finally, we seemed to concentrate on DTMF tones only, but in reality al= l >>> the signaling/special tones are quite important. Fax Send/Receive tones= come >>> to mind almost immediately as tones that are typically detected inband = (very >>> few gateways encode those tones using RFC 4733/2833) >>> >>> I think we should formulate this requirement not in terms of DTMF tone >>> but in terms of accuracy of reproduction of periodic signals in specif= ied >>> frequency ranges. To be honest, the most robust solution would be to >>> incorporate RFC4733/4744 as a part of the codec in a manner similar to >>> comfort noise frames. >>> _____________________________ >>> Roman Shpount - www.telurix.com >>> >>> >>> On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene wrote: >>> >>>> Hi Stephan, >>>> >>>> Comments inline: >>>> >>>> >>>> --------------------------------------------------------------- >>>> Dr.-Ing. Christian Hoene >>>> Interactive Communication Systems (ICS), University of T=FCbingen >>>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >>>> http://www.net.uni-tuebingen.de/ >>>> >>>> From: stephen botzko [mailto:stephen.botzko@gmail.com] >>>> Sent: Friday, April 02, 2010 4:50 PM >>>> To: Christian Hoene >>>> Cc: Michael Knappe; stpeter@stpeter.im; codec@ietf.org >>>> >>>> Subject: Re: [codec] #5: Mention DTMF in requirements >>>> >>>> (a) "MUST NOT" means that it must fail. Perhaps you meant "need not" = or >>>> "might not"? >>>> >>>> CH: Yes, I meant need not (or the German =84muss nicht=93) >>>> >>>> (b) SHOULD is commonly used in establishing requirements, and it >>>> certainly was used in MARTINI and other working groups at IETF77 in >>>> requirements presentations with no confusion. It has a clear meaning i= n >>>> the requirements context (desirable but not essential) and I >>>> see no reason to avoid its use at this phase. There will certainly be >>>> other things that are "nice to have", and it is appropriate >>>> to track them and consider them in the selection/standardization >>>> process. >>>> >>>> CH: Better? "The codec SHOULD support the transmission DTMF at most >>>> transmission conditions." >>>> >>>> I agree that language about DTMF might not need to be in the final RFC= . >>>> Though if DTMF quality is known to be inadequate, it >>>> probably makes sense to tell people that. >>>> >>>> CH: Agreed. The limits of the codec shall be clearly stated. >>>> >>>> I also agree to the obvious comment that DTMF detection methods are ou= t >>>> of scope. >>>> >>>> CH: Agreed. >>>> >>>> CH: Isn't time to include the MUST requirement for DTMF testing and >>>> SHOULD requirement for transmission support into the >>>> requirements document. >>>> Then, we could close issue #5 and continue with other things. >>>> >>>> Christian >>>> >>>> >>>> >>>> _______________________________________________ >>>> codec mailing list >>>> codec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codec >>>> >>> >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>> >>> >> > --000e0cd2578e109f9e0483470070 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Its my understanding that several other standardized codecs have had requir= ements like this one (and have somehow been tested).=A0 I agree that we wil= l need a more precise and testable statement, and a corresponding test meth= od.

Though that will be true for every requirement we agree upon in = this phase.

Stephen Botzko




On Fri, Apr 2, 2010 at 4:32 PM, Roman Shpount <<= a href=3D"mailto:roman@telurix.com">roman@telurix.com> wrote:=
I have a feeling = that this requirement as it stands right now is non-enforceable since there= is no industry accepted test on DTMF pass through.=A0 Creating such test w= ill not be trivial since it will require collection of the large amount of = real life DTMF and other telephony signal recordings. So, we cannot make th= is a requirement for a new codec unless we define this in a form of some mi= nimum frequency fidelity or some other independently verifiable quality req= uirement.
_____________
Roman Shpount



On Fri, Apr 2, 2010 at 4:12 PM, stephen = botzko <stephen.botzko@gmail.com> wrote:
We don't have agreed-upon tests for anything.=A0 I've been assuming= (possibly incorrectly) that after the requirements are understood the grou= p will need to develop a test plan that indicates how we will test against = the various requirements.

Stephen Botzko

On Fri, Apr 2, 20= 10 at 3:02 PM, Roman Shpount <roman@telurix.com> wrote:
This is all wonderful, but what seems to be missing here is any type of sta= ndard test for DTMF tone detection. We have a number of tests for things th= at should not be detected as DTMF (various talk-off tapes), but there is no= test with samples of valid DTMF signals. In real world you get quite a var= iety of tones that different handsets or telephone devices generate when a = digit is pressed. Some of those tones are almost at border line conditions = for a valid DTMF tone.

Second issue, which was already mentioned here, would be performance of= DTMF tone detector in the presence of packet loss or time stretching cause= d by jitter buffer. Those things, even if they do not prevent DTMF detectio= n, are almost guaranteed to split a single long tone in two.

Finally, we seemed to concentrate on DTMF tones only, but in reality al= l the signaling/special tones are quite important. Fax Send/Receive tones c= ome to mind almost immediately as tones that are typically detected inband = (very few gateways encode those tones using RFC 4733/2833)

I think we should formulate this requirement not in terms of DTMF tone = but in terms of accuracy of reproduction of=A0 periodic signals in specifie= d frequency ranges. To be honest, the most robust solution would be to inco= rporate RFC4733/4744 as a part of the codec in a manner similar to comfort = noise frames.
_____________________________
Roman Shpount - www.telurix.com


O= n Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene <hoene@uni-tuebingen.d= e> wrote:
Hi Stephan,

Comments inline:


---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.n= et.uni-tuebingen.de/

From: stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Friday, April 02, 2010 4:50 PM
To: Christian Hoene
Cc: Michael Knappe; stpeter@stpeter.im; codec@ietf.org

Subject: Re: [codec] #5: Mention DTMF in requirements

(a) "MUST NOT" means that it must fail.=A0 Perhaps you= meant "need not" or "might not"?

CH: Yes, I meant need not (or the German =84muss nicht=93)

(b) SHOULD is commonly used in establishing requirements, and it certainly = was used in MARTINI and other working groups at IETF77 in
requirements presentations with no confusion. It has a clear meaning in the= requirements context (desirable but not essential) and I
see no reason to avoid its use at this phase.=A0 There will certainly be ot= her things that are "nice to have", and it is appropriate
to track them and consider them in the selection/standardization process.
CH: Better? "The codec SHOULD support the transmission DTMF at m= ost transmission conditions."

I agree that language about DTMF might not need to be in the final RFC.=A0 = Though if DTMF quality is known to be inadequate, it
probably makes sense to tell people that.

CH: Agreed. The limits of the codec shall be clearly stated.

I also agree to the obvious comment that DTMF detection methods are out of = scope.

CH: Agreed.

CH: Isn't time to include the MUST requirement for DTMF testing and SHO= ULD requirement for transmission support into the
requirements document.
Then, we could close issue #5 and continue with other things.

=A0Christian



_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec


_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec




--000e0cd2578e109f9e0483470070-- From petithug@acm.org Fri Apr 2 13:57:40 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A58623A6AD6 for ; Fri, 2 Apr 2010 13:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.111 X-Spam-Level: X-Spam-Status: No, score=-99.111 tagged_above=-999 required=5 tests=[AWL=-0.576, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mwF3GmL42d03 for ; Fri, 2 Apr 2010 13:57:39 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 5A73C3A68C8 for ; Fri, 2 Apr 2010 13:42:56 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 969BCDC0401A; Fri, 2 Apr 2010 20:43:29 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 9B730DC04018; Fri, 2 Apr 2010 20:43:28 +0000 (UTC) Message-ID: <4BB656F0.5080305@acm.org> Date: Fri, 02 Apr 2010 13:43:28 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.8) Gecko/20100307 Iceowl/1.0b1 Icedove/3.0.3 MIME-Version: 1.0 To: Roman Shpount References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> <4BB64A39.80509@acm.org> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 20:57:40 -0000 On 04/02/2010 01:25 PM, Roman Shpount wrote: > This was somewhat my point: instead of figuring out how to encode > telephone signals in the CODEC encode them using these standards. If we > need to make this robust in situations when these CODECs are not > available we can include a pass though mechanism for their content in > the CODEC itself (even though I really think this is a bad idea). > Whatever we are going to do to encode telephony signals would probably > be worse quality, less robust and consume more bandwidth then the > existing work. Not sure why we need to recreate it. Sorry, I misunderstood you then. I thought that you were proposing to use a different type of frame inside the codec to carry the DTMF. > > Comfort noise is a different animal altogether. First of all, I think CN > is covered by IPR licensing from G.729. I cannot find any IPR disclosure for RFC 3389 or draft-ietf-avt-rtp-cn. If you think that there should be one, then you should fill a third-party IPR disclosure. > Furthermore, unless I am > mistaken, it is narrow band. I heard suggestions about using AMR-WB > comfort noise for wide band, but this once again might be covered by > AMR-WB IPR. I do not see why RFC 3389 would not be used fine for the Internet wideband codec. There is an example for use with G.722.1: m=audio 49230 RTP/AVP 101 102 a=rtpmap:101 G7221/16000 a=fmtp:121 bitrate=24000 a=rtpmap:102 CN/16000 > _____________________________ > Roman Shpount - www.telurix.com > > > On Fri, Apr 2, 2010 at 3:49 PM, Marc Petit-Huguenin > wrote: > > On 04/02/2010 12:02 PM, Roman Shpount wrote: > > This is all wonderful, but what seems to be missing here is any > type of > > standard test for DTMF tone detection. We have a number of tests for > > things that should not be detected as DTMF (various talk-off > tapes), but > > there is no test with samples of valid DTMF signals. In real world you > > get quite a variety of tones that different handsets or telephone > > devices generate when a digit is pressed. Some of those tones are > almost > > at border line conditions for a valid DTMF tone. > > > > Second issue, which was already mentioned here, would be > performance of > > DTMF tone detector in the presence of packet loss or time stretching > > caused by jitter buffer. Those things, even if they do not prevent > DTMF > > detection, are almost guaranteed to split a single long tone in two. > > > > Finally, we seemed to concentrate on DTMF tones only, but in > reality all > > the signaling/special tones are quite important. Fax Send/Receive > tones > > come to mind almost immediately as tones that are typically detected > > inband (very few gateways encode those tones using RFC 4733/2833) > > > > I think we should formulate this requirement not in terms of DTMF tone > > but in terms of accuracy of reproduction of periodic signals in > > specified frequency ranges. To be honest, the most robust solution > would > > be to incorporate RFC4733/4744 as a part of the codec in a manner > > similar to comfort noise frames. > > Why would you want to do that, when there is perfectly good > *Internet* codecs > for telephony signals (RFC 4733, RFC 4734 and RFC 5244) and comfort > noise (RFC > 3389)? > > > _____________________________ > > Roman Shpount - www.telurix.com > > > > > > > On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene > > > >> > wrote: > > > > Hi Stephan, > > > > Comments inline: > > > > > > --------------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of Tübingen > > Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 > > http://www.net.uni-tuebingen.de/ > > > > From: stephen botzko [mailto:stephen.botzko@gmail.com > > > >] > > Sent: Friday, April 02, 2010 4:50 PM > > To: Christian Hoene > > Cc: Michael Knappe; stpeter@stpeter.im > >; > > codec@ietf.org > > > Subject: Re: [codec] #5: Mention DTMF in requirements > > > > (a) "MUST NOT" means that it must fail. Perhaps you meant "need > > not" or "might not"? > > > > CH: Yes, I meant need not (or the German „muss nicht“) > > > > (b) SHOULD is commonly used in establishing requirements, and it > > certainly was used in MARTINI and other working groups at > IETF77 in > > requirements presentations with no confusion. It has a clear > meaning > > in the requirements context (desirable but not essential) and I > > see no reason to avoid its use at this phase. There will > certainly > > be other things that are "nice to have", and it is appropriate > > to track them and consider them in the selection/standardization > > process. > > > > CH: Better? "The codec SHOULD support the transmission DTMF at > most > > transmission conditions." > > > > I agree that language about DTMF might not need to be in the final > > RFC. Though if DTMF quality is known to be inadequate, it > > probably makes sense to tell people that. > > > > CH: Agreed. The limits of the codec shall be clearly stated. > > > > I also agree to the obvious comment that DTMF detection > methods are > > out of scope. > > > > CH: Agreed. > > > > CH: Isn't time to include the MUST requirement for DTMF > testing and > > SHOULD requirement for transmission support into the > > requirements document. > > Then, we could close issue #5 and continue with other things. > > > > Christian -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From rchen@broadcom.com Fri Apr 2 14:08:58 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E76723A6AC8 for ; Fri, 2 Apr 2010 14:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.131 X-Spam-Level: * X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhhFCqJbdE3R for ; Fri, 2 Apr 2010 14:08:52 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 8CC513A6B02 for ; Fri, 2 Apr 2010 13:54:34 -0700 (PDT) Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 02 Apr 2010 13:54:59 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Fri, 2 Apr 2010 13:56:24 -0700 From: "Raymond (Juin-Hwey) Chen" To: "stephen botzko" , "Roman Shpount" Date: Fri, 2 Apr 2010 13:54:58 -0700 Thread-Topic: [codec] #5: Mention DTMF in requirements Thread-Index: AcrSo/iDgxlf/AFdTZOB1dMOKITgqAAAGIDA Message-ID: References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67A8862920S78021599-01-01 Content-Type: multipart/alternative; boundary=_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86DCBIRVEXCHCCR01c_ Cc: "codec@ietf.org" Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 21:08:59 -0000 --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86DCBIRVEXCHCCR01c_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Actually, ITU-T Recommendation G.720 gives some guidelines about how to tes= t a codec's performance when passing DTMF signals through in-band. (It als= o talks about other non-voice signals.) In practice, however, we found that some of the test conditions specified i= n G.720 are fairly extreme corner cases which you normally don't see in rea= l-world recorded DTMF signals. Real-world DTMF signals are usually easier = to pass through a codec without degradation in the DTMF detection error rat= e than those extreme DTMF conditions specified in G.720. In our BroadVoice16 paper that I mentioned previously, we described a metho= d for testing DTMF pass-through performance for a codec. The method is bas= ed on G.720 but with some relaxation of the extreme conditions to better re= flect the DTMF conditions we observed in a large amount of real-world recor= d DTMF signals. This is because we are more interested in how a codec woul= d perform when passing typical real-world DTMF signals through. Raymond From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of s= tephen botzko Sent: Friday, April 02, 2010 1:13 PM To: Roman Shpount Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements We don't have agreed-upon tests for anything. I've been assuming (possibly= incorrectly) that after the requirements are understood the group will nee= d to develop a test plan that indicates how we will test against the variou= s requirements. Stephen Botzko On Fri, Apr 2, 2010 at 3:02 PM, Roman Shpount > wrote: This is all wonderful, but what seems to be missing here is any type of sta= ndard test for DTMF tone detection. We have a number of tests for things th= at should not be detected as DTMF (various talk-off tapes), but there is no= test with samples of valid DTMF signals. In real world you get quite a var= iety of tones that different handsets or telephone devices generate when a = digit is pressed. Some of those tones are almost at border line conditions = for a valid DTMF tone. Second issue, which was already mentioned here, would be performance of DTM= F tone detector in the presence of packet loss or time stretching caused by= jitter buffer. Those things, even if they do not prevent DTMF detection, a= re almost guaranteed to split a single long tone in two. Finally, we seemed to concentrate on DTMF tones only, but in reality all th= e signaling/special tones are quite important. Fax Send/Receive tones come = to mind almost immediately as tones that are typically detected inband (ver= y few gateways encode those tones using RFC 4733/2833) I think we should formulate this requirement not in terms of DTMF tone but = in terms of accuracy of reproduction of periodic signals in specified freq= uency ranges. To be honest, the most robust solution would be to incorporat= e RFC4733/4744 as a part of the codec in a manner similar to comfort noise = frames. _____________________________ Roman Shpount - www.telurix.com On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene > wrote: Hi Stephan, Comments inline: --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ From: stephen botzko [mailto:stephen.botzko@gmail.com] Sent: Friday, April 02, 2010 4:50 PM To: Christian Hoene Cc: Michael Knappe; stpeter@stpeter.im; codec@ie= tf.org Subject: Re: [codec] #5: Mention DTMF in requirements (a) "MUST NOT" means that it must fail. Perhaps you meant "need not" or "m= ight not"? CH: Yes, I meant need not (or the German "muss nicht") (b) SHOULD is commonly used in establishing requirements, and it certainly = was used in MARTINI and other working groups at IETF77 in requirements presentations with no confusion. It has a clear meaning in the= requirements context (desirable but not essential) and I see no reason to avoid its use at this phase. There will certainly be othe= r things that are "nice to have", and it is appropriate to track them and consider them in the selection/standardization process. CH: Better? "The codec SHOULD support the transmission DTMF at most transmi= ssion conditions." I agree that language about DTMF might not need to be in the final RFC. Th= ough if DTMF quality is known to be inadequate, it probably makes sense to tell people that. CH: Agreed. The limits of the codec shall be clearly stated. I also agree to the obvious comment that DTMF detection methods are out of = scope. CH: Agreed. CH: Isn't time to include the MUST requirement for DTMF testing and SHOULD = requirement for transmission support into the requirements document. Then, we could close issue #5 and continue with other things. Christian _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86DCBIRVEXCHCCR01c_ Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Actually, ITU-T Recommendation G.720 gives some guidelines abou= t how to test a codec’s performance when passing DTMF signals through in-band.=A0 (It also talks about other non-voice signals.)

 

In practice, however, we found that some of the test conditions= specified in G.720 are fairly extreme corner cases which you normally don’t see= in real-world recorded DTMF signals.=A0 Real-world DTMF signals are usually ea= sier to pass through a codec without degradation in the DTMF detection error rat= e than those extreme DTMF conditions specified in G.720.

 

In our BroadVoice16 paper that I mentioned previously, we descr= ibed a method for testing DTMF pass-through performance for a codec.=A0 The meth= od is based on G.720 but with some relaxation of the extreme conditions to better reflect the DTMF conditions we observed in a large amount of real-world rec= ord DTMF signals.=A0 This is because we are more interested in how a codec woul= d perform when passing typical real-world DTMF signals through.

 

Raymond

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = stephen botzko
Sent: Friday, April 02, 2010 1:13 PM
To: Roman Shpount
Cc: codec@ietf.org
Subject: Re: [codec] #5: Mention DTMF in requirements

 

We don't have agreed-up= on tests for anything.  I've been assuming (possibly incorrectly) that after th= e requirements are understood the group will need to develop a test plan that indicates how we will test against the various requirements.

Stephen Botzko

On Fri, Apr 2, 2010 at 3:02 PM, Roman Shpount <roman@telurix.com> wrote:

This is all wonderful, = but what seems to be missing here is any type of standard test for DTMF tone detecti= on. We have a number of tests for things that should not be detected as DTMF (various talk-off tapes), but there is no test with samples of valid DTMF signals. In real world you get quite a variety of tones that different hand= sets or telephone devices generate when a digit is pressed. Some of those tones = are almost at border line conditions for a valid DTMF tone.

Second issue, which was already mentioned here, would be performance of DTM= F tone detector in the presence of packet loss or time stretching caused by jitter buffer. Those things, even if they do not prevent DTMF detection, are almos= t guaranteed to split a single long tone in two.

Finally, we seemed to concentrate on DTMF tones only, but in reality all th= e signaling/special tones are quite important. Fax Send/Receive tones come to mind almost immediately as tones that are typically detected inband (very f= ew gateways encode those tones using RFC 4733/2833)

I think we should formulate this requirement not in terms of DTMF tone but = in terms of accuracy of reproduction of  periodic signals in specified frequency ranges. To be honest, the most robust solution would be to incorporate RFC4733/4744 as a part of the codec in a manner similar to comf= ort noise frames.
_____________________________
Roman Shpount - www.telurix.com

On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene <hoene@uni-tuebinge= n.de> wrote:

Hi Stephan,

Comments inline:



---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.n= et.uni-tuebingen.de/

From: stephen botzko [mailto:stephen.botzko@g= mail.com]

Sent: Friday, April 02, 2010 4:50 PM
To: Christian Hoene
Cc: Michael Knappe; stpeter@stpeter.im; codec@ietf.org=

Subject: Re: [codec] #5= : Mention DTMF in requirements

(a) "MUST NOT"= ; means that it must fail.  Perhaps you meant "need not" or "mi= ght not"?

CH: Yes, I meant need not (or the German „muss nicht“)


(b) SHOULD is commonly used in establishing requirements, and it certainly = was used in MARTINI and other working groups at IETF77 in
requirements presentations with no confusion. It has a clear meaning in the requirements context (desirable but not essential) and I
see no reason to avoid its use at this phase.  There will certainly be= other things that are "nice to have", and it is appropriate
to track them and consider them in the selection/standardization process.

CH: Better? "The codec SHOULD support the transmi= ssion DTMF at most transmission conditions."


I agree that language about DTMF might not need to be in the final RFC.&nbs= p; Though if DTMF quality is known to be inadequate, it
probably makes sense to tell people that.

CH: Agreed. The limits of the codec shall be clearly s= tated.


I also agree to the obvious comment that DTMF detection methods are out of scope.

CH: Agreed.

CH: Isn't time to include the MUST requirement for DTMF testing and SHOULD requirement for transmission support into the
requirements document.
Then, we could close issue #5 and continue with other things.

 Christian



_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec



_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

 

--_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86DCBIRVEXCHCCR01c_-- From brian@freeswitch.org Fri Apr 2 14:32:31 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 596DB3A6AA5 for ; Fri, 2 Apr 2010 14:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.038 X-Spam-Level: * X-Spam-Status: No, score=1.038 tagged_above=-999 required=5 tests=[AWL=-0.093, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t-E5uxl6MS8p for ; Fri, 2 Apr 2010 14:32:30 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 0F4903A6A73 for ; Fri, 2 Apr 2010 14:14:12 -0700 (PDT) Received: by gwj20 with SMTP id 20so78166gwj.31 for ; Fri, 02 Apr 2010 14:14:44 -0700 (PDT) Received: by 10.100.74.3 with SMTP id w3mr7548882ana.104.1270242883983; Fri, 02 Apr 2010 14:14:43 -0700 (PDT) Received: from [192.168.1.221] (adsl-70-234-189-29.dsl.tul2ok.sbcglobal.net [70.234.189.29]) by mx.google.com with ESMTPS id 20sm1416473iwn.5.2010.04.02.14.14.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 14:14:43 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: multipart/alternative; boundary=Apple-Mail-22--122094929 From: Brian West In-Reply-To: Date: Fri, 2 Apr 2010 16:14:41 -0500 Message-Id: References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> To: "Raymond (Juin-Hwey) Chen" X-Mailer: Apple Mail (2.1078) Cc: "codec@ietf.org" , stephen botzko Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 21:32:31 -0000 --Apple-Mail-22--122094929 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 The biggest issue with relaxed DTMF is screaming kids can trigger stray = DTMF detection as can some people's voices. /b On Apr 2, 2010, at 3:54 PM, Raymond (Juin-Hwey) Chen wrote: > Actually, ITU-T Recommendation G.720 gives some guidelines about how = to test a codec=92s performance when passing DTMF signals through = in-band. (It also talks about other non-voice signals.) > =20 > In practice, however, we found that some of the test conditions = specified in G.720 are fairly extreme corner cases which you normally = don=92t see in real-world recorded DTMF signals. Real-world DTMF = signals are usually easier to pass through a codec without degradation = in the DTMF detection error rate than those extreme DTMF conditions = specified in G.720. > =20 > In our BroadVoice16 paper that I mentioned previously, we described a = method for testing DTMF pass-through performance for a codec. The = method is based on G.720 but with some relaxation of the extreme = conditions to better reflect the DTMF conditions we observed in a large = amount of real-world record DTMF signals. This is because we are more = interested in how a codec would perform when passing typical real-world = DTMF signals through. > =20 > Raymond > =20 --Apple-Mail-22--122094929 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 The = biggest issue with relaxed DTMF is screaming kids can trigger stray DTMF = detection as can some people's = voices.

/b

On Apr 2, 2010, at = 3:54 PM, Raymond (Juin-Hwey) Chen wrote:

Actually, ITU-T = Recommendation G.720 gives some guidelines about how to test a codec=92s = performance when passing DTMF signals through in-band.  (It also = talks about other non-voice signals.)
 
In our BroadVoice16 = paper that I mentioned previously, we described a method for testing = DTMF pass-through performance for a codec.  The method is based on = G.720 but with some relaxation of the extreme conditions to better = reflect the DTMF conditions we observed in a large amount of real-world = record DTMF signals.  This is because we are more interested in how = a codec would perform when passing typical real-world DTMF signals = through.
To: "Wyss, Felix" , "Brian West" , "stephen botzko" Date: Fri, 2 Apr 2010 14:15:17 -0700 Thread-Topic: [codec] #5: Mention DTMF in requirements Thread-Index: AcrSbkLl/+OtG4IbRliwMoqBvakvvgAIBaGQAAN48QAAArXc8A== Message-ID: References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <4BAF776D.20904@acm.org> <6e9223711003281100q7e1f7ac0pd548a2ab40e95ba4@mail.gmail.com> <4BAF9E7B.1070708@acm.org> <4BB58E31.2050809@coppice.org> <617DF0128820F9458AC39149A627EE6C01A2A21146@MBX.dialogic.com> <4BB5F7B6.1080808@stpeter.im> <0BD7AE28-298A-4586-9FB4-33925A8F8B8C@freeswitch.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67A881EC20S78035345-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 21:32:51 -0000 If I remember it correctly, at least for our BV16 codec, modifying it to im= prove DTMF pass-through performance did not really hurt the codec's perform= ance in coding speech. Obviously I can't guarantee that the same will be t= rue for all other codecs. I can imagine that if a codec has a frame size of 20 or 30 ms, it will prob= ably be more difficult than lower-delay codecs to pass DTMF signals without= affecting DTMF detection performance. This is especially true for the G.72= 0-specified 50 ms on, 40 ms off DTMF tone duration, because generally the c= odec frame boundaries do not coincide with the DTMF on/off time instants, s= o for the beginning frame and the ending frame of the codec where the DTMF = signal only occupies part of the frame, the codec usually cannot reproduce = the DTMF signal well. That makes the remaining middle portion of the DTMF = pulse (which can be coded better) too short for the DTMF detector downstrea= m to decode the DTMF digits reliably. This is especially true for the corn= er case of 50 ms on duration specified in G.720. In our BroadVoice16 paper= , we observed that most real-world DTMF signals we captured have an on dura= tion between 90 and 160 ms, so longer codec frame size will be less of a pr= oblem there. =20 In any case, low-delay codecs with a small frame size definitely have an ad= vantage over longer-delay codecs for passing DTMF signals. If you start wi= th a low-delay codec anyway (like what we did with BV16), then tuning the c= odec to reduce DTMF detection error rate does not necessarily mean you have= to take a hit in speech quality, bit-rate, etc. Raymond -----Original Message----- From: Wyss, Felix [mailto:Felix.Wyss@inin.com]=20 Sent: Friday, April 02, 2010 1:01 PM To: Raymond (Juin-Hwey) Chen; Brian West; stephen botzko Cc: codec@ietf.org Subject: RE: [codec] #5: Mention DTMF in requirements I agree with those who question the value of catering to in-band DTMF for t= his codec. Doing so will invariably require compromises somewhere else (qu= ality/birate, CPU cost, coding delay, development/testing effort, code comp= lexity, etc.) Do we really expect that by the time this codec will be stan= dardized and in wide use there will still be VoIP providers or devices that= do not support RFC#2833 -- yet who do support this new codec?=20 --Felix > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > Raymond (Juin-Hwey) Chen > Sent: Friday, April 02, 2010 14:54 > To: Brian West; stephen botzko > Cc: codec@ietf.org > Subject: Re: [codec] #5: Mention DTMF in requirements >=20 > (Responding to an earlier email on this topic...) >=20 > I think the issue here is not for a codec to detect DTMF, but for a codec > to encode and decode the DTMF waveform with sufficient fidelity so it wil= l > not cause DTMF detection problems later in a DTMF detector. >=20 > Although most codecs do not explicitly make use of DTMF properties to > improve their coding fidelity with DTMF waveforms, a codec developer can > indeed test a codec by passing DTMF tones through the codec followed by a > DTMF detector and try to tune or otherwise improve the codec so that it > minimizes the DTMF detection error rate as seen by the DTMF detector. In > fact, this is exactly what we have done when we developed the BV16 codec, > and as a result of such testing and tuning, we were indeed able to modify > the BV16 codec algorithm to improve the DTMF detection error rate after > DTMF tones were passed through BV16 and then detected by a commercial DTM= F > detector. Such DTMF pass-through test results of BV16, G.711, G.728, > G.729E, and G.729 are described in our BroadVoice16 paper in the > Proceedings of the 40th Asilomar Conference on Signals, Systems and > Computers, 2006, available at our BroadVoice website > www.broadcom.com/broadvoice. That's why I could answer with confidence > the > DTMF pass-through question raised right after my BroadVoice codec > presentation at our IETF 77 codec WG meeting on March 22. >=20 > I think in those conditions where out-of-band DTMF signaling is not > available or is not implemented properly, it is crucial for the codec to > pass DTMF tones through without causing significant increase of the DMTF > detection error rate in a DTMF detector downstream, otherwise you may not > even be able to get the correct telephone number through, or a credit car= d > number or key press responses to a voice response system (press 1 for > this, press 2 for that,...) may not go through correctly. That's why we > went through the trouble of testing BV16 with DTMF tones and modifying > BV16 to minimize the DTMF detection error rate, and that's why I agree > with Stephen's comments below. >=20 > Raymond >=20 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > Brian West > Sent: Friday, April 02, 2010 7:10 AM > To: stephen botzko > Cc: codec@ietf.org > Subject: Re: [codec] #5: Mention DTMF in requirements >=20 > But Codecs themselves do not detect DTMF. Thats the job of the DTMF > detector. NOT the codec. In all my work with codecs I have not once see= n > one that knows anything about DTMF. And if the codec is too lossy inband > is out of the question. >=20 > /b >=20 > On Apr 2, 2010, at 9:01 AM, stephen botzko wrote: >=20 > > I heard no decision as to DTMF tone encoding. > > > > As far as I am concerned, the question of whether the codec MUST encode > DTMF tones accurately enough to be detected at the decoder output (or > SHOULD or non-requirement) is still open. > > > > That question clearly is in-scope, and has nothing to do with signaling= . > > > > Stephen Botzko >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From rchen@broadcom.com Fri Apr 2 14:45:22 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1E9B3A6989 for ; Fri, 2 Apr 2010 14:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvQZbXUKv+DP for ; Fri, 2 Apr 2010 14:45:16 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 4A8593A6957 for ; Fri, 2 Apr 2010 14:43:09 -0700 (PDT) Received: from [10.9.200.133] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 02 Apr 2010 14:43:32 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Fri, 2 Apr 2010 14:44:57 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Brian West" Date: Fri, 2 Apr 2010 14:43:32 -0700 Thread-Topic: [codec] #5: Mention DTMF in requirements Thread-Index: AcrSqYdxY73oTd9iQ+2CNB1fP0OR2QAACmcA Message-ID: References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67A8BA8E31G79145304-01-01 Content-Type: multipart/alternative; boundary=_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86E0AIRVEXCHCCR01c_ Cc: "codec@ietf.org" , stephen botzko Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Apr 2010 21:45:22 -0000 --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86E0AIRVEXCHCCR01c_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Brian, You probably misunderstood me. I am not suggesting relaxing the DTMF detec= tor, which may increase the probability of detecting speech as DTMF. I was= just talking about relaxing the corner-case conditions imposed on the DTMF= signal itself. The DTMF detector remains the same. For example, G.720 sp= ecify 50 ms on, 40 ms off tone duration, but all the automatic DTMF dialers= we recorded has significantly longer on durations than 50 ms, and even whe= n I deliberately tried to press the button for as short a duration as possi= ble, I was never able to produce a DTMF tone duration shorter than about 60= ms. As I said in my last email, most recorded DTMF signals we collected ha= ve on durations of 90 to 160 ms. Therefore, if we want to get a better idea= of how a codec would perform in passing real-world DTMF signals, we may wa= nt to use a tone duration longer than 50 ms, perhaps in the 75 to 105 ms ra= nge like we did in our BroadVoice16 paper. Of course, if necessary, we can still use exactly the corner conditions lis= ted in G.720 and measure the DTMF detection error rate of a codec for each = condition. That will tell us the worst-case DTMF pass-through performance = of a codec (versus the "typical-case" performance for real-world DTMF signa= ls described above). In reality, DTMF tones were carefully chosen so that there is no harmonic r= elationship between any pair of the 8 possible frequencies. This makes the= probability of falsely detecting speech as a valid DTMF tone extremely low= since high-energy voiced signal have harmonically spaced spectral peaks. = Just to give an idea, we passed the 2.5 hours of speech in the Bellcore DTM= F test tapes through a codec then a commercial DTMF detector. When there w= as no codec (i.e. 16-bit linear PCM was used), only 40 isolated DTMF digits= were detected out of 2.5 hours of speech. When the codec was 64 kb/s mu-l= aw PCM, 39 digits were detected. When the codec was BV16, only 31 digits w= ere detected. These numbers are much lower than what's specified in the req= uirement R15-21 of the Bellcore General Requirements GR-506-CORE, which sta= tes that a DTMF receiver shall not register the 16 possible DTMF symbols mo= re than 670 times when decoding the 2.5 hours of signals contained in the t= hree Bellcore cassette tapes. Raymond From: Brian West [mailto:brian@freeswitch.org] Sent: Friday, April 02, 2010 2:15 PM To: Raymond (Juin-Hwey) Chen Cc: stephen botzko; Roman Shpount; codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements The biggest issue with relaxed DTMF is screaming kids can trigger stray DTM= F detection as can some people's voices. /b On Apr 2, 2010, at 3:54 PM, Raymond (Juin-Hwey) Chen wrote: Actually, ITU-T Recommendation G.720 gives some guidelines about how to tes= t a codec's performance when passing DTMF signals through in-band. (It als= o talks about other non-voice signals.) In practice, however, we found that some of the test conditions specified i= n G.720 are fairly extreme corner cases which you normally don't see in rea= l-world recorded DTMF signals. Real-world DTMF signals are usually easier = to pass through a codec without degradation in the DTMF detection error rat= e than those extreme DTMF conditions specified in G.720. In our BroadVoice16 paper that I mentioned previously, we described a metho= d for testing DTMF pass-through performance for a codec. The method is bas= ed on G.720 but with some relaxation of the extreme conditions to better re= flect the DTMF conditions we observed in a large amount of real-world recor= d DTMF signals. This is because we are more interested in how a codec woul= d perform when passing typical real-world DTMF signals through. Raymond --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86E0AIRVEXCHCCR01c_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi Brian,

 

You probably misunderstood me.  I am not suggesting relaxi= ng the DTMF detector, which may increase the probability of detecting speech as DTMF.  I was just talking about relaxing the corner-case conditions imposed on the DTMF signal itself.  The DTMF detector remains the same= .  For example, G.720 specify 50 ms on, 40 ms off tone duration, but all the a= utomatic DTMF dialers we recorded has significantly longer on durations than 50 ms, = and even when I deliberately tried to press the button for as short a duration = as possible, I was never able to produce a DTMF tone duration shorter than abo= ut 60 ms. As I said in my last email, most recorded DTMF signals we collected = have on durations of 90 to 160 ms. Therefore, if we want to get a better idea of= how a codec would perform in passing real-world DTMF signals, we may want to us= e a tone duration longer than 50 ms, perhaps in the 75 to 105 ms range like we = did in our BroadVoice16 paper.

 

Of course, if necessary, we can still use exactly the corner conditions listed in G.720 and measure the DTMF detection error rate of a c= odec for each condition.  That will tell us the worst-case DTMF pass-throug= h performance of a codec (versus the “typical-case” performance f= or real-world DTMF signals described above).

 

In reality, DTMF tones were carefully chosen so that there is n= o harmonic relationship between any pair of the 8 possible frequencies.  This makes the probability of falsely detecting speech as a valid DTMF tone extremely low since high-energy voiced signal have harmonically spaced spec= tral peaks.  Just to give an idea, we passed the 2.5 hours of speech in the Bellcore DTMF test tapes through a codec then a commercial DTMF detector.&n= bsp; When there was no codec (i.e. 16-bit linear PCM was used), only 40 isolated= DTMF digits were detected out of 2.5 hours of speech.  When the codec was 6= 4 kb/s mu-law PCM, 39 digits were detected.  When the codec was BV16, on= ly 31 digits were detected. These numbers are much lower than what’s specified in the requirement R15-21 of the Bellcore General Requirements GR-506-CORE, which states that a DTMF receiver shall not register the 16 possible DTMF symbols more than 670 times when decoding the 2.5 hours of si= gnals contained in the three Bellcore cassette tapes.

 

Raymond

 

From: Brian West [mailto:brian@freeswitch.org]
Sent: Friday, April 02, 2010 2:15 PM
To: Raymond (Juin-Hwey) Chen
Cc: stephen botzko; Roman Shpount; codec@ietf.org
Subject: Re: [codec] #5: Mention DTMF in requirements

 

The biggest issue with relaxed DTMF is screaming kids = can trigger stray DTMF detection as can some people's voices.

 

/b

 

On Apr 2, 2010, at 3:54 PM, Raymond (Juin-Hwey) Chen w= rote:



Actually, ITU-T Recommendation G.720 gives some guidelines abou= t how to test a codec’s performance when passing DTMF signals through in-band.  (It also talks about other non-voice signals.)

 

In practice, however, we found that some of the test conditions specified in G.720 are fairly extreme corner cases which you normally don’t see in real-world recorded DTMF signals.  Real-world DTMF signals are usually easier to pass through a codec without degradation in t= he DTMF detection error rate than those extreme DTMF conditions specified in G= .720.

 

In our BroadVoice16 paper that I mentioned previously, we descr= ibed a method for testing DTMF pass-through performance for a codec.  The method is based on G.720 but with some relaxation of the extreme conditions= to better reflect the DTMF conditions we observed in a large amount of real-wo= rld record DTMF signals.  This is because we are more interested in how a codec would perform when passing typical real-world DTMF signals through.

 

Raymond

 

 

--_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86E0AIRVEXCHCCR01c_-- From rchen@broadcom.com Fri Apr 2 18:11:06 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04ED03A6AC5 for ; Fri, 2 Apr 2010 18:11:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.132 X-Spam-Level: * X-Spam-Status: No, score=1.132 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYddMM7kInE3 for ; Fri, 2 Apr 2010 18:10:57 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 740683A6AA1 for ; Fri, 2 Apr 2010 18:05:41 -0700 (PDT) Received: from [10.9.200.131] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 02 Apr 2010 18:05:28 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Fri, 2 Apr 2010 18:05:28 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Roman Shpount" , "codec@ietf.org" Date: Fri, 2 Apr 2010 18:05:26 -0700 Thread-Topic: [codec] #5: Mention DTMF in requirements Thread-Index: AcrSm7qWtnbNwrPfS8eE7wAGn2v3EwALDi8A Message-ID: References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67A84BD238O161407244-01-01 Content-Type: multipart/alternative; boundary=_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86EB6IRVEXCHCCR01c_ Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 01:11:06 -0000 --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86EB6IRVEXCHCCR01c_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Comments in-line. Raymond From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of R= oman Shpount Sent: Friday, April 02, 2010 12:03 PM To: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements This is all wonderful, but what seems to be missing here is any type of sta= ndard test for DTMF tone detection. We have a number of tests for things th= at should not be detected as DTMF (various talk-off tapes), but there is no= test with samples of valid DTMF signals. In real world you get quite a var= iety of tones that different handsets or telephone devices generate when a = digit is pressed. Some of those tones are almost at border line conditions = for a valid DTMF tone. [Raymond]: I commented on this earlier. ITU-T G.720 can be used for general= guidelines. There were some published papers on codec DTMF pass-through te= sting based on G.720. Our BroadVoice16 paper is one of them (even though we= relaxed some corner conditions of G.720 to get a better idea of real-world= performance). If people are interested, I can share more details about the= test method. Second issue, which was already mentioned here, would be performance of DTM= F tone detector in the presence of packet loss or time stretching caused by= jitter buffer. Those things, even if they do not prevent DTMF detection, a= re almost guaranteed to split a single long tone in two. [Raymond]: Packet loss certainly will cause problems, but if the packet los= s rate is relatively low, there is still a good chance that DTMF digits can= get through. Finally, we seemed to concentrate on DTMF tones only, but in reality all th= e signaling/special tones are quite important. Fax Send/Receive tones come = to mind almost immediately as tones that are typically detected inband (ver= y few gateways encode those tones using RFC 4733/2833) I think we should formulate this requirement not in terms of DTMF tone but = in terms of accuracy of reproduction of periodic signals in specified freq= uency ranges. To be honest, the most robust solution would be to incorporat= e RFC4733/4744 as a part of the codec in a manner similar to comfort noise = frames. [Raymond]: I don't think we can do it in terms of "accuracy of reproduction= of periodic signals in specified frequency ranges". That may work for som= e single-frequency signaling tones, but it won't work for DTMF, since DTMF = signals are not periodic in any sense as the two frequencies of the sine wa= ves are not harmonically related. _____________________________ Roman Shpount - www.telurix.com On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene > wrote: Hi Stephan, Comments inline: --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ From: stephen botzko [mailto:stephen.botzko@gmail.com] Sent: Friday, April 02, 2010 4:50 PM To: Christian Hoene Cc: Michael Knappe; stpeter@stpeter.im; codec@ie= tf.org Subject: Re: [codec] #5: Mention DTMF in requirements (a) "MUST NOT" means that it must fail. Perhaps you meant "need not" or "m= ight not"? CH: Yes, I meant need not (or the German "muss nicht") (b) SHOULD is commonly used in establishing requirements, and it certainly = was used in MARTINI and other working groups at IETF77 in requirements presentations with no confusion. It has a clear meaning in the= requirements context (desirable but not essential) and I see no reason to avoid its use at this phase. There will certainly be othe= r things that are "nice to have", and it is appropriate to track them and consider them in the selection/standardization process. CH: Better? "The codec SHOULD support the transmission DTMF at most transmi= ssion conditions." I agree that language about DTMF might not need to be in the final RFC. Th= ough if DTMF quality is known to be inadequate, it probably makes sense to tell people that. CH: Agreed. The limits of the codec shall be clearly stated. I also agree to the obvious comment that DTMF detection methods are out of = scope. CH: Agreed. CH: Isn't time to include the MUST requirement for DTMF testing and SHOULD = requirement for transmission support into the requirements document. Then, we could close issue #5 and continue with other things. Christian _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86EB6IRVEXCHCCR01c_ Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Comments in-line.

 

Raymond

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Roman Shpount
Sent: Friday, April 02, 2010 12:03 PM
To: codec@ietf.org
Subject: Re: [codec] #5: Mention DTMF in requirements

 

This is all wonderful, = but what seems to be missing here is any type of standard test for DTMF tone detecti= on. We have a number of tests for things that should not be detected as DTMF (various talk-off tapes), but there is no test with samples of valid DTMF signals. In real world you get quite a variety of tones that different hand= sets or telephone devices generate when a digit is pressed. Some of those tones = are almost at border line conditions for a valid DTMF tone.
[Raymond]: I commented on this earlier. ITU-T G.= 720 can be used for general guidelines. There were some published papers on cod= ec DTMF pass-through testing based on G.720. Our BroadVoice16 paper is one of = them (even though we relaxed some corner conditions of G.720 to get a better ide= a of real-world performance). If people are interested, I can share more details about the test method.

Second issue, which was= already mentioned here, would be performance of DTMF tone detector in the presence = of packet loss or time stretching caused by jitter buffer. Those things, even = if they do not prevent DTMF detection, are almost guaranteed to split a single long tone in two.
[Raymond]: Packet loss certainly will cause prob= lems, but if the packet loss rate is relatively low, there is still a good chance that DTMF digits can get through.

Finally, we seemed to concentrate on DTMF tones only, but in reality all the signaling/special to= nes are quite important. Fax Send/Receive tones come to mind almost immediately= as tones that are typically detected inband (very few gateways encode those to= nes using RFC 4733/2833)

I think we should formulate this requirement not in terms of DTMF tone but = in terms of accuracy of reproduction of  periodic signals in specified frequency ranges. To be honest, the most robust solution would be to incorporate RFC4733/4744 as a part of the codec in a manner similar to comf= ort noise frames.
[Raymond]: I don’t think we can do it in t= erms of “accuracy of reproduction of periodic signals in specified frequen= cy ranges”.=A0 That may work for some single-frequency signaling tones, = but it won’t work for DTMF, since DTMF signals are not periodic in any sense= as the two frequencies of the sine waves are not harmonically related.

_______________________= ______
Roman Shpount - www.telurix.com

On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene <hoene@uni-tuebingen.de> wrote= :

Hi Stephan,

Comments inline:



---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.n= et.uni-tuebingen.de/

From: stephen botzko [mailto:stephen.botzko@gmail.com]=

Sent: Friday, April 02, 2010 4:50 PM
To: Christian Hoene
Cc: Michael Knappe; stpeter@stpeter.i= m; codec@ietf.org

Subject: Re: [codec] #5= : Mention DTMF in requirements

(a) "MUST NOT"= ; means that it must fail.  Perhaps you meant "need not" or "mi= ght not"?

CH: Yes, I meant need not (or the German „muss nicht“)


(b) SHOULD is commonly used in establishing requirements, and it certainly = was used in MARTINI and other working groups at IETF77 in
requirements presentations with no confusion. It has a clear meaning in the requirements context (desirable but not essential) and I
see no reason to avoid its use at this phase.  There will certainly be other things that are "nice to have", and it is appropriate
to track them and consider them in the selection/standardization process.

CH: Better? "The codec SHOULD support the transmi= ssion DTMF at most transmission conditions."


I agree that language about DTMF might not need to be in the final RFC.&nbs= p; Though if DTMF quality is known to be inadequate, it
probably makes sense to tell people that.

CH: Agreed. The limits of the codec shall be clearly s= tated.


I also agree to the obvious comment that DTMF detection methods are out of scope.

CH: Agreed.

CH: Isn't time to include the MUST requirement for DTMF testing and SHOULD requirement for transmission support into the
requirements document.
Then, we could close issue #5 and continue with other things.

 Christian




_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

 

--_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86EB6IRVEXCHCCR01c_-- From rchen@broadcom.com Fri Apr 2 18:12:03 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E6803A68D3 for ; Fri, 2 Apr 2010 18:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.168 X-Spam-Level: X-Spam-Status: No, score=-0.168 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7tW6b4CcE2QX for ; Fri, 2 Apr 2010 18:11:59 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id C4F8C3A6A1C for ; Fri, 2 Apr 2010 18:06:15 -0700 (PDT) Received: from [10.9.200.133] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 02 Apr 2010 18:06:00 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Fri, 2 Apr 2010 18:07:25 -0700 From: "Raymond (Juin-Hwey) Chen" To: "James Rafferty" , "stephen botzko" , "Christian Hoene" Date: Fri, 2 Apr 2010 18:05:59 -0700 Thread-Topic: [codec] #5: Mention DTMF in requirements Thread-Index: AcrSlIz6TfvUQu/ATeSsiqID9NFxcwAAHFjwAAy4DqA= Message-ID: References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> <617DF0128820F9458AC39149A627EE6C01A2A9FF9C@MBX.dialogic.com> In-Reply-To: <617DF0128820F9458AC39149A627EE6C01A2A9FF9C@MBX.dialogic.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67A84BF231G79270303-01-01 Content-Type: multipart/alternative; boundary=_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86EB7IRVEXCHCCR01c_ Cc: "codec@ietf.org" Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 01:12:03 -0000 --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86EB7IRVEXCHCCR01c_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable +1 Raymond From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of J= ames Rafferty Sent: Friday, April 02, 2010 11:48 AM To: stephen botzko; Christian Hoene Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements +1 James Rafferty From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of s= tephen botzko Sent: Friday, April 02, 2010 2:18 PM To: Christian Hoene Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements I am fine with your suggestions. Stephen Botzko On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene > wrote: Hi Stephan, Comments inline: --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ From: stephen botzko [mailto:stephen.botzko@gmail.com] Sent: Friday, April 02, 2010 4:50 PM To: Christian Hoene Cc: Michael Knappe; stpeter@stpeter.im; codec@ie= tf.org Subject: Re: [codec] #5: Mention DTMF in requirements (a) "MUST NOT" means that it must fail. Perhaps you meant "need not" or "m= ight not"? CH: Yes, I meant need not (or the German "muss nicht") (b) SHOULD is commonly used in establishing requirements, and it certainly = was used in MARTINI and other working groups at IETF77 in requirements presentations with no confusion. It has a clear meaning in the= requirements context (desirable but not essential) and I see no reason to avoid its use at this phase. There will certainly be othe= r things that are "nice to have", and it is appropriate to track them and consider them in the selection/standardization process. CH: Better? "The codec SHOULD support the transmission DTMF at most transmi= ssion conditions." I agree that language about DTMF might not need to be in the final RFC. Th= ough if DTMF quality is known to be inadequate, it probably makes sense to tell people that. CH: Agreed. The limits of the codec shall be clearly stated. I also agree to the obvious comment that DTMF detection methods are out of = scope. CH: Agreed. CH: Isn't time to include the MUST requirement for DTMF testing and SHOULD = requirement for transmission support into the requirements document. Then, we could close issue #5 and continue with other things. Christian --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86EB7IRVEXCHCCR01c_ Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

+1

 

Raymond

 

From: codec-bounces= @ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of James Rafferty
Sent: Friday, April 02, 2010 11:48 AM
To: stephen botzko; Christian Hoene
Cc: codec@ietf.org
Subject: Re: [codec] #5: Mention DTMF in requirements

 

+1

James Ra= fferty

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = stephen botzko
Sent: Friday, April 02, 2010 2:18 PM
To: Christian Hoene
Cc: codec@ietf.org
Subject: Re: [codec] #5: Mention DTMF in requirements

 

I am fine with your suggestions.

Stephen Botzko

On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene <hoene@uni-tuebingen.de> wrote= :

Hi Stephan,

Comments inline:



---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.n= et.uni-tuebingen.de/

From: stephen botzko [mailto:stephen.botzko@gmail.com]=

Sent: Friday, April 02, 2010 4:50 PM
To: Christian Hoene
Cc: Michael Knappe; stpeter@stpeter.i= m; codec@ietf.org

Subject: Re: [codec] #5= : Mention DTMF in requirements

(a) "MUST NOT"= ; means that it must fail.  Perhaps you meant "need not" or "mi= ght not"?

CH: Yes, I meant need not (or the German „muss nicht“)


(b) SHOULD is commonly used in establishing requirements, and it certainly = was used in MARTINI and other working groups at IETF77 in
requirements presentations with no confusion. It has a clear meaning in the requirements context (desirable but not essential) and I
see no reason to avoid its use at this phase.  There will certainly be other things that are "nice to have", and it is appropriate
to track them and consider them in the selection/standardization process.

CH: Better? "The codec SHOULD support the transmi= ssion DTMF at most transmission conditions."


I agree that language about DTMF might not need to be in the final RFC.&nbs= p; Though if DTMF quality is known to be inadequate, it
probably makes sense to tell people that.

CH: Agreed. The limits of the codec shall be clearly s= tated.


I also agree to the obvious comment that DTMF detection methods are out of scope.

CH: Agreed.

CH: Isn't time to include the MUST requirement for DTMF testing and SHOULD requirement for transmission support into the
requirements document.
Then, we could close issue #5 and continue with other things.

 Christian

 

--_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B86EB7IRVEXCHCCR01c_-- From roman@telurix.com Fri Apr 2 18:28:37 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D17313A6AA5 for ; Fri, 2 Apr 2010 18:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.754 X-Spam-Level: * X-Spam-Status: No, score=1.754 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WJS+EspigDr9 for ; Fri, 2 Apr 2010 18:28:36 -0700 (PDT) Received: from mail-yx0-f177.google.com (mail-yx0-f177.google.com [209.85.210.177]) by core3.amsl.com (Postfix) with ESMTP id 9C1FF3A6A96 for ; Fri, 2 Apr 2010 18:25:45 -0700 (PDT) Received: by yxe7 with SMTP id 7so50852yxe.19 for ; Fri, 02 Apr 2010 18:25:42 -0700 (PDT) Received: by 10.100.24.17 with SMTP id 17mr3964641anx.53.1270257941793; Fri, 02 Apr 2010 18:25:41 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by mx.google.com with ESMTPS id 7sm2609886ywc.49.2010.04.02.18.25.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 18:25:40 -0700 (PDT) Received: by ywh38 with SMTP id 38so182248ywh.29 for ; Fri, 02 Apr 2010 18:25:39 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.12.12 with HTTP; Fri, 2 Apr 2010 18:25:38 -0700 (PDT) In-Reply-To: References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> Date: Fri, 2 Apr 2010 21:25:38 -0400 Received: by 10.150.251.8 with SMTP id y8mr3117789ybh.222.1270257939212; Fri, 02 Apr 2010 18:25:39 -0700 (PDT) Message-ID: From: Roman Shpount To: "Raymond (Juin-Hwey) Chen" Content-Type: multipart/alternative; boundary=000e0cd70e2c3d691b04834af9b4 Cc: "codec@ietf.org" Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 01:28:37 -0000 --000e0cd70e2c3d691b04834af9b4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I understand your points. There are few questions that I have: 1. Do we need a real world DTMF and telephone signals recording database to implement this? Correct me if I am wrong, you've done your tests for BV16 using your own DTMF generator and unspecified "commercial" DTMF detector. How would define this test in a way it is possible to replicate it by third parties and reference it in a standard? 2. Did you ever test your CODEC for other telephony signals, such as /ANSam= , ANS, CED, and CI tones? These tones are needed in order to detect modems an= d fax machines and switch to an appropriate payload. What about progress tones? 3. Is this criteria feasible for large frame CELP CODECs? Are we going to exclude them based on this criteria? _____________________________ Roman Shpount - www.telurix.com On Fri, Apr 2, 2010 at 9:05 PM, Raymond (Juin-Hwey) Chen wrote: > Comments in-line. > > > > Raymond > > > > *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf > Of *Roman Shpount > *Sent:* Friday, April 02, 2010 12:03 PM > *To:* codec@ietf.org > *Subject:* Re: [codec] #5: Mention DTMF in requirements > > > > This is all wonderful, but what seems to be missing here is any type of > standard test for DTMF tone detection. We have a number of tests for thin= gs > that should not be detected as DTMF (various talk-off tapes), but there i= s > no test with samples of valid DTMF signals. In real world you get quite a > variety of tones that different handsets or telephone devices generate wh= en > a digit is pressed. Some of those tones are almost at border line conditi= ons > for a valid DTMF tone. > [Raymond]: I commented on this earlier. ITU-T G.720 can be used for gener= al > guidelines. There were some published papers on codec DTMF pass-through > testing based on G.720. Our BroadVoice16 paper is one of them (even thoug= h > we relaxed some corner conditions of G.720 to get a better idea of > real-world performance). If people are interested, I can share more detai= ls > about the test method. > > Second issue, which was already mentioned here, would be performance of > DTMF tone detector in the presence of packet loss or time stretching caus= ed > by jitter buffer. Those things, even if they do not prevent DTMF detectio= n, > are almost guaranteed to split a single long tone in two. > [Raymond]: Packet loss certainly will cause problems, but if the packet > loss rate is relatively low, there is still a good chance that DTMF digit= s > can get through. > > Finally, we seemed to concentrate on DTMF tones only, but in reality all > the signaling/special tones are quite important. Fax Send/Receive tones c= ome > to mind almost immediately as tones that are typically detected inband (v= ery > few gateways encode those tones using RFC 4733/2833) > > I think we should formulate this requirement not in terms of DTMF tone bu= t > in terms of accuracy of reproduction of periodic signals in specified > frequency ranges. To be honest, the most robust solution would be to > incorporate RFC4733/4744 as a part of the codec in a manner similar to > comfort noise frames. > [Raymond]: I don=92t think we can do it in terms of =93accuracy of reprod= uction > of periodic signals in specified frequency ranges=94. That may work for = some > single-frequency signaling tones, but it won=92t work for DTMF, since DTM= F > signals are not periodic in any sense as the two frequencies of the sine > waves are not harmonically related. > > _____________________________ > Roman Shpount - www.telurix.com > > On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene > wrote: > > Hi Stephan, > > Comments inline: > > > > --------------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of T=FCbingen > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > From: stephen botzko [mailto:stephen.botzko@gmail.com] > > Sent: Friday, April 02, 2010 4:50 PM > To: Christian Hoene > Cc: Michael Knappe; stpeter@stpeter.im; codec@ietf.org > > Subject: Re: [codec] #5: Mention DTMF in requirements > > (a) "MUST NOT" means that it must fail. Perhaps you meant "need not" or > "might not"? > > CH: Yes, I meant need not (or the German =84muss nicht=93) > > > (b) SHOULD is commonly used in establishing requirements, and it certainl= y > was used in MARTINI and other working groups at IETF77 in > requirements presentations with no confusion. It has a clear meaning in t= he > requirements context (desirable but not essential) and I > see no reason to avoid its use at this phase. There will certainly be > other things that are "nice to have", and it is appropriate > to track them and consider them in the selection/standardization process. > > CH: Better? "The codec SHOULD support the transmission DTMF at most > transmission conditions." > > > I agree that language about DTMF might not need to be in the final RFC. > Though if DTMF quality is known to be inadequate, it > probably makes sense to tell people that. > > CH: Agreed. The limits of the codec shall be clearly stated. > > > I also agree to the obvious comment that DTMF detection methods are out o= f > scope. > > CH: Agreed. > > CH: Isn't time to include the MUST requirement for DTMF testing and SHOUL= D > requirement for transmission support into the > requirements document. > Then, we could close issue #5 and continue with other things. > > Christian > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > --000e0cd70e2c3d691b04834af9b4 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I understand your points. There are few questions that I have:

1. Do= we need a real world DTMF and telephone signals recording database to impl= ement this? Correct me if I am wrong, you've done your tests for BV16 u= sing your own DTMF generator and unspecified "commercial" DTMF de= tector. How would define this test in a way it is possible to replicate it = by third parties and reference it in a standard?

2. Did you ever test your CODEC for other telephony signals, such as /A= NSam, ANS, CED, and CI tones? These tones are needed in order to detect mod= ems and fax machines and switch to an appropriate payload. What about progr= ess tones?

3. Is this criteria feasible for large frame CELP CODECs? Are we going = to exclude them based on this criteria?
__________________= ___________
Roman Shpount - www.telur= ix.com


On Fri, Apr 2, 2010 at 9:05 PM, Raymond = (Juin-Hwey) Chen <rchen@broadcom.com> wrote:

Commen= ts in-line.

=A0

Raymon= d

=A0

From:= codec-bounces@i= etf.org [mailto:codec-bounces@ietf.org] On Behalf Of Roman Shpount
Sent: Friday, April 02, 2010 12:03 PM
To: codec@ietf.o= rg
Subject: Re: [codec] #5: Mention DTMF in requirements

=A0

This is all wonderful= , but what seems to be missing here is any type of standard test for DTMF tone detecti= on. We have a number of tests for things that should not be detected as DTMF (various talk-off tapes), but there is no test with samples of valid DTMF signals. In real world you get quite a variety of tones that different hand= sets or telephone devices generate when a digit is pressed. Some of those tones = are almost at border line conditions for a valid DTMF tone.
[Raymond]: I commented on this earlier. ITU-T = G.720 can be used for general guidelines. There were some published papers on cod= ec DTMF pass-through testing based on G.720. Our BroadVoice16 paper is one of = them (even though we relaxed some corner conditions of G.720 to get a better ide= a of real-world performance). If people are interested, I can share more details about the test method.

Second issue, which w= as already mentioned here, would be performance of DTMF tone detector in the presence = of packet loss or time stretching caused by jitter buffer. Those things, even = if they do not prevent DTMF detection, are almost guaranteed to split a single long tone in two.
[Raymond]: Packet loss certainly will cause pr= oblems, but if the packet loss rate is relatively low, there is still a good chance that DTMF digits can get through.

Finally, we seemed to concentrate on DTMF tones only, but in reality all the signaling/special to= nes are quite important. Fax Send/Receive tones come to mind almost immediately= as tones that are typically detected inband (very few gateways encode those to= nes using RFC 4733/2833)

I think we should formulate this requirement not in terms of DTMF tone but = in terms of accuracy of reproduction of=A0 periodic signals in specified frequency ranges. To be honest, the most robust solution would be to incorporate RFC4733/4744 as a part of the codec in a manner similar to comf= ort noise frames.
[Raymond]: I don=92t think we can do it in ter= ms of =93accuracy of reproduction of periodic signals in specified frequency ranges=94.=A0 That may work for some single-frequency signaling tones, but = it won=92t work for DTMF, since DTMF signals are not periodic in any sense as the two frequencies of the sine waves are not harmonically related.<= /p>

_____________________= ________
Roman Shpount - www.te= lurix.com

On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene <= hoene@uni-tuebi= ngen.de> wrote:

Hi Stephan,

Comments inline:



---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.n= et.uni-tuebingen.de/

From: stephen botzko [mailto:stephen.botzko@gmail.com]

Sent: Friday, April 02, 2010 4:50 PM
To: Christian Hoene
Cc: Michael Knappe; stpeter@stpeter.im; codec@ietf.org

Subject: Re: [codec] = #5: Mention DTMF in requirements

(a) "MUST NOT&qu= ot; means that it must fail.=A0 Perhaps you meant "need not" or "might not"?

CH: Yes, I meant need not (or the German =84muss nicht=93)


(b) SHOULD is commonly used in establishing requirements, and it certainly = was used in MARTINI and other working groups at IETF77 in
requirements presentations with no confusion. It has a clear meaning in the requirements context (desirable but not essential) and I
see no reason to avoid its use at this phase.=A0 There will certainly be other things that are "nice to have", and it is appropriate
to track them and consider them in the selection/standardization process.

CH: Better? "The codec SHOULD support the trans= mission DTMF at most transmission conditions."


I agree that language about DTMF might not need to be in the final RFC.=A0 Though if DTMF quality is known to be inadequate, it
probably makes sense to tell people that.

CH: Agreed. The limits of the codec shall be clearly= stated.


I also agree to the obvious comment that DTMF detection methods are out of scope.

CH: Agreed.

CH: Isn't time to include the MUST requirement for DTMF testing and SHO= ULD requirement for transmission support into the
requirements document.
Then, we could close issue #5 and continue with other things.

=A0Christian




_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

=A0


--000e0cd70e2c3d691b04834af9b4-- From bmschwar@fas.harvard.edu Fri Apr 2 18:57:42 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0A3D3A68D3 for ; Fri, 2 Apr 2010 18:57:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.523 X-Spam-Level: X-Spam-Status: No, score=-3.523 tagged_above=-999 required=5 tests=[AWL=-1.946, BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 16G8fwaX1hEg for ; Fri, 2 Apr 2010 18:57:41 -0700 (PDT) Received: from us19.unix.fas.harvard.edu (us19.unix.fas.harvard.edu [140.247.35.199]) by core3.amsl.com (Postfix) with ESMTP id 7D37D3A689A for ; Fri, 2 Apr 2010 18:57:28 -0700 (PDT) Received: from us19.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us19.unix.fas.harvard.edu (Postfix) with ESMTP id 41212AFD35 for ; Fri, 2 Apr 2010 21:57:27 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:cc:subject:references :in-reply-to:content-type; s=mail; bh=4NPhK3+AIetuGekJcfBBsDOQHD F2ZeUgcodWDg9Xc6o=; b=DDCpOTpz6HibO1R8PpJADn9uOSXw70kUpz+TuqMkD3 tGTosrN7ERgMxpQjVNrfKj65ULfijFCbnQJGnDqv2qqBxzc7+3cwTFh+LeD/jfKe Vu+0ZFheLLeU5QVcYyXWa2yHg8hRqQTvxH4h8SOL1ca6XX2eMq1ocL0XxvAn3AlD k= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:cc:subject:references :in-reply-to:content-type; q=dns; s=mail; b=VQPqFMGY5zkCU1GjnH2S tOjrvughF0IRKf+F2Wh2OQjHzLO8VXhsJoZiCexb1ne2pokCiUlfP5Yqd2V/hJg7 EBadxYxJSpnSNMxOZZTiGSwlPCF6x4SvToqMzaUUl66oepC0ZlgFna3V4pc/IBhT in/ZAbBMCPhesi8bAskRQnU= Received: from [192.168.1.101] (c-71-192-160-188.hsd1.nh.comcast.net [71.192.160.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us19.unix.fas.harvard.edu (Postfix) with ESMTPSA id 305CDAFD4F for ; Fri, 2 Apr 2010 21:57:27 -0400 (EDT) Message-ID: <4BB6A082.7010507@fas.harvard.edu> Date: Fri, 02 Apr 2010 21:57:22 -0400 From: "Benjamin M. Schwartz" User-Agent: Thunderbird 2.0.0.23 (X11/20091019) MIME-Version: 1.0 CC: "codec@ietf.org" References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> In-Reply-To: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig718FE52EF0E9474B6F446B44" Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 01:57:42 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig718FE52EF0E9474B6F446B44 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Michael Knappe wrote: > I would agree with 'should'.=20 I think DTMF should be ignored entirely as far as requirements. If someone wishes to perform tests, they are welcome to do so and present results, but there is no need to require anything. > Lot's of dtmf out there still, but also out of band options (rfc 2833 /= 4733) that make in-band carriage less a concern for SIP telephony applic= ations. There are many different machine-to-machine communications systems that have been designed to operate over channels that also carry audio. We should not attempt to support any of them. The only purpose of this code= c should be to carry sounds to a human ear. Any machine-to-machine communications SHOULD be decoded from the stream prior to compression and transmitted independently. Any system that encodes using the IWAC has access to the input stream, and so can perform= any required decoding (of rotary clicks, DTMF, fax, DRM watermark, V.42, ZX Spectrum cassette, etc.) at that time. Decoders MAY do whatever they want with the output stream, but any use other than listening by a human should be unsupported. --Ben --------------enig718FE52EF0E9474B6F446B44 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAku2oIIACgkQUJT6e6HFtqSoxACgncjRJ9zMUrHOERX7uBcfnhbA HLIAn01Uwz49a+7VKYAziTLEk/4w97Cs =DutV -----END PGP SIGNATURE----- --------------enig718FE52EF0E9474B6F446B44-- From roman@telurix.com Fri Apr 2 19:10:24 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36BFF3A681D for ; Fri, 2 Apr 2010 19:10:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.383 X-Spam-Level: * X-Spam-Status: No, score=1.383 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GeYYnJYtGCfP for ; Fri, 2 Apr 2010 19:10:21 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 8F4303A6359 for ; Fri, 2 Apr 2010 19:10:16 -0700 (PDT) Received: by gyh4 with SMTP id 4so1283482gyh.31 for ; Fri, 02 Apr 2010 19:10:13 -0700 (PDT) Received: by 10.101.131.17 with SMTP id i17mr3129433ann.36.1270260612682; Fri, 02 Apr 2010 19:10:12 -0700 (PDT) Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by mx.google.com with ESMTPS id 23sm625016iwn.14.2010.04.02.19.10.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 02 Apr 2010 19:10:11 -0700 (PDT) Received: by iwn29 with SMTP id 29so1931628iwn.17 for ; Fri, 02 Apr 2010 19:10:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.12.12 with HTTP; Fri, 2 Apr 2010 19:10:10 -0700 (PDT) In-Reply-To: <4BB6A082.7010507@fas.harvard.edu> References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <4BB6A082.7010507@fas.harvard.edu> Date: Fri, 2 Apr 2010 22:10:10 -0400 Received: by 10.231.176.74 with SMTP id bd10mr1171745ibb.97.1270260610732; Fri, 02 Apr 2010 19:10:10 -0700 (PDT) Message-ID: From: Roman Shpount To: bens@alum.mit.edu Content-Type: multipart/alternative; boundary=0016363b8c1079923e04834b98d1 Cc: "codec@ietf.org" Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 02:10:26 -0000 --0016363b8c1079923e04834b98d1 Content-Type: text/plain; charset=ISO-8859-1 +1 _____________ Roman Shpount On Fri, Apr 2, 2010 at 9:57 PM, Benjamin M. Schwartz < bmschwar@fas.harvard.edu> wrote: > Michael Knappe wrote: > > I would agree with 'should'. > > I think DTMF should be ignored entirely as far as requirements. If > someone wishes to perform tests, they are welcome to do so and present > results, but there is no need to require anything. > > > Lot's of dtmf out there still, but also out of band options (rfc 2833 / > 4733) that make in-band carriage less a concern for SIP telephony > applications. > > There are many different machine-to-machine communications systems that > have been designed to operate over channels that also carry audio. We > should not attempt to support any of them. The only purpose of this codec > should be to carry sounds to a human ear. > > Any machine-to-machine communications SHOULD be decoded from the stream > prior to compression and transmitted independently. Any system that > encodes using the IWAC has access to the input stream, and so can perform > any required decoding (of rotary clicks, DTMF, fax, DRM watermark, V.42, > ZX Spectrum cassette, etc.) at that time. > > Decoders MAY do whatever they want with the output stream, but any use > other than listening by a human should be unsupported. > > --Ben > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > --0016363b8c1079923e04834b98d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1
_____________
Roman Shpount


On Fri, Apr 2, 2010 at 9:57 PM, Benjamin= M. Schwartz <bmschwar@fas.harvard.edu> wrote:
Michael Knappe wrote:
> I would agree with 'should'.

I think DTMF should be ignored entirely as far as requirements. =A0If
someone wishes to perform tests, they are welcome to do so and present
results, but there is no need to require anything.

> Lot's of dtmf out there still, but also out of band options (rfc 2= 833 / 4733) that make in-band carriage less a concern for SIP telephony app= lications.

There are many different machine-to-machine communications systems that
have been designed to operate over channels that also carry audio. =A0We should not attempt to support any of them. =A0The only purpose of this code= c
should be to carry sounds to a human ear.

Any machine-to-machine communications SHOULD be decoded from the stream
prior to compression and transmitted independently. =A0Any system that
encodes using the IWAC has access to the input stream, and so can perform any required decoding (of rotary clicks, DTMF, fax, DRM watermark, V.42, ZX Spectrum cassette, etc.) at that time.

Decoders MAY do whatever they want with the output stream, but any use
other than listening by a human should be unsupported.

--Ben


_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec


--0016363b8c1079923e04834b98d1-- From stpeter@stpeter.im Fri Apr 2 19:19:29 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E45D13A68D6 for ; Fri, 2 Apr 2010 19:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=-0.452, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2+o5hDYylOHc for ; Fri, 2 Apr 2010 19:19:29 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id EDC733A68DE for ; Fri, 2 Apr 2010 19:18:05 -0700 (PDT) Received: from squire.local (dsl-228-252.dynamic-dsl.frii.net [216.17.228.252]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 0780E40E23 for ; Fri, 2 Apr 2010 20:17:51 -0600 (MDT) Message-ID: <4BB6A54E.4010007@stpeter.im> Date: Fri, 02 Apr 2010 20:17:50 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: codec@ietf.org References: <05542EC42316164383B5180707A489EE1D0AA5F54E@EMBX02-HQ.jnpr.net> <4BB6A082.7010507@fas.harvard.edu> In-Reply-To: X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms090204020805050103040006" Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 02:19:30 -0000 This is a cryptographically signed message in MIME format. --------------ms090204020805050103040006 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Agreed, this seems unnecessary. We have more important things to focus on for now. :) On 4/2/10 8:10 PM, Roman Shpount wrote: > +1 > _____________ > Roman Shpount >=20 >=20 > On Fri, Apr 2, 2010 at 9:57 PM, Benjamin M. Schwartz > > wrote: >=20 > Michael Knappe wrote: > > I would agree with 'should'. >=20 > I think DTMF should be ignored entirely as far as requirements. If= > someone wishes to perform tests, they are welcome to do so and pres= ent > results, but there is no need to require anything. >=20 > > Lot's of dtmf out there still, but also out of band options (rfc > 2833 / 4733) that make in-band carriage less a concern for SIP > telephony applications. >=20 > There are many different machine-to-machine communications systems = that > have been designed to operate over channels that also carry audio. = We > should not attempt to support any of them. The only purpose of thi= s > codec > should be to carry sounds to a human ear. >=20 > Any machine-to-machine communications SHOULD be decoded from the st= ream > prior to compression and transmitted independently. Any system tha= t > encodes using the IWAC has access to the input stream, and so can > perform > any required decoding (of rotary clicks, DTMF, fax, DRM watermark, = V.42, > ZX Spectrum cassette, etc.) at that time. >=20 > Decoders MAY do whatever they want with the output stream, but any = use > other than listening by a human should be unsupported. >=20 > --Ben >=20 --------------ms090204020805050103040006 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDQwMzAyMTc1MFowIwYJKoZIhvcNAQkEMRYEFELB2yQi2ZGDyhL6NN9M V8RI00MuMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEAV1knoE07ydunqoFaFaSQopGBdHoj+wAHhBEUIBmi uHBSCGSzegI/67ZWY3fl2GM/HiV1HTG3/cHXfTJqV/G7JXUW5bylrOwlah7AhQNxpz/rYpqe Uexf0odI9vEFWq6Pv/Zf2VZ3YXZJ9uRWDV6CyRh3Dktzn6Kt2Nhm4kBCbKaLQXraNjo8SrYK 3UqdcoFbKZ+LtjNp5LunjkLZjm16Lu+Hay206schhD80NDNYQEwfbJEmjO7dSdPCg5zpLSra Iz5IkxyHZsEwp6fEMFemwgXY9PwFWgwW0OHmWNuzfqQ1LTgxFJ6XZ8uAkOIRNVocpH0GiSOx YRylv2IfxCVwVQAAAAAAAA== --------------ms090204020805050103040006-- From trac@tools.ietf.org Fri Apr 2 21:55:14 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 57D583A698C for ; Fri, 2 Apr 2010 21:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.987 X-Spam-Level: X-Spam-Status: No, score=-99.987 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_20=-0.74, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMGEjfQ5Kj8A for ; Fri, 2 Apr 2010 21:55:13 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6F58E3A6863 for ; Fri, 2 Apr 2010 21:55:07 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NxvNx-0002G5-SA; Fri, 02 Apr 2010 21:55:05 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 03 Apr 2010 04:55:05 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/codec/trac/ticket/7 Message-ID: <062.fb8f4e16e52b52b754efc94871100328@tools.ietf.org> X-Trac-Ticket-ID: 7 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #7: Providing DTMF Testing Tools and Samples X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 04:55:14 -0000 #7: Providing DTMF Testing Tools and Samples ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: task | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- To verify the performance of DTMF transmission, a DTMF Testing Suite would be useful. Requirements include: - Support DTMF and optinal other signalling tones. - Automatic testing. - Available under similar terms as the CODEC. - Availablity preferable before finishing the IETF Codec Requirements document. -- Ticket URL: codec From trac@tools.ietf.org Fri Apr 2 22:01:31 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1BADD3A68E8 for ; Fri, 2 Apr 2010 22:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.164 X-Spam-Level: X-Spam-Status: No, score=-100.164 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id osPLi5i-pen4 for ; Fri, 2 Apr 2010 22:01:30 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 1C0183A67C2 for ; Fri, 2 Apr 2010 22:01:29 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1NxvU4-0002Sl-OA; Fri, 02 Apr 2010 22:01:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de, kpfleming@digium.com X-Trac-Project: codec Date: Sat, 03 Apr 2010 05:01:24 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/5#comment:2 Message-ID: <071.6faf40466d8604354fffe2d42115af08@tools.ietf.org> References: <062.e6b7c6326118bdb330a524f018229c15@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <062.e6b7c6326118bdb330a524f018229c15@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, kpfleming@digium.com, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 05:01:31 -0000 #5: Mention DTMF in requirements ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): No consensus until now. I see do opinions on the mailing list: a) I think DTMF should be ignored entirely as far as requirements. If someone wishes to perform tests, they are welcome to do so and present results, but there is no need to require anything. There are many different machine-to-machine communications systems that have been designed to operate over channels that also carry audio. We should not attempt to support any of them. The only purpose of this codec should be to carry sounds to a human ear. b) DTMF support is important to ensure interoperability and reliable operation. Thus, the codec SHOULD support the transmission DTMF at most transmission conditions. The DTMF transmission performance MUST be tested and characterized. Thus, I suggest to pause the decision until we found a volunteer that provides a DTMF testing environment. PS: It is common consensus that FAX NEED NOT to be support or tested. -- Ticket URL: codec From hoene@uni-tuebingen.de Fri Apr 2 22:13:08 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1E5833A69AD for ; Fri, 2 Apr 2010 22:13:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.685 X-Spam-Level: X-Spam-Status: No, score=-4.685 tagged_above=-999 required=5 tests=[AWL=0.433, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vhBlUPfdeAeH for ; Fri, 2 Apr 2010 22:13:06 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 0A0CD3A69A4 for ; Fri, 2 Apr 2010 22:12:50 -0700 (PDT) Received: from hoeneT60 ([178.2.210.31]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o335CfKR005516 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 3 Apr 2010 07:12:47 +0200 From: "Christian Hoene" To: "'Peter Saint-Andre'" References: <062.4d96e1ea7b54b22a7110b0760f29dc5d@tools.ietf.org> <4BAA8B59.8030001@stpeter.im> In-Reply-To: <4BAA8B59.8030001@stpeter.im> Date: Sat, 3 Apr 2010 07:12:41 +0200 Message-ID: <000501cad2ec$4d238a10$e76a9e30$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrLnV6LaXoidFFJQ7+ls/kHAkcANQHTrkNg Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] #4: Remove the work "wideband" from the WG title. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 05:13:08 -0000 Hello, I just want to check whether I can close this issue? I did got it whether the WG title is going to be changed or not... With best regards, Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=C3=BCbingen=20 Sand 13, 72076 T=C3=BCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Peter Saint-Andre >Sent: Wednesday, March 24, 2010 11:00 PM >To: codec WG >Subject: Re: [codec] #4: Remove the work "wideband" from the WG title. > >On 3/24/10 1:15 PM, codec issue tracker wrote: >> #4: Remove the work "wideband" from the WG title. >> = ------------------------------------+--------------------------------- >> ------------------------------------+------ >> Reporter: hoene@=E2=80=A6 | Owner: >> Type: defect | Status: new >> Priority: minor | Milestone: >> Component: requirements | Version: >> Severity: - | Keywords: >> = ------------------------------------+--------------------------------- >> ------------------------------------+------ >> As discussed on the mailing list, it might make sence to remove the >> word wideband from WG title and replace it with interactive. >> For example, the following webpages need to be update >> >> https://datatracker.ietf.org/wg/codec/ >> https://datatracker.ietf.org/wg/codec/charter/ >> http://tools.ietf.org/wg/codec/ >> https://svn.tools.ietf.org/wg/codec/ > >Although my chair tenure is ending, I'd like to point out that it's = unhelpful to post something like >this as an issue in the issue tracker. >IMHO an "issue" is a specific bug report or feature request related to = an Internet-Draft that is a >current WG item. Right now the WG has one I-D = (draft-ietf-codec-requirements). If we could restrict >issues to that I-D for now, it would keep us from clogging the tracker = and list with extraneous >topics. > >Peter > >-- >Peter Saint-Andre >https://stpeter.im/ > > From trac@tools.ietf.org Fri Apr 2 22:39:18 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED5AF3A68CF for ; Fri, 2 Apr 2010 22:39:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.905 X-Spam-Level: X-Spam-Status: No, score=-100.905 tagged_above=-999 required=5 tests=[AWL=0.565, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ujvogcZYjN8N for ; Fri, 2 Apr 2010 22:39:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id C9D6A3A68C6 for ; Fri, 2 Apr 2010 22:39:09 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1Nxw4b-0004UV-Gj; Fri, 02 Apr 2010 22:39:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 03 Apr 2010 05:39:09 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: https://svn.tools.ietf.org/wg/codec/trac/ticket/1#comment:1 Message-ID: <071.db71a07d3a8eb1cd6269da2ddeaa0468@tools.ietf.org> References: <062.4b6a3862c443b2d8917e027f2267f4d2@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <062.4b6a3862c443b2d8917e027f2267f4d2@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #1: Application: 2.1. Point to point calls supporting transcoding? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 05:39:19 -0000 #1: Application: 2.1. Point to point calls supporting transcoding? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): No consensus either until now. Again two opinions: a) "To have similar requirements as G.718 and to consider at least cross tandeming conditions with G722.2@12.65 in the characterization phase." b) "I think that transcoding must be an explicit non-goal for this codec." "Sorry, but I still do not understand the need for this testing. In a cell network to VoIP topology, the codec selected must be an ITU codec which we already know are working fine for transcoding. In a VoIP to VoIP topology the codec selected is the one defined by this WG and by definition no transcoding is needed. And that's it, no test needed, because nobody will use it this way." Again, I would suggest to look for volunteers who want to make the subjective tests with G.722.2 and CODEC. -- Ticket URL: codec From stephen.botzko@gmail.com Sat Apr 3 03:54:08 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B2423A67A7 for ; Sat, 3 Apr 2010 03:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.673 X-Spam-Level: X-Spam-Status: No, score=-0.673 tagged_above=-999 required=5 tests=[AWL=0.195, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6MLR3Zv6b2Ik for ; Sat, 3 Apr 2010 03:54:07 -0700 (PDT) Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by core3.amsl.com (Postfix) with ESMTP id 204033A672F for ; Sat, 3 Apr 2010 03:54:07 -0700 (PDT) Received: by iwn29 with SMTP id 29so2116307iwn.17 for ; Sat, 03 Apr 2010 03:54:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=m1HlEMo4+1DewVjYLbfOm7MZ82D9BVUoPavQ2gsT7C8=; b=qP0+qh4HanGXf/bB11DkJEp67rRHgRy3+m5byTxwflBCjmapGtJFR9q3w2tNAwsWcA Wnrv8e4jNytFFHATOd+zzG1ihry2N0WyWIIBXfvfhGo1gznUM1Jjt81Sa8UQDRdJXTeU RvtGpF4fsQWlDWGb2O7LbcJ3cnAz6vABjUtBE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ptqG8nnEOlhhv8pU7bxlxrHQGNar3FYdoYSIU4/CzH4Rg99lOa6UDIGASn6k5VGtdd WVrfedMp1JfA2iFruTzZZ3GlVRctCb1MkKrUJLzcRDX7soTwVswRWvw2DgzNMXKjuSz8 DVXgSFEHRk55S648v03XZCiXDNsIUseuPxwOI= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Sat, 3 Apr 2010 03:54:03 -0700 (PDT) In-Reply-To: <071.db71a07d3a8eb1cd6269da2ddeaa0468@tools.ietf.org> References: <062.4b6a3862c443b2d8917e027f2267f4d2@tools.ietf.org> <071.db71a07d3a8eb1cd6269da2ddeaa0468@tools.ietf.org> Date: Sat, 3 Apr 2010 06:54:03 -0400 Received: by 10.231.145.17 with SMTP id b17mr800000ibv.94.1270292043771; Sat, 03 Apr 2010 03:54:03 -0700 (PDT) Message-ID: From: stephen botzko To: trac@localhost.amsl.com Content-Type: multipart/alternative; boundary=0016e64c145a07b1ce048352eaf0 Cc: codec@ietf.org Subject: Re: [codec] #1: Application: 2.1. Point to point calls supporting transcoding? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 10:54:08 -0000 --0016e64c145a07b1ce048352eaf0 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I personally believe testing tandem operation is a MUST, since devices usin= g this CODEC will certainly connect into networks where it is not supported. The idea below that this will "just work" with every ITU codec is incorrect.. In addition, tandem operation occurs in virtually all conference bridges (including back-to-back encode/decode with CODEC itself). So surely self-tandeming has to be tested anyway. (Though of course is is common for devices in the same conference to be using different codecs). I do not favor just copying the tandem requirements from some other codec's test plan - unless we are sure that it is in essentially the same ecosystem as ours. Ideally the community would identify common use cases, and the test cases would be derived from those cases. Stephen Botzko On Sat, Apr 3, 2010 at 1:39 AM, codec issue tracker wr= ote: > #1: Application: 2.1. Point to point calls supporting transcoding? > > ------------------------------------+------------------------------------= --- > Reporter: hoene@=85 | Owner: > Type: enhancement | Status: new > Priority: major | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Keywords: > > ------------------------------------+------------------------------------= --- > > Comment(by hoene@=85): > > No consensus either until now. Again two opinions: > > a) "To have similar requirements as G.718 and to consider at least cross > tandeming conditions with G722.2@12.65 in the characterization phase." > > b) "I think that transcoding must be an explicit non-goal for this codec= ." > "Sorry, but I still do not understand the need for this testing. In a > cell network to VoIP topology, the codec selected must be an ITU codec > which we already know are working fine for transcoding. In a VoIP to Vo= IP > topology the codec selected is the one defined by this WG and by > definition no transcoding is needed. And that's it, no test needed, > because nobody will use it this way." > > Again, I would suggest to look for volunteers who want to make the > subjective tests with G.722.2 and CODEC. > > -- > Ticket URL: > codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016e64c145a07b1ce048352eaf0 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I personally believe testing tandem operation is a MUST, since devices usin= g this CODEC will certainly connect into networks where it is not supported= .=A0 The idea below that this will "just work" with every ITU cod= ec is incorrect..

In addition, tandem operation occurs in virtually all conference bridge= s (including back-to-back encode/decode with CODEC itself).=A0 So surely se= lf-tandeming has to be tested anyway.=A0 (Though of course is is common for= devices in the same conference to be using different codecs).

I do not favor just copying the tandem requirements from some other cod= ec's test plan - unless we are sure that it is in essentially the same = ecosystem as ours.=A0 Ideally the community would identify common use cases= , and the test cases would be derived from those cases.

Stephen Botzko

On Sat, Apr 3, 2010 at= 1:39 AM, codec issue tracker <trac@tools.ietf.org> wrote:
#1: Application: 2.1. =A0Point to point calls supporting = transcoding?
------------------------------------+--------------------------------------= -
=A0Reporter: =A0hoene@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Own= er:
=A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: = =A0new
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:<= br> Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
=A0Severity: =A0Active WG Document =A0 =A0 =A0| =A0 =A0Keywords:
------------------------------------+--------------------------------------= -

Comment(by hoene@=85):

=A0No consensus either until now. Again two opinions:

=A0a) "To have similar requirements as G.718 and to consider at least = cross
=A0tandeming conditions with G722.2@12.65 in the characte= rization phase."

=A0b) "I think that transcoding must be an explicit non-goal for= this codec."
=A0"Sorry, but I still do not understand the need fo= r this testing. =A0In a
=A0cell network to VoIP topology, the codec selected must be an ITU codec =A0which we already know are working fine for transcoding. =A0In a VoIP to = VoIP
=A0topology the codec selected is the one defined by this WG and by
=A0definition no transcoding is needed. =A0And that's it, no test neede= d,
=A0because nobody will use it this way."

=A0Again, I would suggest to look for volunteers who want to make the=
=A0subjective tests with G.722.2 and CODEC.

--
Ticket URL: <https://svn.tools.ietf.org/wg/codec/trac/tic= ket/1#comment:1>
codec <http://tools.ietf.org/codec/>

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016e64c145a07b1ce048352eaf0-- From stephen.botzko@gmail.com Sat Apr 3 04:22:50 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CF5F3A67D3 for ; Sat, 3 Apr 2010 04:22:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.522 X-Spam-Level: X-Spam-Status: No, score=0.522 tagged_above=-999 required=5 tests=[AWL=-1.024, BAYES_40=-0.185, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMMsBa-FdNPg for ; Sat, 3 Apr 2010 04:22:47 -0700 (PDT) Received: from mail-yx0-f177.google.com (mail-yx0-f177.google.com [209.85.210.177]) by core3.amsl.com (Postfix) with ESMTP id 971773A6A1C for ; Sat, 3 Apr 2010 04:21:25 -0700 (PDT) Received: by yxe7 with SMTP id 7so170029yxe.19 for ; Sat, 03 Apr 2010 04:21:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=d8y0i1qZHq4iFcre295fUtgVo4GjKj5nruUFzA0VW9M=; b=Oyh2lEpHvl6GBiFLs7WU/6mYgvCYqCcROgbTPZ7mk8m6bu0upOmjwBL+0vFG/XdIi1 Y7Sjq4ilK2cv0PWbg6BUPKy6soT38Szk2+wr0+W48mJLsDJ7nLiMm8k6LAuy2+Eh5Q6y XnqUHH/UyStq7MIktY8iS7FRJDLJVh1YHTPPo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KAAzCxYAVp8MlVQxA3ekC9L2Yqh4kmBLHauK4C5HyWBdlT7pZaOouxGpKV7srBzHdp ljJoypz4R8PRDSfhClzGX28fqxjsn967KowwcyKIpVTHw1osIJjaBfthWS+FmFVuhpHb 17WLmADlpf3OmR7deAWDgVJuziG7K3AdBi4Ow= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Sat, 3 Apr 2010 04:21:21 -0700 (PDT) In-Reply-To: <071.6faf40466d8604354fffe2d42115af08@tools.ietf.org> References: <062.e6b7c6326118bdb330a524f018229c15@tools.ietf.org> <071.6faf40466d8604354fffe2d42115af08@tools.ietf.org> Date: Sat, 3 Apr 2010 07:21:21 -0400 Received: by 10.150.184.19 with SMTP id h19mr4154144ybf.235.1270293681432; Sat, 03 Apr 2010 04:21:21 -0700 (PDT) Message-ID: From: stephen botzko To: trac@localhost.amsl.com Content-Type: multipart/alternative; boundary=000e0cd6ec98a468d60483534b7d Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 11:22:50 -0000 --000e0cd6ec98a468d60483534b7d Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think quite a few people seemed to support the SHOULD requirement (with MUST be tested, since all requirements need to be tested). It might be enough to say there is a rough consensus. I'd suggest a show of hands (or hum) be used at the next meeting, in order to get a better sense of the community's view. I do not favor tabling a requirement for X until we find "a volunteer that provides an X testing environment." If there is agreement that the requirement exists (either in MUST or SHOULD form), then we need to find a way to test it. The tests in general will no= t be exhaustive (for instance, we will certainly not produce MOS scores for every language under every channel condition), but they need to be broad enough that we can say we've characterized the performance with some confidence. IMHO we will need to specify and create the testing environment for each of the requirements. It seems to me unavoidable. Implementing a test environment for this particular requirement is frankly = * much* easier than most of the testing we will have to do. Raymond Chen's suggestions seem very reasonable, and would result in an objective automate= d test score. Stephen Botzko On Sat, Apr 3, 2010 at 1:01 AM, codec issue tracker wr= ote: > #5: Mention DTMF in requirements > > ------------------------------------+------------------------------------= --- > Reporter: hoene@=85 | Owner: > Type: defect | Status: new > Priority: major | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Keywords: > > ------------------------------------+------------------------------------= --- > > Comment(by hoene@=85): > > No consensus until now. > I see do opinions on the mailing list: > > a) I think DTMF should be ignored entirely as far as requirements. If > someone wishes to perform tests, they are welcome to do so and present > results, but there is no need to require anything. > There are many different machine-to-machine communications systems that > have been designed to operate over channels that also carry audio. We > should not attempt to support any of them. The only purpose of this cod= ec > should be to carry sounds to a human ear. > > b) DTMF support is important to ensure interoperability and reliable > operation. Thus, the codec SHOULD support the transmission DTMF at most > transmission conditions. The DTMF transmission performance MUST be teste= d > and characterized. > > Thus, I suggest to pause the decision until we found " > > PS: > It is common consensus that FAX NEED NOT to be support or tested. > > -- > Ticket URL: > codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --000e0cd6ec98a468d60483534b7d Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I think quite a few people seemed to support the SHOULD requirement (with M= UST be tested, since all requirements need to be tested). It might be enoug= h to say there is a rough consensus.

I'd suggest a show of hands= (or hum) be used at the next meeting, in order to get a better sense of th= e community's view.

I do not favor tabling a requirement for X until we find "a volunt= eer that provides an X testing environment."=A0

If there is ag= reement that the requirement exists (either in MUST or SHOULD form), then w= e need to find a way to test it.=A0 The tests in general will not be exhaus= tive (for instance, we will certainly not produce MOS scores for every lang= uage under every channel condition), but they need to be broad enough that = we can say we've characterized the performance with some confidence.
IMHO we will need to specify and create the testing environment for eac= h=20 of the requirements.=A0 It seems to me unavoidable.

Implementing a = test environment for this particular requirement is frankly much eas= ier than most of the testing we will have to do. Raymond Chen's suggest= ions seem very reasonable, and would result in an objective automated test = score.

Stephen Botzko



On Sat, Apr 3,= 2010 at 1:01 AM, codec issue tracker <trac@tools.ietf.org> wrote:
#5: Mention DTMF in requirements
------------------------------------+--------------------------------------= -
=A0Reporter: =A0hoene@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Own= er:
=A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0St= atus: =A0new
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:<= br> Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
=A0Severity: =A0Active WG Document =A0 =A0 =A0| =A0 =A0Keywords:
------------------------------------+--------------------------------------= -

Comment(by hoene@=85):

=A0No consensus until now.
=A0I see do opinions on the mailing list:

=A0a) I think DTMF should be ignored entirely as far as requirements. =A0If=
=A0someone wishes to perform tests, they are welcome to d= o so and present
=A0results, but there is no need to require anything.
=A0There are many different machine-to-machine comm= unications systems that
=A0have been designed to operate over channels that also carry audio. =A0We=
=A0should not attempt to support any of them. =A0The only purpose of this c= odec
=A0should be to carry sounds to a human ear.

=A0b) DTMF support is important to ensure interoperability and reliab= le
=A0operation. Thus, the codec SHOULD support the transmission DTMF at most<= br> =A0transmission conditions. The DTMF transmission performance MUST be teste= d
=A0and characterized.

=A0Thus, I suggest to pause the decision until we found "

=A0PS:
=A0It is common consensus that FAX NEED NOT to be support or tested.

--
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/tic= ket/5#comment:2>
codec <http://tools.ietf.org/codec/>

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--000e0cd6ec98a468d60483534b7d-- From hoene@uni-tuebingen.de Sat Apr 3 04:42:49 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D10753A67D3 for ; Sat, 3 Apr 2010 04:42:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[AWL=-0.720, BAYES_05=-1.11, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vvOE266wIitz for ; Sat, 3 Apr 2010 04:42:38 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id C46AB3A67AF for ; Sat, 3 Apr 2010 04:42:36 -0700 (PDT) Received: from hoeneT60 ([178.2.210.31]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o33BgOxZ024039 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Sat, 3 Apr 2010 13:42:30 +0200 From: "Christian Hoene" To: "'stephen botzko'" References: <062.4b6a3862c443b2d8917e027f2267f4d2@tools.ietf.org> <071.db71a07d3a8eb1cd6269da2ddeaa0468@tools.ietf.org> In-Reply-To: Date: Sat, 3 Apr 2010 13:42:24 +0200 Message-ID: <000e01cad322$be102b80$3a308280$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01CAD333.8198FB80" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrTG/5ytW+fg1YfRIW0ypDyBddT3QAA7Mcw Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] #1: Application: 2.1. Point to point calls supporting transcoding? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 11:42:50 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000F_01CAD333.8198FB80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 depending on the use case, the second codec might vary. =20 1) For example, if bandwidth is plenty and music can be streamed, = MP3 might be the source. 2) In case of calling a cellular phone, AMR-NB or GSM-EFR might be = transcoding partner.=20 3) Or if mobile HD voice is deployed as announced ( = http://www.orange.com/en_EN/press/press_releases/cp100214en.jsp ) = G.722.2 (AMR-WB) shall be considered. 4) CAT-iq and many VoIP phones use G.722. 5) ISDN and PSTN gateways still require G.711? =20 In case of G.718, use cases 3) and 4) are considered. =20 Shall the transcoding tests done via subjective (MUSHRA, MOS-LQS) or = objective (PEAQ, PESQ, =85) methods? =20 With best regards, Christian =20 =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 From: stephen botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Saturday, April 03, 2010 12:54 PM To: trac@localhost.amsl.com Cc: hoene@uni-tuebingen.de; codec@ietf.org Subject: Re: [codec] #1: Application: 2.1. Point to point calls = supporting transcoding? =20 I personally believe testing tandem operation is a MUST, since devices = using this CODEC will certainly connect into networks where it is not supported. The idea below that this will "just work" with = every ITU codec is incorrect.. In addition, tandem operation occurs in virtually all conference bridges = (including back-to-back encode/decode with CODEC itself). So surely self-tandeming has to be tested anyway. (Though of course is = is common for devices in the same conference to be using different codecs). I do not favor just copying the tandem requirements from some other = codec's test plan - unless we are sure that it is in essentially the same ecosystem as ours. Ideally the community would identify common = use cases, and the test cases would be derived from those cases. Stephen Botzko On Sat, Apr 3, 2010 at 1:39 AM, codec issue tracker = wrote: #1: Application: 2.1. Point to point calls supporting transcoding? ------------------------------------+------------------------------------= --- Reporter: hoene@=85 | Owner: Type: enhancement | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+------------------------------------= --- Comment(by hoene@=85): No consensus either until now. Again two opinions: a) "To have similar requirements as G.718 and to consider at least = cross tandeming conditions with G722.2@12.65 in the characterization phase." b) "I think that transcoding must be an explicit non-goal for this = codec." "Sorry, but I still do not understand the need for this testing. In a cell network to VoIP topology, the codec selected must be an ITU codec which we already know are working fine for transcoding. In a VoIP to = VoIP topology the codec selected is the one defined by this WG and by definition no transcoding is needed. And that's it, no test needed, because nobody will use it this way." Again, I would suggest to look for volunteers who want to make the subjective tests with G.722.2 and CODEC. -- Ticket URL: = codec _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =20 ------=_NextPart_000_000F_01CAD333.8198FB80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

depending on = the use case, the second codec might vary.

 

1)      = For example, if bandwidth is = plenty and music can be streamed, MP3 might be the = source.

2)      = In case of calling a cellular = phone, AMR-NB or GSM-EFR might be transcoding = partner.

3)      = Or if mobile HD voice is deployed = as announced =A0(= http://www.orange.com/en_EN/press/press= _releases/cp100214en.jsp ) = G.722.2 (AMR-WB) shall be = considered.

4)      = CAT-iq and many VoIP phones use G.722.

5)      = ISDN and PSTN gateways still = require G.711?

 

In case of = G.718, use cases 3) and 4) are considered.

 

Shall the transcoding tests done via subjective (MUSHRA, = MOS-LQS) or objective (PEAQ, PESQ, …) methods?

 

With best = regards,

=A0Christian

 

 

---------------------------------------------------------------=

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen =

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen= .de/

 

From: stephen botzko = [mailto:stephen.botzko@gmail.com]
Sent: Saturday, April 03, = 2010 12:54 PM
To: = trac@localhost.amsl.com
Cc: = hoene@uni-tuebingen.de; codec@ietf.org
Subject: Re: [codec] #1: Application: 2.1. Point to point calls supporting = transcoding?

 

I personally = believe testing tandem operation is a MUST, since devices using this CODEC will certainly connect into networks where it is not supported.  The = idea below that this will "just work" with every ITU codec is = incorrect..

In addition, tandem operation occurs in virtually all conference bridges (including back-to-back encode/decode with CODEC itself).  So = surely self-tandeming has to be tested anyway.  (Though of course is is = common for devices in the same conference to be using different codecs).

I do not favor just copying the tandem requirements from some other = codec's test plan - unless we are sure that it is in essentially the same = ecosystem as ours.  Ideally the community would identify common use cases, and = the test cases would be derived from those cases.

Stephen Botzko

On Sat, Apr 3, 2010 at 1:39 AM, codec issue tracker <trac@tools.ietf.org> = wrote:

#1: = Application: 2.1.  Point to point calls supporting transcoding?
------------------------------------+------------------------------------= ---
 Reporter:  hoene@…           =       |       Owner:
    Type:  enhancement           =   |      Status:  new
 Priority:  major             =       |   Milestone:
Component:  requirements            | =     Version:
 Severity:  Active WG Document      |    Keywords:
------------------------------------+------------------------------------= ---

Comment(by hoene@…):

 No consensus either until now. Again two opinions:

 a) "To have similar requirements as G.718 and to consider at = least cross

 tandeming conditions with G722.2@12.65 in the characterization = phase."

 b) "I think that transcoding must be an explicit = non-goal for this codec."

 "Sorry, but I still do not understand the need for this testing.  In a
 cell network to VoIP topology, the codec selected must be an ITU = codec
 which we already know are working fine for transcoding.  In a = VoIP to VoIP
 topology the codec selected is the one defined by this WG and = by
 definition no transcoding is needed.  And that's it, no test = needed,
 because nobody will use it this = way."

 Again, I would suggest to look for volunteers who want to = make the
 subjective tests with G.722.2 and CODEC.

--
Ticket URL: <https://svn.tools.ietf.org/wg/codec/trac/ticket/1#comme= nt:1>

codec <http://tools.ietf.org/codec/>

_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec

 

------=_NextPart_000_000F_01CAD333.8198FB80-- From stephen.botzko@gmail.com Sat Apr 3 05:11:04 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8AB793A67E7 for ; Sat, 3 Apr 2010 05:11:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.628 X-Spam-Level: X-Spam-Status: No, score=-0.628 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzJQTwR5mJDX for ; Sat, 3 Apr 2010 05:11:01 -0700 (PDT) Received: from mail-iw0-f191.google.com (mail-iw0-f191.google.com [209.85.223.191]) by core3.amsl.com (Postfix) with ESMTP id 18FB73A67AF for ; Sat, 3 Apr 2010 05:11:01 -0700 (PDT) Received: by iwn29 with SMTP id 29so2135721iwn.17 for ; Sat, 03 Apr 2010 05:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=on1mAObRp2JWGSsji8S128afNCOarFShtbjedCOd/oo=; b=vnfQq8iEN2Im8SQ7myRYCIC2EPTw8+B/vOr8gWlWWFblS83qk2sen2fWst171m1/zJ QAH667fobphgPl3m4MZ8aMpBLXuXUPQaqmD7gNQF1XKBBDFUxJgM4xUw4Sw3w49Dol1v ebobwEzsA+7Pv0TS+gf+UJrWfM343vOAgEwQU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OwxKo+s5Agtxvz/t9eGyjaBnNggn73kp15GGVaPjvOdZ06lVIymKpNipGXna7lVsCL kIy4oPGEA8z/ZsPSKZ1rjQkCtugMwfQs0EiXCqz3J8Ojg3SncOwvaOQWoYWJy6kny4l6 /KIi0qZ0RhCs4NcH957drI1HEcZU6BV63wqdI= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Sat, 3 Apr 2010 05:10:57 -0700 (PDT) In-Reply-To: <000e01cad322$be102b80$3a308280$@de> References: <062.4b6a3862c443b2d8917e027f2267f4d2@tools.ietf.org> <071.db71a07d3a8eb1cd6269da2ddeaa0468@tools.ietf.org> <000e01cad322$be102b80$3a308280$@de> Date: Sat, 3 Apr 2010 08:10:57 -0400 Received: by 10.231.145.17 with SMTP id b17mr836765ibv.94.1270296657182; Sat, 03 Apr 2010 05:10:57 -0700 (PDT) Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=0016e64c145a02c2d1048353fdca Cc: codec@ietf.org Subject: Re: [codec] #1: Application: 2.1. Point to point calls supporting transcoding? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 12:11:04 -0000 --0016e64c145a02c2d1048353fdca Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable All valid considerations. G.711 and G.729 are very commonly used in today's enterprise VOIP deployments. In the enterprise video conferencing market, G.722, G.722.1 (wideband and superwideband), G.719, and AAC-LD are in common use. I think it is likely that if G.729/CODEC tandems well, G.711/CODEC would also. Just to point out that we do not necessarily need to test every combination commonly used. As an aside, at some point we will need to decide exactly how important the music/entertainment application is. Many going-forward audio codecs for entertainment scale up to lossless. Personally I think the most important use is conversational speech, and I see little need for yet another music codec. Stephen Botzko On Sat, Apr 3, 2010 at 7:42 AM, Christian Hoene wro= te: > Hi, > > > > depending on the use case, the second codec might vary. > > > > 1) For example, if bandwidth is plenty and music can be streamed, MP= 3 > might be the source. > > 2) In case of calling a cellular phone, AMR-NB or GSM-EFR might be > transcoding partner. > > 3) Or if mobile HD voice is deployed as announced ( > http://www.orange.com/en_EN/press/press_releases/cp100214en.jsp ) G.722.2 > (AMR-WB) shall be considered. > > 4) CAT-iq and many VoIP phones use G.722. > > 5) ISDN and PSTN gateways still require G.711? > > > > In case of G.718, use cases 3) and 4) are considered. > > > > Shall the transcoding tests done via subjective (MUSHRA, MOS-LQS) or > objective (PEAQ, PESQ, =85) methods? > > > > With best regards, > > Christian > > > > > > --------------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of T=FCbingen > > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > > > *From**:* stephen botzko [mailto:stephen.botzko@gmail.com] > *Sent:* Saturday, April 03, 2010 12:54 PM > > *To:* trac@localhost.amsl.com > *Cc:* hoene@uni-tuebingen.de; codec@ietf.org > *Subject:* Re: [codec] #1: Application: 2.1. Point to point calls > supporting transcoding? > > > > I personally believe testing tandem operation is a MUST, since devices > using this CODEC will certainly connect into networks where it is not > supported. The idea below that this will "just work" with every ITU code= c > is incorrect.. > > In addition, tandem operation occurs in virtually all conference bridges > (including back-to-back encode/decode with CODEC itself). So surely > self-tandeming has to be tested anyway. (Though of course is is common f= or > devices in the same conference to be using different codecs). > > I do not favor just copying the tandem requirements from some other codec= 's > test plan - unless we are sure that it is in essentially the same ecosyst= em > as ours. Ideally the community would identify common use cases, and the > test cases would be derived from those cases. > > Stephen Botzko > > On Sat, Apr 3, 2010 at 1:39 AM, codec issue tracker > wrote: > > #1: Application: 2.1. Point to point calls supporting transcoding? > > ------------------------------------+------------------------------------= --- > Reporter: hoene@=85 | Owner: > Type: enhancement | Status: new > Priority: major | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Keywords: > > ------------------------------------+------------------------------------= --- > > Comment(by hoene@=85): > > No consensus either until now. Again two opinions: > > a) "To have similar requirements as G.718 and to consider at least cross > > tandeming conditions with G722.2@12.65 in the characterization phase." > > b) "I think that transcoding must be an explicit non-goal for this codec= ." > > "Sorry, but I still do not understand the need for this testing. In a > cell network to VoIP topology, the codec selected must be an ITU codec > which we already know are working fine for transcoding. In a VoIP to Vo= IP > topology the codec selected is the one defined by this WG and by > definition no transcoding is needed. And that's it, no test needed, > because nobody will use it this way." > > Again, I would suggest to look for volunteers who want to make the > subjective tests with G.722.2 and CODEC. > > -- > Ticket URL: > > codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > --0016e64c145a02c2d1048353fdca Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable All valid considerations.=A0

G.711 and G.729 are very commonly used= in today's enterprise VOIP deployments.=A0

In the enterprise v= ideo conferencing market, G.722, G.722.1 (wideband and superwideband), G.71= 9, and AAC-LD are in common use.

I think it is likely that if G.729/CODEC tandems well, G.711/CODEC woul= d also.=A0 Just to point out that we do not necessarily need to test every = combination commonly used.

As an aside, at some point we will need t= o decide exactly how important the music/entertainment application is.=A0 M= any going-forward audio codecs for entertainment scale up to lossless. Pers= onally I think the most important use is conversational speech, and I see l= ittle need for yet another music codec.

Stephen Botzko

On Sat, Apr 3, 2010 at= 7:42 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:

= Hi,=

= =A0=

= de= pending on the use case, the second codec might vary.

= = =A0

1)=A0=A0=A0=A0=A0 For example, if bandwidth is plenty and music can be streamed, MP3 might be the source.

2)=A0=A0=A0=A0=A0 In case of calling a cellular phone, AMR-NB or GSM-EFR might be transcoding partner. =

3)=A0=A0=A0=A0=A0 Or if mobile HD voice is deployed as announced =A0(http://www.orange.com/en_EN/press/press_releases/cp100214en.jsp ) G.722.2 (AMR-WB) shall be considered.=

4)=A0=A0=A0=A0=A0 CAT-iq and many VoIP phones use G.722.

5)=A0=A0=A0=A0=A0 ISDN and PSTN gateways still require G.71= 1?

= = =A0

= In= case of G.718, use cases 3) and 4) are considered.

= = =A0

= Sh= all the transcoding tests done via subjective (MUSHRA, MOS-LQS= ) or objective (PEAQ, PESQ, =85) methods?

= = =A0

= Wi= th best regards,

= =A0Christian

= = =A0

= = =A0

---------------------------------------------------= ------------

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University= of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 = 2970532
= http://www.net.uni-tu= ebingen.de/

= = =A0

From<= font face=3D"Tahoma" size=3D"2">: stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Saturday, April 03, = 2010 12:54 PM


To: trac@localhost.amsl.com
Cc: hoene@uni-tuebingen.de; codec@ietf.org
Subject: Re: [codec]= #1: Application: 2.1. Point to point calls supporting transcoding?

=A0

I personally believe testing tandem operation is a MUST, since devices using this CODEC will certainly connect into networks where it is not supported.=A0 The idea belo= w that this will "just work" with every ITU codec is incorrect..
In addition, tandem operation occurs in virtually all conference bridges (including back-to-back encode/decode with CODEC itself).=A0 So surely self-tandeming has to be tested anyway.=A0 (Though of course is is common for devices in the same conference to be using different codecs).

I do not favor just copying the tandem requirements from some other codec&#= 39;s test plan - unless we are sure that it is in essentially the same ecosystem= as ours.=A0 Ideally the community would identify common use cases, and the tes= t cases would be derived from those cases.

Stephen Botzko

On Sat, Apr 3, 2010 at 1:39 AM, codec issue tracker = <trac@tools.iet= f.org> wrote:

#1: Application: 2.1. =A0Point to point calls supporting transcoding?
------------------------------------+--------------------------------------= -
=A0Reporter: =A0hoene@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner:
=A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new
=A0Priority: =A0major =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:
Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
=A0Severity: =A0Active WG Document =A0 =A0 =A0| =A0 =A0Keywords:
------------------------------------+--------------------------------------= -

Comment(by hoene@=85):

=A0No consensus either until now. Again two opinions:

=A0a) "To have similar requirements as G.718 and to consider at least cross

=A0tandeming conditions with G722.2@12.65 in the characterization phase."

=A0b) "I think that transcoding must be an expl= icit non-goal for this codec."

=A0"Sorry, but I still do not understand the need for this testing. =A0In a
=A0cell network to VoIP topology, the codec selected must be an ITU codec =A0which we already know are working fine for transcoding. =A0In a VoIP to VoIP
=A0topology the codec selected is the one defined by this WG and by
=A0definition no transcoding is needed. =A0And that's it, no test neede= d,
=A0because nobody will use it this way."

=A0Again, I would suggest to look for volunteers who= want to make the
=A0subjective tests with G.722.2 and CODEC.

--
Ticket URL: <https://svn.tools.ietf.org/wg/codec/trac/tic= ket/1#comment:1>

codec <http://tools.ietf.org/codec/>

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

=A0


--0016e64c145a02c2d1048353fdca-- From koen.vos@skype.net Sat Apr 3 08:44:47 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 375FA3A688A for ; Sat, 3 Apr 2010 08:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.27 X-Spam-Level: X-Spam-Status: No, score=-2.27 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=1.13, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ih-76Pvxwdng for ; Sat, 3 Apr 2010 08:44:46 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id C32A93A677C for ; Sat, 3 Apr 2010 08:44:42 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 9589360CEB58D; Sat, 3 Apr 2010 16:44:40 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=Rjvsu0ei7Yup 9bMeKh8CeJP3sVM=; b=pVMOZURkD29hkp1zYEqSjJ9rEUwoBdm533LvKNW3xQCC pnI7safL2DHJ99yzXzoeK1L3OqESyoAQPNxu/iE6o/ip0lgClvyPH42lUZy/Jq8g mM2L4Vp7GoPXlX614TvOurxUFY9+vGPhw389ZbvB063e/HjYfMfcV5xKSXSv6Qc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=Xk56JESmyNDJ4QvwkjqE 0jDNrbQjbIiduzMoj7JS2MeH7ChqkTqooQXDLp5FqMog1pvU5CrtQqJ9zPKZ7GyL k/EwdyPaT9sc6GLYZjIQPFCjpeLmB7jAbu5eaFInKYjamLDXi1E0gkcAlQWrvFA7 R13c3s4G4G7Rucb5XJ/JmFM= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 93A4C60CEB58B; Sat, 3 Apr 2010 16:44:40 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCCUljWIh9jg; Sat, 3 Apr 2010 16:44:39 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id B8F8460CEB58C; Sat, 3 Apr 2010 16:44:39 +0100 (IST) Received: from 5.Red-217-125-57.staticIP.rima-tde.net (5.Red-217-125-57.staticIP.rima-tde.net [217.125.57.5]) by mail.skype.net (Horde Framework) with HTTP; Sat, 03 Apr 2010 08:44:39 -0700 Message-ID: <20100403084439.78785ekqlw9ysv3b@mail.skype.net> Date: Sat, 03 Apr 2010 08:44:39 -0700 From: Koen Vos To: stephen botzko References: <062.4b6a3862c443b2d8917e027f2267f4d2@tools.ietf.org> <071.db71a07d3a8eb1cd6269da2ddeaa0468@tools.ietf.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: codec@ietf.org Subject: Re: [codec] #1: Application: 2.1. Point to point calls supporting transcoding? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 15:44:47 -0000 Any testing of tandem coding can only be about the audio quality. There is no binary question about whether "it works" or not, because any two codecs do indeed work together when connected through audio. I don't see a need to add tandem testing to the requirements. Quality will be high when operating towards the high end of the range in bitrates mentioned in the requirements, and tandem quality will be limited by the other codec. For lower bitrates the quality naturally goes down.. not sure what to test? koen. Quoting stephen botzko: > I personally believe testing tandem operation is a MUST, since devices using > this CODEC will certainly connect into networks where it is not supported. > The idea below that this will "just work" with every ITU codec is > incorrect.. > > In addition, tandem operation occurs in virtually all conference bridges > (including back-to-back encode/decode with CODEC itself). So surely > self-tandeming has to be tested anyway. (Though of course is is common for > devices in the same conference to be using different codecs). > > I do not favor just copying the tandem requirements from some other codec's > test plan - unless we are sure that it is in essentially the same ecosystem > as ours. Ideally the community would identify common use cases, and the > test cases would be derived from those cases. > > Stephen Botzko > > On Sat, Apr 3, 2010 at 1:39 AM, codec issue tracker > wrote: > >> #1: Application: 2.1. Point to point calls supporting transcoding? >> >> ------------------------------------+--------------------------------------- >> Reporter: hoene@... | Owner: >> Type: enhancement | Status: new >> Priority: major | Milestone: >> Component: requirements | Version: >> Severity: Active WG Document | Keywords: >> >> ------------------------------------+--------------------------------------- >> >> Comment(by hoene@...): >> >> No consensus either until now. Again two opinions: >> >> a) "To have similar requirements as G.718 and to consider at least cross >> tandeming conditions with G722.2@12.65 in the characterization phase." >> >> b) "I think that transcoding must be an explicit non-goal for this codec." >> "Sorry, but I still do not understand the need for this testing. In a >> cell network to VoIP topology, the codec selected must be an ITU codec >> which we already know are working fine for transcoding. In a VoIP to VoIP >> topology the codec selected is the one defined by this WG and by >> definition no transcoding is needed. And that's it, no test needed, >> because nobody will use it this way." >> >> Again, I would suggest to look for volunteers who want to make the >> subjective tests with G.722.2 and CODEC. >> >> -- >> Ticket URL: >> codec >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> > From hoene@uni-tuebingen.de Sat Apr 3 10:16:54 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F1063A6933 for ; Sat, 3 Apr 2010 10:16:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wnGrlIdU82A7 for ; Sat, 3 Apr 2010 10:16:52 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 906C43A6926 for ; Sat, 3 Apr 2010 10:16:33 -0700 (PDT) Received: from wm01.uni-tuebingen.de (wm01.uni-tuebingen.de [134.2.3.20]) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o33HGUuh007258; Sat, 3 Apr 2010 19:16:30 +0200 Received: by wm01.uni-tuebingen.de (Postfix, from userid 30) id 3F8797241E9; Sat, 3 Apr 2010 19:16:30 +0200 (CEST) Received: from 178.2.210.31 ([178.2.210.31]) by webmail.uni-tuebingen.de (Horde Framework) with HTTP; Sat, 03 Apr 2010 19:16:30 +0200 Message-ID: <20100403191630.18411la8a8bbre9a@webmail.uni-tuebingen.de> Date: Sat, 03 Apr 2010 19:16:30 +0200 From: "Dr. Christian Hoene" To: Koen Vos References: <062.4b6a3862c443b2d8917e027f2267f4d2@tools.ietf.org> <071.db71a07d3a8eb1cd6269da2ddeaa0468@tools.ietf.org> <20100403084439.78785ekqlw9ysv3b@mail.skype.net> In-Reply-To: <20100403084439.78785ekqlw9ysv3b@mail.skype.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.6) X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org, stephen botzko Subject: Re: [codec] #1: Application: 2.1. Point to point calls supporting transcoding? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Apr 2010 17:16:54 -0000 Quoting Koen Vos : > Any testing of tandem coding can only be about the audio quality. > There is no binary question about whether "it works" or not, because > any two codecs do indeed work together when connected through audio. > > I don't see a need to add tandem testing to the requirements. > Quality will be high when operating towards the high end of the > range in bitrates mentioned in the requirements, and tandem quality > will be limited by the other codec. For lower bitrates the quality > naturally goes down.. not sure what to test? Assuming two codecs, for example, CELT and AMR-WB, you must compare all CELT modes (about 16) against all AMR-WB modes (about 16), using different sample contents (4), and with noise and without (2). Typically, you need 8 ratings from different persons to get precise results. Actually, one needs to make the tests in at least two different labs. Thus, only 65536 listening-only ratings are required. These results you put in a document that is not public accessible and that nobody will read. Then everybody will believe that transcoding is a good idea and should be done at least twice in every call. Christian > > koen. > > > Quoting stephen botzko: >> I personally believe testing tandem operation is a MUST, since devices using >> this CODEC will certainly connect into networks where it is not supported. >> The idea below that this will "just work" with every ITU codec is >> incorrect.. >> >> In addition, tandem operation occurs in virtually all conference bridges >> (including back-to-back encode/decode with CODEC itself). So surely >> self-tandeming has to be tested anyway. (Though of course is is common for >> devices in the same conference to be using different codecs). >> >> I do not favor just copying the tandem requirements from some other codec's >> test plan - unless we are sure that it is in essentially the same ecosystem >> as ours. Ideally the community would identify common use cases, and the >> test cases would be derived from those cases. >> >> Stephen Botzko >> >> On Sat, Apr 3, 2010 at 1:39 AM, codec issue tracker >> wrote: >> >>> #1: Application: 2.1. Point to point calls supporting transcoding? >>> >>> ------------------------------------+--------------------------------------- >>> Reporter: hoene@... | Owner: >>> Type: enhancement | Status: new >>> Priority: major | Milestone: >>> Component: requirements | Version: >>> Severity: Active WG Document | Keywords: >>> >>> ------------------------------------+--------------------------------------- >>> >>> Comment(by hoene@...): >>> >>> No consensus either until now. Again two opinions: >>> >>> a) "To have similar requirements as G.718 and to consider at least cross >>> tandeming conditions with G722.2@12.65 in the characterization phase." >>> >>> b) "I think that transcoding must be an explicit non-goal for this codec." >>> "Sorry, but I still do not understand the need for this testing. In a >>> cell network to VoIP topology, the codec selected must be an ITU codec >>> which we already know are working fine for transcoding. In a VoIP to VoIP >>> topology the codec selected is the one defined by this WG and by >>> definition no transcoding is needed. And that's it, no test needed, >>> because nobody will use it this way." >>> >>> Again, I would suggest to look for volunteers who want to make the >>> subjective tests with G.722.2 and CODEC. >>> >>> -- >>> Ticket URL: >>> codec >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>> >> > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From rchen@broadcom.com Mon Apr 5 14:43:49 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2D3143A689C for ; Mon, 5 Apr 2010 14:43:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ytJlHL0Jn46I for ; Mon, 5 Apr 2010 14:43:39 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id BEFDD28C108 for ; Mon, 5 Apr 2010 14:43:38 -0700 (PDT) Received: from [10.9.200.131] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 05 Apr 2010 14:43:18 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Mon, 5 Apr 2010 14:43:18 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Roman Shpount" Date: Mon, 5 Apr 2010 14:43:16 -0700 Thread-Topic: [codec] #5: Mention DTMF in requirements Thread-Index: AcrSzJ2v+ELs5hQ7QaqcOJWi+BUS5gCOJbWQ Message-ID: References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67A486FC38O163909412-01-01 Content-Type: multipart/alternative; boundary=_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B87056IRVEXCHCCR01c_ Cc: "codec@ietf.org" Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Apr 2010 21:43:49 -0000 --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B87056IRVEXCHCCR01c_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Roman, Answers to you questions in-line. Raymond From: Roman Shpount [mailto:roman@telurix.com] Sent: Friday, April 02, 2010 6:26 PM To: Raymond (Juin-Hwey) Chen Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements I understand your points. There are few questions that I have: 1. Do we need a real world DTMF and telephone signals recording database to= implement this? Correct me if I am wrong, you've done your tests for BV16 = using your own DTMF generator and unspecified "commercial" DTMF detector. H= ow would define this test in a way it is possible to replicate it by third = parties and reference it in a standard? [Raymond]: We can use real-world recorded DTMF signals if we want to, but w= e don't have to. Yes, in our DTMF testing of BV16 we used a DTMF generator = software to generate the waveform of 20,000 random DTMF symbols for each of= 24 DTMF test conditions, for a total of nearly half a million DTMF symbols= . After passing through the codec, the DTMF signals were passed through a P= C executable program which simulated a DTMF decoder that was widely deploye= d in commercial VoIP applications. The decoded DTMF symbols were then compa= red with the original DTMF keys used to generate the symbols to calculate t= he error rates. As you can see, such a test method is purely based on softw= are and can easily be duplicated by third parties. If the codec WG decides= not to do anything with DTMF, then obviously nothing further needs to be d= one, but if the WG decides that the codec candidate needs to be tested for = DTMF pass-through, I will try to dig up our DTMF test software package and = get internal approval to donate it to IETF for this purpose. 2. Did you ever test your CODEC for other telephony signals, such as /ANSam= , ANS, CED, and CI tones? These tones are needed in order to detect modems = and fax machines and switch to an appropriate payload. What about progress = tones? [Raymond]: No, we didn't. However, if these are single-frequency tones, I = would expect that it should be easier for a typical codec to pass these ton= es than to pass the dual-frequency DTMF signals without causing significant= degradation in the subsequent processing of these tones. 3. Is this criteria feasible for large frame CELP CODECs? Are we going to e= xclude them based on this criteria? [Raymond]: If a CELP codec with a large frame size is designed such that it= can provide high encoding fidelity for DTMF signals, then it is still feas= ible for such a CELP codec to pass DTMF signals without causing subsequent = DTMF decoding errors, so being a large frame CELP codec does not automatica= lly mean it will be excluded. _____________________________ Roman Shpount - www.telurix.com On Fri, Apr 2, 2010 at 9:05 PM, Raymond (Juin-Hwey) Chen > wrote: Comments in-line. Raymond From: codec-bounces@ietf.org [mailto:codec-b= ounces@ietf.org] On Behalf Of Roman Shpount Sent: Friday, April 02, 2010 12:03 PM To: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements This is all wonderful, but what seems to be missing here is any type of sta= ndard test for DTMF tone detection. We have a number of tests for things th= at should not be detected as DTMF (various talk-off tapes), but there is no= test with samples of valid DTMF signals. In real world you get quite a var= iety of tones that different handsets or telephone devices generate when a = digit is pressed. Some of those tones are almost at border line conditions = for a valid DTMF tone. [Raymond]: I commented on this earlier. ITU-T G.720 can be used for general= guidelines. There were some published papers on codec DTMF pass-through te= sting based on G.720. Our BroadVoice16 paper is one of them (even though we= relaxed some corner conditions of G.720 to get a better idea of real-world= performance). If people are interested, I can share more details about the= test method. Second issue, which was already mentioned here, would be performance of DTM= F tone detector in the presence of packet loss or time stretching caused by= jitter buffer. Those things, even if they do not prevent DTMF detection, a= re almost guaranteed to split a single long tone in two. [Raymond]: Packet loss certainly will cause problems, but if the packet los= s rate is relatively low, there is still a good chance that DTMF digits can= get through. Finally, we seemed to concentrate on DTMF tones only, but in reality all th= e signaling/special tones are quite important. Fax Send/Receive tones come = to mind almost immediately as tones that are typically detected inband (ver= y few gateways encode those tones using RFC 4733/2833) I think we should formulate this requirement not in terms of DTMF tone but = in terms of accuracy of reproduction of periodic signals in specified freq= uency ranges. To be honest, the most robust solution would be to incorporat= e RFC4733/4744 as a part of the codec in a manner similar to comfort noise = frames. [Raymond]: I don't think we can do it in terms of "accuracy of reproduction= of periodic signals in specified frequency ranges". That may work for som= e single-frequency signaling tones, but it won't work for DTMF, since DTMF = signals are not periodic in any sense as the two frequencies of the sine wa= ves are not harmonically related. _____________________________ Roman Shpount - www.telurix.com On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene > wrote: Hi Stephan, Comments inline: --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ From: stephen botzko [mailto:stephen.botzko@gmail.com] Sent: Friday, April 02, 2010 4:50 PM To: Christian Hoene Cc: Michael Knappe; stpeter@stpeter.im; codec@ie= tf.org Subject: Re: [codec] #5: Mention DTMF in requirements (a) "MUST NOT" means that it must fail. Perhaps you meant "need not" or "m= ight not"? CH: Yes, I meant need not (or the German "muss nicht") (b) SHOULD is commonly used in establishing requirements, and it certainly = was used in MARTINI and other working groups at IETF77 in requirements presentations with no confusion. It has a clear meaning in the= requirements context (desirable but not essential) and I see no reason to avoid its use at this phase. There will certainly be othe= r things that are "nice to have", and it is appropriate to track them and consider them in the selection/standardization process. CH: Better? "The codec SHOULD support the transmission DTMF at most transmi= ssion conditions." I agree that language about DTMF might not need to be in the final RFC. Th= ough if DTMF quality is known to be inadequate, it probably makes sense to tell people that. CH: Agreed. The limits of the codec shall be clearly stated. I also agree to the obvious comment that DTMF detection methods are out of = scope. CH: Agreed. CH: Isn't time to include the MUST requirement for DTMF testing and SHOULD = requirement for transmission support into the requirements document. Then, we could close issue #5 and continue with other things. Christian _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B87056IRVEXCHCCR01c_ Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Roman,

 

Answers to you questions in-line.

 

Raymond

 

From: Roman Shpount [mailto:roman@telurix.com]
Sent: Friday, April 02, 2010 6:26 PM
To: Raymond (Juin-Hwey) Chen
Cc: codec@ietf.org
Subject: Re: [codec] #5: Mention DTMF in requirements

 

I understand your point= s. There are few questions that I have:

1. Do we need a real world DTMF and telephone signals recording database to implement this? Correct me if I am wrong, you've done your tests for BV16 u= sing your own DTMF generator and unspecified "commercial" DTMF detecto= r. How would define this test in a way it is possible to replicate it by third parties and reference it in a standard?
[Raymond]: We can use real-world recorded DTMF s= ignals if we want to, but we don’t have to. Yes, in our DTMF testing of BV16= we used a DTMF generator software to generate the waveform of 20,000 random DT= MF symbols for each of 24 DTMF test conditions, for a total of nearly half a million DTMF symbols. After passing through the codec, the DTMF signals wer= e passed through a PC executable program which simulated a DTMF decoder that = was widely deployed in commercial VoIP applications. The decoded DTMF symbols w= ere then compared with the original DTMF keys used to generate the symbols to calculate the error rates. As you can see, such a test method is purely bas= ed on software and can easily be duplicated by third parties.=A0 If the codec = WG decides not to do anything with DTMF, then obviously nothing further needs = to be done, but if the WG decides that the codec candidate needs to be tested = for DTMF pass-through, I will try to dig up our DTMF test software package and = get internal approval to donate it to IETF for this purpose.<= /p>

2. Did you ever test yo= ur CODEC for other telephony signals, such as /ANSam, ANS, CED, and CI tones? These tones are needed in order to detect modems and fax machines and switch to a= n appropriate payload. What about progress tones?
[Raymond]: No, we didn’t.=A0 However, if t= hese are single-frequency tones, I would expect that it should be easier for a typic= al codec to pass these tones than to pass the dual-frequency DTMF signals with= out causing significant degradation in the subsequent processing of these tones= .

3. Is this criteria fea= sible for large frame CELP CODECs? Are we going to exclude them based on this criteria?
[Raymond]: If a CELP codec with a large frame si= ze is designed such that it can provide high encoding fidelity for DTMF signals, = then it is still feasible for such a CELP codec to pass DTMF signals without cau= sing subsequent DTMF decoding errors, so being a large frame CELP codec does not automatically mean it will be excluded.

_______________________= ______
Roman Shpount - www.telurix.com

On Fri, Apr 2, 2010 at 9:05 PM, Raymond (Juin-Hwey) Ch= en <rchen@broadcom.com> wrote:=

Comments in-line.

 

Raymond

 

From: codec-bounces@ietf= .org [mailto:codec-b= ounces@ietf.org] On Behalf Of Roman Shpount
Sent: Friday, April 02, 2010 12:03 PM
To: codec@ietf.o= rg
Subject: Re: [codec] #5: Mention DTMF in requirements

 

This is all wonderful, but what seems to be missing here is any type of standard te= st for DTMF tone detection. We have a number of tests for things that should n= ot be detected as DTMF (various talk-off tapes), but there is no test with sam= ples of valid DTMF signals. In real world you get quite a variety of tones that different handsets or telephone devices generate when a digit is pressed. S= ome of those tones are almost at border line conditions for a valid DTMF tone.<= br> [Raymond]: I commented on this earlier. ITU-T G.= 720 can be used for general guidelines. There were some published papers on cod= ec DTMF pass-through testing based on G.720. Our BroadVoice16 paper is one of = them (even though we relaxed some corner conditions of G.720 to get a better ide= a of real-world performance). If people are interested, I can share more details about the test method.

Second issue, which was already mentioned here, would be performance of DTMF tone detector in the presence of packet loss or time stretching caused by jitter buffer. Those things, even if they do not prevent DTMF detection, are almos= t guaranteed to split a single long tone in two.
[Raymond]: Packet loss certainly will cause prob= lems, but if the packet loss rate is relatively low, there is still a good chance that DTMF digits can get through.

Finally, we seemed to concentrate on DTMF tones only, but in reality all the signaling/special tones are quite important. Fax Send/Receive tones come to mind almost immediately as tones that are typically detected inband (very f= ew gateways encode those tones using RFC 4733/2833)

I think we should formulate this requirement not in terms of DTMF tone but = in terms of accuracy of reproduction of  periodic signals in specified frequency ranges. To be honest, the most robust solution would be to incorporate RFC4733/4744 as a part of the codec in a manner similar to comf= ort noise frames.
[Raymond]: I don’t think we can do it in t= erms of “accuracy of reproduction of periodic signals in specified frequen= cy ranges”.  That may work for some single-frequency signaling tone= s, but it won’t work for DTMF, since DTMF signals are not periodic in an= y sense as the two frequencies of the sine waves are not harmonically related= .

_____________________________
Roman Shpount - www.te= lurix.com

On Fri, Apr 2, 2010 at 1:34 PM, Christian Hoene <hoene@uni-tuebinge= n.de> wrote:

Hi Stephan,

Comments inline:



---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.n= et.uni-tuebingen.de/

From: stephen botzko [mailto:stephen.botzko@gmail.com]

Sent: Friday, April 02, 2010 4:50 PM
To: Christian Hoene
Cc: Michael Knappe; stpeter@stpeter.im; codec@ietf.org=

Subject: Re: [codec] #5: Mention DTMF in requirements

(a) "MUST NOT" means that it must fail.  Perhaps you meant "need not" or "might not"?

CH: Yes, I meant need not (or the German „muss nicht“)


(b) SHOULD is commonly used in establishing requirements, and it certainly = was used in MARTINI and other working groups at IETF77 in
requirements presentations with no confusion. It has a clear meaning in the requirements context (desirable but not essential) and I
see no reason to avoid its use at this phase.  There will certainly be other things that are "nice to have", and it is appropriate
to track them and consider them in the selection/standardization process.

CH: Better? "The codec SHOULD support the transmission DTMF at most transmission conditions."


I agree that language about DTMF might not need to be in the final RFC.&nbs= p; Though if DTMF quality is known to be inadequate, it
probably makes sense to tell people that.

CH: Agreed. The limits of the codec shall be clearly stated.


I also agree to the obvious comment that DTMF detection methods are out of scope.

CH: Agreed.

CH: Isn't time to include the MUST requirement for DTMF testing and SHOULD requirement for transmission support into the
requirements document.
Then, we could close issue #5 and continue with other things.

 Christian




_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

 

 

--_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3B87056IRVEXCHCCR01c_-- From kpfleming@digium.com Tue Apr 6 06:28:08 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D60A03A694C for ; Tue, 6 Apr 2010 06:28:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.088 X-Spam-Level: X-Spam-Status: No, score=-102.088 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bMh3IjTZIhyS for ; Tue, 6 Apr 2010 06:28:07 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id CBB623A6944 for ; Tue, 6 Apr 2010 06:28:07 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1Nz8p3-0003K9-0g for codec@ietf.org; Tue, 06 Apr 2010 08:28:05 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id E6A3AD8002 for ; Tue, 6 Apr 2010 08:28:04 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wlLBKmo02qH for ; Tue, 6 Apr 2010 08:28:04 -0500 (CDT) Received: from [10.1.5.116] (unknown [206.166.206.34]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 745FFD8004 for ; Tue, 6 Apr 2010 08:28:04 -0500 (CDT) Message-ID: <4BBB1F67.2080101@digium.com> Date: Tue, 06 Apr 2010 06:47:51 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100317) MIME-Version: 1.0 CC: "codec@ietf.org" References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 13:28:08 -0000 Raymond (Juin-Hwey) Chen wrote: > 2. Did you ever test your CODEC for other telephony signals, such as > /ANSam, ANS, CED, and CI tones? These tones are needed in order to > detect modems and fax machines and switch to an appropriate payload. > What about progress tones? > [Raymond]: No, we didn=92t. However, if these are single-frequency ton= es, > I would expect that it should be easier for a typical codec to pass > these tones than to pass the dual-frequency DTMF signals without causin= g > significant degradation in the subsequent processing of these tones. This is pretty much a dead-end based on the other comments on this list, but in general, no, most of these tones are *not* single-frequency simple tones. ANSam, for example, is a single frequency, but is amplitude modulated. There are also variants that have phase reversals, and these must be preserved for them to be discriminated from the non-phase-reversal versions. --=20 Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From stephen.botzko@gmail.com Tue Apr 6 07:49:39 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E49663A680E for ; Tue, 6 Apr 2010 07:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TzwXyMvCTKMW for ; Tue, 6 Apr 2010 07:49:38 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id ACBB23A692B for ; Tue, 6 Apr 2010 07:49:34 -0700 (PDT) Received: by pwj2 with SMTP id 2so2528373pwj.31 for ; Tue, 06 Apr 2010 07:49:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=LPGyYZYvimiUfoaAy/N7t3HfTTKWnvsqLTybXJ76lIg=; b=nwj54n7nm5YTVmClWxXpXmjjQgSTI4W3SPMDYmpoQh4KXYHNj422I7g+lCh5CWhBTr wLluQcblKEG1P4wl4tCY94lnTrF+ouWilbXFnvw19G69KU516/aEFJ9/HRHY74rix8qE u/ttZ/M2m0wEjRYrbA3RHtHY3rdGB/jGX4b3w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=KYnF9DedFNKJTziP2LTThYmyoqnvl+W2sMjkVRJEuoy0UL2VuACx9r4+o/vhGcKosZ Fzh7tVgvF0X+7uMCDW1ku5e20KqWhllCNzqYMonkOIZN/ec4N9Iz3taVKcvrb7DDqr5Q aO0VTsZAyzv2CaZ0GTZr9CdKdJc18Cv4ilUuc= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Tue, 6 Apr 2010 07:49:29 -0700 (PDT) In-Reply-To: <4BBB1F67.2080101@digium.com> References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> <4BBB1F67.2080101@digium.com> Date: Tue, 6 Apr 2010 10:49:29 -0400 Received: by 10.115.38.21 with SMTP id q21mr6700936waj.217.1270565369466; Tue, 06 Apr 2010 07:49:29 -0700 (PDT) Message-ID: From: stephen botzko To: "Kevin P. Fleming" Content-Type: multipart/alternative; boundary=0016e64cb95682d48e0483928d09 Cc: "codec@ietf.org" Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Apr 2010 14:49:40 -0000 --0016e64cb95682d48e0483928d09 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree that there is a pretty strong consensus that carriage of "analog" fax and modem signals is a non-requirement. If by "payload switching" we are talking about switching codecs, then that is beyond the charter scope. I am thinking that we are getting a bit too focused on testing methods. In my view it would be more efficient to capture use cases, and derive MUST an= d SHOULD requirements from them first. Then go back and figure out what we will test and how we will test it. Stephen Botzko On Tue, Apr 6, 2010 at 7:47 AM, Kevin P. Fleming wrot= e: > Raymond (Juin-Hwey) Chen wrote: > > > 2. Did you ever test your CODEC for other telephony signals, such as > > /ANSam, ANS, CED, and CI tones? These tones are needed in order to > > detect modems and fax machines and switch to an appropriate payload. > > What about progress tones? > > [Raymond]: No, we didn=92t. However, if these are single-frequency ton= es, > > I would expect that it should be easier for a typical codec to pass > > these tones than to pass the dual-frequency DTMF signals without causin= g > > significant degradation in the subsequent processing of these tones. > > This is pretty much a dead-end based on the other comments on this list, > but in general, no, most of these tones are *not* single-frequency > simple tones. ANSam, for example, is a single frequency, but is > amplitude modulated. There are also variants that have phase reversals, > and these must be preserved for them to be discriminated from the > non-phase-reversal versions. > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kfleming@digium.com > Check us out at www.digium.com & www.asterisk.org > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016e64cb95682d48e0483928d09 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree that there is a pretty strong consensus that carriage of "anal= og" fax and modem signals is a non-requirement.=A0 If by "payload= switching" we are talking about switching codecs, then that is beyond= the charter scope.

I am thinking that we are getting a bit too focused on testing methods.= =A0 In my view it would be more efficient to capture use cases, and derive = MUST and SHOULD requirements from them first.=A0 Then go back and figure ou= t what we will test and how we will test it.=A0

Stephen Botzko



On Tue, Apr 6,= 2010 at 7:47 AM, Kevin P. Fleming <kpfleming@digium.com> wrote:
Raymond (Juin-Hwey) Chen wrote:

> 2. Did you ever test your CODEC for other tele= phony signals, such as
> /ANSam, ANS, CED, and CI tones? These tones are needed in order to
> detect modems and fax machines and switch to an appropriate payload. > What about progress tones?
> [Raymond]: No, we didn=92t. =A0However, if these are single-frequency = tones,
> I would expect that it should be easier for a typical codec to pass > these tones than to pass the dual-frequency DTMF signals without causi= ng
> significant degradation in the subsequent processing of these tones.
This is pretty much a dead-end based on the other comments on this li= st,
but in general, no, most of these tones are *not* single-frequency
simple tones. ANSam, for example, is a single frequency, but is
amplitude modulated. There are also variants that have phase reversals,
and these must be preserved for them to be discriminated from the
non-phase-reversal versions.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@= digium.com
Check us out at www.dig= ium.com & www= .asterisk.org

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016e64cb95682d48e0483928d09-- From koen.vos@skype.net Wed Apr 7 10:28:51 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 160C53A694A for ; Wed, 7 Apr 2010 10:28:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YxMtUvQ0an3r for ; Wed, 7 Apr 2010 10:28:50 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 2CD5C3A6AA1 for ; Wed, 7 Apr 2010 10:28:16 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 236E06097EC1B for ; Wed, 7 Apr 2010 18:28:13 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=T2R+nM2Dw2nw m1V0afcyEZXQzq8=; b=PSkdP41cP4Z0tZw1RSy/AiLZaiWgOWNlAQro/+8GC+MX Sbt/wEwvx7FaDb6DxojSv8wQYzbcPoKxxHLoQqm5WLb+K5VYYcTSLRz+AJalYT6v BdroEVqykjfd5oiEdITjZkkMNkvjwhj3ov2Ud32pC+65pamBIYxD/lUi00hwdDw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=sO0VXfRdM8Q/ICBi0/2T pNLM2rhGK6JVqYHQxeNRwFhLp6g/eQS6aLLWrDv5JhgzVDq/sKhqKWOIy3i3zZyE YlrJ19jo9DiPjYVud5qPhEqloGsj1zPaLBQeignOHUgQzsCu051n9FN18qzfYsAY JW6F/eX8yMqSUkq+8CpiXeY= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 21B6860970269 for ; Wed, 7 Apr 2010 18:28:13 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id prk4+gGV6PuQ for ; Wed, 7 Apr 2010 18:28:12 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 31AB76097EC1A; Wed, 7 Apr 2010 18:28:12 +0100 (IST) Received: from adsl-71-141-129-119.dsl.snfc21.pacbell.net (adsl-71-141-129-119.dsl.snfc21.pacbell.net [71.141.129.119]) by mail.skype.net (Horde Framework) with HTTP; Wed, 07 Apr 2010 10:28:12 -0700 Message-ID: <20100407102812.15301dp1i39umzsc@mail.skype.net> Date: Wed, 07 Apr 2010 10:28:12 -0700 From: Koen Vos To: codec@ietf.org References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> <4BBB1F67.2080101@digium.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Apr 2010 17:28:51 -0000 The distinction between use case and testing makes sense to me. DTMF is a real use case. For example some PSTN gateways still don't support out-of-band DTMF. It's unclear what to test about DTMF though. The Codec will support a range of sample rates and bitrates. The requirements specify coding of music at near-transparent quality. I don't see how a such a codec could not provide sufficient quality for in-band DTMF. At the same time, the requirements talk about bitrates down to 8 kbps, where it may be quite tricky to get DTMF to work well. Therefore, specifying that the codec SHOULD or MUST encode DTMF with sufficient quality is meaningless. If anything, the bitrate settings that allow in-band DTMF could be characterized after the Codec is formed. Nevertheless it's good to be aware of these use cases during development. For instance, with SILK we included DTMF signals in the LSF quantizer training database. Similarly, I see tandem coding as a use case to keep in mind during development, but again don't see a need for testing or MUST/SHOULD requirements. koen. Quoting stephen botzko: > I agree that there is a pretty strong consensus that carriage of "analog" > fax and modem signals is a non-requirement. If by "payload switching" we > are talking about switching codecs, then that is beyond the charter scope. > > I am thinking that we are getting a bit too focused on testing methods. In > my view it would be more efficient to capture use cases, and derive MUST and > SHOULD requirements from them first. Then go back and figure out what we > will test and how we will test it. > > Stephen Botzko > > > > On Tue, Apr 6, 2010 at 7:47 AM, Kevin P. Fleming wrote: > >> Raymond (Juin-Hwey) Chen wrote: >> >> > 2. Did you ever test your CODEC for other telephony signals, such as >> > /ANSam, ANS, CED, and CI tones? These tones are needed in order to >> > detect modems and fax machines and switch to an appropriate payload. >> > What about progress tones? >> > [Raymond]: No, we didn't. However, if these are single-frequency tones, >> > I would expect that it should be easier for a typical codec to pass >> > these tones than to pass the dual-frequency DTMF signals without causing >> > significant degradation in the subsequent processing of these tones. >> >> This is pretty much a dead-end based on the other comments on this list, >> but in general, no, most of these tones are *not* single-frequency >> simple tones. ANSam, for example, is a single frequency, but is >> amplitude modulated. There are also variants that have phase reversals, >> and these must be preserved for them to be discriminated from the >> non-phase-reversal versions. >> >> -- >> Kevin P. Fleming >> Digium, Inc. | Director of Software Technologies >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >> skype: kpfleming | jabber: kfleming@digium.com >> Check us out at www.digium.com & www.asterisk.org >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> > From stephen.botzko@gmail.com Thu Apr 8 04:23:42 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D69BF28C11A for ; Thu, 8 Apr 2010 04:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcLGqg08ZiPG for ; Thu, 8 Apr 2010 04:23:39 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 490633A6A44 for ; Thu, 8 Apr 2010 04:23:09 -0700 (PDT) Received: by gyh4 with SMTP id 4so1137798gyh.31 for ; Thu, 08 Apr 2010 04:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=Wuk8GGlQ84LZNFQczalISfHdPwUhmYJ+c0cFxldJV9w=; b=Cr3DIiHoEv4GNQHomAHBzFjCOJ2r9e7a9y4z6RGqtgGRvMnc9XcB8c04FY3X85gmQA sy84lLdVy9Smb8VGmZXIwO8Wey2o73LztzhilwVF8FBmw5aukjjmtZclrE1jiXKyWDlE WlDvO3xnNwRPZoEUk/PGZJKtQquw2JkCNEfyo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Yl/FScXI184Zt6k/JI/LtUM5txjWBJwr/TlQmCly0b9bcnWdi/CCAh3qK0cyMk8uu8 7YFPUnd1sff6n3LyuytJW7ycPo3AubR6thb2bemHpCLm+cEPTRd4wjI4R0DkDH/aotpB XTCMZVUzrcAPnGhSI+ZrukkyBY0wrJ+9hjnjs= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Thu, 8 Apr 2010 04:23:01 -0700 (PDT) In-Reply-To: <20100407102812.15301dp1i39umzsc@mail.skype.net> References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <000301cad28a$ca0c6450$5e252cf0$@de> <4BBB1F67.2080101@digium.com> <20100407102812.15301dp1i39umzsc@mail.skype.net> Date: Thu, 8 Apr 2010 07:23:01 -0400 Received: by 10.101.109.16 with SMTP id l16mr21270430anm.181.1270725781540; Thu, 08 Apr 2010 04:23:01 -0700 (PDT) Message-ID: From: stephen botzko To: Koen Vos Content-Type: multipart/alternative; boundary=001636ed72dbd105300483b7e674 Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 11:23:42 -0000 --001636ed72dbd105300483b7e674 Content-Type: text/plain; charset=ISO-8859-1 We are getting closer to agreement, but maybe aren't all the way there yet. For me, requirements need to be solidly anchored in use cases. So if we identify reasonably common use cases, then the functionality that is needed for use cases has to be reflected in the requirements (either as SHOULDs or MUSTs). If the requirements are not clearly articulated and documented, then some will get lost as we move through the development / seleciton / testing process. We certainly agree that the developers will need to keep all the requirements in mind. After we have the full list of requirements, we will then need to figure out the test plan. I think we also agree that we won't succeed if we have a very long list of requirements. One way to try to prevent that is to narrow our application focus. At the moment that seems a bit vague, and perhaps to broad. As an aside, I would prioritize tandeming well above DTMF. We are not seeing any trend towards client side mixing (either with SIP phones or video systems). Also conference bridges are typically deployed for a very long time, so the existing server-side mixing will be with us for the foreseeable future.. Stephen Botzko On Wed, Apr 7, 2010 at 1:28 PM, Koen Vos wrote: > The distinction between use case and testing makes sense to me. > > DTMF is a real use case. For example some PSTN gateways still don't support > out-of-band DTMF. > > It's unclear what to test about DTMF though. The Codec will support a range > of sample rates and bitrates. The requirements specify coding of music at > near-transparent quality. I don't see how a such a codec could not provide > sufficient quality for in-band DTMF. At the same time, the requirements talk > about bitrates down to 8 kbps, where it may be quite tricky to get DTMF to > work well. Therefore, specifying that the codec SHOULD or MUST encode DTMF > with sufficient quality is meaningless. If anything, the bitrate settings > that allow in-band DTMF could be characterized after the Codec is formed. > > Nevertheless it's good to be aware of these use cases during development. > For instance, with SILK we included DTMF signals in the LSF quantizer > training database. > > Similarly, I see tandem coding as a use case to keep in mind during > development, but again don't see a need for testing or MUST/SHOULD > requirements. > > koen. > > > > > Quoting stephen botzko: > > I agree that there is a pretty strong consensus that carriage of "analog" >> fax and modem signals is a non-requirement. If by "payload switching" we >> are talking about switching codecs, then that is beyond the charter scope. >> >> I am thinking that we are getting a bit too focused on testing methods. >> In >> my view it would be more efficient to capture use cases, and derive MUST >> and >> SHOULD requirements from them first. Then go back and figure out what we >> will test and how we will test it. >> >> Stephen Botzko >> >> >> >> On Tue, Apr 6, 2010 at 7:47 AM, Kevin P. Fleming > >wrote: >> >> Raymond (Juin-Hwey) Chen wrote: >>> >>> > 2. Did you ever test your CODEC for other telephony signals, such as >>> > /ANSam, ANS, CED, and CI tones? These tones are needed in order to >>> > detect modems and fax machines and switch to an appropriate payload. >>> > What about progress tones? >>> > [Raymond]: No, we didn't. However, if these are single-frequency >>> tones, >>> > I would expect that it should be easier for a typical codec to pass >>> > these tones than to pass the dual-frequency DTMF signals without >>> causing >>> > significant degradation in the subsequent processing of these tones. >>> >>> This is pretty much a dead-end based on the other comments on this list, >>> but in general, no, most of these tones are *not* single-frequency >>> simple tones. ANSam, for example, is a single frequency, but is >>> amplitude modulated. There are also variants that have phase reversals, >>> and these must be preserved for them to be discriminated from the >>> non-phase-reversal versions. >>> >>> -- >>> Kevin P. Fleming >>> Digium, Inc. | Director of Software Technologies >>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >>> skype: kpfleming | jabber: kfleming@digium.com >>> Check us out at www.digium.com & www.asterisk.org >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>> >>> >> > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636ed72dbd105300483b7e674 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable We are getting closer to agreement, but maybe aren't all the way there = yet.

For me, requirements need to be solidly anchored in use cases.= =A0 So if we identify reasonably common use cases, then the functionality t= hat is needed for use cases has to be reflected in the requirements (either= as SHOULDs or MUSTs).=A0 If the requirements are not clearly articulated a= nd documented, then some will get lost as we move through the development /= seleciton / testing process.

We certainly agree that the developers will need to keep all the requir= ements in mind.=A0 After we have the full list of requirements, we will the= n need to figure out the test plan.

I think we also agree that we wo= n't succeed if we have a very long list of requirements.=A0 One way to = try to prevent that is to narrow our application focus.=A0 At the moment th= at seems a bit vague, and perhaps to broad.

As an aside, I would prioritize tandeming well above DTMF.=A0 We are no= t seeing any trend towards client side mixing (either with SIP phones or vi= deo systems).=A0 Also conference bridges are typically deployed for a very = long time, so the existing server-side mixing will be with us for the fores= eeable future..

Stephen Botzko





On Wed= , Apr 7, 2010 at 1:28 PM, Koen Vos <koen.vos@skype.net> wrote:
The distinction between use case and testing makes sense to me.

DTMF is a real use case. For example some PSTN gateways still don't sup= port out-of-band DTMF.

It's unclear what to test about DTMF though. The Codec will support a r= ange of sample rates and bitrates. The requirements specify coding of music= at near-transparent quality. I don't see how a such a codec could not = provide sufficient quality for in-band DTMF. At the same time, the requirem= ents talk about bitrates down to 8 kbps, where it may be quite tricky to ge= t DTMF to work well. Therefore, specifying that the codec SHOULD or MUST en= code DTMF with sufficient quality is meaningless. If anything, the bitrate = settings that allow in-band DTMF could be characterized after the Codec is = formed.

Nevertheless it's good to be aware of these use cases during developmen= t. For instance, with SILK we included DTMF signals in the LSF quantizer tr= aining database.

Similarly, I see tandem coding as a use case to keep in mind during develop= ment, but again don't see a need for testing or MUST/SHOULD requirement= s.

koen.




Quoting stephen botzko:

I agree that there is a pretty strong consensus that carriage of "anal= og"
fax and modem signals is a non-requirement. =A0If by "payload switchin= g" we
are talking about switching codecs, then that is beyond the charter scope.<= br>
I am thinking that we are getting a bit too focused on testing methods. =A0= In
my view it would be more efficient to capture use cases, and derive MUST an= d
SHOULD requirements from them first. =A0Then go back and figure out what we=
will test and how we will test it.

Stephen Botzko



On Tue, Apr 6, 2010 at 7:47 AM, Kevin P. Fleming <kpfleming@digium.com>wrote:

Raymond (Juin-Hwey) Chen wrote:

> 2. Did you ever test your CODEC for other telephony signals, such as > /ANSam, ANS, CED, and CI tones? These tones are needed in order to
> detect modems and fax machines and switch to an appropriate payload. > What about progress tones?
> [Raymond]: No, we didn't. =A0However, if these are single-frequenc= y tones,
> I would expect that it should be easier for a typical codec to pass > these tones than to pass the dual-frequency DTMF signals without causi= ng
> significant degradation in the subsequent processing of these tones.
This is pretty much a dead-end based on the other comments on this list, but in general, no, most of these tones are *not* single-frequency
simple tones. ANSam, for example, is a single frequency, but is
amplitude modulated. There are also variants that have phase reversals,
and these must be preserved for them to be discriminated from the
non-phase-reversal versions.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.dig= ium.com & www= .asterisk.org

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec




_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--001636ed72dbd105300483b7e674-- From Felix.Wyss@inin.com Thu Apr 8 06:27:38 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 618333A68A0 for ; Thu, 8 Apr 2010 06:27:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggh+GCAI7dnG for ; Thu, 8 Apr 2010 06:27:37 -0700 (PDT) Received: from inin.com (smtpgw.inin.com [209.43.1.24]) by core3.amsl.com (Postfix) with ESMTP id 01D143A68E3 for ; Thu, 8 Apr 2010 06:27:12 -0700 (PDT) Received: from ININHUB2 [172.16.1.157] by smtpgw.inin.com - Websense Email Security (6.1.1); Thu, 08 Apr 2010 09:27:09 -0400 Received: from ININMAIL.i3domain.inin.com ([172.16.1.186]) by ininhub2.i3domain.inin.com ([172.16.1.157]) with mapi; Thu, 8 Apr 2010 09:27:08 -0400 From: "Wyss, Felix" To: 'Koen Vos' , "codec@ietf.org" Date: Thu, 8 Apr 2010 09:27:08 -0400 Thread-Topic: [codec] #5: Mention DTMF in requirements Thread-Index: AcrWd8pMChjsX6RhQlKSVp/7NMjuJgApXuiA Message-ID: References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <003d01cad270$91acee00$b506ca00$@de> <000301cad28a$ca0c6450$5e252cf0$@de> <4BBB1F67.2080101@digium.com> <20100407102812.15301dp1i39umzsc@mail.skype.net> In-Reply-To: <20100407102812.15301dp1i39umzsc@mail.skype.net> 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 X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1 X-SEF-ZeroHour-RefID: fgs=4 X-SEF-Processed: 6_1_1_105__2010_04_08_09_27_09 Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 13:27:38 -0000 I still fail to see a reason to include support for DTMF transparency as a = requirement. It simply does not seem worth the cost to even test (DTMF) to= nes other than to ensure the codec doesn't produce overly unpleasant audio = artifacts. Your statement that some PSTN gateways currently don't support RFC#2833 see= ms immaterial to me as they also do not support this yet to be designed cod= ec. --Felix > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > Koen Vos > Sent: Wednesday, April 07, 2010 13:28 > To: codec@ietf.org > Subject: Re: [codec] #5: Mention DTMF in requirements > > The distinction between use case and testing makes sense to me. > > DTMF is a real use case. For example some PSTN gateways still don't > support out-of-band DTMF. > > It's unclear what to test about DTMF though. The Codec will support a > range of sample rates and bitrates. The requirements specify coding of > music at near-transparent quality. I don't see how a such a codec > could not provide sufficient quality for in-band DTMF. At the same > time, the requirements talk about bitrates down to 8 kbps, where it > may be quite tricky to get DTMF to work well. Therefore, specifying > that the codec SHOULD or MUST encode DTMF with sufficient quality is > meaningless. If anything, the bitrate settings that allow in-band DTMF > could be characterized after the Codec is formed. > > Nevertheless it's good to be aware of these use cases during > development. For instance, with SILK we included DTMF signals in the > LSF quantizer training database. > > Similarly, I see tandem coding as a use case to keep in mind during > development, but again don't see a need for testing or MUST/SHOULD > requirements. > > koen. > > > > Quoting stephen botzko: > > > I agree that there is a pretty strong consensus that carriage of > "analog" > > fax and modem signals is a non-requirement. If by "payload switching" > we > > are talking about switching codecs, then that is beyond the charter > scope. > > > > I am thinking that we are getting a bit too focused on testing methods. > In > > my view it would be more efficient to capture use cases, and derive MUS= T > and > > SHOULD requirements from them first. Then go back and figure out what > we > > will test and how we will test it. > > > > Stephen Botzko > > > > > > > > On Tue, Apr 6, 2010 at 7:47 AM, Kevin P. Fleming > wrote: > > > >> Raymond (Juin-Hwey) Chen wrote: > >> > >> > 2. Did you ever test your CODEC for other telephony signals, such as > >> > /ANSam, ANS, CED, and CI tones? These tones are needed in order to > >> > detect modems and fax machines and switch to an appropriate payload. > >> > What about progress tones? > >> > [Raymond]: No, we didn't. However, if these are single-frequency > tones, > >> > I would expect that it should be easier for a typical codec to pass > >> > these tones than to pass the dual-frequency DTMF signals without > causing > >> > significant degradation in the subsequent processing of these tones. > >> > >> This is pretty much a dead-end based on the other comments on this > list, > >> but in general, no, most of these tones are *not* single-frequency > >> simple tones. ANSam, for example, is a single frequency, but is > >> amplitude modulated. There are also variants that have phase reversals= , > >> and these must be preserved for them to be discriminated from the > >> non-phase-reversal versions. > >> > >> -- > >> Kevin P. Fleming > >> Digium, Inc. | Director of Software Technologies > >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > >> skype: kpfleming | jabber: kfleming@digium.com > >> Check us out at www.digium.com & www.asterisk.org > >> > >> _______________________________________________ > >> codec mailing list > >> codec@ietf.org > >> https://www.ietf.org/mailman/listinfo/codec > >> > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From stephen.botzko@gmail.com Thu Apr 8 10:52:16 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E8BD63A6A8F for ; Thu, 8 Apr 2010 10:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4wAxm4rey3q for ; Thu, 8 Apr 2010 10:52:15 -0700 (PDT) Received: from mail-pz0-f181.google.com (mail-pz0-f181.google.com [209.85.222.181]) by core3.amsl.com (Postfix) with ESMTP id 422993A67AF for ; Thu, 8 Apr 2010 10:52:02 -0700 (PDT) Received: by pzk11 with SMTP id 11so562360pzk.32 for ; Thu, 08 Apr 2010 10:51:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=+XuiFbx7vmDqxcnxdHI3yDMdVTGbtf4WG7Iju7oiCNg=; b=JzbhxVXRBk7Ixm0GZHrEWZalh7bkiMxUnVM2oTmgTOIFFCfWXSc6lnmiYcPeuFz9Vd I/usZBiGxc7U3AWy2OxEql8nSAVw2UBBKam9sOITlo8BJMOVOlZvbLmDGeI+426jImEV chs9OCRPLQTGCn9PNM+oReXEehtxv6LQOb8A8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oTLX16lC3zyIkQusbm0JaItsOekgwVkTXOxYV2rjzcYwMiCa+EK95Dfr4XHt0Ek7VG 7Pv+3Vy50eS5FzYfEma1d3O+VabeIMubRBt/Ei4JKZXa/DxnQ4vrT2bxg8ngcBSTaGxY MO9RcmI8BqkgXqkKnYshkm+O9hue90Tn1V7QU= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Thu, 8 Apr 2010 10:51:56 -0700 (PDT) In-Reply-To: References: <05542EC42316164383B5180707A489EE1D0AA5F58E@EMBX02-HQ.jnpr.net> <000301cad28a$ca0c6450$5e252cf0$@de> <4BBB1F67.2080101@digium.com> <20100407102812.15301dp1i39umzsc@mail.skype.net> Date: Thu, 8 Apr 2010 13:51:56 -0400 Received: by 10.141.106.15 with SMTP id i15mr712694rvm.194.1270749116209; Thu, 08 Apr 2010 10:51:56 -0700 (PDT) Message-ID: From: stephen botzko To: "Wyss, Felix" Content-Type: multipart/alternative; boundary=000e0cd13bf0ab9caa0483bd5534 Cc: "codec@ietf.org" Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 17:52:17 -0000 --000e0cd13bf0ab9caa0483bd5534 Content-Type: text/plain; charset=ISO-8859-1 On this thread I see 6 posters who see at least a SHOULD requirement, 4 posters who see a NON requirement and 3 posters for which I can't tell. There seems to be general agreement that the use case is real, the disagreement is whether RFC 2833 eliminates the need for DTMF transparency (or not). I suggest a hum in July might be the best way to see where the community as a whole is. Stephen Botzko On Thu, Apr 8, 2010 at 9:27 AM, Wyss, Felix wrote: > I still fail to see a reason to include support for DTMF transparency as a > requirement. It simply does not seem worth the cost to even test (DTMF) > tones other than to ensure the codec doesn't produce overly unpleasant audio > artifacts. > > Your statement that some PSTN gateways currently don't support RFC#2833 > seems immaterial to me as they also do not support this yet to be designed > codec. > > --Felix > > > -----Original Message----- > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of > > Koen Vos > > Sent: Wednesday, April 07, 2010 13:28 > > To: codec@ietf.org > > Subject: Re: [codec] #5: Mention DTMF in requirements > > > > The distinction between use case and testing makes sense to me. > > > > DTMF is a real use case. For example some PSTN gateways still don't > > support out-of-band DTMF. > > > > It's unclear what to test about DTMF though. The Codec will support a > > range of sample rates and bitrates. The requirements specify coding of > > music at near-transparent quality. I don't see how a such a codec > > could not provide sufficient quality for in-band DTMF. At the same > > time, the requirements talk about bitrates down to 8 kbps, where it > > may be quite tricky to get DTMF to work well. Therefore, specifying > > that the codec SHOULD or MUST encode DTMF with sufficient quality is > > meaningless. If anything, the bitrate settings that allow in-band DTMF > > could be characterized after the Codec is formed. > > > > Nevertheless it's good to be aware of these use cases during > > development. For instance, with SILK we included DTMF signals in the > > LSF quantizer training database. > > > > Similarly, I see tandem coding as a use case to keep in mind during > > development, but again don't see a need for testing or MUST/SHOULD > > requirements. > > > > koen. > > > > > > > > Quoting stephen botzko: > > > > > I agree that there is a pretty strong consensus that carriage of > > "analog" > > > fax and modem signals is a non-requirement. If by "payload switching" > > we > > > are talking about switching codecs, then that is beyond the charter > > scope. > > > > > > I am thinking that we are getting a bit too focused on testing methods. > > In > > > my view it would be more efficient to capture use cases, and derive > MUST > > and > > > SHOULD requirements from them first. Then go back and figure out what > > we > > > will test and how we will test it. > > > > > > Stephen Botzko > > > > > > > > > > > > On Tue, Apr 6, 2010 at 7:47 AM, Kevin P. Fleming > > wrote: > > > > > >> Raymond (Juin-Hwey) Chen wrote: > > >> > > >> > 2. Did you ever test your CODEC for other telephony signals, such as > > >> > /ANSam, ANS, CED, and CI tones? These tones are needed in order to > > >> > detect modems and fax machines and switch to an appropriate payload. > > >> > What about progress tones? > > >> > [Raymond]: No, we didn't. However, if these are single-frequency > > tones, > > >> > I would expect that it should be easier for a typical codec to pass > > >> > these tones than to pass the dual-frequency DTMF signals without > > causing > > >> > significant degradation in the subsequent processing of these tones. > > >> > > >> This is pretty much a dead-end based on the other comments on this > > list, > > >> but in general, no, most of these tones are *not* single-frequency > > >> simple tones. ANSam, for example, is a single frequency, but is > > >> amplitude modulated. There are also variants that have phase > reversals, > > >> and these must be preserved for them to be discriminated from the > > >> non-phase-reversal versions. > > >> > > >> -- > > >> Kevin P. Fleming > > >> Digium, Inc. | Director of Software Technologies > > >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > > >> skype: kpfleming | jabber: kfleming@digium.com > > >> Check us out at www.digium.com & www.asterisk.org > > >> > > >> _______________________________________________ > > >> codec mailing list > > >> codec@ietf.org > > >> https://www.ietf.org/mailman/listinfo/codec > > >> > > > > > > > > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --000e0cd13bf0ab9caa0483bd5534 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On this thread I see 6 posters who see at least a SHOULD requirement, 4 pos= ters who see a NON requirement and 3 posters for which I can't tell.
There seems to be general agreement that the use case is real, the dis= agreement is whether RFC 2833 eliminates the need for DTMF transparency (or= not).

I suggest a hum in July might be the best way to see where the communit= y as a whole is.=A0

Stephen Botzko



On Thu, Apr 8, 2010 at 9:27 AM, Wyss, Felix <= ;Felix.Wyss@inin.com> = wrote:
I still fail to s= ee a reason to include support for DTMF transparency as a requirement. =A0I= t simply does not seem worth the cost to even test (DTMF) tones other than = to ensure the codec doesn't produce overly unpleasant audio artifacts.<= br>
Your statement that some PSTN gateways currently don't support RFC#2833= seems immaterial to me as they also do not support this yet to be designed= codec.

--Felix

> -----Original Message-----
> From: codec-bounces@ietf.org= [mailto:codec-bounces@ietf.o= rg] On Behalf Of
> Koen Vos
> Sent: Wednesday, April 07, 2010 13:28
> To: codec@ietf.org
> Subject: Re: [codec] #5: Mention DTMF in requirements
>
> The distinction between use ca= se and testing makes sense to me.
>
> DTMF is a real use case. For example some PSTN gateways still don'= t
> support out-of-band DTMF.
>
> It's unclear what to test about DTMF though. The Codec will suppor= t a
> range of sample rates and bitrates. The requirements specify coding of=
> music at near-transparent quality. I don't see how a such a codec<= br> > could not provide sufficient quality for in-band DTMF. At the same
> time, the requirements talk about bitrates down to 8 kbps, where it > may be quite tricky to get DTMF to work well. Therefore, specifying > that the codec SHOULD or MUST encode DTMF with sufficient quality is > meaningless. If anything, the bitrate settings that allow in-band DTMF=
> could be characterized after the Codec is formed.
>
> Nevertheless it's good to be aware of these use cases during
> development. For instance, with SILK we included DTMF signals in the > LSF quantizer training database.
>
> Similarly, I see tandem coding as a use case to keep in mind during > development, but again don't see a need for testing or MUST/SHOULD=
> requirements.
>
> koen.
>
>
>
> Quoting stephen botzko:
>
> > I agree that there is a pretty strong consensus that carriage of<= br> > "analog"
> > fax and modem signals is a non-requirement. =A0If by "payloa= d switching"
> we
> > are talking about switching codecs, then that is beyond the chart= er
> scope.
> >
> > I am thinking that we are getting a bit too focused on testing me= thods.
> In
> > my view it would be more efficient to capture use cases, and deri= ve MUST
> and
> > SHOULD requirements from them first. =A0Then go back and figure o= ut what
> we
> > will test and how we will test it.
> >
> > Stephen Botzko
> >
> >
> >
> > On Tue, Apr 6, 2010 at 7:47 AM, Kevin P. Fleming
> <kpfleming@digium.com&g= t;wrote:
> >
> >> Raymond (Juin-Hwey) Chen wrote:
> >>
> >> > 2. Did you ever test your CODEC for other telephony sign= als, such as
> >> > /ANSam, ANS, CED, and CI tones? These tones are needed i= n order to
> >> > detect modems and fax machines and switch to an appropri= ate payload.
> >> > What about progress tones?
> >> > [Raymond]: No, we didn't. =A0However, if these are s= ingle-frequency
> tones,
> >> > I would expect that it should be easier for a typical co= dec to pass
> >> > these tones than to pass the dual-frequency DTMF signals= without
> causing
> >> > significant degradation in the subsequent processing of = these tones.
> >>
> >> This is pretty much a dead-end based on the other comments on= this
> list,
> >> but in general, no, most of these tones are *not* single-freq= uency
> >> simple tones. ANSam, for example, is a single frequency, but = is
> >> amplitude modulated. There are also variants that have phase = reversals,
> >> and these must be preserved for them to be discriminated from= the
> >> non-phase-reversal versions.
> >>
> >> --
> >> Kevin P. Fleming
> >> Digium, Inc. | Director of Software Technologies
> >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> >> skype: kpfleming | jabber: kfleming@digium.com
> >> Check us out at www.digium.com & www.asterisk.org
> >>
> >> _______________________________________________
> >> codec mailing list
> >> codec@ietf.org
> >> https://www.ietf.org/mailman/listinfo/codec
> >>
> >
>
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec


_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--000e0cd13bf0ab9caa0483bd5534-- From mknappe@juniper.net Thu Apr 8 11:08:14 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8C5F28C10D for ; Thu, 8 Apr 2010 11:08:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.098 X-Spam-Level: X-Spam-Status: No, score=-6.098 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hPDqe+ULq3Xl for ; Thu, 8 Apr 2010 11:08:13 -0700 (PDT) Received: from exprod7og126.obsmtp.com (exprod7og126.obsmtp.com [64.18.2.206]) by core3.amsl.com (Postfix) with ESMTP id A9AF83A6870 for ; Thu, 8 Apr 2010 11:08:12 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob126.postini.com ([64.18.6.12]) with SMTP ID DSNKS74bhepqhl7sVcz/eJYx5iWzF2Lnx1F1@postini.com; Thu, 08 Apr 2010 11:08:10 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB01-HQ.jnpr.net ([fe80::fc92:eb1:759:2c72%11]) with mapi; Thu, 8 Apr 2010 11:05:22 -0700 From: Michael Knappe To: "stephen.botzko@gmail.com" , "Felix.Wyss@inin.com" Date: Thu, 8 Apr 2010 11:05:21 -0700 Thread-Topic: [codec] #5: Mention DTMF in requirements Thread-Index: AcrXRDosgeDodh35Tk68Uk8DEyFSuQAAdEy5 Message-ID: <05542EC42316164383B5180707A489EE1D0AA5F5B1@EMBX02-HQ.jnpr.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_05542EC42316164383B5180707A489EE1D0AA5F5B1EMBX02HQjnprn_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Apr 2010 18:08:14 -0000 --_000_05542EC42316164383B5180707A489EE1D0AA5F5B1EMBX02HQjnprn_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3RlcGhlbiwNCg0KQWdyZWVkLCBsZXQncyB0YWJsZSB0aGlzIGFuZCBtb3ZlIG9uIHRvIG90aGVy IGlzc3Vlcy4NCg0KTWlrZQ0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KRnJv bTogY29kZWMtYm91bmNlc0BpZXRmLm9yZyA8Y29kZWMtYm91bmNlc0BpZXRmLm9yZz4NClRvOiBX eXNzLCBGZWxpeCA8RmVsaXguV3lzc0BpbmluLmNvbT4NCkNjOiBjb2RlY0BpZXRmLm9yZyA8Y29k ZWNAaWV0Zi5vcmc+DQpTZW50OiBUaHUgQXByIDA4IDEzOjUxOjU2IDIwMTANClN1YmplY3Q6IFJl OiBbY29kZWNdICM1OiBNZW50aW9uIERUTUYgaW4gcmVxdWlyZW1lbnRzDQoNCk9uIHRoaXMgdGhy ZWFkIEkgc2VlIDYgcG9zdGVycyB3aG8gc2VlIGF0IGxlYXN0IGEgU0hPVUxEIHJlcXVpcmVtZW50 LCA0IHBvc3RlcnMgd2hvIHNlZSBhIE5PTiByZXF1aXJlbWVudCBhbmQgMyBwb3N0ZXJzIGZvciB3 aGljaCBJIGNhbid0IHRlbGwuDQoNClRoZXJlIHNlZW1zIHRvIGJlIGdlbmVyYWwgYWdyZWVtZW50 IHRoYXQgdGhlIHVzZSBjYXNlIGlzIHJlYWwsIHRoZSBkaXNhZ3JlZW1lbnQgaXMgd2hldGhlciBS RkMgMjgzMyBlbGltaW5hdGVzIHRoZSBuZWVkIGZvciBEVE1GIHRyYW5zcGFyZW5jeSAob3Igbm90 KS4NCg0KSSBzdWdnZXN0IGEgaHVtIGluIEp1bHkgbWlnaHQgYmUgdGhlIGJlc3Qgd2F5IHRvIHNl ZSB3aGVyZSB0aGUgY29tbXVuaXR5IGFzIGEgd2hvbGUgaXMuDQoNClN0ZXBoZW4gQm90emtvDQoN Cg0KDQpPbiBUaHUsIEFwciA4LCAyMDEwIGF0IDk6MjcgQU0sIFd5c3MsIEZlbGl4IDxGZWxpeC5X eXNzQGluaW4uY29tPG1haWx0bzpGZWxpeC5XeXNzQGluaW4uY29tPj4gd3JvdGU6DQpJIHN0aWxs IGZhaWwgdG8gc2VlIGEgcmVhc29uIHRvIGluY2x1ZGUgc3VwcG9ydCBmb3IgRFRNRiB0cmFuc3Bh cmVuY3kgYXMgYSByZXF1aXJlbWVudC4gIEl0IHNpbXBseSBkb2VzIG5vdCBzZWVtIHdvcnRoIHRo ZSBjb3N0IHRvIGV2ZW4gdGVzdCAoRFRNRikgdG9uZXMgb3RoZXIgdGhhbiB0byBlbnN1cmUgdGhl IGNvZGVjIGRvZXNuJ3QgcHJvZHVjZSBvdmVybHkgdW5wbGVhc2FudCBhdWRpbyBhcnRpZmFjdHMu DQoNCllvdXIgc3RhdGVtZW50IHRoYXQgc29tZSBQU1ROIGdhdGV3YXlzIGN1cnJlbnRseSBkb24n dCBzdXBwb3J0IFJGQyMyODMzIHNlZW1zIGltbWF0ZXJpYWwgdG8gbWUgYXMgdGhleSBhbHNvIGRv IG5vdCBzdXBwb3J0IHRoaXMgeWV0IHRvIGJlIGRlc2lnbmVkIGNvZGVjLg0KDQotLUZlbGl4DQoN Cj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogY29kZWMtYm91bmNlc0BpZXRm Lm9yZzxtYWlsdG86Y29kZWMtYm91bmNlc0BpZXRmLm9yZz4gW21haWx0bzpjb2RlYy1ib3VuY2Vz QGlldGYub3JnPG1haWx0bzpjb2RlYy1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mDQo+ IEtvZW4gVm9zDQo+IFNlbnQ6IFdlZG5lc2RheSwgQXByaWwgMDcsIDIwMTAgMTM6MjgNCj4gVG86 IGNvZGVjQGlldGYub3JnPG1haWx0bzpjb2RlY0BpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtj b2RlY10gIzU6IE1lbnRpb24gRFRNRiBpbiByZXF1aXJlbWVudHMNCj4NCj4gVGhlIGRpc3RpbmN0 aW9uIGJldHdlZW4gdXNlIGNhc2UgYW5kIHRlc3RpbmcgbWFrZXMgc2Vuc2UgdG8gbWUuDQo+DQo+ IERUTUYgaXMgYSByZWFsIHVzZSBjYXNlLiBGb3IgZXhhbXBsZSBzb21lIFBTVE4gZ2F0ZXdheXMg c3RpbGwgZG9uJ3QNCj4gc3VwcG9ydCBvdXQtb2YtYmFuZCBEVE1GLg0KPg0KPiBJdCdzIHVuY2xl YXIgd2hhdCB0byB0ZXN0IGFib3V0IERUTUYgdGhvdWdoLiBUaGUgQ29kZWMgd2lsbCBzdXBwb3J0 IGENCj4gcmFuZ2Ugb2Ygc2FtcGxlIHJhdGVzIGFuZCBiaXRyYXRlcy4gVGhlIHJlcXVpcmVtZW50 cyBzcGVjaWZ5IGNvZGluZyBvZg0KPiBtdXNpYyBhdCBuZWFyLXRyYW5zcGFyZW50IHF1YWxpdHku IEkgZG9uJ3Qgc2VlIGhvdyBhIHN1Y2ggYSBjb2RlYw0KPiBjb3VsZCBub3QgcHJvdmlkZSBzdWZm aWNpZW50IHF1YWxpdHkgZm9yIGluLWJhbmQgRFRNRi4gQXQgdGhlIHNhbWUNCj4gdGltZSwgdGhl IHJlcXVpcmVtZW50cyB0YWxrIGFib3V0IGJpdHJhdGVzIGRvd24gdG8gOCBrYnBzLCB3aGVyZSBp dA0KPiBtYXkgYmUgcXVpdGUgdHJpY2t5IHRvIGdldCBEVE1GIHRvIHdvcmsgd2VsbC4gVGhlcmVm b3JlLCBzcGVjaWZ5aW5nDQo+IHRoYXQgdGhlIGNvZGVjIFNIT1VMRCBvciBNVVNUIGVuY29kZSBE VE1GIHdpdGggc3VmZmljaWVudCBxdWFsaXR5IGlzDQo+IG1lYW5pbmdsZXNzLiBJZiBhbnl0aGlu ZywgdGhlIGJpdHJhdGUgc2V0dGluZ3MgdGhhdCBhbGxvdyBpbi1iYW5kIERUTUYNCj4gY291bGQg YmUgY2hhcmFjdGVyaXplZCBhZnRlciB0aGUgQ29kZWMgaXMgZm9ybWVkLg0KPg0KPiBOZXZlcnRo ZWxlc3MgaXQncyBnb29kIHRvIGJlIGF3YXJlIG9mIHRoZXNlIHVzZSBjYXNlcyBkdXJpbmcNCj4g ZGV2ZWxvcG1lbnQuIEZvciBpbnN0YW5jZSwgd2l0aCBTSUxLIHdlIGluY2x1ZGVkIERUTUYgc2ln bmFscyBpbiB0aGUNCj4gTFNGIHF1YW50aXplciB0cmFpbmluZyBkYXRhYmFzZS4NCj4NCj4gU2lt aWxhcmx5LCBJIHNlZSB0YW5kZW0gY29kaW5nIGFzIGEgdXNlIGNhc2UgdG8ga2VlcCBpbiBtaW5k IGR1cmluZw0KPiBkZXZlbG9wbWVudCwgYnV0IGFnYWluIGRvbid0IHNlZSBhIG5lZWQgZm9yIHRl c3Rpbmcgb3IgTVVTVC9TSE9VTEQNCj4gcmVxdWlyZW1lbnRzLg0KPg0KPiBrb2VuLg0KPg0KPg0K Pg0KPiBRdW90aW5nIHN0ZXBoZW4gYm90emtvOg0KPg0KPiA+IEkgYWdyZWUgdGhhdCB0aGVyZSBp cyBhIHByZXR0eSBzdHJvbmcgY29uc2Vuc3VzIHRoYXQgY2FycmlhZ2Ugb2YNCj4gImFuYWxvZyIN Cj4gPiBmYXggYW5kIG1vZGVtIHNpZ25hbHMgaXMgYSBub24tcmVxdWlyZW1lbnQuICBJZiBieSAi cGF5bG9hZCBzd2l0Y2hpbmciDQo+IHdlDQo+ID4gYXJlIHRhbGtpbmcgYWJvdXQgc3dpdGNoaW5n IGNvZGVjcywgdGhlbiB0aGF0IGlzIGJleW9uZCB0aGUgY2hhcnRlcg0KPiBzY29wZS4NCj4gPg0K PiA+IEkgYW0gdGhpbmtpbmcgdGhhdCB3ZSBhcmUgZ2V0dGluZyBhIGJpdCB0b28gZm9jdXNlZCBv biB0ZXN0aW5nIG1ldGhvZHMuDQo+IEluDQo+ID4gbXkgdmlldyBpdCB3b3VsZCBiZSBtb3JlIGVm ZmljaWVudCB0byBjYXB0dXJlIHVzZSBjYXNlcywgYW5kIGRlcml2ZSBNVVNUDQo+IGFuZA0KPiA+ IFNIT1VMRCByZXF1aXJlbWVudHMgZnJvbSB0aGVtIGZpcnN0LiAgVGhlbiBnbyBiYWNrIGFuZCBm aWd1cmUgb3V0IHdoYXQNCj4gd2UNCj4gPiB3aWxsIHRlc3QgYW5kIGhvdyB3ZSB3aWxsIHRlc3Qg aXQuDQo+ID4NCj4gPiBTdGVwaGVuIEJvdHprbw0KPiA+DQo+ID4NCj4gPg0KPiA+IE9uIFR1ZSwg QXByIDYsIDIwMTAgYXQgNzo0NyBBTSwgS2V2aW4gUC4gRmxlbWluZw0KPiA8a3BmbGVtaW5nQGRp Z2l1bS5jb208bWFpbHRvOmtwZmxlbWluZ0BkaWdpdW0uY29tPj53cm90ZToNCj4gPg0KPiA+PiBS YXltb25kIChKdWluLUh3ZXkpIENoZW4gd3JvdGU6DQo+ID4+DQo+ID4+ID4gMi4gRGlkIHlvdSBl dmVyIHRlc3QgeW91ciBDT0RFQyBmb3Igb3RoZXIgdGVsZXBob255IHNpZ25hbHMsIHN1Y2ggYXMN Cj4gPj4gPiAvQU5TYW0sIEFOUywgQ0VELCBhbmQgQ0kgdG9uZXM/IFRoZXNlIHRvbmVzIGFyZSBu ZWVkZWQgaW4gb3JkZXIgdG8NCj4gPj4gPiBkZXRlY3QgbW9kZW1zIGFuZCBmYXggbWFjaGluZXMg YW5kIHN3aXRjaCB0byBhbiBhcHByb3ByaWF0ZSBwYXlsb2FkLg0KPiA+PiA+IFdoYXQgYWJvdXQg cHJvZ3Jlc3MgdG9uZXM/DQo+ID4+ID4gW1JheW1vbmRdOiBObywgd2UgZGlkbid0LiAgSG93ZXZl ciwgaWYgdGhlc2UgYXJlIHNpbmdsZS1mcmVxdWVuY3kNCj4gdG9uZXMsDQo+ID4+ID4gSSB3b3Vs ZCBleHBlY3QgdGhhdCBpdCBzaG91bGQgYmUgZWFzaWVyIGZvciBhIHR5cGljYWwgY29kZWMgdG8g cGFzcw0KPiA+PiA+IHRoZXNlIHRvbmVzIHRoYW4gdG8gcGFzcyB0aGUgZHVhbC1mcmVxdWVuY3kg RFRNRiBzaWduYWxzIHdpdGhvdXQNCj4gY2F1c2luZw0KPiA+PiA+IHNpZ25pZmljYW50IGRlZ3Jh ZGF0aW9uIGluIHRoZSBzdWJzZXF1ZW50IHByb2Nlc3Npbmcgb2YgdGhlc2UgdG9uZXMuDQo+ID4+ DQo+ID4+IFRoaXMgaXMgcHJldHR5IG11Y2ggYSBkZWFkLWVuZCBiYXNlZCBvbiB0aGUgb3RoZXIg Y29tbWVudHMgb24gdGhpcw0KPiBsaXN0LA0KPiA+PiBidXQgaW4gZ2VuZXJhbCwgbm8sIG1vc3Qg b2YgdGhlc2UgdG9uZXMgYXJlICpub3QqIHNpbmdsZS1mcmVxdWVuY3kNCj4gPj4gc2ltcGxlIHRv bmVzLiBBTlNhbSwgZm9yIGV4YW1wbGUsIGlzIGEgc2luZ2xlIGZyZXF1ZW5jeSwgYnV0IGlzDQo+ ID4+IGFtcGxpdHVkZSBtb2R1bGF0ZWQuIFRoZXJlIGFyZSBhbHNvIHZhcmlhbnRzIHRoYXQgaGF2 ZSBwaGFzZSByZXZlcnNhbHMsDQo+ID4+IGFuZCB0aGVzZSBtdXN0IGJlIHByZXNlcnZlZCBmb3Ig dGhlbSB0byBiZSBkaXNjcmltaW5hdGVkIGZyb20gdGhlDQo+ID4+IG5vbi1waGFzZS1yZXZlcnNh bCB2ZXJzaW9ucy4NCj4gPj4NCj4gPj4gLS0NCj4gPj4gS2V2aW4gUC4gRmxlbWluZw0KPiA+PiBE aWdpdW0sIEluYy4gfCBEaXJlY3RvciBvZiBTb2Z0d2FyZSBUZWNobm9sb2dpZXMNCj4gPj4gNDQ1 IEphbiBEYXZpcyBEcml2ZSBOVyAtIEh1bnRzdmlsbGUsIEFMIDM1ODA2IC0gVVNBDQo+ID4+IHNr eXBlOiBrcGZsZW1pbmcgfCBqYWJiZXI6IGtmbGVtaW5nQGRpZ2l1bS5jb208bWFpbHRvOmtmbGVt aW5nQGRpZ2l1bS5jb20+DQo+ID4+IENoZWNrIHVzIG91dCBhdCB3d3cuZGlnaXVtLmNvbTxodHRw Oi8vd3d3LmRpZ2l1bS5jb20+ICYgd3d3LmFzdGVyaXNrLm9yZzxodHRwOi8vd3d3LmFzdGVyaXNr Lm9yZz4NCj4gPj4NCj4gPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gPj4gY29kZWMgbWFpbGluZyBsaXN0DQo+ID4+IGNvZGVjQGlldGYub3JnPG1h aWx0bzpjb2RlY0BpZXRmLm9yZz4NCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9jb2RlYw0KPiA+Pg0KPiA+DQo+DQo+DQo+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+IGNvZGVjIG1haWxpbmcgbGlzdA0KPiBjb2RlY0Bp ZXRmLm9yZzxtYWlsdG86Y29kZWNAaWV0Zi5vcmc+DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vY29kZWMNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KY29kZWMgbWFpbGluZyBsaXN0DQpjb2RlY0BpZXRmLm9yZzxtYWls dG86Y29kZWNAaWV0Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2NvZGVjDQoNCg== --_000_05542EC42316164383B5180707A489EE1D0AA5F5B1EMBX02HQjnprn_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PHA+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD4NClN0ZXBoZW4sPGJyPjxicj5B Z3JlZWQsIGxldCdzIHRhYmxlIHRoaXMgYW5kIG1vdmUgb24gdG8gb3RoZXIgaXNzdWVzLjxicj48 YnI+TWlrZTwvZm9udD48L3A+DQo8cD48aHIgc2l6ZT0yIHdpZHRoPSIxMDAlIiBhbGlnbj1jZW50 ZXIgdGFiaW5kZXg9LTE+DQo8Zm9udCBmYWNlPVRhaG9tYSBzaXplPTI+DQo8Yj5Gcm9tPC9iPjog Y29kZWMtYm91bmNlc0BpZXRmLm9yZyAmbHQ7Y29kZWMtYm91bmNlc0BpZXRmLm9yZyZndDsNPGJy PjxiPlRvPC9iPjogV3lzcywgRmVsaXggJmx0O0ZlbGl4Lld5c3NAaW5pbi5jb20mZ3Q7DTxicj48 Yj5DYzwvYj46IGNvZGVjQGlldGYub3JnICZsdDtjb2RlY0BpZXRmLm9yZyZndDsNPGJyPjxiPlNl bnQ8L2I+OiBUaHUgQXByIDA4IDEzOjUxOjU2IDIwMTA8YnI+PGI+U3ViamVjdDwvYj46IFJlOiBb Y29kZWNdICM1OiBNZW50aW9uIERUTUYgaW4gcmVxdWlyZW1lbnRzDTxicj48L2ZvbnQ+PC9wPg0K T24gdGhpcyB0aHJlYWQgSSBzZWUgNiBwb3N0ZXJzIHdobyBzZWUgYXQgbGVhc3QgYSBTSE9VTEQg cmVxdWlyZW1lbnQsIDQgcG9zdGVycyB3aG8gc2VlIGEgTk9OIHJlcXVpcmVtZW50IGFuZCAzIHBv c3RlcnMgZm9yIHdoaWNoIEkgY2FuJiMzOTt0IHRlbGwuPGJyPjxicj5UaGVyZSBzZWVtcyB0byBi ZSBnZW5lcmFsIGFncmVlbWVudCB0aGF0IHRoZSB1c2UgY2FzZSBpcyByZWFsLCB0aGUgZGlzYWdy ZWVtZW50IGlzIHdoZXRoZXIgUkZDIDI4MzMgZWxpbWluYXRlcyB0aGUgbmVlZCBmb3IgRFRNRiB0 cmFuc3BhcmVuY3kgKG9yIG5vdCkuPGJyPg0KPGJyPkkgc3VnZ2VzdCBhIGh1bSBpbiBKdWx5IG1p Z2h0IGJlIHRoZSBiZXN0IHdheSB0byBzZWUgd2hlcmUgdGhlIGNvbW11bml0eSBhcyBhIHdob2xl IGlzLsKgIDxicj48YnI+U3RlcGhlbiBCb3R6a288YnI+PGJyPjxicj48YnI+PGRpdiBjbGFzcz0i Z21haWxfcXVvdGUiPk9uIFRodSwgQXByIDgsIDIwMTAgYXQgOToyNyBBTSwgV3lzcywgRmVsaXgg PHNwYW4gZGlyPSJsdHIiPiZsdDs8YSBocmVmPSJtYWlsdG86RmVsaXguV3lzc0BpbmluLmNvbSI+ RmVsaXguV3lzc0BpbmluLmNvbTwvYT4mZ3Q7PC9zcGFuPiB3cm90ZTo8YnI+DQo8YmxvY2txdW90 ZSBjbGFzcz0iZ21haWxfcXVvdGUiIHN0eWxlPSJtYXJnaW46IDBwdCAwcHQgMHB0IDAuOGV4OyBi b3JkZXItbGVmdDogMXB4IHNvbGlkIHJnYigyMDQsIDIwNCwgMjA0KTsgcGFkZGluZy1sZWZ0OiAx ZXg7Ij5JIHN0aWxsIGZhaWwgdG8gc2VlIGEgcmVhc29uIHRvIGluY2x1ZGUgc3VwcG9ydCBmb3Ig RFRNRiB0cmFuc3BhcmVuY3kgYXMgYSByZXF1aXJlbWVudC4gwqBJdCBzaW1wbHkgZG9lcyBub3Qg c2VlbSB3b3J0aCB0aGUgY29zdCB0byBldmVuIHRlc3QgKERUTUYpIHRvbmVzIG90aGVyIHRoYW4g dG8gZW5zdXJlIHRoZSBjb2RlYyBkb2VzbiYjMzk7dCBwcm9kdWNlIG92ZXJseSB1bnBsZWFzYW50 IGF1ZGlvIGFydGlmYWN0cy48YnI+DQoNCjxicj4NCllvdXIgc3RhdGVtZW50IHRoYXQgc29tZSBQ U1ROIGdhdGV3YXlzIGN1cnJlbnRseSBkb24mIzM5O3Qgc3VwcG9ydCBSRkMjMjgzMyBzZWVtcyBp bW1hdGVyaWFsIHRvIG1lIGFzIHRoZXkgYWxzbyBkbyBub3Qgc3VwcG9ydCB0aGlzIHlldCB0byBi ZSBkZXNpZ25lZCBjb2RlYy48YnI+DQo8Zm9udCBjb2xvcj0iIzg4ODg4OCI+PGJyPg0KLS1GZWxp eDxicj4NCjwvZm9udD48ZGl2IGNsYXNzPSJpbSI+PGJyPg0KJmd0OyAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLTxicj4NCiZndDsgRnJvbTogPGEgaHJlZj0ibWFpbHRvOmNvZGVjLWJvdW5jZXNA aWV0Zi5vcmciPmNvZGVjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IFttYWlsdG86PGEgaHJlZj0ibWFp bHRvOmNvZGVjLWJvdW5jZXNAaWV0Zi5vcmciPmNvZGVjLWJvdW5jZXNAaWV0Zi5vcmc8L2E+XSBP biBCZWhhbGYgT2Y8YnI+DQo8L2Rpdj48ZGl2IGNsYXNzPSJpbSI+Jmd0OyBLb2VuIFZvczxicj4N CiZndDsgU2VudDogV2VkbmVzZGF5LCBBcHJpbCAwNywgMjAxMCAxMzoyODxicj4NCiZndDsgVG86 IDxhIGhyZWY9Im1haWx0bzpjb2RlY0BpZXRmLm9yZyI+Y29kZWNAaWV0Zi5vcmc8L2E+PGJyPg0K Jmd0OyBTdWJqZWN0OiBSZTogW2NvZGVjXSAjNTogTWVudGlvbiBEVE1GIGluIHJlcXVpcmVtZW50 czxicj4NCiZndDs8YnI+DQo8L2Rpdj48ZGl2PjxkaXY+PC9kaXY+PGRpdiBjbGFzcz0iaDUiPiZn dDsgVGhlIGRpc3RpbmN0aW9uIGJldHdlZW4gdXNlIGNhc2UgYW5kIHRlc3RpbmcgbWFrZXMgc2Vu c2UgdG8gbWUuPGJyPg0KJmd0Ozxicj4NCiZndDsgRFRNRiBpcyBhIHJlYWwgdXNlIGNhc2UuIEZv ciBleGFtcGxlIHNvbWUgUFNUTiBnYXRld2F5cyBzdGlsbCBkb24mIzM5O3Q8YnI+DQomZ3Q7IHN1 cHBvcnQgb3V0LW9mLWJhbmQgRFRNRi48YnI+DQomZ3Q7PGJyPg0KJmd0OyBJdCYjMzk7cyB1bmNs ZWFyIHdoYXQgdG8gdGVzdCBhYm91dCBEVE1GIHRob3VnaC4gVGhlIENvZGVjIHdpbGwgc3VwcG9y dCBhPGJyPg0KJmd0OyByYW5nZSBvZiBzYW1wbGUgcmF0ZXMgYW5kIGJpdHJhdGVzLiBUaGUgcmVx dWlyZW1lbnRzIHNwZWNpZnkgY29kaW5nIG9mPGJyPg0KJmd0OyBtdXNpYyBhdCBuZWFyLXRyYW5z cGFyZW50IHF1YWxpdHkuIEkgZG9uJiMzOTt0IHNlZSBob3cgYSBzdWNoIGEgY29kZWM8YnI+DQom Z3Q7IGNvdWxkIG5vdCBwcm92aWRlIHN1ZmZpY2llbnQgcXVhbGl0eSBmb3IgaW4tYmFuZCBEVE1G LiBBdCB0aGUgc2FtZTxicj4NCiZndDsgdGltZSwgdGhlIHJlcXVpcmVtZW50cyB0YWxrIGFib3V0 IGJpdHJhdGVzIGRvd24gdG8gOCBrYnBzLCB3aGVyZSBpdDxicj4NCiZndDsgbWF5IGJlIHF1aXRl IHRyaWNreSB0byBnZXQgRFRNRiB0byB3b3JrIHdlbGwuIFRoZXJlZm9yZSwgc3BlY2lmeWluZzxi cj4NCiZndDsgdGhhdCB0aGUgY29kZWMgU0hPVUxEIG9yIE1VU1QgZW5jb2RlIERUTUYgd2l0aCBz dWZmaWNpZW50IHF1YWxpdHkgaXM8YnI+DQomZ3Q7IG1lYW5pbmdsZXNzLiBJZiBhbnl0aGluZywg dGhlIGJpdHJhdGUgc2V0dGluZ3MgdGhhdCBhbGxvdyBpbi1iYW5kIERUTUY8YnI+DQomZ3Q7IGNv dWxkIGJlIGNoYXJhY3Rlcml6ZWQgYWZ0ZXIgdGhlIENvZGVjIGlzIGZvcm1lZC48YnI+DQomZ3Q7 PGJyPg0KJmd0OyBOZXZlcnRoZWxlc3MgaXQmIzM5O3MgZ29vZCB0byBiZSBhd2FyZSBvZiB0aGVz ZSB1c2UgY2FzZXMgZHVyaW5nPGJyPg0KJmd0OyBkZXZlbG9wbWVudC4gRm9yIGluc3RhbmNlLCB3 aXRoIFNJTEsgd2UgaW5jbHVkZWQgRFRNRiBzaWduYWxzIGluIHRoZTxicj4NCiZndDsgTFNGIHF1 YW50aXplciB0cmFpbmluZyBkYXRhYmFzZS48YnI+DQomZ3Q7PGJyPg0KJmd0OyBTaW1pbGFybHks IEkgc2VlIHRhbmRlbSBjb2RpbmcgYXMgYSB1c2UgY2FzZSB0byBrZWVwIGluIG1pbmQgZHVyaW5n PGJyPg0KJmd0OyBkZXZlbG9wbWVudCwgYnV0IGFnYWluIGRvbiYjMzk7dCBzZWUgYSBuZWVkIGZv ciB0ZXN0aW5nIG9yIE1VU1QvU0hPVUxEPGJyPg0KJmd0OyByZXF1aXJlbWVudHMuPGJyPg0KJmd0 Ozxicj4NCiZndDsga29lbi48YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 IFF1b3Rpbmcgc3RlcGhlbiBib3R6a286PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyBJIGFncmVl IHRoYXQgdGhlcmUgaXMgYSBwcmV0dHkgc3Ryb25nIGNvbnNlbnN1cyB0aGF0IGNhcnJpYWdlIG9m PGJyPg0KJmd0OyAmcXVvdDthbmFsb2cmcXVvdDs8YnI+DQomZ3Q7ICZndDsgZmF4IGFuZCBtb2Rl bSBzaWduYWxzIGlzIGEgbm9uLXJlcXVpcmVtZW50LiDCoElmIGJ5ICZxdW90O3BheWxvYWQgc3dp dGNoaW5nJnF1b3Q7PGJyPg0KJmd0OyB3ZTxicj4NCiZndDsgJmd0OyBhcmUgdGFsa2luZyBhYm91 dCBzd2l0Y2hpbmcgY29kZWNzLCB0aGVuIHRoYXQgaXMgYmV5b25kIHRoZSBjaGFydGVyPGJyPg0K Jmd0OyBzY29wZS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSSBhbSB0aGlua2luZyB0 aGF0IHdlIGFyZSBnZXR0aW5nIGEgYml0IHRvbyBmb2N1c2VkIG9uIHRlc3RpbmcgbWV0aG9kcy48 YnI+DQomZ3Q7IEluPGJyPg0KJmd0OyAmZ3Q7IG15IHZpZXcgaXQgd291bGQgYmUgbW9yZSBlZmZp Y2llbnQgdG8gY2FwdHVyZSB1c2UgY2FzZXMsIGFuZCBkZXJpdmUgTVVTVDxicj4NCiZndDsgYW5k PGJyPg0KJmd0OyAmZ3Q7IFNIT1VMRCByZXF1aXJlbWVudHMgZnJvbSB0aGVtIGZpcnN0LiDCoFRo ZW4gZ28gYmFjayBhbmQgZmlndXJlIG91dCB3aGF0PGJyPg0KJmd0OyB3ZTxicj4NCiZndDsgJmd0 OyB3aWxsIHRlc3QgYW5kIGhvdyB3ZSB3aWxsIHRlc3QgaXQuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7IFN0ZXBoZW4gQm90emtvPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE9uIFR1ZSwgQXByIDYsIDIwMTAgYXQgNzo0NyBB TSwgS2V2aW4gUC4gRmxlbWluZzxicj4NCiZndDsgJmx0OzxhIGhyZWY9Im1haWx0bzprcGZsZW1p bmdAZGlnaXVtLmNvbSI+a3BmbGVtaW5nQGRpZ2l1bS5jb208L2E+Jmd0O3dyb3RlOjxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyZndDsgUmF5bW9uZCAoSnVpbi1Id2V5KSBDaGVuIHdyb3Rl Ojxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgMi4gRGlkIHlvdSBl dmVyIHRlc3QgeW91ciBDT0RFQyBmb3Igb3RoZXIgdGVsZXBob255IHNpZ25hbHMsIHN1Y2ggYXM8 YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsgL0FOU2FtLCBBTlMsIENFRCwgYW5kIENJIHRvbmVzPyBU aGVzZSB0b25lcyBhcmUgbmVlZGVkIGluIG9yZGVyIHRvPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7 IGRldGVjdCBtb2RlbXMgYW5kIGZheCBtYWNoaW5lcyBhbmQgc3dpdGNoIHRvIGFuIGFwcHJvcHJp YXRlIHBheWxvYWQuPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IFdoYXQgYWJvdXQgcHJvZ3Jlc3Mg dG9uZXM/PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmZ3Q7IFtSYXltb25kXTogTm8sIHdlIGRpZG4mIzM5 O3QuIMKgSG93ZXZlciwgaWYgdGhlc2UgYXJlIHNpbmdsZS1mcmVxdWVuY3k8YnI+DQomZ3Q7IHRv bmVzLDxicj4NCiZndDsgJmd0OyZndDsgJmd0OyBJIHdvdWxkIGV4cGVjdCB0aGF0IGl0IHNob3Vs ZCBiZSBlYXNpZXIgZm9yIGEgdHlwaWNhbCBjb2RlYyB0byBwYXNzPGJyPg0KJmd0OyAmZ3Q7Jmd0 OyAmZ3Q7IHRoZXNlIHRvbmVzIHRoYW4gdG8gcGFzcyB0aGUgZHVhbC1mcmVxdWVuY3kgRFRNRiBz aWduYWxzIHdpdGhvdXQ8YnI+DQomZ3Q7IGNhdXNpbmc8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZndDsg c2lnbmlmaWNhbnQgZGVncmFkYXRpb24gaW4gdGhlIHN1YnNlcXVlbnQgcHJvY2Vzc2luZyBvZiB0 aGVzZSB0b25lcy48YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBUaGlzIGlz IHByZXR0eSBtdWNoIGEgZGVhZC1lbmQgYmFzZWQgb24gdGhlIG90aGVyIGNvbW1lbnRzIG9uIHRo aXM8YnI+DQomZ3Q7IGxpc3QsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBidXQgaW4gZ2VuZXJhbCwgbm8s IG1vc3Qgb2YgdGhlc2UgdG9uZXMgYXJlICpub3QqIHNpbmdsZS1mcmVxdWVuY3k8YnI+DQomZ3Q7 ICZndDsmZ3Q7IHNpbXBsZSB0b25lcy4gQU5TYW0sIGZvciBleGFtcGxlLCBpcyBhIHNpbmdsZSBm cmVxdWVuY3ksIGJ1dCBpczxicj4NCiZndDsgJmd0OyZndDsgYW1wbGl0dWRlIG1vZHVsYXRlZC4g VGhlcmUgYXJlIGFsc28gdmFyaWFudHMgdGhhdCBoYXZlIHBoYXNlIHJldmVyc2Fscyw8YnI+DQom Z3Q7ICZndDsmZ3Q7IGFuZCB0aGVzZSBtdXN0IGJlIHByZXNlcnZlZCBmb3IgdGhlbSB0byBiZSBk aXNjcmltaW5hdGVkIGZyb20gdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBub24tcGhhc2UtcmV2ZXJz YWwgdmVyc2lvbnMuPGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgLS08YnI+ DQomZ3Q7ICZndDsmZ3Q7IEtldmluIFAuIEZsZW1pbmc8YnI+DQomZ3Q7ICZndDsmZ3Q7IERpZ2l1 bSwgSW5jLiB8IERpcmVjdG9yIG9mIFNvZnR3YXJlIFRlY2hub2xvZ2llczxicj4NCiZndDsgJmd0 OyZndDsgNDQ1IEphbiBEYXZpcyBEcml2ZSBOVyAtIEh1bnRzdmlsbGUsIEFMIDM1ODA2IC0gVVNB PGJyPg0KJmd0OyAmZ3Q7Jmd0OyBza3lwZToga3BmbGVtaW5nIHwgamFiYmVyOiA8YSBocmVmPSJt YWlsdG86a2ZsZW1pbmdAZGlnaXVtLmNvbSI+a2ZsZW1pbmdAZGlnaXVtLmNvbTwvYT48YnI+DQom Z3Q7ICZndDsmZ3Q7IENoZWNrIHVzIG91dCBhdCA8YSBocmVmPSJodHRwOi8vd3d3LmRpZ2l1bS5j b20iIHRhcmdldD0iX2JsYW5rIj53d3cuZGlnaXVtLmNvbTwvYT4gJmFtcDsgPGEgaHJlZj0iaHR0 cDovL3d3dy5hc3Rlcmlzay5vcmciIHRhcmdldD0iX2JsYW5rIj53d3cuYXN0ZXJpc2sub3JnPC9h Pjxicj4NCiZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmZ3Q7IF9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyAmZ3Q7Jmd0OyBjb2RlYyBt YWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsmZ3Q7IDxhIGhyZWY9Im1haWx0bzpjb2RlY0BpZXRm Lm9yZyI+Y29kZWNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA8YSBocmVmPSJodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvZGVjIiB0YXJnZXQ9Il9ibGFuayI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb2RlYzwvYT48YnI+DQomZ3Q7 ICZndDsmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBj b2RlYyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpjb2RlY0BpZXRmLm9y ZyI+Y29kZWNAaWV0Zi5vcmc8L2E+PGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL2NvZGVjIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9jb2RlYzwvYT48YnI+DQo8YnI+DQo8YnI+DQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCmNvZGVjIG1h aWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpjb2RlY0BpZXRmLm9yZyI+Y29kZWNAaWV0 Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9jb2RlYyIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vY29kZWM8L2E+PGJyPg0KPC9kaXY+PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxi cj4NCg== --_000_05542EC42316164383B5180707A489EE1D0AA5F5B1EMBX02HQjnprn_-- From mknappe@juniper.net Fri Apr 9 06:44:40 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E3523A6808 for ; Fri, 9 Apr 2010 06:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.419 X-Spam-Level: X-Spam-Status: No, score=-5.419 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rEwsvB65-6a7 for ; Fri, 9 Apr 2010 06:44:39 -0700 (PDT) Received: from exprod7og114.obsmtp.com (exprod7og114.obsmtp.com [64.18.2.215]) by core3.amsl.com (Postfix) with ESMTP id 33D4C3A672F for ; Fri, 9 Apr 2010 06:44:39 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob114.postini.com ([64.18.6.12]) with SMTP ID DSNKS78vQqQIdTvhSp7PG17Z3Z/vpwIoXmOd@postini.com; Fri, 09 Apr 2010 06:44:36 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Fri, 9 Apr 2010 06:39:51 -0700 From: Michael Knappe To: "codec@ietf.org" Date: Fri, 9 Apr 2010 06:39:47 -0700 Thread-Topic: [codec] additional topics for discussion Thread-Index: AcrX6h6mtT3sL3z7WkuM9le+u+8/EA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [codec] additional topics for discussion X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 13:44:40 -0000 We=92ve had some good discussion around DTMF carriage and tandem/transcode = situations, let=92s continue to open up discussion to other points of inter= est. Here=92s a few that we=92ve had some initial discussion about at IETF7= 7 and/or on the mailing list: 1. sample rates: which sample rate(s) will the proposed codec support? If m= ore than one, will one of the sample rates be a MUST handled by all impleme= ntations, with the others optional dependent on the capabilities of the end= point? Will each sample rate variation of the codec be treated as a unique = codec as far as SDP negotiation is concerned? 2. joint stereo/channel coding: will joint channel coding be supported, per= haps optionally? 3. multi-channel frame ordering: what channel naming and ordering scheme wi= ll we support or specify for packing variations of multiple channels in eac= h frame? 4. packet loss concealment: will PLC be a mandatory component of the codec?= Will the codec provide an implementation of PLC, but with the hooks to all= ow different and potentially improved (or network condition specific) imple= mentations of PLC to be substituted in the codec? 5. bit-exact vs. bit-compatible: will all variations of the codec allow bit= -compatible implementation, or will we specify a bit-exact variation of the= codec (e.g. Specifying a bit-exact fixed point implementation of the lowes= t sample rate variation of the codec)? 6. reference use-cases and topologies: let=92s start putting together a doc= of use-cases and topologies that we expect the proposed codec to operate i= n. This will be useful for both determining implementation characteristics = of the codec as well as its test regimen. Any takers for kicking this off? 7. quality assessment / qualification process: we need to begin putting tog= ether a doc that details how we will assess the proposed codec, anyone inte= rested in working on this? Comments and discussion welcome! Cheers, Mike From roman@telurix.com Fri Apr 9 09:20:25 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8FB028C0E4 for ; Fri, 9 Apr 2010 09:20:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CbcsDtL7Vo0u for ; Fri, 9 Apr 2010 09:20:24 -0700 (PDT) Received: from mail-pz0-f191.google.com (mail-pz0-f191.google.com [209.85.222.191]) by core3.amsl.com (Postfix) with ESMTP id A6A5028C0FC for ; Fri, 9 Apr 2010 09:20:17 -0700 (PDT) Received: by pzk29 with SMTP id 29so2968862pzk.29 for ; Fri, 09 Apr 2010 09:19:57 -0700 (PDT) Received: by 10.114.214.26 with SMTP id m26mr425145wag.204.1270829992907; Fri, 09 Apr 2010 09:19:52 -0700 (PDT) Received: from mail-iw0-f194.google.com (mail-iw0-f194.google.com [209.85.223.194]) by mx.google.com with ESMTPS id c21sm988552ibr.10.2010.04.09.09.19.51 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 09 Apr 2010 09:19:52 -0700 (PDT) Received: by iwn32 with SMTP id 32so2173617iwn.18 for ; Fri, 09 Apr 2010 09:19:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.14.205 with HTTP; Fri, 9 Apr 2010 09:19:49 -0700 (PDT) In-Reply-To: References: Date: Fri, 9 Apr 2010 12:19:49 -0400 Received: by 10.231.59.5 with SMTP id j5mr125603ibh.6.1270829989433; Fri, 09 Apr 2010 09:19:49 -0700 (PDT) Message-ID: From: Roman Shpount To: Michael Knappe Content-Type: multipart/alternative; boundary=001485e7c9fc1715780483d02a57 Cc: "codec@ietf.org" Subject: Re: [codec] additional topics for discussion X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Apr 2010 16:20:26 -0000 --001485e7c9fc1715780483d02a57 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Couple more items I wanted to raise: 1. Should VAD and separate noise encoding be a mandatory part of this codec= ? As a conferencing server vendor I would be very interested in client doing VAD, allowing the conferencing server only to decode and mix (or just pass through without transcoding) speech audio. 2. Ability to efficiently combine pre-encoded audio into a single stream. For instance, if a server needs to play an announcement it would be nice to be able to send pre-encoded, cached audio data to the client in such a way that decoder will reset its state and decode this audio properly. Or, in case of conference server, to switch to another audio source without the need to decode and encode the audio again. _____________________________ Roman Shpount - www.telurix.com On Fri, Apr 9, 2010 at 9:39 AM, Michael Knappe wrote: > We=92ve had some good discussion around DTMF carriage and tandem/transcod= e > situations, let=92s continue to open up discussion to other points of > interest. Here=92s a few that we=92ve had some initial discussion about a= t > IETF77 and/or on the mailing list: > > 1. sample rates: which sample rate(s) will the proposed codec support? If > more than one, will one of the sample rates be a MUST handled by all > implementations, with the others optional dependent on the capabilities o= f > the endpoint? Will each sample rate variation of the codec be treated as = a > unique codec as far as SDP negotiation is concerned? > 2. joint stereo/channel coding: will joint channel coding be supported, > perhaps optionally? > 3. multi-channel frame ordering: what channel naming and ordering scheme > will we support or specify for packing variations of multiple channels in > each frame? > 4. packet loss concealment: will PLC be a mandatory component of the code= c? > Will the codec provide an implementation of PLC, but with the hooks to al= low > different and potentially improved (or network condition specific) > implementations of PLC to be substituted in the codec? > 5. bit-exact vs. bit-compatible: will all variations of the codec allow > bit-compatible implementation, or will we specify a bit-exact variation o= f > the codec (e.g. Specifying a bit-exact fixed point implementation of the > lowest sample rate variation of the codec)? > 6. reference use-cases and topologies: let=92s start putting together a d= oc > of use-cases and topologies that we expect the proposed codec to operate = in. > This will be useful for both determining implementation characteristics o= f > the codec as well as its test regimen. Any takers for kicking this off? > 7. quality assessment / qualification process: we need to begin putting > together a doc that details how we will assess the proposed codec, anyone > interested in working on this? > > Comments and discussion welcome! > > Cheers, > > Mike > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001485e7c9fc1715780483d02a57 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Couple more items I wanted to raise:

1. Should VAD and separate noi= se encoding be a mandatory part of this codec? As a conferencing server ven= dor I would be very interested in client doing VAD, allowing the conferenci= ng server only to decode and mix (or just pass through without transcoding)= speech audio.

2. Ability to efficiently combine pre-encoded audio into a single strea= m. For instance, if a server needs to play an announcement it would be nice= to be able to send pre-encoded, cached audio data to the client in such a= way that decoder will reset its state and decode this audio properly. Or, = in case of conference server, to switch to another audio source without the= need to decode and encode the audio again.
_____________________________
Roman Shpount - www.telurix.com


On Fri, Apr 9, 2010 at 9:39 AM, Michael = Knappe <mknappe= @juniper.net> wrote:
We=92ve had some good discussion around DTMF carriage and tandem/transcode = situations, let=92s continue to open up discussion to other points of inter= est. Here=92s a few that we=92ve had some initial discussion about at IETF7= 7 and/or on the mailing list:

1. sample rates: which sample rate(s) will the proposed codec support? If m= ore than one, will one of the sample rates be a MUST handled by all impleme= ntations, with the others optional dependent on the capabilities of the end= point? Will each sample rate variation of the codec be treated as a unique = codec as far as SDP negotiation is concerned?
2. joint stereo/channel coding: will joint channel coding be supported, per= haps optionally?
3. multi-channel frame ordering: what channel naming and ordering scheme wi= ll we support or specify for packing variations of multiple channels in eac= h frame?
4. packet loss concealment: will PLC be a mandatory component of the codec?= Will the codec provide an implementation of PLC, but with the hooks to all= ow different and potentially improved (or network condition specific) imple= mentations of PLC to be substituted in the codec?
5. bit-exact vs. bit-compatible: will all variations of the codec allow bit= -compatible implementation, or will we specify a bit-exact variation of the= codec (e.g. Specifying a bit-exact fixed point implementation of the lowes= t sample rate variation of the codec)?
6. reference use-cases and topologies: let=92s start putting together a doc= of use-cases and topologies that we expect the proposed codec to operate i= n. This will be useful for both determining implementation characteristics = of the codec as well as its test regimen. Any takers for kicking this off?<= br> 7. quality assessment / qualification process: we need to begin putting tog= ether a doc that details how we will assess the proposed codec, anyone inte= rested in working on this?

Comments and discussion welcome!

Cheers,

Mike
_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--001485e7c9fc1715780483d02a57-- From trac@tools.ietf.org Fri Apr 9 22:35:56 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC6783A68F1 for ; Fri, 9 Apr 2010 22:35:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.544 X-Spam-Level: X-Spam-Status: No, score=-102.544 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0qFE3BSDg++A for ; Fri, 9 Apr 2010 22:35:56 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4983A3A693F for ; Fri, 9 Apr 2010 22:35:55 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O0TMA-0001tX-8E; Fri, 09 Apr 2010 22:35:46 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de, kpfleming@digium.com X-Trac-Project: codec Date: Sat, 10 Apr 2010 05:35:46 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/5#comment:3 Message-ID: <071.f2d77220909ddf362e2feaa4d861e59f@tools.ietf.org> References: <062.e6b7c6326118bdb330a524f018229c15@tools.ietf.org> X-Trac-Ticket-ID: 5 In-Reply-To: <062.e6b7c6326118bdb330a524f018229c15@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, kpfleming@digium.com, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #5: Mention DTMF in requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 05:35:56 -0000 #5: Mention DTMF in requirements ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: task | Status: closed Priority: trivial | Milestone: Component: requirements | Version: Severity: Active WG Document | Resolution: wontfix Keywords: | ------------------------------------+--------------------------------------- Changes (by hoene@…): * priority: major => trivial * status: new => closed * resolution: => wontfix * type: defect => task Comment: On this thread I see 6 posters who see at least a SHOULD requirement, 4 posters who see a NON requirement and 3 posters for which I can't tell. There seems to be general agreement that the use case is real, the disagreement is whether RFC 2833 eliminates the need for DTMF transparency (or not). I suggest a hum in July might be the best way to see where the community as a whole is. Stephen Botzko -- Ticket URL: codec From trac@tools.ietf.org Fri Apr 9 22:39:18 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D94863A693F for ; Fri, 9 Apr 2010 22:39:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hqAifvonKMjj for ; Fri, 9 Apr 2010 22:39:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0414A3A681F for ; Fri, 9 Apr 2010 22:39:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O0TPS-0001vU-Eb; Fri, 09 Apr 2010 22:39:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 10 Apr 2010 05:39:10 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/7#comment:1 Message-ID: <071.a059ad2ce394466eab38abd0e860735d@tools.ietf.org> References: <062.fb8f4e16e52b52b754efc94871100328@tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <062.fb8f4e16e52b52b754efc94871100328@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #7: Providing DTMF Testing Tools and Samples X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 05:39:18 -0000 #7: Providing DTMF Testing Tools and Samples ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: task | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): Koen Vos: It's unclear what to test about DTMF though. The Codec will support a range of sample rates and bitrates. The requirements specify coding of music at near-transparent quality. I don't see how a such a codec could not provide sufficient quality for in-band DTMF. At the same time, the requirements talk about bitrates down to 8 kbps, where it may be quite tricky to get DTMF to work well. Therefore, specifying that the codec SHOULD or MUST encode DTMF with sufficient quality is meaningless. If anything, the bitrate settings that allow in-band DTMF could be characterized after the Codec is formed. Nevertheless it's good to be aware of these use cases during development. For instance, with SILK we included DTMF signals in the LSF quantizer training database. -- Ticket URL: codec From trac@tools.ietf.org Fri Apr 9 22:40:22 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78EAB3A681F for ; Fri, 9 Apr 2010 22:40:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VbZaglJSI7vc for ; Fri, 9 Apr 2010 22:40:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2A9943A693F for ; Fri, 9 Apr 2010 22:40:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O0TQX-0001yZ-A6; Fri, 09 Apr 2010 22:40:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 10 Apr 2010 05:40:17 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/7#comment:2 Message-ID: <071.21f3efa1f68fa97d13b4a755fc21562b@tools.ietf.org> References: <062.fb8f4e16e52b52b754efc94871100328@tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <062.fb8f4e16e52b52b754efc94871100328@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #7: Providing DTMF Testing Tools and Samples X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 05:40:22 -0000 #7: Providing DTMF Testing Tools and Samples ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: task | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): Raymond (Juin-Hwey) Chen wrote: > 2. Did you ever test your CODEC for other telephony signals, such as > /ANSam, ANS, CED, and CI tones? These tones are needed in order to > detect modems and fax machines and switch to an appropriate payload. > What about progress tones? > [Raymond]: No, we didn’t. However, if these are single-frequency > tones, I would expect that it should be easier for a typical codec to > pass these tones than to pass the dual-frequency DTMF signals without > causing significant degradation in the subsequent processing of these tones. This is pretty much a dead-end based on the other comments on this list, but in general, no, most of these tones are *not* single-frequency simple tones. ANSam, for example, is a single frequency, but is amplitude modulated. There are also variants that have phase reversals, and these must be preserved for them to be discriminated from the non-phase-reversal versions. -- Kevin P. Fleming -- Ticket URL: codec From trac@tools.ietf.org Fri Apr 9 22:40:52 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 866EF3A6969 for ; Fri, 9 Apr 2010 22:40:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.546 X-Spam-Level: X-Spam-Status: No, score=-102.546 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g9WrshBEpMdg for ; Fri, 9 Apr 2010 22:40:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3080A3A6892 for ; Fri, 9 Apr 2010 22:40:51 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O0TR1-00021M-Km; Fri, 09 Apr 2010 22:40:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 10 Apr 2010 05:40:47 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/7#comment:3 Message-ID: <071.cc5927789ef823fa149c969e4c453bae@tools.ietf.org> References: <062.fb8f4e16e52b52b754efc94871100328@tools.ietf.org> X-Trac-Ticket-ID: 7 In-Reply-To: <062.fb8f4e16e52b52b754efc94871100328@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #7: Providing DTMF Testing Tools and Samples X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 05:40:52 -0000 #7: Providing DTMF Testing Tools and Samples ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: task | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): [Raymond]: We can use real-world recorded DTMF signals if we want to, but we don’t have to. Yes, in our DTMF testing of BV16 we used a DTMF generator software to generate the waveform of 20,000 random DTMF symbols for each of 24 DTMF test conditions, for a total of nearly half a million DTMF symbols. After passing through the codec, the DTMF signals were passed through a PC executable program which simulated a DTMF decoder that was widely deployed in commercial VoIP applications. The decoded DTMF symbols were then compared with the original DTMF keys used to generate the symbols to calculate the error rates. As you can see, such a test method is purely based on software and can easily be duplicated by third parties. If the codec WG decides not to do anything with DTMF, then obviously nothing further needs to be done, but if the WG decides that the codec candidate needs to be tested for DTMF pass-through, I will try to dig up our DTMF test software package and get internal approval to donate it to IETF for this purpose. -- Ticket URL: codec From trac@tools.ietf.org Fri Apr 9 22:44:20 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02E1C3A693F for ; Fri, 9 Apr 2010 22:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmqOkTs57nYV for ; Fri, 9 Apr 2010 22:44:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 4F62C3A6892 for ; Fri, 9 Apr 2010 22:44:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O0TUE-00025B-Eu; Fri, 09 Apr 2010 22:44:06 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sat, 10 Apr 2010 05:44:06 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/1#comment:2 Message-ID: <071.a8d36bcf3f790bf78b57601e3d83536e@tools.ietf.org> References: <062.4b6a3862c443b2d8917e027f2267f4d2@tools.ietf.org> X-Trac-Ticket-ID: 1 In-Reply-To: <062.4b6a3862c443b2d8917e027f2267f4d2@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #1: Point to point calls supporting transcoding? (was: Application: 2.1. Point to point calls supporting transcoding?) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Apr 2010 05:44:20 -0000 #1: Point to point calls supporting transcoding? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: closed Priority: major | Milestone: Component: requirements | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by hoene@…): * status: new => closed * resolution: => fixed Comment: Any testing of tandem coding can only be about the audio quality. There is no binary question about whether "it works" or not, because any two codecs do indeed work together when connected through audio. I don't see a need to add tandem testing to the requirements. Quality will be high when operating towards the high end of the range in bitrates mentioned in the requirements, and tandem quality will be limited by the other codec. For lower bitrates the quality naturally goes down.. not sure what to test? koen. Problem solved: If tandem coding is a quality problem, just add bandwidth on the side of the Internet codec. CH -- Ticket URL: codec From trac@tools.ietf.org Sun Apr 11 07:54:05 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 559F63A68BD for ; Sun, 11 Apr 2010 07:54:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8DvllDftEpAI for ; Sun, 11 Apr 2010 07:54:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 77D343A687B for ; Sun, 11 Apr 2010 07:54:04 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O0yXu-00053O-MD; Sun, 11 Apr 2010 07:53:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 11 Apr 2010 14:53:58 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/8 Message-ID: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> X-Trac-Ticket-ID: 8 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 14:54:05 -0000 #8: Sample rates? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Which sample rate(s) will the proposed codec support? If more than one, will one of the sample rates be a MUST handled by all implementations, with the others optional dependent on the capabilities of the endpoint? Will each sample rate variation of the codec be treated as a unique codec as far as SDP negotiation is concerned? -- Ticket URL: codec From trac@tools.ietf.org Sun Apr 11 07:54:46 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D62CE3A68BD for ; Sun, 11 Apr 2010 07:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 87P7E7cdEJsv for ; Sun, 11 Apr 2010 07:54:46 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 254973A687B for ; Sun, 11 Apr 2010 07:54:46 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O0yYb-00054c-UI; Sun, 11 Apr 2010 07:54:41 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 11 Apr 2010 14:54:41 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/9 Message-ID: <062.883ae48af6ccd7f3e6be6d31dd956f2a@tools.ietf.org> X-Trac-Ticket-ID: 9 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #9: Joint stereo/channel coding? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 14:54:46 -0000 #9: Joint stereo/channel coding? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Will joint channel coding be supported, perhaps optionally? -- Ticket URL: codec From trac@tools.ietf.org Sun Apr 11 07:55:22 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 28DAA3A6808 for ; Sun, 11 Apr 2010 07:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQlS1IzTRpEZ for ; Sun, 11 Apr 2010 07:55:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7DBA33A67FE for ; Sun, 11 Apr 2010 07:55:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O0yZB-00057F-A7; Sun, 11 Apr 2010 07:55:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 11 Apr 2010 14:55:17 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/10 Message-ID: <062.5924fe56212099d2fdb86d57ea18cfe0@tools.ietf.org> X-Trac-Ticket-ID: 10 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #10: Multi-channel frame ordering? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 14:55:22 -0000 #10: Multi-channel frame ordering? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- What channel naming and ordering scheme will we support or specify for packing variations of multiple channels in each frame? -- Ticket URL: codec From trac@tools.ietf.org Sun Apr 11 07:55:48 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14B213A687B for ; Sun, 11 Apr 2010 07:55:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pxqiSFlZab9v for ; Sun, 11 Apr 2010 07:55:47 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 679733A67FE for ; Sun, 11 Apr 2010 07:55:47 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O0yZb-0005Aa-6k; Sun, 11 Apr 2010 07:55:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 11 Apr 2010 14:55:43 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/11 Message-ID: <062.348f1aead12a1cf82f83703f06be8fb5@tools.ietf.org> X-Trac-Ticket-ID: 11 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #11: Packet loss concealment? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 14:55:48 -0000 #11: Packet loss concealment? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Will PLC be a mandatory component of the codec? Will the codec provide an implementation of PLC, but with the hooks to allow different and potentially improved (or network condition specific) implementations of PLC to be substituted in the codec? -- Ticket URL: codec From trac@tools.ietf.org Sun Apr 11 07:56:18 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BD1553A6808 for ; Sun, 11 Apr 2010 07:56:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n5T8rk+yQHFW for ; Sun, 11 Apr 2010 07:56:18 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2B2D33A67FE for ; Sun, 11 Apr 2010 07:56:18 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O0ya5-0005BR-Ve; Sun, 11 Apr 2010 07:56:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 11 Apr 2010 14:56:13 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/12 Message-ID: <062.8c126c3a81785b4856060d1e2a0914c8@tools.ietf.org> X-Trac-Ticket-ID: 12 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #12: bit-exact vs. bit-compatible? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 14:56:18 -0000 #12: bit-exact vs. bit-compatible? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- will all variations of the codec allow bit-compatible implementation, or will we specify a bit-exact variation of the codec (e.g. Specifying a bit- exact fixed point implementation of the lowest sample rate variation of the codec)? -- Ticket URL: codec From trac@tools.ietf.org Sun Apr 11 07:57:29 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 235FC3A6808 for ; Sun, 11 Apr 2010 07:57:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TV8OwjZ39QWf for ; Sun, 11 Apr 2010 07:57:28 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 7F4F73A67FE for ; Sun, 11 Apr 2010 07:57:28 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O0ybE-0005D7-Ab; Sun, 11 Apr 2010 07:57:24 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 11 Apr 2010 14:57:24 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/13 Message-ID: <062.407382d901e5e6b8dea15d6e3ae1a2c8@tools.ietf.org> X-Trac-Ticket-ID: 13 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #13: reference use-cases and topologies! X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 14:57:29 -0000 #13: reference use-cases and topologies! ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- let’s start putting together a doc of use-cases and topologies that we expect the proposed codec to operate in. This will be useful for both determining implementation characteristics of the codec as well as its test regimen. -- Ticket URL: codec From trac@tools.ietf.org Sun Apr 11 08:05:53 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 298083A67F8 for ; Sun, 11 Apr 2010 08:05:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 519PgH4UgYi5 for ; Sun, 11 Apr 2010 08:05:52 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2F2873A676A for ; Sun, 11 Apr 2010 08:05:52 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O0yjL-0005ew-VK; Sun, 11 Apr 2010 08:05:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 11 Apr 2010 15:05:47 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/14 Message-ID: <062.0a0a8ad9a1d9d19f0f66b4858f523549@tools.ietf.org> X-Trac-Ticket-ID: 14 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #14: VAD and CNG? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 15:05:53 -0000 #14: VAD and CNG? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: major | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Should VAD and separate noise encoding be a mandatory part of this codec? As a conferencing server vendor I would be very interested in client doing VAD, allowing the conferencing server only to decode and mix (or just pass through without transcoding) speech audio. -- Ticket URL: codec From trac@tools.ietf.org Sun Apr 11 08:08:01 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1755F3A67F9 for ; Sun, 11 Apr 2010 08:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1OhRJ8omIGy for ; Sun, 11 Apr 2010 08:08:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5F40F3A676A for ; Sun, 11 Apr 2010 08:08:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O0ylQ-0005mA-6B; Sun, 11 Apr 2010 08:07:56 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Sun, 11 Apr 2010 15:07:56 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/15 Message-ID: <062.bc75a3b3c4a980df34535f87c9484935@tools.ietf.org> X-Trac-Ticket-ID: 15 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #15: Efficiently combine pre-encoded audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 15:08:01 -0000 #15: Efficiently combine pre-encoded audio ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Ability to efficiently combine pre-encoded audio into a single stream. For instance, if a server needs to play an announcement it would be nice to be able to send pre-encoded, cached audio data to the client in such a way that decoder will reset its state and decode this audio properly. Or, in case of conference server, to switch to another audio source without the need to decode and encode the audio again -- Ticket URL: codec From stephen.botzko@gmail.com Sun Apr 11 11:14:04 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7642F3A68D3 for ; Sun, 11 Apr 2010 11:14:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1sDgHSWBcgDo for ; Sun, 11 Apr 2010 11:14:03 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id D2DCF3A687E for ; Sun, 11 Apr 2010 11:14:02 -0700 (PDT) Received: by iwn27 with SMTP id 27so3934635iwn.5 for ; Sun, 11 Apr 2010 11:13:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=JgOgJpf85F9CCJ9r3FfgpNkLvimwjCfzRg2HyU+4pbA=; b=rTNqYcgHchoSQ32H0V3jqmJL7azGcaqWYXnwbbN8WUpNmXW1oqQKFEyDWnHO+gigNC 5u/lon/Rdu608OClXpiH3CTFSw0LhnPbISNVP3BnaV0CdY6WcyhaSUkO/g7zmJ73rY79 rME5cb3JsLgFOjylEYOhXYnbtQIRI6wgWcb7I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZBHZ0nmNK8KIqQmylkvIy2ztJUDpj1zgC1LYoh70tJaDVhCNFkTu/neYqDRTyYg3Ol MWImLsgLH8v8J7A1Cs19Jazi5+YPBI47fROoE609V4qNPG9aaRf9nuMtuF7rYLAy2r4K BRqsqAuSyZs6r1VsFtUoQQawl5vAPxbsoPf+A= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Sun, 11 Apr 2010 11:13:54 -0700 (PDT) In-Reply-To: <062.bc75a3b3c4a980df34535f87c9484935@tools.ietf.org> References: <062.bc75a3b3c4a980df34535f87c9484935@tools.ietf.org> Date: Sun, 11 Apr 2010 14:13:54 -0400 Received: by 10.231.60.19 with SMTP id n19mr1388887ibh.79.1271009634774; Sun, 11 Apr 2010 11:13:54 -0700 (PDT) Message-ID: From: stephen botzko To: hoene@uni-tuebingen.de Content-Type: multipart/alternative; boundary=001485e76dfec970970483f9fd69 Cc: codec@ietf.org Subject: Re: [codec] #15: Efficiently combine pre-encoded audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 18:14:04 -0000 --001485e76dfec970970483f9fd69 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable A related question is encoder-decoder synchronization time. Generally audi= o codecs are designed so that even if they start decoding with unknown state, the encoder and decoder synchronize automatically and very quickly. (Video codecs generally do not have this property BTW). Stephen Botzko On Sun, Apr 11, 2010 at 11:07 AM, codec issue tracker wrote: > #15: Efficiently combine pre-encoded audio > > ------------------------------------+------------------------------------= --- > Reporter: hoene@=85 | Owner: > Type: enhancement | Status: new > Priority: minor | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Keywords: > > ------------------------------------+------------------------------------= --- > Ability to efficiently combine pre-encoded audio into a single stream. F= or > instance, if a server needs to play an announcement it would be nice to = be > able to send pre-encoded, cached audio data to the client in such a way > that decoder will reset its state and decode this audio properly. Or, in > case of conference server, to switch to another audio source without the > need to decode and encode the audio again > > -- > Ticket URL: > codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001485e76dfec970970483f9fd69 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable A related question is encoder-decoder synchronization time.=A0 Generally au= dio codecs are designed so that even if they start decoding with unknown st= ate, the encoder and decoder synchronize automatically and very quickly.
(Video codecs generally do not have this property BTW).

Stephen = Botzko


On Sun, Apr 11, 2010 at 11:07 = AM, codec issue tracker <trac@tools.ietf.org> wrote:
#15: Efficiently = combine pre-encoded audio
------------------------------------+--------------------------------------= -
=A0Reporter: =A0hoene@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Own= er:
=A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: = =A0new
=A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:<= br> Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
=A0Severity: =A0Active WG Document =A0 =A0 =A0| =A0 =A0Keywords:
------------------------------------+--------------------------------------= -
=A0Ability to efficiently combine pre-encoded audio into a single stream. F= or
=A0instance, if a server needs to play an announcement it would be nice to = be
=A0able to send pre-encoded, cached audio data to the client in such a way<= br> =A0that decoder will reset its state and decode this audio properly. Or, in=
=A0case of conference server, to switch to another audio source without the=
=A0need to decode and encode the audio again

--
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/15>
codec <http:/= /tools.ietf.org/codec/>

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--001485e76dfec970970483f9fd69-- From stewe@stewe.org Sun Apr 11 12:04:29 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4359F3A68D6 for ; Sun, 11 Apr 2010 12:04:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.098 X-Spam-Level: X-Spam-Status: No, score=0.098 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tc7FhWQ4Wg44 for ; Sun, 11 Apr 2010 12:04:24 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id DF7CE3A6894 for ; Sun, 11 Apr 2010 12:04:23 -0700 (PDT) Received: from [192.168.1.104] (unverified [24.5.132.232]) by stewe.org (SurgeMail 3.9e) with ESMTP id 639716-1743317 for multiple; Sun, 11 Apr 2010 21:04:17 +0200 User-Agent: Microsoft-Entourage/12.24.0.100205 Date: Sun, 11 Apr 2010 12:03:56 -0700 From: Stephan Wenger To: stephen botzko Message-ID: Thread-Topic: [codec] #15: Efficiently combine pre-encoded audio Thread-Index: AcrZqbv7fGT/cWGqdkG/P650XylN+Q== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3353832256_3376303" X-Originating-IP: 24.5.132.232 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (24.5.132.232) was found in the spamhaus database. http://www.spamhaus.net Cc: codec@ietf.org Subject: Re: [codec] #15: Efficiently combine pre-encoded audio X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Apr 2010 19:04:29 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3353832256_3376303 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable True, with the notable exception of Vorbis (whose codebook concept is very similar to H.264=B9s parameter set concept, and the codebooks can be sent out-of-band=8Bthat=B9s actually recommended for many applications). See RFC 5215 how this is done. Combining vorbis streams in a box that receives codebooks via SDP in SIP-reinvite or something, and without in band codebooks, is an interesting task from a synchronization viewpoint, but not impossible. Stephan On 4.11.2010 11:13 , "stephen botzko" wrote: > A related question is encoder-decoder synchronization time.=A0 Generally au= dio > codecs are designed so that even if they start decoding with unknown stat= e, > the encoder and decoder synchronize automatically and very quickly. >=20 > (Video codecs generally do not have this property BTW). >=20 > Stephen Botzko >=20 >=20 > On Sun, Apr 11, 2010 at 11:07 AM, codec issue tracker > wrote: >> #15: Efficiently combine pre-encoded audio >> ------------------------------------+-----------------------------------= ---- >> =A0Reporter: =A0hoene@=8A =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner: >> =A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new >> =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone: >> Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version: >> =A0Severity: =A0Active WG Document =A0 =A0 =A0| =A0 =A0Keywords: >> ------------------------------------+-----------------------------------= ---- >> =A0Ability to efficiently combine pre-encoded audio into a single stream. = For >> =A0instance, if a server needs to play an announcement it would be nice to= be >> =A0able to send pre-encoded, cached audio data to the client in such a way >> =A0that decoder will reset its state and decode this audio properly. Or, i= n >> =A0case of conference server, to switch to another audio source without th= e >> =A0need to decode and encode the audio again >>=20 >> -- >> Ticket URL: >> codec >>=20 >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --B_3353832256_3376303 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] #15: Efficiently combine pre-encoded audio True, with the notable exception of Vorbis (whose codebook concept is very= similar to H.264’s parameter set concept, and the codebooks can be se= nt out-of-band—that’s actually recommended for many applications= ).  See RFC 5215 how this is done.
Combining vorbis streams in a box that receives codebooks via SDP in SIP-re= invite or something, and without in band codebooks, is an interesting task f= rom a synchronization viewpoint, but not impossible.
Stephan


On 4.11.2010 11:13 , "stephen botzko" <stephen.botzko@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>A related question is encoder-decoder synchroniz= ation time.=A0 Generally audio codecs are designed so that even if they start = decoding with unknown state, the encoder and decoder synchronize automatical= ly and very quickly.

(Video codecs generally do not have this property BTW).

Stephen Botzko


On Sun, Apr 11, 2010 at 11:07 AM, codec issue tracker <trac@tools.ietf.org> wrote:
<= SPAN STYLE=3D'font-size:11pt'>#15: Efficiently combine pre-encoded audio
------------------------------------+--------------------------------------= -
=A0Reporter: =A0hoene@… =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner:
 =A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new
=A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:
Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
=A0Severity: =A0Active WG Document =A0 =A0 =A0| =A0 =A0Keywords:
------------------------------------+--------------------------------------= -
=A0Ability to efficiently combine pre-encoded audio into a single stream. For=
=A0instance, if a server needs to play an announcement it would be nice to be=
=A0able to send pre-encoded, cached audio data to the client in such a way =A0that decoder will reset its state and decode this audio properly. Or, in =A0case of conference server, to switch to another audio source without the =A0need to decode and encode the audio again

--
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/15>
codec <http://tools.ietf.org/code= c/>

_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec


___________= ____________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec
--B_3353832256_3376303-- From trac@tools.ietf.org Mon Apr 12 15:53:57 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC9C83A68AF for ; Mon, 12 Apr 2010 15:53:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BY5tQy7o1CHD for ; Mon, 12 Apr 2010 15:53:57 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0D2E63A6868 for ; Mon, 12 Apr 2010 15:53:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O1SVr-0004cV-Oo; Mon, 12 Apr 2010 15:53:51 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: kpfleming@digium.com X-Trac-Project: codec Date: Mon, 12 Apr 2010 22:53:51 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/8#comment:1 Message-ID: <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: kpfleming@digium.com, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Apr 2010 22:53:57 -0000 #8: Sample rates? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by kpfleming@…): If our goal is to use RTP AVP/SAVP/AVPF/SAVPF profiles for transport (as seems likely), then differences in sample rates between stream offers must be listed separately in the SDP. Whether they have a different codec 'name' in the SDP or not seems less important, because the combination of the codec name and sample rate is required to uniquely identify the format in any case. Note that this is *sample rate*, and not bitstream rate. -- Ticket URL: codec From hoene@uni-tuebingen.de Mon Apr 12 22:16:27 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77CB53A68B5 for ; Mon, 12 Apr 2010 22:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.784 X-Spam-Level: X-Spam-Status: No, score=-2.784 tagged_above=-999 required=5 tests=[AWL=0.865, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EAZzBWovR22x for ; Mon, 12 Apr 2010 22:16:19 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 62DBD3A68A9 for ; Mon, 12 Apr 2010 22:16:10 -0700 (PDT) Received: from hoeneT60 ([178.2.210.31]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o3D5FukI016228 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 13 Apr 2010 07:16:02 +0200 From: "Christian Hoene" To: References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> In-Reply-To: <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> Date: Tue, 13 Apr 2010 07:15:55 +0200 Message-ID: <002a01cadac8$68dbf380$3a93da80$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-index: Acrakw+V6xvPUJfsSoq0LvVBy0a63wANC0KQ Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 05:16:27 -0000 > >#8: Sample rates? >------------------------------------+-----------------------------------= ---- > Reporter: hoene@=E2=80=A6 | Owner: > Type: enhancement | Status: new > Priority: minor | Milestone: >Component: requirements | Version: > Severity: Active WG Document | Keywords: >------------------------------------+-----------------------------------= ---- > >Comment(by kpfleming@=E2=80=A6): > > If our goal is to use RTP AVP/SAVP/AVPF/SAVPF profiles for transport = (as > seems likely), then differences in sample rates between stream offers = must > be listed separately in the SDP. Whether they have a different codec > 'name' in the SDP or not seems less important, because the combination = of > the codec name and sample rate is required to uniquely identify the = format > in any case. Note that this is *sample rate*, and not bitstream rate. No, please not. Please keep the interface to the codec as simple as = possible! =20 In addition, one must consider the following requirements: 1) First, the sample rate MUST be changed dynamically to cope with = varying transmission bandwidths. 2) Typically, sound cards do not allow changes of the sample rate on the = fly.=20 3) Thus, the codec SHOULD have an internal sampling rate conversion. I would recommend to use only one nominal sampling rate (e.g. the = sampling rate of the sound card) and let the codec do the conversion = between the actually used and predefined. It might be useful to state that it is not recommended to use 44100 Hz, = because the conversion to 16kHz and 32kHz is computational more = demanding than 48kHz and requires more power/time. With best regards, Christian From stephen.botzko@gmail.com Tue Apr 13 03:38:20 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2FBA3A6821 for ; Tue, 13 Apr 2010 03:38:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.854 X-Spam-Level: X-Spam-Status: No, score=-1.854 tagged_above=-999 required=5 tests=[AWL=-0.744, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x83iEk6zRLCn for ; Tue, 13 Apr 2010 03:38:19 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id B459E3A6A27 for ; Tue, 13 Apr 2010 03:37:55 -0700 (PDT) Received: by iwn27 with SMTP id 27so5383444iwn.5 for ; Tue, 13 Apr 2010 03:37:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=CuxeecNyoK6FssoPJ5LJvD1bl0NpaenIxEcYghP+WbI=; b=cnaQFfk+h87XD4aVAMzsbtuwn0Ujn4KA5iRdiRMdur7UMC7c1iiLn1Ic+wLQ7naBDL /XWc0NbQa11pqmYX7U0xne8YTJHk0YDIlhdHaISO/QxoV/UN/mxyVkhAaATwaLG91u3l 2U7llX91KzIYgHT19awtyV+9UiMsw25RsJZr4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Hof+XZWi3E/hddgpsAJBEGxaLA7UwemCAnYpNUMPIj3OTx4RvKsh3zeHWgOG+AzGu+ bh/bpOpX6F94S02NoutrXW5Sge5TKw7uy3XTwPctDihRzurk3KYyNJkWTh7r2DVGATUo hfX//fsxNE5qcIrnF/ubysJ35SwKAXyyNrSLI= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Tue, 13 Apr 2010 03:37:47 -0700 (PDT) In-Reply-To: <002a01cadac8$68dbf380$3a93da80$@de> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> <002a01cadac8$68dbf380$3a93da80$@de> Date: Tue, 13 Apr 2010 06:37:47 -0400 Received: by 10.231.154.77 with SMTP id n13mr2578954ibw.11.1271155067633; Tue, 13 Apr 2010 03:37:47 -0700 (PDT) Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=001636cd737f42bfd104841bda74 Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 10:38:20 -0000 --001636cd737f42bfd104841bda74 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I do not think that we should include multiple sample rates in the requirements at all. If you use *internal *sample rate conversion in the encoder and the decoder= ; then that becomes part of the compression, and is transparent to the system. There are other ways to accomplish the same end - for instance removing (not transmitting) high frequency coefficients in a transform coder, or dropping sub-bands in a filter bank. For instance, with G.722, you can omit the high frequency bits on the wire (the upper 4 bits for each 8 bit sample), and get a 32 kbs narrow band code= r "for free". If the decoder continues to run the QMF reconstriction filter with 0 coefficients, you still have a wideband 16 kHz output (with no high frequencies); if not you get a narrow band 8 kHz output. I would not call this "sample rate conversion", though it has a similar effect. Since all three methods (and possibly others) have essentially the same effect, we should not bias the selection / development process by forcing one method to be used (by explicitly stating it in the requirements). Dynamically changing sample rates on the system level adds some complexity for RTP, since the timestamp granularity is supposed to be the sample rate. BTW, dynamically changing the sample rate may be in conflict with the idea of low-complexity compressed-domain mixing (even if the conversion is done internally). Stephen Botzko On Tue, Apr 13, 2010 at 1:15 AM, Christian Hoene wr= ote: > > > >#8: Sample rates? > > >------------------------------------+-----------------------------------= ---- > > Reporter: hoene@=85 | Owner: > > Type: enhancement | Status: new > > Priority: minor | Milestone: > >Component: requirements | Version: > > Severity: Active WG Document | Keywords: > > >------------------------------------+-----------------------------------= ---- > > > >Comment(by kpfleming@=85): > > > > If our goal is to use RTP AVP/SAVP/AVPF/SAVPF profiles for transport (a= s > > seems likely), then differences in sample rates between stream offers > must > > be listed separately in the SDP. Whether they have a different codec > > 'name' in the SDP or not seems less important, because the combination = of > > the codec name and sample rate is required to uniquely identify the > format > > in any case. Note that this is *sample rate*, and not bitstream rate. > > No, please not. Please keep the interface to the codec as simple as > possible! > > In addition, one must consider the following requirements: > > 1) First, the sample rate MUST be changed dynamically to cope with varyin= g > transmission bandwidths. > 2) Typically, sound cards do not allow changes of the sample rate on the > fly. > 3) Thus, the codec SHOULD have an internal sampling rate conversion. > > I would recommend to use only one nominal sampling rate (e.g. the samplin= g > rate of the sound card) and let the codec do the conversion between the > actually used and predefined. > > It might be useful to state that it is not recommended to use 44100 Hz, > because the conversion to 16kHz and 32kHz is computational more demanding > than 48kHz and requires more power/time. > > With best regards, > > Christian > > > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636cd737f42bfd104841bda74 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I do not think that we should include multiple sample rates in the requirem= ents at all.

If you use internal sample rate conversion in th= e encoder and the decoder; then that becomes part of the compression, and i= s transparent to the system.=A0 There are other ways to accomplish the same= end - for instance removing (not transmitting) high frequency coefficients= in a transform coder, or dropping sub-bands in a filter bank.

For instance, with G.722, you can omit the high frequency bits on the w= ire (the upper 4 bits for each 8 bit sample), and get a 32 kbs narrow band = coder "for free".=A0 If the decoder continues to run the QMF reco= nstriction filter with 0 coefficients, you still have a wideband 16 kHz out= put (with no high frequencies); if not you get a narrow band 8 kHz output.= =A0 I would not call this "sample rate conversion", though it has= a similar effect.

Since all three methods (and possibly others) have essentially the same= effect, we should not bias the selection / development process by forcing = one method to be used (by explicitly stating it in the requirements).

Dynamically changing sample rates on the system level adds some complex= ity for RTP, since the timestamp granularity is supposed to be the sample r= ate.

BTW, dynamically changing the sample rate may be in conflict wi= th the idea of low-complexity compressed-domain mixing (even if the convers= ion is done internally).

Stephen Botzko




On Tue, Ap= r 13, 2010 at 1:15 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:
>
>#8: Sample rates?
>------------------------------------+----------------------------------= -----
> Reporter: =A0hoene@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 O= wner:
> =A0 =A0 Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Stat= us: =A0new
> Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone= :
>Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version: > Severity: =A0Active WG Document =A0 =A0 =A0| =A0 =A0Keywords:
>------------------------------------+----------------------------------= -----
>
>Comment(by kpfleming@=85):
>
> If our goal is to use RTP AVP/SAVP/AVPF/SAVPF profiles for transport (= as
> seems likely), then differences in sample rates between stream offers = must
> be listed separately in the SDP. Whether they have a different codec > 'name' in the SDP or not seems less important, because the com= bination of
> the codec name and sample rate is required to uniquely identify the fo= rmat
> in any case. Note that this is *sample rate*, and not bitstream rate.<= br>
No, please not. Please keep the interface to the codec as simple as p= ossible!

In addition, one must consider the following requirements:

1) First, the sample rate MUST be changed dynamically to cope with varying = transmission bandwidths.
2) Typically, sound cards do not allow changes of the sample rate on the fl= y.
3) Thus, the codec SHOULD have an internal sampling rate conversion.

I would recommend to use only one nominal sampling rate (e.g. the sampling = rate of the sound card) and let the codec do the conversion between the act= ually used and predefined.

It might be useful to state that it is not recommended to use 44100 Hz, bec= ause the conversion to 16kHz and 32kHz is computational more demanding than= 48kHz and requires more power/time.

With best regards,

=A0Christian






_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--001636cd737f42bfd104841bda74-- From kpfleming@digium.com Tue Apr 13 04:44:44 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92C5A3A68A5 for ; Tue, 13 Apr 2010 04:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.999 X-Spam-Level: X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5 tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XWStBbAzL-DW for ; Tue, 13 Apr 2010 04:44:43 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id D4A793A684C for ; Tue, 13 Apr 2010 04:41:44 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1O1eUr-0004hU-7e; Tue, 13 Apr 2010 06:41:37 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 3B1FBD8004; Tue, 13 Apr 2010 06:41:37 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qtMOV+LNv3Aw; Tue, 13 Apr 2010 06:41:36 -0500 (CDT) Received: from [172.19.1.105] (173-24-205-74.client.mchsi.com [173.24.205.74]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id 893D5D8002; Tue, 13 Apr 2010 06:41:36 -0500 (CDT) Message-ID: <4BC4586F.1010709@digium.com> Date: Tue, 13 Apr 2010 06:41:35 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: stephen botzko References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> <002a01cadac8$68dbf380$3a93da80$@de> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 11:44:44 -0000 stephen botzko wrote: > Dynamically changing sample rates on the system level adds some > complexity for RTP, since the timestamp granularity is supposed to be > the sample rate. And jitter buffers, and anything else that is based on timestamps and sample rates/counts. If the desire is for the codec to be able to change sample rates to adjust to network conditions, then I agree with Stephen... the 'external' sample rate (input to the encoder and output from the decoder) should be fixed, and this is what would be negotiated in SDP and used for RTP timestamps. The codec can downsample in the encoder and upsample in the decoder if it has decided to transmit fewer bits across the network. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From stephen.botzko@gmail.com Tue Apr 13 06:21:00 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DF9A3A69A1 for ; Tue, 13 Apr 2010 06:21:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 67ua1gvKTbhv for ; Tue, 13 Apr 2010 06:20:56 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 1C1883A692D for ; Tue, 13 Apr 2010 06:20:50 -0700 (PDT) Received: by pwj2 with SMTP id 2so5357140pwj.31 for ; Tue, 13 Apr 2010 06:20:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=BMOXQYGh/SrCZUFWIv5OVUlVHQ68jQ5c1EEXkbTbd2I=; b=STbzKnO+pwZdrDjVOMfVhQJLiqrQfoB+dsh0caCDBXSRYK2Zn+WOSkvlaKo2DSSgrB qj5NqJS46c5tWXtfGwGxQLkgFRgLbZNAzLocUXWhXhQe4LuzBZaLsU9TGrakfbtVWBSu iNfDZb4dCMxYKwJnY9wO/gnBznGFzukLePiFU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NBldxS30k/N7TC5BSERCohZpQwzWtnZZMovx/LeEbtfUFsFO+kbXy6yGfy4j4VAogk 6Q4T5aIIg1Hod3CYlkGR3E2QnqDzVADxglJeBPIkzgDZbNcg6NOoJESGU0+pMMmggtbr Jj+ey7WICp+0i+wNk8UUGTg8thnKUxI7K1jN8= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Tue, 13 Apr 2010 06:20:42 -0700 (PDT) In-Reply-To: <4BC4586F.1010709@digium.com> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> <002a01cadac8$68dbf380$3a93da80$@de> <4BC4586F.1010709@digium.com> Date: Tue, 13 Apr 2010 09:20:42 -0400 Received: by 10.141.187.12 with SMTP id o12mr5350655rvp.43.1271164842811; Tue, 13 Apr 2010 06:20:42 -0700 (PDT) Message-ID: From: stephen botzko To: "Kevin P. Fleming" Content-Type: multipart/alternative; boundary=000e0cd18222e8236104841e202c Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 13:21:00 -0000 --000e0cd18222e8236104841e202c Content-Type: text/plain; charset=ISO-8859-1 Though I generally avoid MAY, this could be a case where it makes sense. Something like: CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to optimize audio quality. This is free of any technology assumption about *how* the acoustic bandwidth is reduced. The MAY indicates that it is permissible. But if the CODEC algorithm doesn't need to reduce the acoustic bandwidth, then we are making no statement that it SHOULD (or SHOULD NOT). Kevin is distinguishing dynamic changes to the sample rate (for bandwidth management) from multiple fixed sample rates; and I agree that is a key distinction. I have not heard any clear application requirement for more than one fixed sampling rate. Though if there is such a requirement, IMHO we would have to negotiate the rate within SDP in the usual way, and it would affect the RTP timestamps, jitter buffers, etc. G.722.1 / G.722.1C is one precedent - it is the same core codec, but can run at two different sample rates (negotiated by SDP). Stephen Botzko On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming wrote: > stephen botzko wrote: > > > Dynamically changing sample rates on the system level adds some > > complexity for RTP, since the timestamp granularity is supposed to be > > the sample rate. > > And jitter buffers, and anything else that is based on timestamps and > sample rates/counts. If the desire is for the codec to be able to change > sample rates to adjust to network conditions, then I agree with > Stephen... the 'external' sample rate (input to the encoder and output > from the decoder) should be fixed, and this is what would be negotiated > in SDP and used for RTP timestamps. The codec can downsample in the > encoder and upsample in the decoder if it has decided to transmit fewer > bits across the network. > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kfleming@digium.com > Check us out at www.digium.com & www.asterisk.org > --000e0cd18222e8236104841e202c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Though I generally avoid MAY, this could be a case where it makes sense.
Something like:

CODEC MAY reduce the acoustic bandwidth at lowe= r bit rates in order to optimize audio quality.

This is free of any = technology assumption about how the acoustic bandwidth is reduced.= =A0 The MAY indicates that it is permissible.=A0 But if the CODEC algorithm= doesn't need to reduce the acoustic bandwidth, then we are making no s= tatement that it SHOULD (or SHOULD NOT).

Kevin is distinguishing dynamic changes to the sample rate (for bandwid= th management) from multiple fixed sample rates; and I agree that is a key = distinction.

I have not heard any clear application requirement for= more than one fixed sampling rate.=A0 Though if there is such a requiremen= t, IMHO we would have to negotiate the rate within SDP in the usual way, an= d it would affect the RTP timestamps, jitter buffers, etc.=A0 G.722.1 / G.7= 22.1C is one precedent - it is the same core codec, but can run at two diff= erent sample rates (negotiated by SDP).

Stephen Botzko

On Tue, Apr 13, 2010 a= t 7:41 AM, Kevin P. Fleming <kpfleming@digium.com> wrote:
stephen botzko wrote:

> Dynamically changing sample rates on the system level adds some
> complexity for RTP, since the timestamp granularity is supposed to be<= br> > the sample rate.

And jitter buffers, and anything else that is based on timestamps and=
sample rates/counts. If the desire is for the codec to be able to change sample rates to adjust to network conditions, then I agree with
Stephen... the 'external' sample rate (input to the encoder and out= put
from the decoder) should be fixed, and this is what would be negotiated
in SDP and used for RTP timestamps. The codec can downsample in the
encoder and upsample in the decoder if it has decided to transmit fewer
bits across the network.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@= digium.com
Check us out at www.dig= ium.com & www= .asterisk.org

--000e0cd18222e8236104841e202c-- From hoene@uni-tuebingen.de Tue Apr 13 07:42:48 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5015A28C1BC for ; Tue, 13 Apr 2010 07:42:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.834 X-Spam-Level: X-Spam-Status: No, score=-3.834 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djUzsCqhlFlg for ; Tue, 13 Apr 2010 07:42:46 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 764D328C22B for ; Tue, 13 Apr 2010 07:42:37 -0700 (PDT) Received: from hoeneT60 (u-173-c009.cs.uni-tuebingen.de [134.2.173.9]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o3DEgNlA002202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Apr 2010 16:42:23 +0200 From: "Christian Hoene" To: "'stephen botzko'" , "'Kevin P. Fleming'" References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> <002a01cadac8$68dbf380$3a93da80$@de> <4BC4586F.1010709@digium.com> In-Reply-To: Date: Tue, 13 Apr 2010 16:42:22 +0200 Message-ID: <001e01cadb17$886fcec0$994f6c40$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001F_01CADB28.4BF89EC0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrbDCRiS9Xxk4q3TvSgFCqadoTfqQACUYxw Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 14:42:48 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_001F_01CADB28.4BF89EC0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 It still might make sense to negotiate the maximal supported sampling = rate via SDP or, if possible, to select one out of multiple sampling rates, if the audio receiver can cope with multiple rates well. = The internal sampling frequency of the codec NEEDS NOT to be affected by the external sampling frequency. =20 However, the decoder might want to signal to the encoder that the = decoding is requiring too many computational resources and that a less complex coding mode (or a lower sampling frequency) should be = taken. =20 Christian =20 =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 From: stephen botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Tuesday, April 13, 2010 3:21 PM To: Kevin P. Fleming Cc: Christian Hoene; codec@ietf.org Subject: Re: [codec] #8: Sample rates? =20 Though I generally avoid MAY, this could be a case where it makes sense. Something like: CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to = optimize audio quality. This is free of any technology assumption about how the acoustic = bandwidth is reduced. The MAY indicates that it is permissible. But if the CODEC algorithm doesn't need to reduce the acoustic = bandwidth, then we are making no statement that it SHOULD (or SHOULD NOT). Kevin is distinguishing dynamic changes to the sample rate (for = bandwidth management) from multiple fixed sample rates; and I agree that is a key distinction.=20 I have not heard any clear application requirement for more than one = fixed sampling rate. Though if there is such a requirement, IMHO we would have to negotiate the rate within SDP in the usual way, = and it would affect the RTP timestamps, jitter buffers, etc. G.722.1 / G.722.1C is one precedent - it is the same core codec, but can = run at two different sample rates (negotiated by SDP). Stephen Botzko On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming = wrote: stephen botzko wrote: > Dynamically changing sample rates on the system level adds some > complexity for RTP, since the timestamp granularity is supposed to be > the sample rate. And jitter buffers, and anything else that is based on timestamps and sample rates/counts. If the desire is for the codec to be able to change sample rates to adjust to network conditions, then I agree with Stephen... the 'external' sample rate (input to the encoder and output from the decoder) should be fixed, and this is what would be negotiated in SDP and used for RTP timestamps. The codec can downsample in the encoder and upsample in the decoder if it has decided to transmit fewer bits across the network. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org =20 ------=_NextPart_000_001F_01CADB28.4BF89EC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

It still might = make sense to negotiate the maximal supported sampling rate via SDP or, if = possible, to select one out of multiple sampling rates, if the audio receiver can = cope with multiple rates well. The internal sampling frequency of the codec = NEEDS NOT to be affected by the external sampling = frequency.

 

However, the = decoder might want to signal to the encoder that the decoding is requiring too = many computational resources and that a less complex coding mode (or a lower sampling frequency) should be taken.

 

Christian=

 

 

---------------------------------------------------------------=

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen =

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen= .de/

 

From: stephen botzko [mailto:stephen.botzko@gmail.com] =
Sent: Tuesday, April 13, = 2010 3:21 PM
To: Kevin P. Fleming
Cc: Christian Hoene; codec@ietf.org
Subject: Re: [codec] #8: = Sample rates?

 

Though I = generally avoid MAY, this could be a case where it makes sense.

Something like:

CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to = optimize audio quality.

This is free of any technology assumption about how the acoustic bandwidth is reduced.  The MAY indicates that it is = permissible.  But if the CODEC algorithm doesn't need to reduce the acoustic bandwidth, = then we are making no statement that it SHOULD (or SHOULD NOT).

Kevin is distinguishing dynamic changes to the sample rate (for = bandwidth management) from multiple fixed sample rates; and I agree that is a key distinction.

I have not heard any clear application requirement for more than one = fixed sampling rate.  Though if there is such a requirement, IMHO we = would have to negotiate the rate within SDP in the usual way, and it would affect = the RTP timestamps, jitter buffers, etc.  G.722.1 / G.722.1C is one = precedent - it is the same core codec, but can run at two different sample rates = (negotiated by SDP).

Stephen Botzko

On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming <kpfleming@digium.com> = wrote:

stephen botzko = wrote:

> Dynamically changing sample rates on the system level adds some
> complexity for RTP, since the timestamp granularity is supposed to = be
> the sample rate.

And jitter buffers, and anything else that is based on = timestamps and
sample rates/counts. If the desire is for the codec to be able to = change
sample rates to adjust to network conditions, then I agree with
Stephen... the 'external' sample rate (input to the encoder and = output
from the decoder) should be fixed, and this is what would be = negotiated
in SDP and used for RTP timestamps. The codec can downsample in the
encoder and upsample in the decoder if it has decided to transmit = fewer
bits across the network.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.digium.com & www.asterisk.org

 

------=_NextPart_000_001F_01CADB28.4BF89EC0-- From stephen.botzko@gmail.com Tue Apr 13 07:56:14 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2F443A69FD for ; Tue, 13 Apr 2010 07:56:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.124, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YACz0azVP1Xj for ; Tue, 13 Apr 2010 07:56:13 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 40B3D3A680A for ; Tue, 13 Apr 2010 07:56:13 -0700 (PDT) Received: by iwn27 with SMTP id 27so5554353iwn.5 for ; Tue, 13 Apr 2010 07:56:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=oPj4/R+92Qm1M2+QjoimzVaSItEyOs2G4uXIlsguTLE=; b=q7mZYWdbY6Fq7b73VqqFsPkCDAqjjNdyGsBwbduwIJ8kvxUnTB2ykLrI5Z+Zr9LeCO Bkh/sJ0M1rtbsRG2IHMe9DX2QCbtNv5UWIuxYKWFQwqgly9czbBDN8yJi960CFGVCBPl ieh9QTMjId0/LX1u8qNz5HNcXMjCx5Jm/TZNI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Tydblscx724wSRF6DkP0JPzWTOh8W+Sf8bolGR92G02ZHRhPwZGwaDtE7yd6OD5msj 3Lj4rPqjhIoRFgiOoBW8s+9ZuSiD661HFUJ0G6lkOD+JPIaQA1xjhxSwe0iLBjXkDTHA O7chCYdRVjkP68X3tPT259J4bOfgLXisZ4Lcg= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Tue, 13 Apr 2010 07:56:01 -0700 (PDT) In-Reply-To: <001e01cadb17$886fcec0$994f6c40$@de> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> <002a01cadac8$68dbf380$3a93da80$@de> <4BC4586F.1010709@digium.com> <001e01cadb17$886fcec0$994f6c40$@de> Date: Tue, 13 Apr 2010 10:56:01 -0400 Received: by 10.143.85.8 with SMTP id n8mr2628230wfl.282.1271170561906; Tue, 13 Apr 2010 07:56:01 -0700 (PDT) Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=000e0cd5cdc8ca99ff04841f7588 Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 14:56:14 -0000 --000e0cd5cdc8ca99ff04841f7588 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This would make the signaling more complicated - personally I am not convinced it is worth it. I think a better avenue is to bound overall complexity, and to focus on dynamically adapting to network conditions (as opposed to dynamic complexit= y management). You can't dynamically negotiate complexity in many scenarios anyway - for instance it makes no sense if you are using multicast. Stephen Botzko On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene w= rote: > Hi, > > > > It still might make sense to negotiate the maximal supported sampling rat= e > via SDP or, if possible, to select one out of multiple sampling rates, if > the audio receiver can cope with multiple rates well. The internal sampli= ng > frequency of the codec NEEDS NOT to be affected by the external sampling > frequency. > > > > However, the decoder might want to signal to the encoder that the decodin= g > is requiring too many computational resources and that a less complex cod= ing > mode (or a lower sampling frequency) should be taken. > > > > Christian > > > > > > --------------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of T=FCbingen > > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > > > *From:* stephen botzko [mailto:stephen.botzko@gmail.com] > *Sent:* Tuesday, April 13, 2010 3:21 PM > *To:* Kevin P. Fleming > *Cc:* Christian Hoene; codec@ietf.org > *Subject:* Re: [codec] #8: Sample rates? > > > > Though I generally avoid MAY, this could be a case where it makes sense. > > Something like: > > CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to > optimize audio quality. > > This is free of any technology assumption about *how* the acoustic > bandwidth is reduced. The MAY indicates that it is permissible. But if = the > CODEC algorithm doesn't need to reduce the acoustic bandwidth, then we ar= e > making no statement that it SHOULD (or SHOULD NOT). > > Kevin is distinguishing dynamic changes to the sample rate (for bandwidth > management) from multiple fixed sample rates; and I agree that is a key > distinction. > > I have not heard any clear application requirement for more than one fixe= d > sampling rate. Though if there is such a requirement, IMHO we would have= to > negotiate the rate within SDP in the usual way, and it would affect the R= TP > timestamps, jitter buffers, etc. G.722.1 / G.722.1C is one precedent - i= t > is the same core codec, but can run at two different sample rates > (negotiated by SDP). > > Stephen Botzko > > On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming > wrote: > > stephen botzko wrote: > > > Dynamically changing sample rates on the system level adds some > > complexity for RTP, since the timestamp granularity is supposed to be > > the sample rate. > > And jitter buffers, and anything else that is based on timestamps and > sample rates/counts. If the desire is for the codec to be able to change > sample rates to adjust to network conditions, then I agree with > Stephen... the 'external' sample rate (input to the encoder and output > from the decoder) should be fixed, and this is what would be negotiated > in SDP and used for RTP timestamps. The codec can downsample in the > encoder and upsample in the decoder if it has decided to transmit fewer > bits across the network. > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kfleming@digium.com > Check us out at www.digium.com & www.asterisk.org > > > --000e0cd5cdc8ca99ff04841f7588 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable This would make the signaling more complicated - personally I am not convin= ced it is worth it.=A0

I think a better avenue is to bound overall = complexity, and to focus on dynamically adapting to network conditions (as = opposed to dynamic complexity management).

You can't dynamically negotiate complexity in many scenarios anyway= - for instance it makes no sense if you are using multicast.

Stephe= n Botzko


On Tue, Apr 13, 2010 at 10:4= 2 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:

= Hi,=

= =A0=

= It= still might make sense to negotiate the maximal supported sampling rate via SDP or, if possi= ble, to select one out of multiple sampling rates, if the audio receiver can cop= e with multiple rates well. The internal sampling frequency of the codec NEED= S NOT to be affected by the external sampling frequency.

= = =A0

= Ho= wever, the decoder might want to signal to the encoder that the decoding is requiring too many computational resources and that a less complex coding mode (or a lower sampling frequency) should be taken.

= = =A0

= Ch= ristian

= = =A0

= = =A0

---------------------------------------------------= ------------

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University= of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 = 2970532
= http://www.net.uni-tu= ebingen.de/

= = =A0

From: stephen botzko [mailto:<= a href=3D"mailto:stephen.botzko@gmail.com" target=3D"_blank">stephen.botzko= @gmail.com]
Sent: Tuesday, April 13, 2= 010 3:21 PM
To: Kevin P. Fleming
Cc: Christian Hoene; codec@ietf.org
Subject: Re: [codec] #8: S= ample rates?

=A0

Though I generally av= oid MAY, this could be a case where it makes sense.

Something like:

CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to opti= mize audio quality.

This is free of any technology assumption about how the acoustic bandwidth is reduced.=A0 The MAY indicates that it is permissible.=A0 But if the CODEC algorithm doesn't need to reduce the acoustic bandwidth, t= hen we are making no statement that it SHOULD (or SHOULD NOT).

Kevin is distinguishing dynamic changes to the sample rate (for bandwidth management) from multiple fixed sample rates; and I agree that is a key distinction.

I have not heard any clear application requirement for more than one fixed sampling rate.=A0 Though if there is such a requirement, IMHO we would have to negotiate the rate within SDP in the usual way, and it would affect the = RTP timestamps, jitter buffers, etc.=A0 G.722.1 / G.722.1C is one precedent - i= t is the same core codec, but can run at two different sample rates (negotiat= ed by SDP).

Stephen Botzko

On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming &l= t;kpfleming@digiu= m.com> wrote:

stephen botzko wrote:=

> Dynamically changing sample rates on the system level adds some
> complexity for RTP, since the timestamp granularity is supposed to be<= br> > the sample rate.

And jitter buffers, and anything else that is based = on timestamps and
sample rates/counts. If the desire is for the codec to be able to change sample rates to adjust to network conditions, then I agree with
Stephen... the 'external' sample rate (input to the encoder and out= put
from the decoder) should be fixed, and this is what would be negotiated
in SDP and used for RTP timestamps. The codec can downsample in the
encoder and upsample in the decoder if it has decided to transmit fewer
bits across the network.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.dig= ium.com & www.asterisk.or= g

=A0


--000e0cd5cdc8ca99ff04841f7588-- From hoene@uni-tuebingen.de Tue Apr 13 08:18:38 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61AC13A6B27 for ; Tue, 13 Apr 2010 08:18:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.041 X-Spam-Level: X-Spam-Status: No, score=-5.041 tagged_above=-999 required=5 tests=[AWL=1.207, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2y2AVW2Xc7Bh for ; Tue, 13 Apr 2010 08:18:34 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 381FC3A6B08 for ; Tue, 13 Apr 2010 08:18:12 -0700 (PDT) Received: from hoeneT60 (u-173-c009.cs.uni-tuebingen.de [134.2.173.9]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o3DFI4c4016148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Apr 2010 17:18:04 +0200 From: "Christian Hoene" To: "'stephen botzko'" References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> <002a01cadac8$68dbf380$3a93da80$@de> <4BC4586F.1010709@digium.com> <001e01cadb17$886fcec0$994f6c40$@de> In-Reply-To: Date: Tue, 13 Apr 2010 17:18:02 +0200 Message-ID: <003101cadb1c$828b3990$87a1acb0$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01CADB2D.46140990" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrbGXSTO9UYGSTpQPGZEetS173EYgAAYmzQ Content-Language: de X-AntiVirus-Spam-Check: failed (checked by Avira MailGate: version: 3.0.0-4; spam filter version: unknown; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.210; VDF: 7.10.6.68; host: mx05); id=19160-qzh4PO Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 15:18:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0032_01CADB2D.46140990 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 comments inline: =20 =20 From: stephen botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Tuesday, April 13, 2010 4:56 PM To: Christian Hoene Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? =20 This would make the signaling more complicated - personally I am not = convinced it is worth it. =20 CH: It is a difficult tradeoff. However, signaling overload is done in = Skype. Such as signaling might be very useful for mobile devices, which want to save power and thus lower their CPU clock. Or = wireless IP based headphones which do not have large batteries. I am thinking of signaling the states: overloaded, fine, and low. That = should be enough for most operational cases. I think a better avenue is to bound overall complexity, and to focus on = dynamically adapting to network conditions (as opposed to dynamic complexity management).=20 CH: I just like to remind that the good old TCP does support both: = congestion control to adapt to network conditions and flow control take into account an overloaded (=3Dfull) receiver. You can't dynamically negotiate complexity in many scenarios anyway - = for instance it makes no sense if you are using multicast. CH: Multicast is out of scope anyhow. We are considering an interactive = codec.=20 CH: The conferencing scenario might be some more difficult to handle but = will not a big problem. Christian Stephen Botzko On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene < = hoene@uni-tuebingen.de> wrote: Hi, =20 It still might make sense to negotiate the maximal supported sampling = rate via SDP or, if possible, to select one out of multiple sampling rates, if the audio receiver can cope with multiple rates well. = The internal sampling frequency of the codec NEEDS NOT to be affected by the external sampling frequency. =20 However, the decoder might want to signal to the encoder that the = decoding is requiring too many computational resources and that a less complex coding mode (or a lower sampling frequency) should be = taken. =20 Christian =20 =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 From: stephen botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Tuesday, April 13, 2010 3:21 PM To: Kevin P. Fleming Cc: Christian Hoene; codec@ietf.org Subject: Re: [codec] #8: Sample rates? =20 Though I generally avoid MAY, this could be a case where it makes sense. Something like: CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to = optimize audio quality. This is free of any technology assumption about how the acoustic = bandwidth is reduced. The MAY indicates that it is permissible. But if the CODEC algorithm doesn't need to reduce the acoustic = bandwidth, then we are making no statement that it SHOULD (or SHOULD NOT). Kevin is distinguishing dynamic changes to the sample rate (for = bandwidth management) from multiple fixed sample rates; and I agree that is a key distinction.=20 I have not heard any clear application requirement for more than one = fixed sampling rate. Though if there is such a requirement, IMHO we would have to negotiate the rate within SDP in the usual way, = and it would affect the RTP timestamps, jitter buffers, etc. G.722.1 / G.722.1C is one precedent - it is the same core codec, but can = run at two different sample rates (negotiated by SDP). Stephen Botzko On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming = wrote: stephen botzko wrote: > Dynamically changing sample rates on the system level adds some > complexity for RTP, since the timestamp granularity is supposed to be > the sample rate. And jitter buffers, and anything else that is based on timestamps and sample rates/counts. If the desire is for the codec to be able to change sample rates to adjust to network conditions, then I agree with Stephen... the 'external' sample rate (input to the encoder and output from the decoder) should be fixed, and this is what would be negotiated in SDP and used for RTP timestamps. The codec can downsample in the encoder and upsample in the decoder if it has decided to transmit fewer bits across the network. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org =20 =20 ------=_NextPart_000_0032_01CADB2D.46140990 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

comments inline:

 

 

From:<= font size=3D2 face=3DTahoma> = stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Tuesday, April 13, = 2010 4:56 PM
To: Christian Hoene
Cc: codec@ietf.org
Subject: Re: [codec] #8: = Sample rates?

 

This would make the signaling more complicated - personally I am = not convinced it is worth it. 

CH: It is a difficult tradeoff. However, signaling overload is done in = Skype. =A0Such as signaling might be very = useful for mobile devices, which want to save power and thus lower their CPU clock. = Or wireless IP based headphones which do not have large batteries. I am thinking of = signaling the states: overloaded, fine, and low. That should be enough for most operational cases.


I think a better avenue is to bound overall complexity, and to focus on dynamically adapting to network conditions (as opposed to dynamic = complexity management).

CH: I just like to remind that the good old TCP does support both: = congestion control to adapt to network conditions and flow control take into account an = overloaded (=3Dfull) receiver.

You can't dynamically negotiate complexity in many scenarios = anyway - for instance it makes no sense if you are using multicast.

CH: Multicast is out of scope anyhow. We are considering an interactive = codec.

CH: The conferencing scenario might be some more difficult to handle but = will not a big problem.

Christian



Stephen Botzko

On Tue, Apr 13, 2010 = at 10:42 AM, Christian Hoene <hoene@uni-tuebingen.de> = wrote:

Hi,

 

=

It still might make sense to negotiate the maximal supported sampling rate = via SDP or, if possible, to select one out of multiple sampling rates, if the = audio receiver can cope with multiple rates well. The internal sampling = frequency of the codec NEEDS NOT to be affected by the external sampling = frequency.

 

However, the decoder might want to signal to the encoder that the decoding is = requiring too many computational resources and that a less complex coding mode (or = a lower sampling frequency) should be taken.

 

Christian

 

 

-------------= --------------------------------------------------

Dr.-Ing. = Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen =

Sand 13, = 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen.de/=

 

From: stephen = botzko [mailto:stephen.botzko@gmail.com]
Sent: Tuesday, April 13, = 2010 3:21 PM
To: Kevin P. Fleming
Cc: Christian Hoene; codec@ietf.org
Subject: Re: [codec] #8: = Sample rates?

 

Though I generally avoid MAY, this could be a case where it makes sense.

Something like:

CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to = optimize audio quality.

This is free of any technology assumption about how the acoustic bandwidth is reduced.  The MAY indicates that it is = permissible.  But if the CODEC algorithm doesn't need to reduce the acoustic bandwidth, = then we are making no statement that it SHOULD (or SHOULD NOT).

Kevin is distinguishing dynamic changes to the sample rate (for = bandwidth management) from multiple fixed sample rates; and I agree that is a key distinction.

I have not heard any clear application requirement for more than one = fixed sampling rate.  Though if there is such a requirement, IMHO we = would have to negotiate the rate within SDP in the usual way, and it would affect = the RTP timestamps, jitter buffers, etc.  G.722.1 / G.722.1C is one = precedent - it is the same core codec, but can run at two different sample rates = (negotiated by SDP).

Stephen Botzko

On = Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming <kpfleming@digium.com> = wrote:

stephen botzko wrote:

> Dynamically changing sample rates on the system level adds some
> complexity for RTP, since the timestamp granularity is supposed to = be
> the sample rate.

And = jitter buffers, and anything else that is based on timestamps and
sample rates/counts. If the desire is for the codec to be able to = change
sample rates to adjust to network conditions, then I agree with
Stephen... the 'external' sample rate (input to the encoder and = output
from the decoder) should be fixed, and this is what would be = negotiated
in SDP and used for RTP timestamps. The codec can downsample in the
encoder and upsample in the decoder if it has decided to transmit = fewer
bits across the network.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.digium.com & www.asterisk.org

 

 

------=_NextPart_000_0032_01CADB2D.46140990-- From stephen.botzko@gmail.com Tue Apr 13 09:26:13 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 937273A6801 for ; Tue, 13 Apr 2010 09:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.492 X-Spam-Level: X-Spam-Status: No, score=-2.492 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Hp4xx1pvlcZ for ; Tue, 13 Apr 2010 09:26:11 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 813193A66B4 for ; Tue, 13 Apr 2010 09:26:11 -0700 (PDT) Received: by iwn27 with SMTP id 27so5662720iwn.5 for ; Tue, 13 Apr 2010 09:26:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=vEWuseePTOl1KJJlg7yBMpyekqYZumBhRPLodNE4N3Y=; b=iGJgs9ulPDMSTC7mCSvDzd9cdirDFJ7KV4QF0JjqWe7qUSUKKAL8z1LchZ95rrkNm0 FDoE4m+idSoJ8cWyvKn0Zbw56Z7c898SnTPBH/SrdctWjgCNu8Vi1/IuVCk2AVOZttvW sHpmZDiaj6lFywVHRHRCxBMO4XLIfuqsVTmGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=x8eFMpCtPIE6cJb+fcL3JMt9NAl9HVW8jzLVCOiJsLkjFZEmMAppKJ8Az+rj8SgP7X 9NxCf8ko0Itu4eiSZ/KCREXwTMXrgeguRWc3A7nX37355KmvMz29TjpuTONrX3VF48nc y0Oox4/ylZ4sAYPJbMAfWIu7/ridCRK+ac/6g= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Tue, 13 Apr 2010 09:26:02 -0700 (PDT) In-Reply-To: <003101cadb1c$828b3990$87a1acb0$@de> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> <002a01cadac8$68dbf380$3a93da80$@de> <4BC4586F.1010709@digium.com> <001e01cadb17$886fcec0$994f6c40$@de> <003101cadb1c$828b3990$87a1acb0$@de> Date: Tue, 13 Apr 2010 12:26:02 -0400 Received: by 10.231.152.79 with SMTP id f15mr1526417ibw.19.1271175962659; Tue, 13 Apr 2010 09:26:02 -0700 (PDT) Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=001636c92aa3b38f91048420b7b8 Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 16:26:13 -0000 --001636c92aa3b38f91048420b7b8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable TCP is a different case, since for this we are using RTCP to signal our feedback, and I don't think it has the facility you are envisioning. Also, I disagree with your presumption that multicast is out of scope. I don't know of any other packetization RFCs that expressly rule out multicast, and multicast can be used for interactive applications. This concept seems pretty theoretical to me. If we need to manage complexity / quality tradeoffs, why not just use profiles (as AVC/H.264 does) or create a low complexity variant (like G.729A). I really don't see the need for *dynamic* complexity management. BTW, you seem to be assuming that a lower sample rate results in significantly less complexity. The savings there might not be as great as you think, especially if the receiver needs to resample anyway (to prevent those sound card limitations you were talking about before). Stephen Botzko On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene w= rote: > Hi, > > > > comments inline: > > > > > > *From:* stephen botzko [mailto:stephen.botzko@gmail.com] > *Sent:* Tuesday, April 13, 2010 4:56 PM > *To:* Christian Hoene > *Cc:* codec@ietf.org > > *Subject:* Re: [codec] #8: Sample rates? > > > > This would make the signaling more complicated - personally I am not > convinced it is worth it. > > CH: It is a difficult tradeoff. However, signaling overload is done in > Skype. Such as signaling might be very useful for mobile devices, which > want to save power and thus lower their CPU clock. Or wireless IP based > headphones which do not have large batteries. I am thinking of signaling = the > states: overloaded, fine, and low. That should be enough for most > operational cases. > > > I think a better avenue is to bound overall complexity, and to focus on > dynamically adapting to network conditions (as opposed to dynamic complex= ity > management). > > CH: I just like to remind that the good old TCP does support both: > congestion control to adapt to network conditions and flow control take i= nto > account an overloaded (=3Dfull) receiver. > > You can't dynamically negotiate complexity in many scenarios anyway - for > instance it makes no sense if you are using multicast. > > CH: Multicast is out of scope anyhow. We are considering an interactive > codec. > > CH: The conferencing scenario might be some more difficult to handle but > will not a big problem. > > Christian > > > > Stephen Botzko > > On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene > wrote: > > Hi, > > > > It still might make sense to negotiate the maximal supported sampling rat= e > via SDP or, if possible, to select one out of multiple sampling rates, if > the audio receiver can cope with multiple rates well. The internal sampli= ng > frequency of the codec NEEDS NOT to be affected by the external sampling > frequency. > > > > However, the decoder might want to signal to the encoder that the decodin= g > is requiring too many computational resources and that a less complex cod= ing > mode (or a lower sampling frequency) should be taken. > > > > Christian > > > > > > --------------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of T=FCbingen > > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > > > *From:* stephen botzko [mailto:stephen.botzko@gmail.com] > *Sent:* Tuesday, April 13, 2010 3:21 PM > *To:* Kevin P. Fleming > *Cc:* Christian Hoene; codec@ietf.org > *Subject:* Re: [codec] #8: Sample rates? > > > > Though I generally avoid MAY, this could be a case where it makes sense. > > Something like: > > CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to > optimize audio quality. > > This is free of any technology assumption about *how* the acoustic > bandwidth is reduced. The MAY indicates that it is permissible. But if = the > CODEC algorithm doesn't need to reduce the acoustic bandwidth, then we ar= e > making no statement that it SHOULD (or SHOULD NOT). > > Kevin is distinguishing dynamic changes to the sample rate (for bandwidth > management) from multiple fixed sample rates; and I agree that is a key > distinction. > > I have not heard any clear application requirement for more than one fixe= d > sampling rate. Though if there is such a requirement, IMHO we would have= to > negotiate the rate within SDP in the usual way, and it would affect the R= TP > timestamps, jitter buffers, etc. G.722.1 / G.722.1C is one precedent - i= t > is the same core codec, but can run at two different sample rates > (negotiated by SDP). > > Stephen Botzko > > On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming > wrote: > > stephen botzko wrote: > > > Dynamically changing sample rates on the system level adds some > > complexity for RTP, since the timestamp granularity is supposed to be > > the sample rate. > > And jitter buffers, and anything else that is based on timestamps and > sample rates/counts. If the desire is for the codec to be able to change > sample rates to adjust to network conditions, then I agree with > Stephen... the 'external' sample rate (input to the encoder and output > from the decoder) should be fixed, and this is what would be negotiated > in SDP and used for RTP timestamps. The codec can downsample in the > encoder and upsample in the decoder if it has decided to transmit fewer > bits across the network. > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kfleming@digium.com > Check us out at www.digium.com & www.asterisk.org > > > > > --001636c92aa3b38f91048420b7b8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable TCP is a different case, since for this we are using RTCP to signal our fee= dback, and I don't think it has the facility you are envisioning.=A0
Also, I disagree with your presumption that multicast is out of scope= .=A0 I don't know of any other packetization RFCs that expressly rule o= ut multicast, and multicast can be used for interactive applications.

This concept seems pretty theoretical to me.=A0 If we need to manage co= mplexity / quality tradeoffs, why not just use profiles (as AVC/H.264 does)= or create a low complexity variant (like G.729A).=A0 I really don't se= e the need for dynamic complexity management.

BTW, you seem to be assuming that a lower sample rate results in=20 significantly less complexity.=A0 The savings there might not be as great= =20 as you think, especially if the receiver needs to resample anyway (to=20 prevent those sound card limitations you were talking about before).
Stephen Botzko

On Tue, Apr 13, 2010 at 1= 1:18 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:

= Hi,=

= =A0=

comments inline:

= =A0=

= = =A0

From:<= font size=3D"2" face=3D"Tahoma"> stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Tuesday, April 13, 2= 010 4:56 PM
To: Christian Hoene
Cc: codec@ietf.org


Subject: Re: [codec] #8: S= ample rates?

=A0

This would make the signaling more compli= cated - personally I am not convinced it is worth it.=A0

CH: It is a difficult tradeoff. However, signaling overload is done in Skype. <= span>=A0Such as signaling might be very useful for mobile devices, which want to save power and thus lower their CPU clock. Or= wireless IP based headphones which do not have large batteries. I am thinking of sig= naling the states: overloaded, fine, and low. That should be enough for most operational cases.


I think a better avenue is to bound overall complexity, and to focus on dynamically adapting to network conditions (as opposed to dynamic complexit= y management).

CH: I just like to remind that the good old TCP does support both: congestion c= ontrol to adapt to network conditions and flow control take into account an overlo= aded (=3Dfull) receiver.

You ca= n't dynamically negotiate complexity in many scenarios anyway - for instance it makes no sense if you are using multicast.

CH: Multicast is out of scope anyhow. We are considering an interactive codec. =

CH: The conferencing scenario might be some more difficult to handle but will n= ot a big problem.

Christian

<= /div>



Stephen Botzko

On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:

= Hi,=

= =A0=

= It still might make sense to negotiate the maximal supported sampling rate via= SDP or, if possible, to select one out of multiple sampling rates, if the audio receiver can cope with multiple rates well. The internal sampling frequency= of the codec NEEDS NOT to be affected by the external sampling frequency.

= = =A0

= Ho= wever, the decoder might want to signal to the encoder that the decoding is requir= ing too many computational resources and that a less complex coding mode (or a lower sampling frequency) should be taken.

= = =A0

= Ch= ristian

= = =A0

= = =A0

---------------------------------------------------= ------------

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
= http://www.net.uni-tuebingen.de/

= = =A0

From: stephen botzko [mailto:steph= en.botzko@gmail.com]
Sent: Tuesday, April 13, 2= 010 3:21 PM
To: Kevin P. Fleming
Cc: Christian Hoene; codec@ietf.org
Subject: Re: [codec] #8: S= ample rates?

=A0

Though I generally avoid MAY, this could be a case where it makes sense.

Something like:

CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to opti= mize audio quality.

This is free of any technology assumption about how the acoustic bandwidth is reduced.=A0 The MAY indicates that it is permissible.=A0 But if the CODEC algorithm doesn't need to reduce the acoustic bandwidth, t= hen we are making no statement that it SHOULD (or SHOULD NOT).

Kevin is distinguishing dynamic changes to the sample rate (for bandwidth management) from multiple fixed sample rates; and I agree that is a key distinction.

I have not heard any clear application requirement for more than one fixed sampling rate.=A0 Though if there is such a requirement, IMHO we would have to negotiate the rate within SDP in the usual way, and it would affect the = RTP timestamps, jitter buffers, etc.=A0 G.722.1 / G.722.1C is one precedent - i= t is the same core codec, but can run at two different sample rates (negotiat= ed by SDP).

Stephen Botzko

On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming <kpfleming@digium.com> wrote:

stephen botzko wrote:

> Dynamically changing sample rates on the system level adds some
> complexity for RTP, since the timestamp granularity is supposed to be<= br> > the sample rate.

And jitter buffers, and anything else that is based on timestamps and
sample rates/counts. If the desire is for the codec to be able to change sample rates to adjust to network conditions, then I agree with
Stephen... the 'external' sample rate (input to the encoder and out= put
from the decoder) should be fixed, and this is what would be negotiated
in SDP and used for RTP timestamps. The codec can downsample in the
encoder and upsample in the decoder if it has decided to transmit fewer
bits across the network.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.dig= ium.com & www.asterisk.or= g

=A0

=A0


--001636c92aa3b38f91048420b7b8-- From roman@telurix.com Tue Apr 13 09:42:14 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 11C393A694C for ; Tue, 13 Apr 2010 09:42:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JhSUt31jV4hA for ; Tue, 13 Apr 2010 09:42:12 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 9C8053A6A06 for ; Tue, 13 Apr 2010 09:42:09 -0700 (PDT) Received: by iwn27 with SMTP id 27so5681170iwn.5 for ; Tue, 13 Apr 2010 09:42:01 -0700 (PDT) Received: by 10.142.120.4 with SMTP id s4mr2763386wfc.108.1271176919173; Tue, 13 Apr 2010 09:41:59 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by mx.google.com with ESMTPS id 21sm5183962pzk.4.2010.04.13.09.41.57 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 13 Apr 2010 09:41:58 -0700 (PDT) Received: by pwj2 with SMTP id 2so5583762pwj.31 for ; Tue, 13 Apr 2010 09:41:57 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.14.205 with HTTP; Tue, 13 Apr 2010 09:41:57 -0700 (PDT) In-Reply-To: References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> <002a01cadac8$68dbf380$3a93da80$@de> <4BC4586F.1010709@digium.com> <001e01cadb17$886fcec0$994f6c40$@de> <003101cadb1c$828b3990$87a1acb0$@de> Date: Tue, 13 Apr 2010 12:41:57 -0400 Received: by 10.142.56.10 with SMTP id e10mr2827695wfa.156.1271176917245; Tue, 13 Apr 2010 09:41:57 -0700 (PDT) Message-ID: From: Roman Shpount To: stephen botzko Content-Type: multipart/alternative; boundary=001636e0b48399607f048420f0a4 Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 16:42:14 -0000 --001636e0b48399607f048420f0a4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not sure if this was decided, but should this new CODEC support music encoding? If we don't plan to support music, we should probably stick to 16 Khz sampling rate. If we need music, I would suggest to have a 24 Khz (or higher sampling rate) variant. I am not sure how many people here care abou= t a non-voice CODEC. For all the practical purposes I don't. I would argue, at least, for a fixed 16 KHz sampling rate CODEC variant. P.S. On the same note, does anybody here cares about using this CODEC with multicast? Is there a single commercial multicast voice deployment? From what I've seen all multicast does is making IETF voice standards harder to understand or implement. P.P.S. RTCP is almost universally not implemented. The biggest VoIP gateway on the market does not generate RTCP. If we will rely on any RTCP functionality for bandwidth control it will probably be ignored. ______________________________ Roman Shpount - www.telurix.com On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko wrote: > TCP is a different case, since for this we are using RTCP to signal our > feedback, and I don't think it has the facility you are envisioning. > > Also, I disagree with your presumption that multicast is out of scope. I > don't know of any other packetization RFCs that expressly rule out > multicast, and multicast can be used for interactive applications. > > This concept seems pretty theoretical to me. If we need to manage > complexity / quality tradeoffs, why not just use profiles (as AVC/H.264 > does) or create a low complexity variant (like G.729A). I really don't s= ee > the need for *dynamic* complexity management. > > BTW, you seem to be assuming that a lower sample rate results in > significantly less complexity. The savings there might not be as great a= s > you think, especially if the receiver needs to resample anyway (to preven= t > those sound card limitations you were talking about before). > > Stephen Botzko > > On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene wrote: > >> Hi, >> >> >> >> comments inline: >> >> >> >> >> >> *From:* stephen botzko [mailto:stephen.botzko@gmail.com] >> *Sent:* Tuesday, April 13, 2010 4:56 PM >> *To:* Christian Hoene >> *Cc:* codec@ietf.org >> >> *Subject:* Re: [codec] #8: Sample rates? >> >> >> >> This would make the signaling more complicated - personally I am not >> convinced it is worth it. >> >> CH: It is a difficult tradeoff. However, signaling overload is done in >> Skype. Such as signaling might be very useful for mobile devices, which >> want to save power and thus lower their CPU clock. Or wireless IP based >> headphones which do not have large batteries. I am thinking of signaling= the >> states: overloaded, fine, and low. That should be enough for most >> operational cases. >> >> >> I think a better avenue is to bound overall complexity, and to focus on >> dynamically adapting to network conditions (as opposed to dynamic comple= xity >> management). >> >> CH: I just like to remind that the good old TCP does support both: >> congestion control to adapt to network conditions and flow control take = into >> account an overloaded (=3Dfull) receiver. >> >> You can't dynamically negotiate complexity in many scenarios anyway - fo= r >> instance it makes no sense if you are using multicast. >> >> CH: Multicast is out of scope anyhow. We are considering an interactive >> codec. >> >> CH: The conferencing scenario might be some more difficult to handle but >> will not a big problem. >> >> Christian >> >> >> >> Stephen Botzko >> >> On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene < >> hoene@uni-tuebingen.de> wrote: >> >> Hi, >> >> >> >> It still might make sense to negotiate the maximal supported sampling ra= te >> via SDP or, if possible, to select one out of multiple sampling rates, i= f >> the audio receiver can cope with multiple rates well. The internal sampl= ing >> frequency of the codec NEEDS NOT to be affected by the external sampling >> frequency. >> >> >> >> However, the decoder might want to signal to the encoder that the decodi= ng >> is requiring too many computational resources and that a less complex co= ding >> mode (or a lower sampling frequency) should be taken. >> >> >> >> Christian >> >> >> >> >> >> --------------------------------------------------------------- >> >> Dr.-Ing. Christian Hoene >> >> Interactive Communication Systems (ICS), University of T=FCbingen >> >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >> http://www.net.uni-tuebingen.de/ >> >> >> >> *From:* stephen botzko [mailto:stephen.botzko@gmail.com] >> *Sent:* Tuesday, April 13, 2010 3:21 PM >> *To:* Kevin P. Fleming >> *Cc:* Christian Hoene; codec@ietf.org >> *Subject:* Re: [codec] #8: Sample rates? >> >> >> >> Though I generally avoid MAY, this could be a case where it makes sense. >> >> Something like: >> >> CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to >> optimize audio quality. >> >> This is free of any technology assumption about *how* the acoustic >> bandwidth is reduced. The MAY indicates that it is permissible. But if= the >> CODEC algorithm doesn't need to reduce the acoustic bandwidth, then we a= re >> making no statement that it SHOULD (or SHOULD NOT). >> >> Kevin is distinguishing dynamic changes to the sample rate (for bandwidt= h >> management) from multiple fixed sample rates; and I agree that is a key >> distinction. >> >> I have not heard any clear application requirement for more than one fix= ed >> sampling rate. Though if there is such a requirement, IMHO we would hav= e to >> negotiate the rate within SDP in the usual way, and it would affect the = RTP >> timestamps, jitter buffers, etc. G.722.1 / G.722.1C is one precedent - = it >> is the same core codec, but can run at two different sample rates >> (negotiated by SDP). >> >> Stephen Botzko >> >> On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming >> wrote: >> >> stephen botzko wrote: >> >> > Dynamically changing sample rates on the system level adds some >> > complexity for RTP, since the timestamp granularity is supposed to be >> > the sample rate. >> >> And jitter buffers, and anything else that is based on timestamps and >> sample rates/counts. If the desire is for the codec to be able to change >> sample rates to adjust to network conditions, then I agree with >> Stephen... the 'external' sample rate (input to the encoder and output >> from the decoder) should be fixed, and this is what would be negotiated >> in SDP and used for RTP timestamps. The codec can downsample in the >> encoder and upsample in the decoder if it has decided to transmit fewer >> bits across the network. >> >> -- >> Kevin P. Fleming >> Digium, Inc. | Director of Software Technologies >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >> skype: kpfleming | jabber: kfleming@digium.com >> Check us out at www.digium.com & www.asterisk.org >> >> >> >> >> > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > --001636e0b48399607f048420f0a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not sure if this was decided, but should this new CODEC support music = encoding? If we don't plan to support music, we should probably stick t= o 16 Khz sampling rate. If we need music, I would suggest to have a 24 Khz= (or higher sampling rate) variant. I am not sure how many people here care= about a non-voice CODEC. For all the practical purposes I don't. I wou= ld argue,=A0 at least, for a fixed 16 KHz sampling rate CODEC variant.

P.S. On the same note, does anybody here cares about using this CODEC w= ith multicast? Is there a single commercial multicast voice deployment? Fro= m what I've seen all multicast does is making IETF voice standards hard= er to understand or implement.

P.P.S. RTCP is almost universally not implemented. The biggest VoIP gat= eway on the market does not generate RTCP. If we will rely on any RTCP func= tionality for bandwidth control it will probably be ignored.
______________________________
Roman Shpount -=A0 www.telurix.com


On Tue, Apr 13, 2010 at 12:26 PM, stephe= n botzko <= stephen.botzko@gmail.com> wrote:
TCP is a different case, since for this we are using RTCP to signal our fee= dback, and I don't think it has the facility you are envisioning.=A0
Also, I disagree with your presumption that multicast is out of scope= .=A0 I don't know of any other packetization RFCs that expressly rule o= ut multicast, and multicast can be used for interactive applications.

This concept seems pretty theoretical to me.=A0 If we need to manage co= mplexity / quality tradeoffs, why not just use profiles (as AVC/H.264 does)= or create a low complexity variant (like G.729A).=A0 I really don't se= e the need for dynamic complexity management.

BTW, you seem to be assuming that a lower sample rate results in=20 significantly less complexity.=A0 The savings there might not be as great= =20 as you think, especially if the receiver needs to resample anyway (to=20 prevent those sound card limitations you were talking about before).
Stephen Botzko

On Tue, Apr 13, 2010 at 1= 1:18 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote= :

= Hi,=

= =A0=

comments inline:

= =A0=

= = =A0

From:<= font face=3D"Tahoma" size=3D"2"> stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Tuesday, April 13, 2= 010 4:56 PM
To: Christian Hoene
Cc: codec@ietf.org


Subject: Re: [codec] #8: S= ample rates?

=A0

This would make the signaling more compli= cated - personally I am not convinced it is worth it.=A0

CH: It is a difficult tradeoff. However, signaling overload is done in Skype. <= span>=A0Such as signaling might be very useful for mobile devices, which want to save power and thus lower their CPU clock. Or= wireless IP based headphones which do not have large batteries. I am thinking of sig= naling the states: overloaded, fine, and low. That should be enough for most operational cases.


I think a better avenue is to bound overall complexity, and to focus on dynamically adapting to network conditions (as opposed to dynamic complexit= y management).

CH: I just like to remind that the good old TCP does support both: congestion c= ontrol to adapt to network conditions and flow control take into account an overlo= aded (=3Dfull) receiver.

You ca= n't dynamically negotiate complexity in many scenarios anyway - for instance it makes no sense if you are using multicast.

CH: Multicast is out of scope anyhow. We are considering an interactive codec. =

CH: The conferencing scenario might be some more difficult to handle but will n= ot a big problem.

Christian

<= /div>



Stephen Botzko

On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:

= Hi,=

= =A0=

= It still might make sense to negotiate the maximal supported sampling rate via= SDP or, if possible, to select one out of multiple sampling rates, if the audio receiver can cope with multiple rates well. The internal sampling frequency= of the codec NEEDS NOT to be affected by the external sampling frequency.

= = =A0

= Ho= wever, the decoder might want to signal to the encoder that the decoding is requir= ing too many computational resources and that a less complex coding mode (or a lower sampling frequency) should be taken.

= = =A0

= Ch= ristian

= = =A0

= = =A0

---------------------------------------------------= ------------

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
= http://www.net.uni-tuebingen.de/

= = =A0

From: stephen botzko [mailto:steph= en.botzko@gmail.com]
Sent: Tuesday, April 13, 2= 010 3:21 PM
To: Kevin P. Fleming
Cc: Christian Hoene; codec@ietf.org
Subject: Re: [codec] #8: S= ample rates?

=A0

Though I generally avoid MAY, this could be a case where it makes sense.

Something like:

CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to opti= mize audio quality.

This is free of any technology assumption about how the acoustic bandwidth is reduced.=A0 The MAY indicates that it is permissible.=A0 But if the CODEC algorithm doesn't need to reduce the acoustic bandwidth, t= hen we are making no statement that it SHOULD (or SHOULD NOT).

Kevin is distinguishing dynamic changes to the sample rate (for bandwidth management) from multiple fixed sample rates; and I agree that is a key distinction.

I have not heard any clear application requirement for more than one fixed sampling rate.=A0 Though if there is such a requirement, IMHO we would have to negotiate the rate within SDP in the usual way, and it would affect the = RTP timestamps, jitter buffers, etc.=A0 G.722.1 / G.722.1C is one precedent - i= t is the same core codec, but can run at two different sample rates (negotiat= ed by SDP).

Stephen Botzko

On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming <kpfleming@digium.com> wrote:

stephen botzko wrote:

> Dynamically changing sample rates on the system level adds some
> complexity for RTP, since the timestamp granularity is supposed to be<= br> > the sample rate.

And jitter buffers, and anything else that is based on timestamps and
sample rates/counts. If the desire is for the codec to be able to change sample rates to adjust to network conditions, then I agree with
Stephen... the 'external' sample rate (input to the encoder and out= put
from the decoder) should be fixed, and this is what would be negotiated
in SDP and used for RTP timestamps. The codec can downsample in the
encoder and upsample in the decoder if it has decided to transmit fewer
bits across the network.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.dig= ium.com & www.asterisk.or= g

=A0

=A0



_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec


--001636e0b48399607f048420f0a4-- From petithug@acm.org Tue Apr 13 10:01:01 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E3E13A694A for ; Tue, 13 Apr 2010 10:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HcvHZxugoUjw for ; Tue, 13 Apr 2010 10:00:59 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id E58963A6A46 for ; Tue, 13 Apr 2010 10:00:50 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id E122D6C984E4; Tue, 13 Apr 2010 17:00:44 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 73AD26C984D4; Tue, 13 Apr 2010 17:00:41 +0000 (UTC) Message-ID: <4BC4A336.9080804@acm.org> Date: Tue, 13 Apr 2010 10:00:38 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100411 Iceowl/1.0b1 Icedove/3.0.4 MIME-Version: 1.0 To: Roman Shpount References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> <002a01cadac8$68dbf380$3a93da80$@de> <4BC4586F.1010709@digium.com> <001e01cadb17$886fcec0$994f6c40$@de> <003101cadb1c$828b3990$87a1acb0$@de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Cc: codec@ietf.org, stephen botzko Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 17:01:02 -0000 On 04/13/2010 09:41 AM, Roman Shpount wrote: > I am not sure if this was decided, but should this new CODEC support > music encoding? If we don't plan to support music, we should probably > stick to 16 Khz sampling rate. If we need music, I would suggest to have > a 24 Khz (or higher sampling rate) variant. I am not sure how many > people here care about a non-voice CODEC. For all the practical purposes > I don't. I do. > I would argue, at least, for a fixed 16 KHz sampling rate > CODEC variant. > > P.S. On the same note, does anybody here cares about using this CODEC > with multicast? Is there a single commercial multicast voice deployment? > From what I've seen all multicast does is making IETF voice standards > harder to understand or implement. I think that would be a mistake to ignore multicast - not because of multicast itself, but because of Xcast (RFC 5058) which is a promising technology to replace centralized conference bridges. > > P.P.S. RTCP is almost universally not implemented. The biggest VoIP > gateway on the market does not generate RTCP. If we will rely on any > RTCP functionality for bandwidth control it will probably be ignored. Why is the opinion of gateway vendors relevant for an *Internet* codec? Our (S)AVP/RTP stack, that will implement this codec as soon we have a specification, implements RTCP. > ______________________________ > Roman Shpount - www.telurix.com > > > On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko > > wrote: > > TCP is a different case, since for this we are using RTCP to signal > our feedback, and I don't think it has the facility you are > envisioning. > > Also, I disagree with your presumption that multicast is out of > scope. I don't know of any other packetization RFCs that expressly > rule out multicast, and multicast can be used for interactive > applications. > > This concept seems pretty theoretical to me. If we need to manage > complexity / quality tradeoffs, why not just use profiles (as > AVC/H.264 does) or create a low complexity variant (like G.729A). I > really don't see the need for dynamic complexity management. > > BTW, you seem to be assuming that a lower sample rate results in > significantly less complexity. The savings there might not be as > great as you think, especially if the receiver needs to resample > anyway (to prevent those sound card limitations you were talking > about before). > > Stephen Botzko > > On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene > > wrote: > > Hi, > > > > comments inline: > > > > > > * From: * stephen botzko [mailto:stephen.botzko@gmail.com > ] > *Sent:* Tuesday, April 13, 2010 4:56 PM > *To:* Christian Hoene > *Cc:* codec@ietf.org > > *Subject:* Re: [codec] #8: Sample rates? > > > > This would make the signaling more complicated - personally I am > not convinced it is worth it. > > CH: It is a difficult tradeoff. However, signaling overload is > done in Skype. Such as signaling might be very useful for > mobile devices, which want to save power and thus lower their > CPU clock. Or wireless IP based headphones which do not have > large batteries. I am thinking of signaling the states: > overloaded, fine, and low. That should be enough for most > operational cases. > > > I think a better avenue is to bound overall complexity, and to > focus on dynamically adapting to network conditions (as opposed > to dynamic complexity management). > > CH: I just like to remind that the good old TCP does support > both: congestion control to adapt to network conditions and flow > control take into account an overloaded (=full) receiver. > > You can't dynamically negotiate complexity in many scenarios > anyway - for instance it makes no sense if you are using multicast. > > CH: Multicast is out of scope anyhow. We are considering an > interactive codec. > > CH: The conferencing scenario might be some more difficult to > handle but will not a big problem. > > Christian > > > > Stephen Botzko > > On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene > > wrote: > > Hi, > > > > It still might make sense to negotiate the maximal supported > sampling rate via SDP or, if possible, to select one out of > multiple sampling rates, if the audio receiver can cope with > multiple rates well. The internal sampling frequency of the > codec NEEDS NOT to be affected by the external sampling frequency. > > > > However, the decoder might want to signal to the encoder that > the decoding is requiring too many computational resources and > that a less complex coding mode (or a lower sampling frequency) > should be taken. > > > > Christian > > > > > > --------------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of Tübingen > > Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > > > * From: * stephen botzko [mailto:stephen.botzko@gmail.com > ] > *Sent:* Tuesday, April 13, 2010 3:21 PM > *To:* Kevin P. Fleming > *Cc:* Christian Hoene; codec@ietf.org > *Subject:* Re: [codec] #8: Sample rates? > > > > Though I generally avoid MAY, this could be a case where it > makes sense. > > Something like: > > CODEC MAY reduce the acoustic bandwidth at lower bit rates in > order to optimize audio quality. > > This is free of any technology assumption about how the acoustic > bandwidth is reduced. The MAY indicates that it is > permissible. But if the CODEC algorithm doesn't need to reduce > the acoustic bandwidth, then we are making no statement that it > SHOULD (or SHOULD NOT). > > Kevin is distinguishing dynamic changes to the sample rate (for > bandwidth management) from multiple fixed sample rates; and I > agree that is a key distinction. > > I have not heard any clear application requirement for more than > one fixed sampling rate. Though if there is such a requirement, > IMHO we would have to negotiate the rate within SDP in the usual > way, and it would affect the RTP timestamps, jitter buffers, > etc. G.722.1 / G.722.1C is one precedent - it is the same core > codec, but can run at two different sample rates (negotiated by > SDP). > > Stephen Botzko > > On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming > > wrote: > > stephen botzko wrote: > > > Dynamically changing sample rates on the system level adds some > > complexity for RTP, since the timestamp granularity is supposed > to be > > the sample rate. > > And jitter buffers, and anything else that is based on > timestamps and > sample rates/counts. If the desire is for the codec to be able > to change > sample rates to adjust to network conditions, then I agree with > Stephen... the 'external' sample rate (input to the encoder and > output > from the decoder) should be fixed, and this is what would be > negotiated > in SDP and used for RTP timestamps. The codec can downsample in the > encoder and upsample in the decoder if it has decided to > transmit fewer > bits across the network. -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From petithug@acm.org Tue Apr 13 10:08:32 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F8763A6A46 for ; Tue, 13 Apr 2010 10:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.319 X-Spam-Level: X-Spam-Status: No, score=-101.319 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_72=0.6, MISSING_HEADERS=1.292, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tV-PP8pQakxG for ; Tue, 13 Apr 2010 10:08:31 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id BED3A3A6993 for ; Tue, 13 Apr 2010 10:08:30 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 561F16C984E6; Tue, 13 Apr 2010 17:08:25 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id DC0166C984DA; Tue, 13 Apr 2010 17:08:24 +0000 (UTC) Message-ID: <4BC4A507.10300@acm.org> Date: Tue, 13 Apr 2010 10:08:23 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100411 Iceowl/1.0b1 Icedove/3.0.4 MIME-Version: 1.0 References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> In-Reply-To: <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 17:08:32 -0000 On 04/12/2010 03:53 PM, codec issue tracker wrote: > #8: Sample rates? > ------------------------------------+--------------------------------------- > Reporter: hoene@… | Owner: > Type: enhancement | Status: new > Priority: minor | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Keywords: > ------------------------------------+--------------------------------------- > > Comment(by kpfleming@…): > > If our goal is to use RTP AVP/SAVP/AVPF/SAVPF profiles for transport (as > seems likely), then differences in sample rates between stream offers must > be listed separately in the SDP. Whether they have a different codec > 'name' in the SDP or not seems less important, because the combination of > the codec name and sample rate is required to uniquely identify the format > in any case. Note that this is *sample rate*, and not bitstream rate. > On the subject of multiple clock rates in RTP, please have a look to this I-D that is discussed in the AVT WG: http://tools.ietf.org/id/draft-petithuguenin-avt-multiple-clock-rates-01.txt Here's the slides used for the presentation in Anaheim: http://www.ietf.org/proceedings/10mar/slides/avt-6.pdf -- Marc Petit-Huguenin Personal email: marc@petit-huguenin.org Professional email: petithug@acm.org Blog: http://blog.marc.petit-huguenin.org From stephen.botzko@gmail.com Tue Apr 13 10:29:34 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E7143A690B for ; Tue, 13 Apr 2010 10:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.505 X-Spam-Level: X-Spam-Status: No, score=-2.505 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6wUNIPDW2xjr for ; Tue, 13 Apr 2010 10:29:32 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 54D8F3A63EB for ; Tue, 13 Apr 2010 10:29:16 -0700 (PDT) Received: by pwj2 with SMTP id 2so5634733pwj.31 for ; Tue, 13 Apr 2010 10:29:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=qJsQAdAEq0cNckXsRgLapiEp4ybT7WfvkShdpZYlXUY=; b=gO0sVELj7b7Ij6hv5Pb8/fd0/pUPOR8DfgSSMW7omQZO03oIcOwkHldeqLmw9ng0Z2 bhncn5vpmE9uPZEnDzPZm80SIueyW46yjPaN/Mba+SeLeFH1tc2jQbth0L66cYFdS7V8 drILIenEGKgdmDu54aKk7l/8R5x7ouE0DgSIo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=tPzOKIa3ZDS67ltu6sOnPDSs0lh2lW8XEv21+SUO0taaAtpER1NbQjwwweqZBBIdJC qds7M6dd3YpBCOBvDrs84ixUU3fxqAr+ZTaBnfPaYNKVkpdccgZYum70jzHxUJfnrJSV qbULoWLBnOxqWH6g5G7xU5g7d+N9V5cU08sxc= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Tue, 13 Apr 2010 10:29:05 -0700 (PDT) In-Reply-To: References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <002a01cadac8$68dbf380$3a93da80$@de> <4BC4586F.1010709@digium.com> <001e01cadb17$886fcec0$994f6c40$@de> <003101cadb1c$828b3990$87a1acb0$@de> Date: Tue, 13 Apr 2010 13:29:05 -0400 Received: by 10.141.91.16 with SMTP id t16mr5910013rvl.128.1271179746108; Tue, 13 Apr 2010 10:29:06 -0700 (PDT) Message-ID: From: stephen botzko To: Roman Shpount Content-Type: multipart/alternative; boundary=000e0cd1123c366a6e04842199ef Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 17:29:34 -0000 --000e0cd1123c366a6e04842199ef Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Superwideband (and even fullband) do make speech somewhat more intelligible= , and also reduce listener fatigue. Telepresence and other videoconferencing equipment use those acoustic bandwidths today, so it would be nice if CODEC supported at least superwideband also. Personally I see some value in carriage of music. Sometimes our equipment is used for music performance. Distance learning is another use case where music has some value, since course and training materials frequently do include videos with music. Though of course conversational speech is the dominant use case. BTW, Videoconferencing devices do almost always support RTCP. It is regrettable that so many VOIP devices do not. Anyway, I do not think our charter scope includes invention of a new mechanism for signaling the network quality. Stephen Botzko On Tue, Apr 13, 2010 at 12:41 PM, Roman Shpount wrote: > I am not sure if this was decided, but should this new CODEC support musi= c > encoding? If we don't plan to support music, we should probably stick to = 16 > Khz sampling rate. If we need music, I would suggest to have a 24 Khz (or > higher sampling rate) variant. I am not sure how many people here care ab= out > a non-voice CODEC. For all the practical purposes I don't. I would argue, > at least, for a fixed 16 KHz sampling rate CODEC variant. > > P.S. On the same note, does anybody here cares about using this CODEC wit= h > multicast? Is there a single commercial multicast voice deployment? From > what I've seen all multicast does is making IETF voice standards harder t= o > understand or implement. > > P.P.S. RTCP is almost universally not implemented. The biggest VoIP gatew= ay > on the market does not generate RTCP. If we will rely on any RTCP > functionality for bandwidth control it will probably be ignored. > ______________________________ > Roman Shpount - www.telurix.com > > > On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko > wrote: > >> TCP is a different case, since for this we are using RTCP to signal our >> feedback, and I don't think it has the facility you are envisioning. >> >> Also, I disagree with your presumption that multicast is out of scope. = I >> don't know of any other packetization RFCs that expressly rule out >> multicast, and multicast can be used for interactive applications. >> >> This concept seems pretty theoretical to me. If we need to manage >> complexity / quality tradeoffs, why not just use profiles (as AVC/H.264 >> does) or create a low complexity variant (like G.729A). I really don't = see >> the need for *dynamic* complexity management. >> >> BTW, you seem to be assuming that a lower sample rate results in >> significantly less complexity. The savings there might not be as great = as >> you think, especially if the receiver needs to resample anyway (to preve= nt >> those sound card limitations you were talking about before). >> >> Stephen Botzko >> >> On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene > > wrote: >> >>> Hi, >>> >>> >>> >>> comments inline: >>> >>> >>> >>> >>> >>> *From:* stephen botzko [mailto:stephen.botzko@gmail.com] >>> *Sent:* Tuesday, April 13, 2010 4:56 PM >>> *To:* Christian Hoene >>> *Cc:* codec@ietf.org >>> >>> *Subject:* Re: [codec] #8: Sample rates? >>> >>> >>> >>> This would make the signaling more complicated - personally I am not >>> convinced it is worth it. >>> >>> CH: It is a difficult tradeoff. However, signaling overload is done in >>> Skype. Such as signaling might be very useful for mobile devices, whic= h >>> want to save power and thus lower their CPU clock. Or wireless IP based >>> headphones which do not have large batteries. I am thinking of signalin= g the >>> states: overloaded, fine, and low. That should be enough for most >>> operational cases. >>> >>> >>> I think a better avenue is to bound overall complexity, and to focus on >>> dynamically adapting to network conditions (as opposed to dynamic compl= exity >>> management). >>> >>> CH: I just like to remind that the good old TCP does support both: >>> congestion control to adapt to network conditions and flow control take= into >>> account an overloaded (=3Dfull) receiver. >>> >>> You can't dynamically negotiate complexity in many scenarios anyway - f= or >>> instance it makes no sense if you are using multicast. >>> >>> CH: Multicast is out of scope anyhow. We are considering an interactive >>> codec. >>> >>> CH: The conferencing scenario might be some more difficult to handle bu= t >>> will not a big problem. >>> >>> Christian >>> >>> >>> >>> Stephen Botzko >>> >>> On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene < >>> hoene@uni-tuebingen.de> wrote: >>> >>> Hi, >>> >>> >>> >>> It still might make sense to negotiate the maximal supported sampling >>> rate via SDP or, if possible, to select one out of multiple sampling ra= tes, >>> if the audio receiver can cope with multiple rates well. The internal >>> sampling frequency of the codec NEEDS NOT to be affected by the externa= l >>> sampling frequency. >>> >>> >>> >>> However, the decoder might want to signal to the encoder that the >>> decoding is requiring too many computational resources and that a less >>> complex coding mode (or a lower sampling frequency) should be taken. >>> >>> >>> >>> Christian >>> >>> >>> >>> >>> >>> --------------------------------------------------------------- >>> >>> Dr.-Ing. Christian Hoene >>> >>> Interactive Communication Systems (ICS), University of T=FCbingen >>> >>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >>> http://www.net.uni-tuebingen.de/ >>> >>> >>> >>> *From:* stephen botzko [mailto:stephen.botzko@gmail.com] >>> *Sent:* Tuesday, April 13, 2010 3:21 PM >>> *To:* Kevin P. Fleming >>> *Cc:* Christian Hoene; codec@ietf.org >>> *Subject:* Re: [codec] #8: Sample rates? >>> >>> >>> >>> Though I generally avoid MAY, this could be a case where it makes sense= . >>> >>> Something like: >>> >>> CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to >>> optimize audio quality. >>> >>> This is free of any technology assumption about *how* the acoustic >>> bandwidth is reduced. The MAY indicates that it is permissible. But i= f the >>> CODEC algorithm doesn't need to reduce the acoustic bandwidth, then we = are >>> making no statement that it SHOULD (or SHOULD NOT). >>> >>> Kevin is distinguishing dynamic changes to the sample rate (for bandwid= th >>> management) from multiple fixed sample rates; and I agree that is a key >>> distinction. >>> >>> I have not heard any clear application requirement for more than one >>> fixed sampling rate. Though if there is such a requirement, IMHO we wo= uld >>> have to negotiate the rate within SDP in the usual way, and it would af= fect >>> the RTP timestamps, jitter buffers, etc. G.722.1 / G.722.1C is one >>> precedent - it is the same core codec, but can run at two different sam= ple >>> rates (negotiated by SDP). >>> >>> Stephen Botzko >>> >>> On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming >>> wrote: >>> >>> stephen botzko wrote: >>> >>> > Dynamically changing sample rates on the system level adds some >>> > complexity for RTP, since the timestamp granularity is supposed to be >>> > the sample rate. >>> >>> And jitter buffers, and anything else that is based on timestamps and >>> sample rates/counts. If the desire is for the codec to be able to chang= e >>> sample rates to adjust to network conditions, then I agree with >>> Stephen... the 'external' sample rate (input to the encoder and output >>> from the decoder) should be fixed, and this is what would be negotiated >>> in SDP and used for RTP timestamps. The codec can downsample in the >>> encoder and upsample in the decoder if it has decided to transmit fewer >>> bits across the network. >>> >>> -- >>> Kevin P. Fleming >>> Digium, Inc. | Director of Software Technologies >>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >>> skype: kpfleming | jabber: kfleming@digium.com >>> Check us out at www.digium.com & www.asterisk.org >>> >>> >>> >>> >>> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> > --000e0cd1123c366a6e04842199ef Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Superwideband (and even fullband) do make speech somewhat more intelligible= , and also reduce listener fatigue.=A0 Telepresence and other videoconferen= cing equipment use those acoustic bandwidths today, so it would be nice if = CODEC supported at least superwideband also.

Personally I see some value in carriage of music.=A0 Sometimes our equi= pment is used for music performance.=A0 Distance learning is another use ca= se where music has some value, since course and training materials frequent= ly do include videos with music.=A0 Though of course conversational speech = is the dominant use case.

BTW, Videoconferencing devices do almost always support RTCP.=A0 It is = regrettable that so many VOIP devices do not.=A0 Anyway, I do not think our= charter scope includes invention of a new mechanism for signaling the netw= ork quality.

Stephen Botzko

On Tue, Apr 13, 2010 a= t 12:41 PM, Roman Shpount <roman@telurix.com> wrote:
I am not sure if this was decided, but should this new CODEC support music = encoding? If we don't plan to support music, we should probably stick t= o 16 Khz sampling rate. If we need music, I would suggest to have a 24 Khz= (or higher sampling rate) variant. I am not sure how many people here care= about a non-voice CODEC. For all the practical purposes I don't. I wou= ld argue,=A0 at least, for a fixed 16 KHz sampling rate CODEC variant.

P.S. On the same note, does anybody here cares about using this CODEC w= ith multicast? Is there a single commercial multicast voice deployment? Fro= m what I've seen all multicast does is making IETF voice standards hard= er to understand or implement.

P.P.S. RTCP is almost universally not implemented. The biggest VoIP gat= eway on the market does not generate RTCP. If we will rely on any RTCP func= tionality for bandwidth control it will probably be ignored.
______________________________
Roman Shpount -= =A0 www.telurix.com


=
TCP is a different case, since for this we are using RTCP to signal our fee= dback, and I don't think it has the facility you are envisioning.=A0
Also, I disagree with your presumption that multicast is out of scope= .=A0 I don't know of any other packetization RFCs that expressly rule o= ut multicast, and multicast can be used for interactive applications.

This concept seems pretty theoretical to me.=A0 If we need to manage co= mplexity / quality tradeoffs, why not just use profiles (as AVC/H.264 does)= or create a low complexity variant (like G.729A).=A0 I really don't se= e the need for dynamic complexity management.

BTW, you seem to be assuming that a lower sample rate results in=20 significantly less complexity.=A0 The savings there might not be as great= =20 as you think, especially if the receiver needs to resample anyway (to=20 prevent those sound card limitations you were talking about before).
Stephen Botzko

On Tue, Apr 13, 2010 at 1= 1:18 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote= :

= Hi,=

= =A0=

comments inline:

= =A0=

= = =A0

From:<= font size=3D"2" face=3D"Tahoma"> stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Tuesday, April 13, 2= 010 4:56 PM
To: Christian Hoene
Cc: codec@ietf.org


Subject: Re: [codec] #8: S= ample rates?

=A0

This would make the signaling more compli= cated - personally I am not convinced it is worth it.=A0

CH: It is a difficult tradeoff. However, signaling overload is done in Skype. <= span>=A0Such as signaling might be very useful for mobile devices, which want to save power and thus lower their CPU clock. Or= wireless IP based headphones which do not have large batteries. I am thinking of sig= naling the states: overloaded, fine, and low. That should be enough for most operational cases.


I think a better avenue is to bound overall complexity, and to focus on dynamically adapting to network conditions (as opposed to dynamic complexit= y management).

CH: I just like to remind that the good old TCP does support both: congestion c= ontrol to adapt to network conditions and flow control take into account an overlo= aded (=3Dfull) receiver.

You ca= n't dynamically negotiate complexity in many scenarios anyway - for instance it makes no sense if you are using multicast.

CH: Multicast is out of scope anyhow. We are considering an interactive codec. =

CH: The conferencing scenario might be some more difficult to handle but will n= ot a big problem.

Christian

<= /div>



Stephen Botzko

On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:

= Hi,=

= =A0=

= It still might make sense to negotiate the maximal supported sampling rate via= SDP or, if possible, to select one out of multiple sampling rates, if the audio receiver can cope with multiple rates well. The internal sampling frequency= of the codec NEEDS NOT to be affected by the external sampling frequency.

= = =A0

= Ho= wever, the decoder might want to signal to the encoder that the decoding is requir= ing too many computational resources and that a less complex coding mode (or a lower sampling frequency) should be taken.

= = =A0

= Ch= ristian

= = =A0

= = =A0

---------------------------------------------------= ------------

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
= http://www.net.uni-tuebingen.de/

= = =A0

From: stephen botzko [mailto:steph= en.botzko@gmail.com]
Sent: Tuesday, April 13, 2= 010 3:21 PM
To: Kevin P. Fleming
Cc: Christian Hoene; codec@ietf.org
Subject: Re: [codec] #8: S= ample rates?

=A0

Though I generally avoid MAY, this could be a case where it makes sense.

Something like:

CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to opti= mize audio quality.

This is free of any technology assumption about how the acoustic bandwidth is reduced.=A0 The MAY indicates that it is permissible.=A0 But if the CODEC algorithm doesn't need to reduce the acoustic bandwidth, t= hen we are making no statement that it SHOULD (or SHOULD NOT).

Kevin is distinguishing dynamic changes to the sample rate (for bandwidth management) from multiple fixed sample rates; and I agree that is a key distinction.

I have not heard any clear application requirement for more than one fixed sampling rate.=A0 Though if there is such a requirement, IMHO we would have to negotiate the rate within SDP in the usual way, and it would affect the = RTP timestamps, jitter buffers, etc.=A0 G.722.1 / G.722.1C is one precedent - i= t is the same core codec, but can run at two different sample rates (negotiat= ed by SDP).

Stephen Botzko

On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming <kpfleming@digium.com> wrote:

stephen botzko wrote:

> Dynamically changing sample rates on the system level adds some
> complexity for RTP, since the timestamp granularity is supposed to be<= br> > the sample rate.

And jitter buffers, and anything else that is based on timestamps and
sample rates/counts. If the desire is for the codec to be able to change sample rates to adjust to network conditions, then I agree with
Stephen... the 'external' sample rate (input to the encoder and out= put
from the decoder) should be fixed, and this is what would be negotiated
in SDP and used for RTP timestamps. The codec can downsample in the
encoder and upsample in the decoder if it has decided to transmit fewer
bits across the network.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.dig= ium.com & www.asterisk.or= g

=A0

=A0



_________________________________________= ______
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec



--000e0cd1123c366a6e04842199ef-- From kpfleming@digium.com Tue Apr 13 10:46:25 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 846E93A6A61 for ; Tue, 13 Apr 2010 10:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HkxoNCrYWeJv for ; Tue, 13 Apr 2010 10:46:24 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 861913A690B for ; Tue, 13 Apr 2010 10:46:24 -0700 (PDT) Received: from zimbra.digium.internal ([10.24.55.203] helo=zimbra.hsv.digium.com) by mail.digium.com with esmtp (Exim 4.69) (envelope-from ) id 1O1kBm-0000fg-5y; Tue, 13 Apr 2010 12:46:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbra.hsv.digium.com (Postfix) with ESMTP id 2D857D8004; Tue, 13 Apr 2010 12:46:18 -0500 (CDT) Received: from zimbra.hsv.digium.com ([127.0.0.1]) by localhost (zimbra.hsv.digium.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8d21lkiFUfR; Tue, 13 Apr 2010 12:46:17 -0500 (CDT) Received: from [10.24.250.46] (unknown [10.24.250.46]) by zimbra.hsv.digium.com (Postfix) with ESMTPSA id D6765D8002; Tue, 13 Apr 2010 12:46:17 -0500 (CDT) Message-ID: <4BC4ADE9.9000804@digium.com> Date: Tue, 13 Apr 2010 12:46:17 -0500 From: "Kevin P. Fleming" Organization: Digium, Inc. User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: stephen botzko References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <002a01cadac8$68dbf380$3a93da80$@de> <4BC4586F.1010709@digium.com> <001e01cadb17$886fcec0$994f6c40$@de> <003101cadb1c$828b3990$87a1acb0$@de> In-Reply-To: X-Enigmail-Version: 0.95.7 OpenPGP: id=05FB8DB2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 17:46:25 -0000 stephen botzko wrote: > Superwideband (and even fullband) do make speech somewhat more > intelligible, and also reduce listener fatigue. Telepresence and other > videoconferencing equipment use those acoustic bandwidths today, so it > would be nice if CODEC supported at least superwideband also. They also greatly enhance the accuracy of speech recognition... and vendors are starting to produce recognition platforms using wideband sample libraries now, so it wouldn't hurt to be one step ahead. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org From roman@telurix.com Tue Apr 13 11:11:28 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71F123A6999 for ; Tue, 13 Apr 2010 11:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zlB-PJSrzgiC for ; Tue, 13 Apr 2010 11:11:26 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 873043A6407 for ; Tue, 13 Apr 2010 11:11:24 -0700 (PDT) Received: by pvf33 with SMTP id 33so3308595pvf.31 for ; Tue, 13 Apr 2010 11:11:14 -0700 (PDT) Received: by 10.114.18.4 with SMTP id 4mr5839897war.186.1271182274145; Tue, 13 Apr 2010 11:11:14 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by mx.google.com with ESMTPS id 22sm5222512pzk.13.2010.04.13.11.11.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 13 Apr 2010 11:11:13 -0700 (PDT) Received: by pvf33 with SMTP id 33so3308559pvf.31 for ; Tue, 13 Apr 2010 11:11:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.14.205 with HTTP; Tue, 13 Apr 2010 11:11:12 -0700 (PDT) In-Reply-To: References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <4BC4586F.1010709@digium.com> <001e01cadb17$886fcec0$994f6c40$@de> <003101cadb1c$828b3990$87a1acb0$@de> Date: Tue, 13 Apr 2010 14:11:12 -0400 Received: by 10.114.162.11 with SMTP id k11mr5839821wae.138.1271182272197; Tue, 13 Apr 2010 11:11:12 -0700 (PDT) Message-ID: From: Roman Shpount To: stephen botzko Content-Type: multipart/alternative; boundary=00504502f5fec773940484222f79 Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 18:11:28 -0000 --00504502f5fec773940484222f79 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I will not argue superwideband vs wideband, even though we did some, not very scientific, blind tests, and in most cases people (especially men) cannot even distinguish wideband from superwideband when listening to voice samples. Only a very small percentage of voice energy is even present above 8 Khz. Music on the other hand, especially past 24Khz sampling rate, gets affected by the CODEC more then by bandwidth. For instance 8KHz G.711 encoded music sounds poor, but reasonable, and G.729 encoded music cannot be listened to. In most cases (apart from critical listening), music sampled at 16Khz is acceptable, especially for generation iPod. My remark about RTPC was to try to develop a CODEC that will function properly with RTCP absent. If we require RTCP based mechanisms in order for the CODEC to operate properly, this can impede the adoption of this CODEC. In no way do I propose to create new signaling mechanisms. ______________________________ Roman Shpount - www.telurix.com On Tue, Apr 13, 2010 at 1:29 PM, stephen botzko w= rote: > Superwideband (and even fullband) do make speech somewhat more > intelligible, and also reduce listener fatigue. Telepresence and other > videoconferencing equipment use those acoustic bandwidths today, so it wo= uld > be nice if CODEC supported at least superwideband also. > > Personally I see some value in carriage of music. Sometimes our equipmen= t > is used for music performance. Distance learning is another use case whe= re > music has some value, since course and training materials frequently do > include videos with music. Though of course conversational speech is the > dominant use case. > > BTW, Videoconferencing devices do almost always support RTCP. It is > regrettable that so many VOIP devices do not. Anyway, I do not think our > charter scope includes invention of a new mechanism for signaling the > network quality. > > Stephen Botzko > > > On Tue, Apr 13, 2010 at 12:41 PM, Roman Shpount wrote= : > >> I am not sure if this was decided, but should this new CODEC support mus= ic >> encoding? If we don't plan to support music, we should probably stick to= 16 >> Khz sampling rate. If we need music, I would suggest to have a 24 Khz (o= r >> higher sampling rate) variant. I am not sure how many people here care a= bout >> a non-voice CODEC. For all the practical purposes I don't. I would argue= , >> at least, for a fixed 16 KHz sampling rate CODEC variant. >> >> P.S. On the same note, does anybody here cares about using this CODEC wi= th >> multicast? Is there a single commercial multicast voice deployment? From >> what I've seen all multicast does is making IETF voice standards harder = to >> understand or implement. >> >> P.P.S. RTCP is almost universally not implemented. The biggest VoIP >> gateway on the market does not generate RTCP. If we will rely on any RTC= P >> functionality for bandwidth control it will probably be ignored. >> ______________________________ >> Roman Shpount - www.telurix.com >> >> >> On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko < >> stephen.botzko@gmail.com> wrote: >> >>> TCP is a different case, since for this we are using RTCP to signal our >>> feedback, and I don't think it has the facility you are envisioning. >>> >>> Also, I disagree with your presumption that multicast is out of scope. = I >>> don't know of any other packetization RFCs that expressly rule out >>> multicast, and multicast can be used for interactive applications. >>> >>> This concept seems pretty theoretical to me. If we need to manage >>> complexity / quality tradeoffs, why not just use profiles (as AVC/H.264 >>> does) or create a low complexity variant (like G.729A). I really don't= see >>> the need for *dynamic* complexity management. >>> >>> BTW, you seem to be assuming that a lower sample rate results in >>> significantly less complexity. The savings there might not be as great= as >>> you think, especially if the receiver needs to resample anyway (to prev= ent >>> those sound card limitations you were talking about before). >>> >>> Stephen Botzko >>> >>> On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene < >>> hoene@uni-tuebingen.de> wrote: >>> >>>> Hi, >>>> >>>> >>>> >>>> comments inline: >>>> >>>> >>>> >>>> >>>> >>>> *From:* stephen botzko [mailto:stephen.botzko@gmail.com] >>>> *Sent:* Tuesday, April 13, 2010 4:56 PM >>>> *To:* Christian Hoene >>>> *Cc:* codec@ietf.org >>>> >>>> *Subject:* Re: [codec] #8: Sample rates? >>>> >>>> >>>> >>>> This would make the signaling more complicated - personally I am not >>>> convinced it is worth it. >>>> >>>> CH: It is a difficult tradeoff. However, signaling overload is done in >>>> Skype. Such as signaling might be very useful for mobile devices, >>>> which want to save power and thus lower their CPU clock. Or wireless I= P >>>> based headphones which do not have large batteries. I am thinking of >>>> signaling the states: overloaded, fine, and low. That should be enough= for >>>> most operational cases. >>>> >>>> >>>> I think a better avenue is to bound overall complexity, and to focus o= n >>>> dynamically adapting to network conditions (as opposed to dynamic comp= lexity >>>> management). >>>> >>>> CH: I just like to remind that the good old TCP does support both: >>>> congestion control to adapt to network conditions and flow control tak= e into >>>> account an overloaded (=3Dfull) receiver. >>>> >>>> You can't dynamically negotiate complexity in many scenarios anyway - >>>> for instance it makes no sense if you are using multicast. >>>> >>>> CH: Multicast is out of scope anyhow. We are considering an interactiv= e >>>> codec. >>>> >>>> CH: The conferencing scenario might be some more difficult to handle b= ut >>>> will not a big problem. >>>> >>>> Christian >>>> >>>> >>>> >>>> Stephen Botzko >>>> >>>> On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene < >>>> hoene@uni-tuebingen.de> wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>> It still might make sense to negotiate the maximal supported sampling >>>> rate via SDP or, if possible, to select one out of multiple sampling r= ates, >>>> if the audio receiver can cope with multiple rates well. The internal >>>> sampling frequency of the codec NEEDS NOT to be affected by the extern= al >>>> sampling frequency. >>>> >>>> >>>> >>>> However, the decoder might want to signal to the encoder that the >>>> decoding is requiring too many computational resources and that a less >>>> complex coding mode (or a lower sampling frequency) should be taken. >>>> >>>> >>>> >>>> Christian >>>> >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------- >>>> >>>> Dr.-Ing. Christian Hoene >>>> >>>> Interactive Communication Systems (ICS), University of T=FCbingen >>>> >>>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >>>> http://www.net.uni-tuebingen.de/ >>>> >>>> >>>> >>>> *From:* stephen botzko [mailto:stephen.botzko@gmail.com] >>>> *Sent:* Tuesday, April 13, 2010 3:21 PM >>>> *To:* Kevin P. Fleming >>>> *Cc:* Christian Hoene; codec@ietf.org >>>> *Subject:* Re: [codec] #8: Sample rates? >>>> >>>> >>>> >>>> Though I generally avoid MAY, this could be a case where it makes sens= e. >>>> >>>> Something like: >>>> >>>> CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to >>>> optimize audio quality. >>>> >>>> This is free of any technology assumption about *how* the acoustic >>>> bandwidth is reduced. The MAY indicates that it is permissible. But = if the >>>> CODEC algorithm doesn't need to reduce the acoustic bandwidth, then we= are >>>> making no statement that it SHOULD (or SHOULD NOT). >>>> >>>> Kevin is distinguishing dynamic changes to the sample rate (for >>>> bandwidth management) from multiple fixed sample rates; and I agree th= at is >>>> a key distinction. >>>> >>>> I have not heard any clear application requirement for more than one >>>> fixed sampling rate. Though if there is such a requirement, IMHO we w= ould >>>> have to negotiate the rate within SDP in the usual way, and it would a= ffect >>>> the RTP timestamps, jitter buffers, etc. G.722.1 / G.722.1C is one >>>> precedent - it is the same core codec, but can run at two different sa= mple >>>> rates (negotiated by SDP). >>>> >>>> Stephen Botzko >>>> >>>> On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming >>>> wrote: >>>> >>>> stephen botzko wrote: >>>> >>>> > Dynamically changing sample rates on the system level adds some >>>> > complexity for RTP, since the timestamp granularity is supposed to b= e >>>> > the sample rate. >>>> >>>> And jitter buffers, and anything else that is based on timestamps and >>>> sample rates/counts. If the desire is for the codec to be able to chan= ge >>>> sample rates to adjust to network conditions, then I agree with >>>> Stephen... the 'external' sample rate (input to the encoder and output >>>> from the decoder) should be fixed, and this is what would be negotiate= d >>>> in SDP and used for RTP timestamps. The codec can downsample in the >>>> encoder and upsample in the decoder if it has decided to transmit fewe= r >>>> bits across the network. >>>> >>>> -- >>>> Kevin P. Fleming >>>> Digium, Inc. | Director of Software Technologies >>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >>>> skype: kpfleming | jabber: kfleming@digium.com >>>> Check us out at www.digium.com & www.asterisk.org >>>> >>>> >>>> >>>> >>>> >>> >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>> >>> >> > --00504502f5fec773940484222f79 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I will not argue superwideband vs wideband, even though we did some, not ve= ry scientific, blind tests, and in most cases people (especially men) canno= t even distinguish wideband from superwideband when listening to voice samp= les. Only a very small percentage of voice energy is even present above 8 K= hz.

Music on the other hand, especially past 24Khz sampling rate, gets affe= cted by the CODEC more then by bandwidth. For instance 8KHz G.711 encoded m= usic sounds poor, but reasonable, and G.729 encoded music cannot be listene= d to. In most cases (apart from critical listening), music sampled at 16Khz= is acceptable, especially for generation iPod.

My remark about RTPC was to try to develop a CODEC that will function p= roperly with RTCP absent. If we require RTCP based mechanisms in order for = the CODEC to operate properly, this can impede the adoption of this CODEC. = In no way do I propose to create new signaling mechanisms.
______________________________
Roman Shpount - www.telurix.com


On Tue, Apr 13, 2010 at 1:29 PM, stephen= botzko <s= tephen.botzko@gmail.com> wrote:
Superwideband (and even fullband) do make speech somewhat more intelligible= , and also reduce listener fatigue.=A0 Telepresence and other videoconferen= cing equipment use those acoustic bandwidths today, so it would be nice if = CODEC supported at least superwideband also.

Personally I see some value in carriage of music.=A0 Sometimes our equi= pment is used for music performance.=A0 Distance learning is another use ca= se where music has some value, since course and training materials frequent= ly do include videos with music.=A0 Though of course conversational speech = is the dominant use case.

BTW, Videoconferencing devices do almost always support RTCP.=A0 It is = regrettable that so many VOIP devices do not.=A0 Anyway, I do not think our= charter scope includes invention of a new mechanism for signaling the netw= ork quality.

Stephen Botzko


On Tue, Apr 13, 2010 at 12:41 PM, Roman Shpount <roman@= telurix.com> wrote:
I am not sure if this was decided, but should this new CODEC support music = encoding? If we don't plan to support music, we should probably stick t= o 16 Khz sampling rate. If we need music, I would suggest to have a 24 Khz= (or higher sampling rate) variant. I am not sure how many people here care= about a non-voice CODEC. For all the practical purposes I don't. I wou= ld argue,=A0 at least, for a fixed 16 KHz sampling rate CODEC variant.

P.S. On the same note, does anybody here cares about using this CODEC w= ith multicast? Is there a single commercial multicast voice deployment? Fro= m what I've seen all multicast does is making IETF voice standards hard= er to understand or implement.

P.P.S. RTCP is almost universally not implemented. The biggest VoIP gat= eway on the market does not generate RTCP. If we will rely on any RTCP func= tionality for bandwidth control it will probably be ignored.
______________________________
Roman Shpount -= =A0 www.telurix.com


=
TCP is a different case, since for this we are using RTCP to signal our fee= dback, and I don't think it has the facility you are envisioning.=A0
Also, I disagree with your presumption that multicast is out of scope= .=A0 I don't know of any other packetization RFCs that expressly rule o= ut multicast, and multicast can be used for interactive applications.

This concept seems pretty theoretical to me.=A0 If we need to manage co= mplexity / quality tradeoffs, why not just use profiles (as AVC/H.264 does)= or create a low complexity variant (like G.729A).=A0 I really don't se= e the need for dynamic complexity management.

BTW, you seem to be assuming that a lower sample rate results in=20 significantly less complexity.=A0 The savings there might not be as great= =20 as you think, especially if the receiver needs to resample anyway (to=20 prevent those sound card limitations you were talking about before).
Stephen Botzko

On Tue, Apr 13, 2010 at 1= 1:18 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote= :

= Hi,=

= =A0=

comments inline:

= =A0=

= = =A0

From:<= font face=3D"Tahoma" size=3D"2"> stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Tuesday, April 13, 2= 010 4:56 PM
To: Christian Hoene
Cc: codec@ietf.org


Subject: Re: [codec] #8: S= ample rates?

=A0

This would make the signaling more compli= cated - personally I am not convinced it is worth it.=A0

CH: It is a difficult tradeoff. However, signaling overload is done in Skype. <= span>=A0Such as signaling might be very useful for mobile devices, which want to save power and thus lower their CPU clock. Or= wireless IP based headphones which do not have large batteries. I am thinking of sig= naling the states: overloaded, fine, and low. That should be enough for most operational cases.


I think a better avenue is to bound overall complexity, and to focus on dynamically adapting to network conditions (as opposed to dynamic complexit= y management).

CH: I just like to remind that the good old TCP does support both: congestion c= ontrol to adapt to network conditions and flow control take into account an overlo= aded (=3Dfull) receiver.

You ca= n't dynamically negotiate complexity in many scenarios anyway - for instance it makes no sense if you are using multicast.

CH: Multicast is out of scope anyhow. We are considering an interactive codec. =

CH: The conferencing scenario might be some more difficult to handle but will n= ot a big problem.

Christian

<= /div>



Stephen Botzko

On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:

= Hi,=

= =A0=

= It still might make sense to negotiate the maximal supported sampling rate via= SDP or, if possible, to select one out of multiple sampling rates, if the audio receiver can cope with multiple rates well. The internal sampling frequency= of the codec NEEDS NOT to be affected by the external sampling frequency.

= = =A0

= Ho= wever, the decoder might want to signal to the encoder that the decoding is requir= ing too many computational resources and that a less complex coding mode (or a lower sampling frequency) should be taken.

= = =A0

= Ch= ristian

= = =A0

= = =A0

---------------------------------------------------= ------------

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
= http://www.net.uni-tuebingen.de/

= = =A0

From: stephen botzko [mailto:steph= en.botzko@gmail.com]
Sent: Tuesday, April 13, 2= 010 3:21 PM
To: Kevin P. Fleming
Cc: Christian Hoene; codec@ietf.org
Subject: Re: [codec] #8: S= ample rates?

=A0

Though I generally avoid MAY, this could be a case where it makes sense.

Something like:

CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to opti= mize audio quality.

This is free of any technology assumption about how the acoustic bandwidth is reduced.=A0 The MAY indicates that it is permissible.=A0 But if the CODEC algorithm doesn't need to reduce the acoustic bandwidth, t= hen we are making no statement that it SHOULD (or SHOULD NOT).

Kevin is distinguishing dynamic changes to the sample rate (for bandwidth management) from multiple fixed sample rates; and I agree that is a key distinction.

I have not heard any clear application requirement for more than one fixed sampling rate.=A0 Though if there is such a requirement, IMHO we would have to negotiate the rate within SDP in the usual way, and it would affect the = RTP timestamps, jitter buffers, etc.=A0 G.722.1 / G.722.1C is one precedent - i= t is the same core codec, but can run at two different sample rates (negotiat= ed by SDP).

Stephen Botzko

On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming <kpfleming@digium.com> wrote:

stephen botzko wrote:

> Dynamically changing sample rates on the system level adds some
> complexity for RTP, since the timestamp granularity is supposed to be<= br> > the sample rate.

And jitter buffers, and anything else that is based on timestamps and
sample rates/counts. If the desire is for the codec to be able to change sample rates to adjust to network conditions, then I agree with
Stephen... the 'external' sample rate (input to the encoder and out= put
from the decoder) should be fixed, and this is what would be negotiated
in SDP and used for RTP timestamps. The codec can downsample in the
encoder and upsample in the decoder if it has decided to transmit fewer
bits across the network.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.dig= ium.com & www.asterisk.or= g

=A0

=A0



_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec




--00504502f5fec773940484222f79-- From stephen.botzko@gmail.com Tue Apr 13 11:43:23 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 14C4E28C141 for ; Tue, 13 Apr 2010 11:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.515 X-Spam-Level: X-Spam-Status: No, score=-2.515 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AsQRH2EYjLfR for ; Tue, 13 Apr 2010 11:43:20 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 70D3B28C0D6 for ; Tue, 13 Apr 2010 11:43:20 -0700 (PDT) Received: by iwn27 with SMTP id 27so5812281iwn.5 for ; Tue, 13 Apr 2010 11:43:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=iR43d/yFZ7GVEQsm7WVjQl8g7BSG1DiQVQzXsrBvDEs=; b=djKiAUarUUb2/1aE8VWxb8X6fGf/v0NKd6ldhBasvfmx8K7NCRJucdpp71P0821FX9 MYedKg1UshgqtEepspPDUiLUKyxrJlcBkd9UnXi14KAlyhObqpKg2NRbdviDks2gDw2w m0BTmi5rdk5fG4eOXetRtpodmEP7r/AQalv5Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=LG8zIQGS2AWsFaCSCTyIszbh4XGwX23V65YrNFf9vdjp/Nc2Jx02/uQDvhyTLXi4Vv IjVVdTHCzaUSHgAXYbmNs4MNJyS/TPfWP7ZPb94FQNiUB3wG3BMpjkuiYPj7MCkuGz7m 3RMHgDJ0dazwHOBvNXOVM7e47LqXiBoJ114ss= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Tue, 13 Apr 2010 11:43:11 -0700 (PDT) In-Reply-To: References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <4BC4586F.1010709@digium.com> <001e01cadb17$886fcec0$994f6c40$@de> <003101cadb1c$828b3990$87a1acb0$@de> Date: Tue, 13 Apr 2010 14:43:11 -0400 Received: by 10.143.85.8 with SMTP id n8mr2897964wfl.282.1271184191995; Tue, 13 Apr 2010 11:43:11 -0700 (PDT) Message-ID: From: stephen botzko To: Roman Shpount Content-Type: multipart/alternative; boundary=000e0cd5cdc8353f58048422a26c Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 18:43:23 -0000 --000e0cd5cdc8353f58048422a26c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>> I will not argue superwideband vs wideband, even though we did some, not very scientific, blind tests, and in most cases people (especially men) cannot even distinguish wideband from superwideband when listening to voice samples. Only a very small percentage of voice energy is even present above 8 Khz. >>> Though there isn't much voice energy over 8 kHz, in our (equally unscientific) tests, sibilants and fricatives are easier to distinguish if you are using superwideband or better. That was one reason we added Annec = C to G.722.1. Fullband is (IMHO) a specsmanship thing for speech (and probably for music also for most of us). Though it may not be that hard to get it, if we are shooting for superwideband anyway. Stephen Botzko On Tue, Apr 13, 2010 at 2:11 PM, Roman Shpount wrote: > I will not argue superwideband vs wideband, even though we did some, not > very scientific, blind tests, and in most cases people (especially men) > cannot even distinguish wideband from superwideband when listening to voi= ce > samples. Only a very small percentage of voice energy is even present abo= ve > 8 Khz. > > Music on the other hand, especially past 24Khz sampling rate, gets affect= ed > by the CODEC more then by bandwidth. For instance 8KHz G.711 encoded musi= c > sounds poor, but reasonable, and G.729 encoded music cannot be listened t= o. > In most cases (apart from critical listening), music sampled at 16Khz is > acceptable, especially for generation iPod. > > My remark about RTPC was to try to develop a CODEC that will function > properly with RTCP absent. If we require RTCP based mechanisms in order f= or > the CODEC to operate properly, this can impede the adoption of this CODEC= . > In no way do I propose to create new signaling mechanisms. > > ______________________________ > Roman Shpount - www.telurix.com > > > On Tue, Apr 13, 2010 at 1:29 PM, stephen botzko wrote: > >> Superwideband (and even fullband) do make speech somewhat more >> intelligible, and also reduce listener fatigue. Telepresence and other >> videoconferencing equipment use those acoustic bandwidths today, so it w= ould >> be nice if CODEC supported at least superwideband also. >> >> Personally I see some value in carriage of music. Sometimes our equipme= nt >> is used for music performance. Distance learning is another use case wh= ere >> music has some value, since course and training materials frequently do >> include videos with music. Though of course conversational speech is th= e >> dominant use case. >> >> BTW, Videoconferencing devices do almost always support RTCP. It is >> regrettable that so many VOIP devices do not. Anyway, I do not think ou= r >> charter scope includes invention of a new mechanism for signaling the >> network quality. >> >> Stephen Botzko >> >> >> On Tue, Apr 13, 2010 at 12:41 PM, Roman Shpount wrote= : >> >>> I am not sure if this was decided, but should this new CODEC support >>> music encoding? If we don't plan to support music, we should probably s= tick >>> to 16 Khz sampling rate. If we need music, I would suggest to have a 24= Khz >>> (or higher sampling rate) variant. I am not sure how many people here c= are >>> about a non-voice CODEC. For all the practical purposes I don't. I woul= d >>> argue, at least, for a fixed 16 KHz sampling rate CODEC variant. >>> >>> P.S. On the same note, does anybody here cares about using this CODEC >>> with multicast? Is there a single commercial multicast voice deployment= ? >>> From what I've seen all multicast does is making IETF voice standards h= arder >>> to understand or implement. >>> >>> P.P.S. RTCP is almost universally not implemented. The biggest VoIP >>> gateway on the market does not generate RTCP. If we will rely on any RT= CP >>> functionality for bandwidth control it will probably be ignored. >>> ______________________________ >>> Roman Shpount - www.telurix.com >>> >>> >>> On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko < >>> stephen.botzko@gmail.com> wrote: >>> >>>> TCP is a different case, since for this we are using RTCP to signal ou= r >>>> feedback, and I don't think it has the facility you are envisioning. >>>> >>>> Also, I disagree with your presumption that multicast is out of scope. >>>> I don't know of any other packetization RFCs that expressly rule out >>>> multicast, and multicast can be used for interactive applications. >>>> >>>> This concept seems pretty theoretical to me. If we need to manage >>>> complexity / quality tradeoffs, why not just use profiles (as AVC/H.26= 4 >>>> does) or create a low complexity variant (like G.729A). I really don'= t see >>>> the need for *dynamic* complexity management. >>>> >>>> BTW, you seem to be assuming that a lower sample rate results in >>>> significantly less complexity. The savings there might not be as grea= t as >>>> you think, especially if the receiver needs to resample anyway (to pre= vent >>>> those sound card limitations you were talking about before). >>>> >>>> Stephen Botzko >>>> >>>> On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene < >>>> hoene@uni-tuebingen.de> wrote: >>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> comments inline: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> *From:* stephen botzko [mailto:stephen.botzko@gmail.com] >>>>> *Sent:* Tuesday, April 13, 2010 4:56 PM >>>>> *To:* Christian Hoene >>>>> *Cc:* codec@ietf.org >>>>> >>>>> *Subject:* Re: [codec] #8: Sample rates? >>>>> >>>>> >>>>> >>>>> This would make the signaling more complicated - personally I am not >>>>> convinced it is worth it. >>>>> >>>>> CH: It is a difficult tradeoff. However, signaling overload is done i= n >>>>> Skype. Such as signaling might be very useful for mobile devices, >>>>> which want to save power and thus lower their CPU clock. Or wireless = IP >>>>> based headphones which do not have large batteries. I am thinking of >>>>> signaling the states: overloaded, fine, and low. That should be enoug= h for >>>>> most operational cases. >>>>> >>>>> >>>>> I think a better avenue is to bound overall complexity, and to focus = on >>>>> dynamically adapting to network conditions (as opposed to dynamic com= plexity >>>>> management). >>>>> >>>>> CH: I just like to remind that the good old TCP does support both: >>>>> congestion control to adapt to network conditions and flow control ta= ke into >>>>> account an overloaded (=3Dfull) receiver. >>>>> >>>>> You can't dynamically negotiate complexity in many scenarios anyway - >>>>> for instance it makes no sense if you are using multicast. >>>>> >>>>> CH: Multicast is out of scope anyhow. We are considering an interacti= ve >>>>> codec. >>>>> >>>>> CH: The conferencing scenario might be some more difficult to handle >>>>> but will not a big problem. >>>>> >>>>> Christian >>>>> >>>>> >>>>> >>>>> Stephen Botzko >>>>> >>>>> On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene < >>>>> hoene@uni-tuebingen.de> wrote: >>>>> >>>>> Hi, >>>>> >>>>> >>>>> >>>>> It still might make sense to negotiate the maximal supported sampling >>>>> rate via SDP or, if possible, to select one out of multiple sampling = rates, >>>>> if the audio receiver can cope with multiple rates well. The internal >>>>> sampling frequency of the codec NEEDS NOT to be affected by the exter= nal >>>>> sampling frequency. >>>>> >>>>> >>>>> >>>>> However, the decoder might want to signal to the encoder that the >>>>> decoding is requiring too many computational resources and that a les= s >>>>> complex coding mode (or a lower sampling frequency) should be taken. >>>>> >>>>> >>>>> >>>>> Christian >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------- >>>>> >>>>> Dr.-Ing. Christian Hoene >>>>> >>>>> Interactive Communication Systems (ICS), University of T=FCbingen >>>>> >>>>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >>>>> http://www.net.uni-tuebingen.de/ >>>>> >>>>> >>>>> >>>>> *From:* stephen botzko [mailto:stephen.botzko@gmail.com] >>>>> *Sent:* Tuesday, April 13, 2010 3:21 PM >>>>> *To:* Kevin P. Fleming >>>>> *Cc:* Christian Hoene; codec@ietf.org >>>>> *Subject:* Re: [codec] #8: Sample rates? >>>>> >>>>> >>>>> >>>>> Though I generally avoid MAY, this could be a case where it makes >>>>> sense. >>>>> >>>>> Something like: >>>>> >>>>> CODEC MAY reduce the acoustic bandwidth at lower bit rates in order t= o >>>>> optimize audio quality. >>>>> >>>>> This is free of any technology assumption about *how* the acoustic >>>>> bandwidth is reduced. The MAY indicates that it is permissible. But= if the >>>>> CODEC algorithm doesn't need to reduce the acoustic bandwidth, then w= e are >>>>> making no statement that it SHOULD (or SHOULD NOT). >>>>> >>>>> Kevin is distinguishing dynamic changes to the sample rate (for >>>>> bandwidth management) from multiple fixed sample rates; and I agree t= hat is >>>>> a key distinction. >>>>> >>>>> I have not heard any clear application requirement for more than one >>>>> fixed sampling rate. Though if there is such a requirement, IMHO we = would >>>>> have to negotiate the rate within SDP in the usual way, and it would = affect >>>>> the RTP timestamps, jitter buffers, etc. G.722.1 / G.722.1C is one >>>>> precedent - it is the same core codec, but can run at two different s= ample >>>>> rates (negotiated by SDP). >>>>> >>>>> Stephen Botzko >>>>> >>>>> On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming < >>>>> kpfleming@digium.com> wrote: >>>>> >>>>> stephen botzko wrote: >>>>> >>>>> > Dynamically changing sample rates on the system level adds some >>>>> > complexity for RTP, since the timestamp granularity is supposed to = be >>>>> > the sample rate. >>>>> >>>>> And jitter buffers, and anything else that is based on timestamps and >>>>> sample rates/counts. If the desire is for the codec to be able to >>>>> change >>>>> sample rates to adjust to network conditions, then I agree with >>>>> Stephen... the 'external' sample rate (input to the encoder and outpu= t >>>>> from the decoder) should be fixed, and this is what would be negotiat= ed >>>>> in SDP and used for RTP timestamps. The codec can downsample in the >>>>> encoder and upsample in the decoder if it has decided to transmit few= er >>>>> bits across the network. >>>>> >>>>> -- >>>>> Kevin P. Fleming >>>>> Digium, Inc. | Director of Software Technologies >>>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >>>>> skype: kpfleming | jabber: kfleming@digium.com >>>>> Check us out at www.digium.com & www.asterisk.org >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> codec mailing list >>>> codec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codec >>>> >>>> >>> >> > --000e0cd5cdc8353f58048422a26c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
I will not argue superwid= eband vs wideband, even though we did some, not very scientific, blind tests, and in most cases people (especially men) cannot even distinguish wideband from superwideband when=A0=A0=A0 listenin= g to=20 voice samples. Only a very small percentage of voice energy is even=20 present above 8 Khz.
>>>
Though there isn't much v= oice energy over 8 kHz, in our (equally unscientific) tests, sibilants and = fricatives are easier to distinguish if you are using superwideband or bett= er.=A0 That was one reason we added Annec C to G.722.1.

Fullband is (IMHO) a specsmanship thing for speech (and probably for mu= sic also for most of us).=A0 Though it may not be that hard to get it, if w= e are shooting for superwideband anyway.

Stephen Botzko


On Tue, Apr 13, 2010 at 2:11 PM, Roman Shpount <= span dir=3D"ltr"><roman@telurix.com= > wrote:
I will not argue superwideband vs wideband, even though we did some, not ve= ry scientific, blind tests, and in most cases people (especially men) canno= t even distinguish wideband from superwideband when listening to voice samp= les. Only a very small percentage of voice energy is even present above 8 K= hz.

Music on the other hand, especially past 24Khz sampling rate, gets affe= cted by the CODEC more then by bandwidth. For instance 8KHz G.711 encoded m= usic sounds poor, but reasonable, and G.729 encoded music cannot be listene= d to. In most cases (apart from critical listening), music sampled at 16Khz= is acceptable, especially for generation iPod.

My remark about RTPC was to try to develop a CODEC that will function p= roperly with RTCP absent. If we require RTCP based mechanisms in order for = the CODEC to operate properly, this can impede the adoption of this CODEC. = In no way do I propose to create new signaling mechanisms.

______________________________
Roman Shpount - www.telurix.com


= On Tue, Apr 13, 2010 at 1:29 PM, stephen botzko <stephen.botzko@gma= il.com> wrote:
Superwideband (and even fullband) do make speech somewhat more intelligible= , and also reduce listener fatigue.=A0 Telepresence and other videoconferen= cing equipment use those acoustic bandwidths today, so it would be nice if = CODEC supported at least superwideband also.

Personally I see some value in carriage of music.=A0 Sometimes our equi= pment is used for music performance.=A0 Distance learning is another use ca= se where music has some value, since course and training materials frequent= ly do include videos with music.=A0 Though of course conversational speech = is the dominant use case.

BTW, Videoconferencing devices do almost always support RTCP.=A0 It is = regrettable that so many VOIP devices do not.=A0 Anyway, I do not think our= charter scope includes invention of a new mechanism for signaling the netw= ork quality.

Stephen Botzko


On Tue, Apr 13, 2010 at 12:41 PM, Roman Shpount <= ;roman@telurix.com> wrote:
I am not sure if this was decided, but should this new CODEC support music = encoding? If we don't plan to support music, we should probably stick t= o 16 Khz sampling rate. If we need music, I would suggest to have a 24 Khz= (or higher sampling rate) variant. I am not sure how many people here care= about a non-voice CODEC. For all the practical purposes I don't. I wou= ld argue,=A0 at least, for a fixed 16 KHz sampling rate CODEC variant.

P.S. On the same note, does anybody here cares about using this CODEC w= ith multicast? Is there a single commercial multicast voice deployment? Fro= m what I've seen all multicast does is making IETF voice standards hard= er to understand or implement.

P.P.S. RTCP is almost universally not implemented. The biggest VoIP gat= eway on the market does not generate RTCP. If we will rely on any RTCP func= tionality for bandwidth control it will probably be ignored.
______________________________
Roman Shpount -= =A0 www.telurix.com


=
TCP is a different case, since for this we are using RTCP to signal our fee= dback, and I don't think it has the facility you are envisioning.=A0
Also, I disagree with your presumption that multicast is out of scope= .=A0 I don't know of any other packetization RFCs that expressly rule o= ut multicast, and multicast can be used for interactive applications.

This concept seems pretty theoretical to me.=A0 If we need to manage co= mplexity / quality tradeoffs, why not just use profiles (as AVC/H.264 does)= or create a low complexity variant (like G.729A).=A0 I really don't se= e the need for dynamic complexity management.

BTW, you seem to be assuming that a lower sample rate results in=20 significantly less complexity.=A0 The savings there might not be as great= =20 as you think, especially if the receiver needs to resample anyway (to=20 prevent those sound card limitations you were talking about before).
Stephen Botzko

On Tue, Apr 13, 2010 at 1= 1:18 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote= :

= Hi,=

= =A0=

comments inline:

= =A0=

= = =A0

From:<= font size=3D"2" face=3D"Tahoma"> stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Tuesday, April 13, 2= 010 4:56 PM
To: Christian Hoene
Cc: codec@ietf.org


Subject: Re: [codec] #8: S= ample rates?

=A0

This would make the signaling more compli= cated - personally I am not convinced it is worth it.=A0

CH: It is a difficult tradeoff. However, signaling overload is done in Skype. <= span>=A0Such as signaling might be very useful for mobile devices, which want to save power and thus lower their CPU clock. Or= wireless IP based headphones which do not have large batteries. I am thinking of sig= naling the states: overloaded, fine, and low. That should be enough for most operational cases.


I think a better avenue is to bound overall complexity, and to focus on dynamically adapting to network conditions (as opposed to dynamic complexit= y management).

CH: I just like to remind that the good old TCP does support both: congestion c= ontrol to adapt to network conditions and flow control take into account an overlo= aded (=3Dfull) receiver.

You ca= n't dynamically negotiate complexity in many scenarios anyway - for instance it makes no sense if you are using multicast.

CH: Multicast is out of scope anyhow. We are considering an interactive codec. =

CH: The conferencing scenario might be some more difficult to handle but will n= ot a big problem.

Christian

<= /div>



Stephen Botzko

On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:

= Hi,=

= =A0=

= It still might make sense to negotiate the maximal supported sampling rate via= SDP or, if possible, to select one out of multiple sampling rates, if the audio receiver can cope with multiple rates well. The internal sampling frequency= of the codec NEEDS NOT to be affected by the external sampling frequency.

= = =A0

= Ho= wever, the decoder might want to signal to the encoder that the decoding is requir= ing too many computational resources and that a less complex coding mode (or a lower sampling frequency) should be taken.

= = =A0

= Ch= ristian

= = =A0

= = =A0

---------------------------------------------------= ------------

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
= http://www.net.uni-tuebingen.de/

= = =A0

From: stephen botzko [mailto:steph= en.botzko@gmail.com]
Sent: Tuesday, April 13, 2= 010 3:21 PM
To: Kevin P. Fleming
Cc: Christian Hoene; codec@ietf.org
Subject: Re: [codec] #8: S= ample rates?

=A0

Though I generally avoid MAY, this could be a case where it makes sense.

Something like:

CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to opti= mize audio quality.

This is free of any technology assumption about how the acoustic bandwidth is reduced.=A0 The MAY indicates that it is permissible.=A0 But if the CODEC algorithm doesn't need to reduce the acoustic bandwidth, t= hen we are making no statement that it SHOULD (or SHOULD NOT).

Kevin is distinguishing dynamic changes to the sample rate (for bandwidth management) from multiple fixed sample rates; and I agree that is a key distinction.

I have not heard any clear application requirement for more than one fixed sampling rate.=A0 Though if there is such a requirement, IMHO we would have to negotiate the rate within SDP in the usual way, and it would affect the = RTP timestamps, jitter buffers, etc.=A0 G.722.1 / G.722.1C is one precedent - i= t is the same core codec, but can run at two different sample rates (negotiat= ed by SDP).

Stephen Botzko

On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming <kpfleming@digium.com> wrote:

stephen botzko wrote:

> Dynamically changing sample rates on the system level adds some
> complexity for RTP, since the timestamp granularity is supposed to be<= br> > the sample rate.

And jitter buffers, and anything else that is based on timestamps and
sample rates/counts. If the desire is for the codec to be able to change sample rates to adjust to network conditions, then I agree with
Stephen... the 'external' sample rate (input to the encoder and out= put
from the decoder) should be fixed, and this is what would be negotiated
in SDP and used for RTP timestamps. The codec can downsample in the
encoder and upsample in the decoder if it has decided to transmit fewer
bits across the network.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.dig= ium.com & www.asterisk.or= g

=A0

=A0



_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec





--000e0cd5cdc8353f58048422a26c-- From bmschwar@fas.harvard.edu Tue Apr 13 12:00:09 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B121228C16A for ; Tue, 13 Apr 2010 12:00:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.98 X-Spam-Level: X-Spam-Status: No, score=-5.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIlUC66n4arG for ; Tue, 13 Apr 2010 12:00:08 -0700 (PDT) Received: from us17.unix.fas.harvard.edu (us17.unix.fas.harvard.edu [140.247.35.197]) by core3.amsl.com (Postfix) with ESMTP id F41563A68F7 for ; Tue, 13 Apr 2010 12:00:00 -0700 (PDT) Received: from us17.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us17.unix.fas.harvard.edu (Postfix) with ESMTP id 7535041E226; Tue, 13 Apr 2010 14:59:54 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; s=mail; bh=0Of2vOTv/fJUrFs Z21cmS7Rb5sFJjGi/T/5YDNRCQxk=; b=eVpNBxJElpmf030LoXGjmuLr1E/L17p HXzhhm01fZU/JjTmr7eyUjd77iK6TZoPMp2YM1VnbOILdR79ta+HpvAMrgMW//wI b8zNbx/WckbpQQXHJ8DYoD4PU2Zj1AzzQDG3GBw1Lll8hrvStSDEOf5gvzt/DwKg py0KXPHuqqnY= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; q=dns; s=mail; b=Ki0lrJKRq PHCNf+xHk8GSseZkw7Hc+KEZCcaqeTKw/CP3+5pQi2qpPnDmCrsKr36bTxBkIgeq t4gpJ+aWfhe1ZjVTjExsci/hzkkh0z4MSkB0HjQ6MMso0b59tAe1yB1hrSwNJ4V3 NA2vlOk2fMYMsNcv3L/1oi7PZgtzTDaXDg= Received: from [172.23.141.66] (bwhmaincampuspat25.partners.org [170.223.207.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us17.unix.fas.harvard.edu (Postfix) with ESMTPSA id 6C27C41E21D; Tue, 13 Apr 2010 14:59:54 -0400 (EDT) Message-ID: <4BC4BF26.9060008@fas.harvard.edu> Date: Tue, 13 Apr 2010 14:59:50 -0400 From: "Benjamin M. Schwartz" User-Agent: Thunderbird 2.0.0.23 (X11/20091019) MIME-Version: 1.0 To: stephen botzko References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <4BC4586F.1010709@digium.com> <001e01cadb17$886fcec0$994f6c40$@de> <003101cadb1c$828b3990$87a1acb0$@de> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigAEAF8703DED36F7F839D1C0E" Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 19:00:09 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigAEAF8703DED36F7F839D1C0E Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable stephen botzko wrote: > Fullband is (IMHO) a specsmanship thing for speech (and probably for mu= sic > also for most of us). Though it may not be that hard to get it, if we = are > shooting for superwideband anyway. I think scaling up to fullband and total transparency is important, so that we never have to do this* again. --Ben *: "this" being standardizing a low-latency audio codec. Of course, we can do this again if we want to, but we have an opportunity to be somewha= t "future-proof", and we might as well take it. --------------enigAEAF8703DED36F7F839D1C0E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkvEvycACgkQUJT6e6HFtqRwcQCeIBkvFihYCh2q9dEWKY2hXhCB H0wAmgMeAW0lLf9ITit+zpsDZjrZZTYl =bgjq -----END PGP SIGNATURE----- --------------enigAEAF8703DED36F7F839D1C0E-- From rchen@broadcom.com Tue Apr 13 12:24:01 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEA3928C10C for ; Tue, 13 Apr 2010 12:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GRSBRnLaLXow for ; Tue, 13 Apr 2010 12:23:48 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 282853A67D2 for ; Tue, 13 Apr 2010 12:23:37 -0700 (PDT) Received: from [10.9.200.131] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 13 Apr 2010 12:23:20 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Tue, 13 Apr 2010 12:23:20 -0700 From: "Raymond (Juin-Hwey) Chen" To: "stephen botzko" , "Roman Shpount" Date: Tue, 13 Apr 2010 12:23:14 -0700 Thread-Topic: [codec] #8: Sample rates? Thread-Index: AcrbOTZWi76aUmScTxuZJb1uyJKJzAAAg9tg Message-ID: References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <4BC4586F.1010709@digium.com> <001e01cadb17$886fcec0$994f6c40$@de> <003101cadb1c$828b3990$87a1acb0$@de> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: DxdR IRVg LMl1 MtVd OIAy Pnrv QQVt RPsn R6je Vc5R VxGb XCbT ZGOY ZqSv eAQC fjRp; 3; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAcgBvAG0AYQBuAEAAdABlAGwAdQByAGkAeAAuAGMAbwBtADsAcwB0AGUAcABoAGUAbgAuAGIAbwB0AHoAawBvAEAAZwBtAGEAaQBsAC4AYwBvAG0A; Sosha1_v1; 7; {EFC8A4B4-70EA-41ED-8146-5508C4B35EDE}; cgBjAGgAZQBuAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0A; Tue, 13 Apr 2010 19:23:14 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAIwA4ADoAIABTAGEAbQBwAGwAZQAgAHIAYQB0AGUAcwA/AA== x-cr-puzzleid: {EFC8A4B4-70EA-41ED-8146-5508C4B35EDE} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67DA1B2238O171493291-01-01 Content-Type: multipart/alternative; boundary=_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3D92271IRVEXCHCCR01c_ Cc: "codec@ietf.org" Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 19:24:01 -0000 --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3D92271IRVEXCHCCR01c_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable I would agree with Roman that for speech the difference between wideband (1= 6 kHz sampling) and super-wideband/full-band (32 ~ 48 kHz sampling) is ther= e but very small and many people cannot even distinguish between them, whil= e for music the difference can be much more noticeable. From all the codec = WG emails dating back to last year, it appears to me that most people want = the IETF codec to handle music as well as speech. Therefore, it seems appr= opriate to have the maximum sampling rate up to 48 kHz if we want to the co= dec to handle music. Regarding the dynamic switching of the sampling rate or audio bandwidth, if= this is to be done, I think we need to be careful not to change the audio = bandwidth too frequently, otherwise the frequent change of the audio bandwi= dth can be quite disturbing to the listener. It would certainly be disturb= ing to me personally if the audio bandwidth changes more frequently than on= ce every few seconds, but if it changes once every few minutes, that's prob= ably tolerable to me. Raymond From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of s= tephen botzko Sent: Tuesday, April 13, 2010 11:43 AM To: Roman Shpount Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? >>> I will not argue superwideband vs wideband, even though we did some, not ve= ry scientific, blind tests, and in most cases people (especially men) canno= t even distinguish wideband from superwideband when listening to voice s= amples. Only a very small percentage of voice energy is even present above = 8 Khz. >>> Though there isn't much voice energy over 8 kHz, in our (equally unscientif= ic) tests, sibilants and fricatives are easier to distinguish if you are us= ing superwideband or better. That was one reason we added Annec C to G.722= .1. Fullband is (IMHO) a specsmanship thing for speech (and probably for music = also for most of us). Though it may not be that hard to get it, if we are = shooting for superwideband anyway. Stephen Botzko On Tue, Apr 13, 2010 at 2:11 PM, Roman Shpount > wrote: I will not argue superwideband vs wideband, even though we did some, not ve= ry scientific, blind tests, and in most cases people (especially men) canno= t even distinguish wideband from superwideband when listening to voice samp= les. Only a very small percentage of voice energy is even present above 8 K= hz. Music on the other hand, especially past 24Khz sampling rate, gets affected= by the CODEC more then by bandwidth. For instance 8KHz G.711 encoded music= sounds poor, but reasonable, and G.729 encoded music cannot be listened to= . In most cases (apart from critical listening), music sampled at 16Khz is = acceptable, especially for generation iPod. My remark about RTPC was to try to develop a CODEC that will function prope= rly with RTCP absent. If we require RTCP based mechanisms in order for the = CODEC to operate properly, this can impede the adoption of this CODEC. In n= o way do I propose to create new signaling mechanisms. ______________________________ Roman Shpount - www.telurix.com On Tue, Apr 13, 2010 at 1:29 PM, stephen botzko > wrote: Superwideband (and even fullband) do make speech somewhat more intelligible= , and also reduce listener fatigue. Telepresence and other videoconferenci= ng equipment use those acoustic bandwidths today, so it would be nice if CO= DEC supported at least superwideband also. Personally I see some value in carriage of music. Sometimes our equipment = is used for music performance. Distance learning is another use case where= music has some value, since course and training materials frequently do in= clude videos with music. Though of course conversational speech is the dom= inant use case. BTW, Videoconferencing devices do almost always support RTCP. It is regret= table that so many VOIP devices do not. Anyway, I do not think our charter= scope includes invention of a new mechanism for signaling the network qual= ity. Stephen Botzko On Tue, Apr 13, 2010 at 12:41 PM, Roman Shpount > wrote: I am not sure if this was decided, but should this new CODEC support music = encoding? If we don't plan to support music, we should probably stick to 16= Khz sampling rate. If we need music, I would suggest to have a 24 Khz (or = higher sampling rate) variant. I am not sure how many people here care abou= t a non-voice CODEC. For all the practical purposes I don't. I would argue,= at least, for a fixed 16 KHz sampling rate CODEC variant. P.S. On the same note, does anybody here cares about using this CODEC with = multicast? Is there a single commercial multicast voice deployment? From wh= at I've seen all multicast does is making IETF voice standards harder to un= derstand or implement. P.P.S. RTCP is almost universally not implemented. The biggest VoIP gateway= on the market does not generate RTCP. If we will rely on any RTCP function= ality for bandwidth control it will probably be ignored. ______________________________ Roman Shpount - www.telurix.com On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko > wrote: TCP is a different case, since for this we are using RTCP to signal our fee= dback, and I don't think it has the facility you are envisioning. Also, I disagree with your presumption that multicast is out of scope. I d= on't know of any other packetization RFCs that expressly rule out multicast= , and multicast can be used for interactive applications. This concept seems pretty theoretical to me. If we need to manage complexi= ty / quality tradeoffs, why not just use profiles (as AVC/H.264 does) or cr= eate a low complexity variant (like G.729A). I really don't see the need f= or dynamic complexity management. BTW, you seem to be assuming that a lower sample rate results in significan= tly less complexity. The savings there might not be as great as you think,= especially if the receiver needs to resample anyway (to prevent those soun= d card limitations you were talking about before). Stephen Botzko On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene > wrote: Hi, comments inline: From: stephen botzko [mailto:stephen.botzko@gmail.com] Sent: Tuesday, April 13, 2010 4:56 PM To: Christian Hoene Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? This would make the signaling more complicated - personally I am not convin= ced it is worth it. CH: It is a difficult tradeoff. However, signaling overload is done in Skyp= e. Such as signaling might be very useful for mobile devices, which want t= o save power and thus lower their CPU clock. Or wireless IP based headphone= s which do not have large batteries. I am thinking of signaling the states:= overloaded, fine, and low. That should be enough for most operational case= s. I think a better avenue is to bound overall complexity, and to focus on dyn= amically adapting to network conditions (as opposed to dynamic complexity m= anagement). CH: I just like to remind that the good old TCP does support both: congesti= on control to adapt to network conditions and flow control take into accoun= t an overloaded (=3Dfull) receiver. You can't dynamically negotiate complexity in many scenarios anyway - for i= nstance it makes no sense if you are using multicast. CH: Multicast is out of scope anyhow. We are considering an interactive cod= ec. CH: The conferencing scenario might be some more difficult to handle but wi= ll not a big problem. Christian Stephen Botzko On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene > wrote: Hi, It still might make sense to negotiate the maximal supported sampling rate = via SDP or, if possible, to select one out of multiple sampling rates, if t= he audio receiver can cope with multiple rates well. The internal sampling = frequency of the codec NEEDS NOT to be affected by the external sampling fr= equency. However, the decoder might want to signal to the encoder that the decoding = is requiring too many computational resources and that a less complex codin= g mode (or a lower sampling frequency) should be taken. Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ From: stephen botzko [mailto:stephen.botzko@gmail.com] Sent: Tuesday, April 13, 2010 3:21 PM To: Kevin P. Fleming Cc: Christian Hoene; codec@ietf.org Subject: Re: [codec] #8: Sample rates? Though I generally avoid MAY, this could be a case where it makes sense. Something like: CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to opti= mize audio quality. This is free of any technology assumption about how the acoustic bandwidth = is reduced. The MAY indicates that it is permissible. But if the CODEC al= gorithm doesn't need to reduce the acoustic bandwidth, then we are making n= o statement that it SHOULD (or SHOULD NOT). Kevin is distinguishing dynamic changes to the sample rate (for bandwidth m= anagement) from multiple fixed sample rates; and I agree that is a key dist= inction. I have not heard any clear application requirement for more than one fixed = sampling rate. Though if there is such a requirement, IMHO we would have t= o negotiate the rate within SDP in the usual way, and it would affect the R= TP timestamps, jitter buffers, etc. G.722.1 / G.722.1C is one precedent - = it is the same core codec, but can run at two different sample rates (negot= iated by SDP). Stephen Botzko On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming > wrote: stephen botzko wrote: > Dynamically changing sample rates on the system level adds some > complexity for RTP, since the timestamp granularity is supposed to be > the sample rate. And jitter buffers, and anything else that is based on timestamps and sample rates/counts. If the desire is for the codec to be able to change sample rates to adjust to network conditions, then I agree with Stephen... the 'external' sample rate (input to the encoder and output from the decoder) should be fixed, and this is what would be negotiated in SDP and used for RTP timestamps. The codec can downsample in the encoder and upsample in the decoder if it has decided to transmit fewer bits across the network. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kfleming@digium.com Check us out at www.digium.com & www.asterisk.org _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3D92271IRVEXCHCCR01c_ Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

I would agree with Roman that for speech the difference between= wideband (16 kHz sampling) and super-wideband/full-band (32 ~ 48 kHz sampling) is th= ere but very small and many people cannot even distinguish between them, while = for music the difference can be much more noticeable. From all the codec WG ema= ils dating back to last year, it appears to me that most people want the IETF c= odec to handle music as well as speech.=A0 Therefore, it seems appropriate to ha= ve the maximum sampling rate up to 48 kHz if we want to the codec to handle music.=

 

Regarding the dynamic switching of the sampling rate or audio bandwidth, if this is to be done, I think we need to be careful not to chan= ge the audio bandwidth too frequently, otherwise the frequent change of the audio bandwidth can be quite disturbing to the listener.=A0 It would certainly be disturbing to me personally if the audio bandwidth changes more frequently = than once every few seconds, but if it changes once every few minutes, that̵= 7;s probably tolerable to me.

 

Raymond

 

From: codec-bounces= @ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of stephen botzko
Sent: Tuesday, April 13, 2010 11:43 AM
To: Roman Shpount
Cc: codec@ietf.org
Subject: Re: [codec] #8: Sample rates?

 

>>> 

I will not argue superwideband vs wideband, even thoug= h we did some, not very scientific, blind tests, and in most cases people (especially men) cannot even distinguish wideband from superwideband when    listening to voice samples. Only a very small percen= tage of voice energy is even present above 8 Khz.

>>>
Though there isn't much voice energy over 8 kHz, in our (equally unscientif= ic) tests, sibilants and fricatives are easier to distinguish if you are using superwideband or better.  That was one reason we added Annec C to G.72= 2.1.

Fullband is (IMHO) a specsmanship thing for speech (and probably for music = also for most of us).  Though it may not be that hard to get it, if we are shooting for superwideband anyway.

Stephen Botzko

On Tue, Apr 13, 2010 at 2:11 PM, Roman Shpount <roman@telurix.com> wrote:

I will not argue superwideband vs wideband, even thoug= h we did some, not very scientific, blind tests, and in most cases people (especially men) cannot even distinguish wideband from superwideband when listening to voice samples. Only a very small percentage of voice energy is even present above 8 Khz.

Music on the other hand, especially past 24Khz sampling rate, gets affected= by the CODEC more then by bandwidth. For instance 8KHz G.711 encoded music sou= nds poor, but reasonable, and G.729 encoded music cannot be listened to. In mos= t cases (apart from critical listening), music sampled at 16Khz is acceptable= , especially for generation iPod.

My remark about RTPC was to try to develop a CODEC that will function prope= rly with RTCP absent. If we require RTCP based mechanisms in order for the CODE= C to operate properly, this can impede the adoption of this CODEC. In no way do = I propose to create new signaling mechanisms.


______________________________
Roman Shpount - www.te= lurix.com

On Tue, Apr 13, 2010 at 1:29 PM, stephen botzko <stephen.botzko@g= mail.com> wrote:

Superwideband (and even fullband) do make speech somew= hat more intelligible, and also reduce listener fatigue.  Telepresence and other videoconferencing equipment use those acoustic bandwidths today, so i= t would be nice if CODEC supported at least superwideband also.

Personally I see some value in carriage of music.  Sometimes our equip= ment is used for music performance.  Distance learning is another use case where music has some value, since course and training materials frequently = do include videos with music.  Though of course conversational speech is = the dominant use case.

BTW, Videoconferencing devices do almost always support RTCP.  It is regrettable that so many VOIP devices do not.  Anyway, I do not think = our charter scope includes invention of a new mechanism for signaling the netwo= rk quality.

Stephen Botzko

 

On Tue, Apr 13, 2010 at 12:41 PM, Roman Shpount <roman@telurix.com&g= t; wrote:

I am not sure if this w= as decided, but should this new CODEC support music encoding? If we don't plan= to support music, we should probably stick to 16 Khz sampling rate. If we need music, I would suggest to have a 24 Khz (or higher sampling rate) variant. = I am not sure how many people here care about a non-voice CODEC. For all the practical purposes I don't. I would argue,  at least, for a fixed 16 K= Hz sampling rate CODEC variant.

P.S. On the same note, does anybody here cares about using this CODEC with multicast? Is there a single commercial multicast voice deployment? From wh= at I've seen all multicast does is making IETF voice standards harder to understand or implement.

P.P.S. RTCP is almost universally not implemented. The biggest VoIP gateway= on the market does not generate RTCP. If we will rely on any RTCP functionalit= y for bandwidth control it will probably be ignored.
______________________________
Roman Shpount -  www.telurix.com

On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko <<= a href=3D"mailto:stephen.botzko@gmail.com" target=3D"_blank">stephen.botzko@g= mail.com> wrote:

TCP is a different case= , since for this we are using RTCP to signal our feedback, and I don't think it has= the facility you are envisioning. 

Also, I disagree with your presumption that multicast is out of scope. = ; I don't know of any other packetization RFCs that expressly rule out multicas= t, and multicast can be used for interactive applications.

This concept seems pretty theoretical to me.  If we need to manage complexity / quality tradeoffs, why not just use profiles (as AVC/H.264 doe= s) or create a low complexity variant (like G.729A).  I really don't see = the need for dynamic complexity management.

BTW, you seem to be assuming that a lower sample rate results in significan= tly less complexity.  The savings there might not be as great as you think= , especially if the receiver needs to resample anyway (to prevent those sound card limitations you were talking about before).

Stephen Botzko

On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene <= hoene@uni-tuebinge= n.de> wrote:

Hi,

 

comments inline:

 

 

From: stephen botzk= o [mailto:steph= en.botzko@gmail.com]
Sent: Tuesday, April 13, 2010 4:56 PM
To: Christian Hoene
Cc: codec@ietf.o= rg


Subject: Re: [codec] #8: Sample rates?

 

This would make the signaling more complicated - personally I am = not convinced it is worth it. 

CH: It is a difficult tradeoff. However, signaling overload is done in Skype.  Such as signaling might be very useful for mobile devices, which want= to save power and thus lower their CPU clock. Or wireless IP based headphones which do not have large batteries. I am thinking of signaling the states: overloaded, fine, and low. That should be enough for most operational cases= .


I think a better avenue is to bound overall complexity, and to focus on dynamically adapting to network conditions (as opposed to dynamic complexit= y management).

CH: I just like to remind that the good old TCP does support both: congestion con= trol to adapt to network conditions and flow control take into account an overlo= aded (=3Dfull) receiver.

You can't dynamically negotiate complexity in many scenarios anyway - for insta= nce it makes no sense if you are using multicast.

CH: Multicast is out of scope anyhow. We are considering an interactive codec. =

CH: The conferencing scenario might be some more difficult to handle but will n= ot a big problem.

Christian<= /p>



Stephen Botzko

On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:

Hi,

 

It still might make sense to negotiate the maximal supported sampling rate via= SDP or, if possible, to select one out of multiple sampling rates, if the audio receiver can cope with multiple rates well. The internal sampling frequency= of the codec NEEDS NOT to be affected by the external sampling frequency.

 

However, the decoder might want to signal to the encoder that the decoding is requir= ing too many computational resources and that a less complex coding mode (or a lower sampling frequency) should be taken.

 

Christian

 

 

-------------= --------------------------------------------------

Dr.-Ing. Chri= stian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen

Sand 13, 7207= 6 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen.de/

 

From= : ste= phen botzko [mailto:stephen.botzko@gmail.com]
Sent: Tuesday, April 13, 2010 3:21 PM
To: Kevin P. Fleming
Cc: Christian Hoene; codec@ietf.org
Subject: Re: [codec] #8: Sample rates?

 

Though I generally avoid MAY, this could be a case where it makes sense.

Something like:

CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to opti= mize audio quality.

This is free of any technology assumption about how the acoustic bandwidth is reduced.  The MAY indicates that it is permissible. = But if the CODEC algorithm doesn't need to reduce the acoustic bandwidth, then = we are making no statement that it SHOULD (or SHOULD NOT).

Kevin is distinguishing dynamic changes to the sample rate (for bandwidth management) from multiple fixed sample rates; and I agree that is a key distinction.

I have not heard any clear application requirement for more than one fixed sampling rate.  Though if there is such a requirement, IMHO we would h= ave to negotiate the rate within SDP in the usual way, and it would affect the = RTP timestamps, jitter buffers, etc.  G.722.1 / G.722.1C is one precedent = - it is the same core codec, but can run at two different sample rates (negotiat= ed by SDP).

Stephen Botzko

On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming <kpfleming@digium.com= > wrote:

stephen botzko wrote:

> Dynamically changing sample rates on the system level adds some
> complexity for RTP, since the timestamp granularity is supposed to be<= br> > the sample rate.

And jitter buffers, and anything else that is based on timestamps= and
sample rates/counts. If the desire is for the codec to be able to change sample rates to adjust to network conditions, then I agree with
Stephen... the 'external' sample rate (input to the encoder and output
from the decoder) should be fixed, and this is what would be negotiated
in SDP and used for RTP timestamps. The codec can downsample in the
encoder and upsample in the decoder if it has decided to transmit fewer
bits across the network.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.dig= ium.com & www.asterisk.or= g

 

 

 

_______________________= ________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

 

 

 

 

--_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3D92271IRVEXCHCCR01c_-- From stephen.botzko@gmail.com Tue Apr 13 13:03:45 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 42AFA28C157 for ; Tue, 13 Apr 2010 13:03:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.074, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KnvNy8QbZIcP for ; Tue, 13 Apr 2010 13:03:42 -0700 (PDT) Received: from mail-pz0-f182.google.com (mail-pz0-f182.google.com [209.85.222.182]) by core3.amsl.com (Postfix) with ESMTP id 3CE3928C15D for ; Tue, 13 Apr 2010 13:03:38 -0700 (PDT) Received: by pzk12 with SMTP id 12so646309pzk.32 for ; Tue, 13 Apr 2010 13:03:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=JGO0dDAsVJ51C2ys9oclJ74r+e6YD2mAjuXwZdTSK1I=; b=N+8i85E2STiupvmvw+RWe02YrmZASVPpDJjLSkmQ8Xx2NWkRvJ+9hCffzCLYOr5SUE zIuiEZ2vIZPK9xOpDa/ledKko/yGZvgJO7YO7IPQwuuRUXIeLfwdqELtRE5nhtpAFTO/ W55HRj2YvRV8/t2jsJ4Cb9OrXQQp0K8rW8XsM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RDSTjFilPdd/Ij5TZj42wAMon9sAtDzJUc2pzNEc4crCsiMYmNKxzjKsI+rLHH/NSI ymqRSp6jbQ8R/9i/CbLhFuo3JoMYzKpbeX3BFYpzG/tTLGdDtVnnYWlzmIVQPEvoBznv UwEuf3zCG4TjRLZnDkryaT9BBdpSQTWctbdDk= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Tue, 13 Apr 2010 13:03:29 -0700 (PDT) In-Reply-To: References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <001e01cadb17$886fcec0$994f6c40$@de> <003101cadb1c$828b3990$87a1acb0$@de> Date: Tue, 13 Apr 2010 16:03:29 -0400 Received: by 10.114.186.40 with SMTP id j40mr6124810waf.93.1271189009176; Tue, 13 Apr 2010 13:03:29 -0700 (PDT) Message-ID: From: stephen botzko To: "Raymond (Juin-Hwey) Chen" Content-Type: multipart/alternative; boundary=0016e64cc89655ab0f048423c1ce Cc: "codec@ietf.org" Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 20:03:45 -0000 --0016e64cc89655ab0f048423c1ce Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree. The changes in audio bandwidth will certainly be audible, and personally I would prefer a stable experience. Also, increasing the audio bandwidth might result in audible temporary echo (in the newly opened frequencies), since the acoustic echo cancellers will often need to re-adapt. The acoustic feedback paths can change pretty quickly at higher frequencies. Stephen Botzko On Tue, Apr 13, 2010 at 3:23 PM, Raymond (Juin-Hwey) Chen < rchen@broadcom.com> wrote: > I would agree with Roman that for speech the difference between wideband > (16 kHz sampling) and super-wideband/full-band (32 ~ 48 kHz sampling) is > there but very small and many people cannot even distinguish between them= , > while for music the difference can be much more noticeable. From all the > codec WG emails dating back to last year, it appears to me that most peop= le > want the IETF codec to handle music as well as speech. Therefore, it see= ms > appropriate to have the maximum sampling rate up to 48 kHz if we want to = the > codec to handle music. > > > > Regarding the dynamic switching of the sampling rate or audio bandwidth, = if > this is to be done, I think we need to be careful not to change the audio > bandwidth too frequently, otherwise the frequent change of the audio > bandwidth can be quite disturbing to the listener. It would certainly be > disturbing to me personally if the audio bandwidth changes more frequentl= y > than once every few seconds, but if it changes once every few minutes, > that=92s probably tolerable to me. > > > > Raymond > > > > *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf > Of *stephen botzko > *Sent:* Tuesday, April 13, 2010 11:43 AM > *To:* Roman Shpount > > *Cc:* codec@ietf.org > *Subject:* Re: [codec] #8: Sample rates? > > > > >>> > > I will not argue superwideband vs wideband, even though we did some, not > very scientific, blind tests, and in most cases people (especially men) > cannot even distinguish wideband from superwideband when listening to > voice samples. Only a very small percentage of voice energy is even prese= nt > above 8 Khz. > > >>> > Though there isn't much voice energy over 8 kHz, in our (equally > unscientific) tests, sibilants and fricatives are easier to distinguish i= f > you are using superwideband or better. That was one reason we added Anne= c C > to G.722.1. > > Fullband is (IMHO) a specsmanship thing for speech (and probably for musi= c > also for most of us). Though it may not be that hard to get it, if we ar= e > shooting for superwideband anyway. > > Stephen Botzko > > On Tue, Apr 13, 2010 at 2:11 PM, Roman Shpount wrote= : > > I will not argue superwideband vs wideband, even though we did some, not > very scientific, blind tests, and in most cases people (especially men) > cannot even distinguish wideband from superwideband when listening to voi= ce > samples. Only a very small percentage of voice energy is even present abo= ve > 8 Khz. > > Music on the other hand, especially past 24Khz sampling rate, gets affect= ed > by the CODEC more then by bandwidth. For instance 8KHz G.711 encoded musi= c > sounds poor, but reasonable, and G.729 encoded music cannot be listened t= o. > In most cases (apart from critical listening), music sampled at 16Khz is > acceptable, especially for generation iPod. > > My remark about RTPC was to try to develop a CODEC that will function > properly with RTCP absent. If we require RTCP based mechanisms in order f= or > the CODEC to operate properly, this can impede the adoption of this CODEC= . > In no way do I propose to create new signaling mechanisms. > > > ______________________________ > Roman Shpount - www.telurix.com > > On Tue, Apr 13, 2010 at 1:29 PM, stephen botzko < > stephen.botzko@gmail.com> wrote: > > Superwideband (and even fullband) do make speech somewhat more > intelligible, and also reduce listener fatigue. Telepresence and other > videoconferencing equipment use those acoustic bandwidths today, so it wo= uld > be nice if CODEC supported at least superwideband also. > > Personally I see some value in carriage of music. Sometimes our equipmen= t > is used for music performance. Distance learning is another use case whe= re > music has some value, since course and training materials frequently do > include videos with music. Though of course conversational speech is the > dominant use case. > > BTW, Videoconferencing devices do almost always support RTCP. It is > regrettable that so many VOIP devices do not. Anyway, I do not think our > charter scope includes invention of a new mechanism for signaling the > network quality. > > Stephen Botzko > > > > On Tue, Apr 13, 2010 at 12:41 PM, Roman Shpount wrote= : > > I am not sure if this was decided, but should this new CODEC support musi= c > encoding? If we don't plan to support music, we should probably stick to = 16 > Khz sampling rate. If we need music, I would suggest to have a 24 Khz (or > higher sampling rate) variant. I am not sure how many people here care ab= out > a non-voice CODEC. For all the practical purposes I don't. I would argue, > at least, for a fixed 16 KHz sampling rate CODEC variant. > > P.S. On the same note, does anybody here cares about using this CODEC wit= h > multicast? Is there a single commercial multicast voice deployment? From > what I've seen all multicast does is making IETF voice standards harder t= o > understand or implement. > > P.P.S. RTCP is almost universally not implemented. The biggest VoIP gatew= ay > on the market does not generate RTCP. If we will rely on any RTCP > functionality for bandwidth control it will probably be ignored. > ______________________________ > Roman Shpount - www.telurix.com > > On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko < > stephen.botzko@gmail.com> wrote: > > TCP is a different case, since for this we are using RTCP to signal our > feedback, and I don't think it has the facility you are envisioning. > > Also, I disagree with your presumption that multicast is out of scope. I > don't know of any other packetization RFCs that expressly rule out > multicast, and multicast can be used for interactive applications. > > This concept seems pretty theoretical to me. If we need to manage > complexity / quality tradeoffs, why not just use profiles (as AVC/H.264 > does) or create a low complexity variant (like G.729A). I really don't s= ee > the need for *dynamic* complexity management. > > BTW, you seem to be assuming that a lower sample rate results in > significantly less complexity. The savings there might not be as great a= s > you think, especially if the receiver needs to resample anyway (to preven= t > those sound card limitations you were talking about before). > > Stephen Botzko > > On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene > wrote: > > Hi, > > > > comments inline: > > > > > > *From:* stephen botzko [mailto:stephen.botzko@gmail.com] > *Sent:* Tuesday, April 13, 2010 4:56 PM > *To:* Christian Hoene > *Cc:* codec@ietf.org > > > *Subject:* Re: [codec] #8: Sample rates? > > > > This would make the signaling more complicated - personally I am not > convinced it is worth it. > > CH: It is a difficult tradeoff. However, signaling overload is done in > Skype. Such as signaling might be very useful for mobile devices, which > want to save power and thus lower their CPU clock. Or wireless IP based > headphones which do not have large batteries. I am thinking of signaling = the > states: overloaded, fine, and low. That should be enough for most > operational cases. > > > I think a better avenue is to bound overall complexity, and to focus on > dynamically adapting to network conditions (as opposed to dynamic complex= ity > management). > > CH: I just like to remind that the good old TCP does support both: > congestion control to adapt to network conditions and flow control take i= nto > account an overloaded (=3Dfull) receiver. > > You can't dynamically negotiate complexity in many scenarios anyway - for > instance it makes no sense if you are using multicast. > > CH: Multicast is out of scope anyhow. We are considering an interactive > codec. > > CH: The conferencing scenario might be some more difficult to handle but > will not a big problem. > > Christian > > > > Stephen Botzko > > On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene > wrote: > > Hi, > > > > It still might make sense to negotiate the maximal supported sampling rat= e > via SDP or, if possible, to select one out of multiple sampling rates, if > the audio receiver can cope with multiple rates well. The internal sampli= ng > frequency of the codec NEEDS NOT to be affected by the external sampling > frequency. > > > > However, the decoder might want to signal to the encoder that the decodin= g > is requiring too many computational resources and that a less complex cod= ing > mode (or a lower sampling frequency) should be taken. > > > > Christian > > > > > > --------------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of T=FCbingen > > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > > > *From:* stephen botzko [mailto:stephen.botzko@gmail.com] > *Sent:* Tuesday, April 13, 2010 3:21 PM > *To:* Kevin P. Fleming > *Cc:* Christian Hoene; codec@ietf.org > *Subject:* Re: [codec] #8: Sample rates? > > > > Though I generally avoid MAY, this could be a case where it makes sense. > > Something like: > > CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to > optimize audio quality. > > This is free of any technology assumption about *how* the acoustic > bandwidth is reduced. The MAY indicates that it is permissible. But if = the > CODEC algorithm doesn't need to reduce the acoustic bandwidth, then we ar= e > making no statement that it SHOULD (or SHOULD NOT). > > Kevin is distinguishing dynamic changes to the sample rate (for bandwidth > management) from multiple fixed sample rates; and I agree that is a key > distinction. > > I have not heard any clear application requirement for more than one fixe= d > sampling rate. Though if there is such a requirement, IMHO we would have= to > negotiate the rate within SDP in the usual way, and it would affect the R= TP > timestamps, jitter buffers, etc. G.722.1 / G.722.1C is one precedent - i= t > is the same core codec, but can run at two different sample rates > (negotiated by SDP). > > Stephen Botzko > > On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming > wrote: > > stephen botzko wrote: > > > Dynamically changing sample rates on the system level adds some > > complexity for RTP, since the timestamp granularity is supposed to be > > the sample rate. > > And jitter buffers, and anything else that is based on timestamps and > sample rates/counts. If the desire is for the codec to be able to change > sample rates to adjust to network conditions, then I agree with > Stephen... the 'external' sample rate (input to the encoder and output > from the decoder) should be fixed, and this is what would be negotiated > in SDP and used for RTP timestamps. The codec can downsample in the > encoder and upsample in the decoder if it has decided to transmit fewer > bits across the network. > > -- > Kevin P. Fleming > Digium, Inc. | Director of Software Technologies > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > skype: kpfleming | jabber: kfleming@digium.com > Check us out at www.digium.com & www.asterisk.org > > > > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > > > > > > > --0016e64cc89655ab0f048423c1ce Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree.=A0

The changes in audio bandwidth will certainly be audibl= e, and personally I would prefer a stable experience.=A0

Also, incr= easing the audio bandwidth might result in audible temporary echo (in the n= ewly opened frequencies), since the acoustic echo cancellers will often nee= d to re-adapt.=A0 The acoustic feedback paths can change pretty quickly at = higher frequencies.

Stephen Botzko

On Tue, Apr 13, 2010 a= t 3:23 PM, Raymond (Juin-Hwey) Chen <rchen@broadcom.com> wrote:

I woul= d agree with Roman that for speech the difference between wideband (16 kHz sampling) and super-wideband/full-band (32 ~ 48 kHz sampling) is th= ere but very small and many people cannot even distinguish between them, while = for music the difference can be much more noticeable. From all the codec WG ema= ils dating back to last year, it appears to me that most people want the IETF c= odec to handle music as well as speech.=A0 Therefore, it seems appropriate to ha= ve the maximum sampling rate up to 48 kHz if we want to the codec to handle music.=

=A0

Regard= ing the dynamic switching of the sampling rate or audio bandwidth, if this is to be done, I think we need to be careful not to chan= ge the audio bandwidth too frequently, otherwise the frequent change of the audio bandwidth can be quite disturbing to the listener.=A0 It would certainly be disturbing to me personally if the audio bandwidth changes more frequently = than once every few seconds, but if it changes once every few minutes, that=92s probably tolerable to me.

=A0

Raymon= d

=A0

From:= codec-bounces@ietf.org [mailto:codec-b= ounces@ietf.org] On Behalf Of stephen botzko
Sent: Tuesday, April 13, 2010 11:43 AM
To: Roman Shpount


Cc: codec@ietf.o= rg
Subject: Re: [codec] #8: Sample rates?

=A0

>>>=A0

I will not argue superwideband vs wideband, even tho= ugh we did some, not very scientific, blind tests, and in most cases people (especially men) cannot even distinguish wideband from superwideband when=A0=A0=A0 listening to voice samples. Only a very small percentage of voice energy is even present above 8 Khz.

>>>
Though there isn't much voice energy over 8 kHz, in our (equally unscie= ntific) tests, sibilants and fricatives are easier to distinguish if you are using superwideband or better.=A0 That was one reason we added Annec C to G.722.1= .

Fullband is (IMHO) a specsmanship thing for speech (and probably for music = also for most of us).=A0 Though it may not be that hard to get it, if we are shooting for superwideband anyway.

Stephen Botzko

On Tue, Apr 13, 2010 at 2:11 PM, Roman Shpount <<= a href=3D"mailto:roman@telurix.com" target=3D"_blank">roman@telurix.com= > wrote:

I will not argue superwideband vs wideband, even tho= ugh we did some, not very scientific, blind tests, and in most cases people (especially men) cannot even distinguish wideband from superwideband when listening to voice samples. Only a very small percentage of voice energy is even present above 8 Khz.

Music on the other hand, especially past 24Khz sampling rate, gets affected= by the CODEC more then by bandwidth. For instance 8KHz G.711 encoded music sou= nds poor, but reasonable, and G.729 encoded music cannot be listened to. In mos= t cases (apart from critical listening), music sampled at 16Khz is acceptable= , especially for generation iPod.

My remark about RTPC was to try to develop a CODEC that will function prope= rly with RTCP absent. If we require RTCP based mechanisms in order for the CODE= C to operate properly, this can impede the adoption of this CODEC. In no way do = I propose to create new signaling mechanisms.


______________________________
Roman Shpount - www.te= lurix.com

On Tue, Apr 13, 2010 at 1:29 PM, stephen botzko <= stephen.botzk= o@gmail.com> wrote:

Superwideband (and even fullband) do make speech som= ewhat more intelligible, and also reduce listener fatigue.=A0 Telepresence and other videoconferencing equipment use those acoustic bandwidths today, so i= t would be nice if CODEC supported at least superwideband also.

Personally I see some value in carriage of music.=A0 Sometimes our equipmen= t is used for music performance.=A0 Distance learning is another use case where music has some value, since course and training materials frequently = do include videos with music.=A0 Though of course conversational speech is the dominant use case.

BTW, Videoconferencing devices do almost always support RTCP.=A0 It is regrettable that so many VOIP devices do not.=A0 Anyway, I do not think our charter scope includes invention of a new mechanism for signaling the netwo= rk quality.

Stephen Botzko

=A0

On Tue, Apr 13, 2010 at 12:41 PM, Roman Shpount <= roman@telurix.com> wrote:

I am not sure if this= was decided, but should this new CODEC support music encoding? If we don't = plan to support music, we should probably stick to 16 Khz sampling rate. If we need music, I would suggest to have a 24 Khz (or higher sampling rate) variant. = I am not sure how many people here care about a non-voice CODEC. For all the practical purposes I don't. I would argue,=A0 at least, for a fixed 16 = KHz sampling rate CODEC variant.

P.S. On the same note, does anybody here cares about using this CODEC with multicast? Is there a single commercial multicast voice deployment? From wh= at I've seen all multicast does is making IETF voice standards harder to understand or implement.

P.P.S. RTCP is almost universally not implemented. The biggest VoIP gateway= on the market does not generate RTCP. If we will rely on any RTCP functionalit= y for bandwidth control it will probably be ignored.
______________________________
Roman Shpount -=A0 www.telurix.com

On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko <= ;stephen.botz= ko@gmail.com> wrote:

TCP is a different ca= se, since for this we are using RTCP to signal our feedback, and I don't think it= has the facility you are envisioning.=A0

Also, I disagree with your presumption that multicast is out of scope.=A0 I don't know of any other packetization RFCs that expressly rule out mult= icast, and multicast can be used for interactive applications.

This concept seems pretty theoretical to me.=A0 If we need to manage complexity / quality tradeoffs, why not just use profiles (as AVC/H.264 doe= s) or create a low complexity variant (like G.729A).=A0 I really don't see= the need for dynamic complexity management.

BTW, you seem to be assuming that a lower sample rate results in significan= tly less complexity.=A0 The savings there might not be as great as you think, especially if the receiver needs to resample anyway (to prevent those sound card limitations you were talking about before).

Stephen Botzko

On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene &l= t;hoene@uni-tue= bingen.de> wrote:

Hi,

=A0

comments inline:

=A0

=A0

From:= stephen botzko [mailto:steph= en.botzko@gmail.com]
Sent: Tuesday, April 13, 2010 4:56 PM
To: Christian Hoene
Cc: codec@ietf.o= rg


Subject: Re: [codec] #8: Sample rates?

=A0

Thi= s would make the signaling more complicated - personally I am not convinced it is worth it.=A0

CH: It is a difficult tradeoff. However, signaling overload is done in Skype. =A0Such as signaling might be very useful for mobile devices, which want to save power and thus lower their CPU clock. Or wireless IP based headphones which do not have large batteries. I am thinking of signaling the states: overloaded, fine, and low. That should be enough for most operational cases= .


I think a better avenue is to bound overall complexity, and to focus on dynamically adapting to network conditions (as opposed to dynamic complexit= y management).

CH: I just like to remind that the good old TCP does support both: congestion con= trol to adapt to network conditions and flow control take into account an overlo= aded (=3Dfull) receiver.

You can't dynamically negotiate complexity in many scenarios anyway - for i= nstance it makes no sense if you are using multicast.

CH: Multicast is out of scope anyhow. We are considering an interactive codec. =

CH: The conferencing scenario might be some more difficult to handle but will n= ot a big problem.

Christian



Stephen Botzko

On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene <= hoene@uni-tuebingen.de> wrote:

Hi,

=A0

It still might make sense to negotiate the maximal supported sampling rate via= SDP or, if possible, to select one out of multiple sampling rates, if the audio receiver can cope with multiple rates well. The internal sampling frequency= of the codec NEEDS NOT to be affected by the external sampling frequency.

=A0

However, the decoder might want to signal to the encoder that the decoding is requir= ing too many computational resources and that a less complex coding mode (or a lower sampling frequency) should be taken.<= /p>

=A0

Christian

=A0

=A0

--------------------------------------------= -------------------

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen.de/=

=A0

From= : stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Tuesday, April 13, 2010 3:21 PM
To: Kevin P. Fleming
Cc: Christian Hoene; codec@ietf.org
Subject: Re: [codec] #8: Sample rates?

=A0

Tho= ugh I generally avoid MAY, this could be a case where it makes sense.

Something like:

CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to opti= mize audio quality.

This is free of any technology assumption about how the acoustic bandwidth is reduced.=A0 The MAY indicates that it is permissible.=A0 But if the CODEC algorithm doesn't need to reduce the acoustic bandwidth, t= hen we are making no statement that it SHOULD (or SHOULD NOT).

Kevin is distinguishing dynamic changes to the sample rate (for bandwidth management) from multiple fixed sample rates; and I agree that is a key distinction.

I have not heard any clear application requirement for more than one fixed sampling rate.=A0 Though if there is such a requirement, IMHO we would have to negotiate the rate within SDP in the usual way, and it would affect the = RTP timestamps, jitter buffers, etc.=A0 G.722.1 / G.722.1C is one precedent - i= t is the same core codec, but can run at two different sample rates (negotiat= ed by SDP).

Stephen Botzko

On Tue, Apr 13, 2010 at 7:41 AM, K= evin P. Fleming <kpfleming@digium.com> wrote:

ste= phen botzko wrote:

> Dynamically changing sample rates on the system level adds some
> complexity for RTP, since the timestamp granularity is supposed to be<= br> > the sample rate.

And jitter buffers, and anything e= lse that is based on timestamps and
sample rates/counts. If the desire is for the codec to be able to change sample rates to adjust to network conditions, then I agree with
Stephen... the 'external' sample rate (input to the encoder and out= put
from the decoder) should be fixed, and this is what would be negotiated
in SDP and used for RTP timestamps. The codec can downsample in the
encoder and upsample in the decoder if it has decided to transmit fewer
bits across the network.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.dig= ium.com & www.asterisk.or= g

=A0

=A0

=A0

_____________________= __________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

=A0

=A0

=A0

=A0


--0016e64cc89655ab0f048423c1ce-- From koen.vos@skype.net Tue Apr 13 16:48:28 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C53893A6B32 for ; Tue, 13 Apr 2010 16:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.601 X-Spam-Level: X-Spam-Status: No, score=-4.601 tagged_above=-999 required=5 tests=[AWL=0.602, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzOsnwj388uG for ; Tue, 13 Apr 2010 16:48:26 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id B9D9B3A69D5 for ; Tue, 13 Apr 2010 16:48:25 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 8E59760133B7A for ; Wed, 14 Apr 2010 00:48:19 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=OEvtiL5Z73GG zsBe/vEpn84//Zo=; b=Z0u8KfNGcjGKR5C/X8aGcyY/qiY6XCoxfXWK7RGxWlSQ BKwCjnuYE7hHB1GpSk2A2TQXlSFWQ4ouaM2s7/crrBCPVcGFVQEUXjfhiCJ9It4T ToKS92grjfJR4k9jl1Xs23U5CfGx86A01H0Y5kwgPtb1tvdkNgMMltdXGN4OXcc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=faY5AhXEum+QeTCj7aw/ y/iVtueVhq+4IvYQ0PVq9AOyNNhkzt4sM5zHV/VPPl688ZUBujWbRa+0zeyvVcUv Kku0n6D1RawLJQPpqU49m/nKxtS3UwKRgoa1PSYtWBRUx4UNcBclTNGLUmklgpFS 9VkpqMKKB40JQYOkXDSKVD8= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 8C93060133B76 for ; Wed, 14 Apr 2010 00:48:19 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EfQJHv1QUkdg for ; Wed, 14 Apr 2010 00:48:18 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 52FBB60133B77; Wed, 14 Apr 2010 00:48:18 +0100 (IST) Received: from adsl-71-141-129-119.dsl.snfc21.pacbell.net (adsl-71-141-129-119.dsl.snfc21.pacbell.net [71.141.129.119]) by mail.skype.net (Horde Framework) with HTTP; Tue, 13 Apr 2010 16:48:18 -0700 Message-ID: <20100413164818.546929eae97cjjr6@mail.skype.net> Date: Tue, 13 Apr 2010 16:48:18 -0700 From: Koen Vos To: codec@ietf.org References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <001e01cadb17$886fcec0$994f6c40$@de> <003101cadb1c$828b3990$87a1acb0$@de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Apr 2010 23:48:28 -0000 My 2 cents on this thread: - Going beyond WB quality matters a lot, even for speech. See for =20 example slides 2, 3 of =20 http://www.ietf.org/proceedings/10mar/slides/codec-3.pdf. Agree with =20 Ben that we might as well go full-band. - The codec has 3 sampling rates: 1. Encoder API 2. Codec internal (not strictly sampling rate, more audio bandwidth =20 as Stephen pointed out) 3. Decoder API I don't see a reason to impose that some or all of these be identical. =20 For (conference) mixing of several streams it helps if all decoders =20 run at the same API sampling rate. It would be unreasonable to require =20 that every encoder also runs at that API sampling rate. Some encoders =20 may for instance sit in a PSTN gateway, dealing strictly with =20 narrowband signals. - To keep RTP timestamps simple, they could always be based on the =20 same sampling rate, irrespective of any of the ones above. Maybe 48 =20 kHz is a good choice? - Sometimes a decoder runs on hardware with limited audio bandwidth =20 playback capabilities (e.g. mobile devices). In those cases it helps =20 if the decoder can request a maximum internal audio bandwidth to the =20 encoder, during call setup. Otherwise the encoder may be wasting bits =20 on unused audio spectrum. So I agree with Christian on this. - Agree with Raymond that fast switching of audio bandwidth sounds =20 unpleasant. SILK has a hysteresis mechanism for this, and we rarely =20 get more than one or two switches during a Skype call. best, koen. Quoting stephen botzko : > I agree. > > The changes in audio bandwidth will certainly be audible, and personally I > would prefer a stable experience. > > Also, increasing the audio bandwidth might result in audible temporary ech= o > (in the newly opened frequencies), since the acoustic echo cancellers will > often need to re-adapt. The acoustic feedback paths can change pretty > quickly at higher frequencies. > > Stephen Botzko > > On Tue, Apr 13, 2010 at 3:23 PM, Raymond (Juin-Hwey) Chen < > rchen@broadcom.com> wrote: > >> I would agree with Roman that for speech the difference between wideband >> (16 kHz sampling) and super-wideband/full-band (32 ~ 48 kHz sampling) is >> there but very small and many people cannot even distinguish between them= , >> while for music the difference can be much more noticeable. From all the >> codec WG emails dating back to last year, it appears to me that most peop= le >> want the IETF codec to handle music as well as speech. Therefore, it see= ms >> appropriate to have the maximum sampling rate up to 48 kHz if we want to = the >> codec to handle music. >> >> >> >> Regarding the dynamic switching of the sampling rate or audio bandwidth, = if >> this is to be done, I think we need to be careful not to change the audio >> bandwidth too frequently, otherwise the frequent change of the audio >> bandwidth can be quite disturbing to the listener. It would certainly be >> disturbing to me personally if the audio bandwidth changes more frequentl= y >> than once every few seconds, but if it changes once every few minutes, >> that's probably tolerable to me. >> >> >> >> Raymond >> >> >> >> *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf >> Of *stephen botzko >> *Sent:* Tuesday, April 13, 2010 11:43 AM >> *To:* Roman Shpount >> >> *Cc:* codec@ietf.org >> *Subject:* Re: [codec] #8: Sample rates? >> >> >> >> >>> >> >> I will not argue superwideband vs wideband, even though we did some, not >> very scientific, blind tests, and in most cases people (especially men) >> cannot even distinguish wideband from superwideband when listening to >> voice samples. Only a very small percentage of voice energy is even prese= nt >> above 8 Khz. >> >> >>> >> Though there isn't much voice energy over 8 kHz, in our (equally >> unscientific) tests, sibilants and fricatives are easier to distinguish i= f >> you are using superwideband or better. That was one reason we added Anne= c C >> to G.722.1. >> >> Fullband is (IMHO) a specsmanship thing for speech (and probably for musi= c >> also for most of us). Though it may not be that hard to get it, if we ar= e >> shooting for superwideband anyway. >> >> Stephen Botzko >> >> On Tue, Apr 13, 2010 at 2:11 PM, Roman Shpount wrote= : >> >> I will not argue superwideband vs wideband, even though we did some, not >> very scientific, blind tests, and in most cases people (especially men) >> cannot even distinguish wideband from superwideband when listening to voi= ce >> samples. Only a very small percentage of voice energy is even present abo= ve >> 8 Khz. >> >> Music on the other hand, especially past 24Khz sampling rate, gets affect= ed >> by the CODEC more then by bandwidth. For instance 8KHz G.711 encoded musi= c >> sounds poor, but reasonable, and G.729 encoded music cannot be listened t= o. >> In most cases (apart from critical listening), music sampled at 16Khz is >> acceptable, especially for generation iPod. >> >> My remark about RTPC was to try to develop a CODEC that will function >> properly with RTCP absent. If we require RTCP based mechanisms in order f= or >> the CODEC to operate properly, this can impede the adoption of this CODEC= . >> In no way do I propose to create new signaling mechanisms. >> >> >> ______________________________ >> Roman Shpount - www.telurix.com >> >> On Tue, Apr 13, 2010 at 1:29 PM, stephen botzko < >> stephen.botzko@gmail.com> wrote: >> >> Superwideband (and even fullband) do make speech somewhat more >> intelligible, and also reduce listener fatigue. Telepresence and other >> videoconferencing equipment use those acoustic bandwidths today, so it wo= uld >> be nice if CODEC supported at least superwideband also. >> >> Personally I see some value in carriage of music. Sometimes our equipmen= t >> is used for music performance. Distance learning is another use case whe= re >> music has some value, since course and training materials frequently do >> include videos with music. Though of course conversational speech is the >> dominant use case. >> >> BTW, Videoconferencing devices do almost always support RTCP. It is >> regrettable that so many VOIP devices do not. Anyway, I do not think our >> charter scope includes invention of a new mechanism for signaling the >> network quality. >> >> Stephen Botzko >> >> >> >> On Tue, Apr 13, 2010 at 12:41 PM, Roman Shpount wrote= : >> >> I am not sure if this was decided, but should this new CODEC support musi= c >> encoding? If we don't plan to support music, we should probably stick to = 16 >> Khz sampling rate. If we need music, I would suggest to have a 24 Khz (or >> higher sampling rate) variant. I am not sure how many people here care ab= out >> a non-voice CODEC. For all the practical purposes I don't. I would argue, >> at least, for a fixed 16 KHz sampling rate CODEC variant. >> >> P.S. On the same note, does anybody here cares about using this CODEC wit= h >> multicast? Is there a single commercial multicast voice deployment? From >> what I've seen all multicast does is making IETF voice standards harder t= o >> understand or implement. >> >> P.P.S. RTCP is almost universally not implemented. The biggest VoIP gatew= ay >> on the market does not generate RTCP. If we will rely on any RTCP >> functionality for bandwidth control it will probably be ignored. >> ______________________________ >> Roman Shpount - www.telurix.com >> >> On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko < >> stephen.botzko@gmail.com> wrote: >> >> TCP is a different case, since for this we are using RTCP to signal our >> feedback, and I don't think it has the facility you are envisioning. >> >> Also, I disagree with your presumption that multicast is out of scope. I >> don't know of any other packetization RFCs that expressly rule out >> multicast, and multicast can be used for interactive applications. >> >> This concept seems pretty theoretical to me. If we need to manage >> complexity / quality tradeoffs, why not just use profiles (as AVC/H.264 >> does) or create a low complexity variant (like G.729A). I really don't s= ee >> the need for *dynamic* complexity management. >> >> BTW, you seem to be assuming that a lower sample rate results in >> significantly less complexity. The savings there might not be as great a= s >> you think, especially if the receiver needs to resample anyway (to preven= t >> those sound card limitations you were talking about before). >> >> Stephen Botzko >> >> On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene >> wrote: >> >> Hi, >> >> >> >> comments inline: >> >> >> >> >> >> *From:* stephen botzko [mailto:stephen.botzko@gmail.com] >> *Sent:* Tuesday, April 13, 2010 4:56 PM >> *To:* Christian Hoene >> *Cc:* codec@ietf.org >> >> >> *Subject:* Re: [codec] #8: Sample rates? >> >> >> >> This would make the signaling more complicated - personally I am not >> convinced it is worth it. >> >> CH: It is a difficult tradeoff. However, signaling overload is done in >> Skype. Such as signaling might be very useful for mobile devices, which >> want to save power and thus lower their CPU clock. Or wireless IP based >> headphones which do not have large batteries. I am thinking of signaling = the >> states: overloaded, fine, and low. That should be enough for most >> operational cases. >> >> >> I think a better avenue is to bound overall complexity, and to focus on >> dynamically adapting to network conditions (as opposed to dynamic complex= ity >> management). >> >> CH: I just like to remind that the good old TCP does support both: >> congestion control to adapt to network conditions and flow control take i= nto >> account an overloaded (=3Dfull) receiver. >> >> You can't dynamically negotiate complexity in many scenarios anyway - for >> instance it makes no sense if you are using multicast. >> >> CH: Multicast is out of scope anyhow. We are considering an interactive >> codec. >> >> CH: The conferencing scenario might be some more difficult to handle but >> will not a big problem. >> >> Christian >> >> >> >> Stephen Botzko >> >> On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene >> wrote: >> >> Hi, >> >> >> >> It still might make sense to negotiate the maximal supported sampling rat= e >> via SDP or, if possible, to select one out of multiple sampling rates, if >> the audio receiver can cope with multiple rates well. The internal sampli= ng >> frequency of the codec NEEDS NOT to be affected by the external sampling >> frequency. >> >> >> >> However, the decoder might want to signal to the encoder that the decodin= g >> is requiring too many computational resources and that a less complex cod= ing >> mode (or a lower sampling frequency) should be taken. >> >> >> >> Christian >> >> >> >> >> >> --------------------------------------------------------------- >> >> Dr.-Ing. Christian Hoene >> >> Interactive Communication Systems (ICS), University of T=FCbingen >> >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >> http://www.net.uni-tuebingen.de/ >> >> >> >> *From:* stephen botzko [mailto:stephen.botzko@gmail.com] >> *Sent:* Tuesday, April 13, 2010 3:21 PM >> *To:* Kevin P. Fleming >> *Cc:* Christian Hoene; codec@ietf.org >> *Subject:* Re: [codec] #8: Sample rates? >> >> >> >> Though I generally avoid MAY, this could be a case where it makes sense. >> >> Something like: >> >> CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to >> optimize audio quality. >> >> This is free of any technology assumption about *how* the acoustic >> bandwidth is reduced. The MAY indicates that it is permissible. But if = the >> CODEC algorithm doesn't need to reduce the acoustic bandwidth, then we ar= e >> making no statement that it SHOULD (or SHOULD NOT). >> >> Kevin is distinguishing dynamic changes to the sample rate (for bandwidth >> management) from multiple fixed sample rates; and I agree that is a key >> distinction. >> >> I have not heard any clear application requirement for more than one fixe= d >> sampling rate. Though if there is such a requirement, IMHO we would have= to >> negotiate the rate within SDP in the usual way, and it would affect the R= TP >> timestamps, jitter buffers, etc. G.722.1 / G.722.1C is one precedent - i= t >> is the same core codec, but can run at two different sample rates >> (negotiated by SDP). >> >> Stephen Botzko >> >> On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming >> wrote: >> >> stephen botzko wrote: >> >> > Dynamically changing sample rates on the system level adds some >> > complexity for RTP, since the timestamp granularity is supposed to be >> > the sample rate. >> >> And jitter buffers, and anything else that is based on timestamps and >> sample rates/counts. If the desire is for the codec to be able to change >> sample rates to adjust to network conditions, then I agree with >> Stephen... the 'external' sample rate (input to the encoder and output >> from the decoder) should be fixed, and this is what would be negotiated >> in SDP and used for RTP timestamps. The codec can downsample in the >> encoder and upsample in the decoder if it has decided to transmit fewer >> bits across the network. >> >> -- >> Kevin P. Fleming >> Digium, Inc. | Director of Software Technologies >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >> skype: kpfleming | jabber: kfleming@digium.com >> Check us out at www.digium.com & www.asterisk.org >> >> >> >> >> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> >> >> >> >> >> >> > From stephen.botzko@gmail.com Tue Apr 13 17:24:18 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5CB73A6ADD for ; Tue, 13 Apr 2010 17:24:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.23 X-Spam-Level: X-Spam-Status: No, score=-2.23 tagged_above=-999 required=5 tests=[AWL=-0.232, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_23=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rVnFpowbCBsa for ; Tue, 13 Apr 2010 17:24:16 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id B836428C12F for ; Tue, 13 Apr 2010 17:23:49 -0700 (PDT) Received: by gyh4 with SMTP id 4so3889248gyh.31 for ; Tue, 13 Apr 2010 17:23:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=U0oRxpWRapU7lepiznJJ7hTnVDlE/0nT+xzr1TynXRM=; b=RW94gHHOoXd+E+/pu4D0ORml99J8qbmtu7t6j6ZC62pLKFVN2AYD3bEYy9ncQ0o36n Ma5ZFSOHmUMgnqq0rzqiQHuMVHBckwUV4fDchHiiLuLvwaFHDnB2bp7ioEo7s1bO+vIK dD+AbapRJUxdUoSkq/WqYDEEjhO+Fgktm22NU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=eLXydGy+PKcowjllF6H9zVFWOSJRzCpZ42f8ePUkhwlr6B9rbdTRpT32Xo8pXq7g3z ylkLCigDebsBVA2AipkqhLuo1v4JybTpWpk5tuSBJSIEMaqcJaeFXlDEnBvIKy78kBC6 u2OaS9PsjuShr6zzbCYQNxZwv87rG/lEKehHY= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Tue, 13 Apr 2010 17:23:40 -0700 (PDT) In-Reply-To: <20100413164818.546929eae97cjjr6@mail.skype.net> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <003101cadb1c$828b3990$87a1acb0$@de> <20100413164818.546929eae97cjjr6@mail.skype.net> Date: Tue, 13 Apr 2010 20:23:40 -0400 Received: by 10.101.150.5 with SMTP id c5mr11261416ano.158.1271204620312; Tue, 13 Apr 2010 17:23:40 -0700 (PDT) Message-ID: From: stephen botzko To: Koen Vos Content-Type: multipart/alternative; boundary=0016e68ea0a7d4a1f30484276351 Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 00:24:19 -0000 --0016e68ea0a7d4a1f30484276351 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not sure exactly what you mean by "API rate". Seems to me that the reference encoder source code might accept any sample rate, but convert it to 48 kHz before encoding. If that is what you mean, then the two API rates are never signaled? I rather like the idea of negotiating maximum audio bandwidth. For me that is different from dynamic complexity management, and is being signaled for = a different purpose (wasting coded bits on unheard spectrum degrades the quality of the heard spectrum). Signaling the bandwidth, and defining the internal codec rate as fullband should let us lock down the RTP timestamp rate at 48 kHz (which I think is desirable). Stephen Botzko On Tue, Apr 13, 2010 at 7:48 PM, Koen Vos wrote: > My 2 cents on this thread: > > - Going beyond WB quality matters a lot, even for speech. See for exampl= e > slides 2, 3 of http://www.ietf.org/proceedings/10mar/slides/codec-3.pdf. > Agree with Ben that we might as well go full-band. > > - The codec has 3 sampling rates: > 1. Encoder API > 2. Codec internal (not strictly sampling rate, more audio bandwidth as > Stephen pointed out) > 3. Decoder API > I don't see a reason to impose that some or all of these be identical. F= or > (conference) mixing of several streams it helps if all decoders run at th= e > same API sampling rate. It would be unreasonable to require that every > encoder also runs at that API sampling rate. Some encoders may for insta= nce > sit in a PSTN gateway, dealing strictly with narrowband signals. > > - To keep RTP timestamps simple, they could always be based on the same > sampling rate, irrespective of any of the ones above. Maybe 48 kHz is a g= ood > choice? > > - Sometimes a decoder runs on hardware with limited audio bandwidth > playback capabilities (e.g. mobile devices). In th?ose cases it helps if > the decoder can request a maximum internal audio bandwidth to the encoder= , > during call setup. Otherwise the encoder may be wasting bits on unused au= dio > spectrum. So I agree with Christian on this. > > - Agree with Raymond that fast switching of audio bandwidth sounds > unpleasant. SILK has a hysteresis mechanism for this, and we rarely get > more than one or two switches during a Skype call. > > best, > koen. > > > > > Quoting stephen botzko : > > I agree. >> >> The changes in audio bandwidth will certainly be audible, and personally= I >> would prefer a stable experience. >> >> Also, increasing the audio bandwidth might result in audible temporary >> echo >> (in the newly opened frequencies), since the acoustic echo cancellers wi= ll >> often need to re-adapt. The acoustic feedback paths can change pretty >> quickly at higher frequencies. >> >> Stephen Botzko >> >> On Tue, Apr 13, 2010 at 3:23 PM, Raymond (Juin-Hwey) Chen < >> rchen@broadcom.com> wrote: >> >> I would agree with Roman that for speech the difference between wideba= nd >>> (16 kHz sampling) and super-wideband/full-band (32 ~ 48 kHz sampling) i= s >>> there but very small and many people cannot even distinguish between >>> them, >>> while for music the difference can be much more noticeable. From all th= e >>> codec WG emails dating back to last year, it appears to me that most >>> people >>> want the IETF codec to handle music as well as speech. Therefore, it >>> seems >>> appropriate to have the maximum sampling rate up to 48 kHz if we want t= o >>> the >>> codec to handle music. >>> >>> >>> >>> Regarding the dynamic switching of the sampling rate or audio bandwidth= , >>> if >>> this is to be done, I think we need to be careful not to change the aud= io >>> bandwidth too frequently, otherwise the frequent change of the audio >>> bandwidth can be quite disturbing to the listener. It would certainly = be >>> disturbing to me personally if the audio bandwidth changes more >>> frequently >>> than once every few seconds, but if it changes once every few minutes, >>> that's probably tolerable to me. >>> >>> >>> >>> Raymond >>> >>> >>> >>> *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On >>> Behalf >>> Of *stephen botzko >>> *Sent:* Tuesday, April 13, 2010 11:43 AM >>> *To:* Roman Shpount >>> >>> *Cc:* codec@ietf.org >>> *Subject:* Re: [codec] #8: Sample rates? >>> >>> >>> >>> >>> >>> >>> I will not argue superwideband vs wideband, even though we did some, no= t >>> very scientific, blind tests, and in most cases people (especially men) >>> cannot even distinguish wideband from superwideband when listening t= o >>> voice samples. Only a very small percentage of voice energy is even >>> present >>> above 8 Khz. >>> >>> >>> >>> Though there isn't much voice energy over 8 kHz, in our (equally >>> unscientific) tests, sibilants and fricatives are easier to distinguish >>> if >>> you are using superwideband or better. That was one reason we added >>> Annec C >>> to G.722.1. >>> >>> Fullband is (IMHO) a specsmanship thing for speech (and probably for >>> music >>> also for most of us). Though it may not be that hard to get it, if we >>> are >>> shooting for superwideband anyway. >>> >>> Stephen Botzko >>> >>> On Tue, Apr 13, 2010 at 2:11 PM, Roman Shpount >>> wrote: >>> >>> I will not argue superwideband vs wideband, even though we did some, no= t >>> very scientific, blind tests, and in most cases people (especially men) >>> cannot even distinguish wideband from superwideband when listening to >>> voice >>> samples. Only a very small percentage of voice energy is even present >>> above >>> 8 Khz. >>> >>> Music on the other hand, especially past 24Khz sampling rate, gets >>> affected >>> by the CODEC more then by bandwidth. For instance 8KHz G.711 encoded >>> music >>> sounds poor, but reasonable, and G.729 encoded music cannot be listened >>> to. >>> In most cases (apart from critical listening), music sampled at 16Khz i= s >>> acceptable, especially for generation iPod. >>> >>> My remark about RTPC was to try to develop a CODEC that will function >>> properly with RTCP absent. If we require RTCP based mechanisms in order >>> for >>> the CODEC to operate properly, this can impede the adoption of this >>> CODEC. >>> In no way do I propose to create new signaling mechanisms. >>> >>> >>> ______________________________ >>> Roman Shpount - www.telurix.com >>> >>> On Tue, Apr 13, 2010 at 1:29 PM, stephen botzko < >>> stephen.botzko@gmail.com> wrote: >>> >>> Superwideband (and even fullband) do make speech somewhat more >>> intelligible, and also reduce listener fatigue. Telepresence and other >>> videoconferencing equipment use those acoustic bandwidths today, so it >>> would >>> be nice if CODEC supported at least superwideband also. >>> >>> Personally I see some value in carriage of music. Sometimes our >>> equipment >>> is used for music performance. Distance learning is another use case >>> where >>> music has some value, since course and training materials frequently do >>> include videos with music. Though of course conversational speech is t= he >>> dominant use case. >>> >>> BTW, Videoconferencing devices do almost always support RTCP. It is >>> regrettable that so many VOIP devices do not. Anyway, I do not think o= ur >>> charter scope includes invention of a new mechanism for signaling the >>> network quality. >>> >>> Stephen Botzko >>> >>> >>> >>> On Tue, Apr 13, 2010 at 12:41 PM, Roman Shpount >>> wrote: >>> >>> I am not sure if this was decided, but should this new CODEC support >>> music >>> encoding? If we don't plan to support music, we should probably stick t= o >>> 16 >>> Khz sampling rate. If we need music, I would suggest to have a 24 Khz (= or >>> higher sampling rate) variant. I am not sure how many people here care >>> about >>> a non-voice CODEC. For all the practical purposes I don't. I would argu= e, >>> at least, for a fixed 16 KHz sampling rate CODEC variant. >>> >>> P.S. On the same note, does anybody here cares about using this CODEC >>> with >>> multicast? Is there a single commercial multicast voice deployment? Fro= m >>> what I've seen all multicast does is making IETF voice standards harder >>> to >>> understand or implement. >>> >>> P.P.S. RTCP is almost universally not implemented. The biggest VoIP >>> gateway >>> on the market does not generate RTCP. If we will rely on any RTCP >>> functionality for bandwidth control it will probably be ignored. >>> ______________________________ >>> Roman Shpount - www.telurix.com >>> >>> On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko < >>> stephen.botzko@gmail.com> wrote: >>> >>> TCP is a different case, since for this we are using RTCP to signal ou= r >>> feedback, and I don't think it has the facility you are envisioning. >>> >>> Also, I disagree with your presumption that multicast is out of scope. = I >>> don't know of any other packetization RFCs that expressly rule out >>> multicast, and multicast can be used for interactive applications. >>> >>> This concept seems pretty theoretical to me. If we need to manage >>> complexity / quality tradeoffs, why not just use profiles (as AVC/H.264 >>> does) or create a low complexity variant (like G.729A). I really don't >>> see >>> the need for *dynamic* complexity management. >>> >>> BTW, you seem to be assuming that a lower sample rate results in >>> significantly less complexity. The savings there might not be as great >>> as >>> you think, especially if the receiver needs to resample anyway (to >>> prevent >>> those sound card limitations you were talking about before). >>> >>> Stephen Botzko >>> >>> On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene < >>> hoene@uni-tuebingen.de> >>> wrote: >>> >>> Hi, >>> >>> >>> >>> comments inline: >>> >>> >>> >>> >>> >>> *From:* stephen botzko [mailto:stephen.botzko@gmail.com] >>> *Sent:* Tuesday, April 13, 2010 4:56 PM >>> *To:* Christian Hoene >>> *Cc:* codec@ietf.org >>> >>> >>> *Subject:* Re: [codec] #8: Sample rates? >>> >>> >>> >>> This would make the signaling more complicated - personally I am not >>> convinced it is worth it. >>> >>> CH: It is a difficult tradeoff. However, signaling overload is done in >>> Skype. Such as signaling might be very useful for mobile devices, whic= h >>> want to save power and thus lower their CPU clock. Or wireless IP based >>> headphones which do not have large batteries. I am thinking of signalin= g >>> the >>> states: overloaded, fine, and low. That should be enough for most >>> operational cases. >>> >>> >>> I think a better avenue is to bound overall complexity, and to focus on >>> dynamically adapting to network conditions (as opposed to dynamic >>> complexity >>> management). >>> >>> CH: I just like to remind that the good old TCP does support both: >>> congestion control to adapt to network conditions and flow control take >>> into >>> account an overloaded (=3Dfull) receiver. >>> >>> You can't dynamically negotiate complexity in many scenarios anyway - f= or >>> instance it makes no sense if you are using multicast. >>> >>> CH: Multicast is out of scope anyhow. We are considering an interactive >>> codec. >>> >>> CH: The conferencing scenario might be some more difficult to handle bu= t >>> will not a big problem. >>> >>> Christian >>> >>> >>> >>> Stephen Botzko >>> >>> On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene < >>> hoene@uni-tuebingen.de> >>> wrote: >>> >>> Hi, >>> >>> >>> >>> It still might make sense to negotiate the maximal supported sampling >>> rate >>> via SDP or, if possible, to select one out of multiple sampling rates, = if >>> the audio receiver can cope with multiple rates well. The internal >>> sampling >>> frequency of the codec NEEDS NOT to be affected by the external samplin= g >>> frequency. >>> >>> >>> >>> However, the decoder might want to signal to the encoder that the >>> decoding >>> is requiring too many computational resources and that a less complex >>> coding >>> mode (or a lower sampling frequency) should be taken. >>> >>> >>> >>> Christian >>> >>> >>> >>> >>> >>> --------------------------------------------------------------- >>> >>> Dr.-Ing. Christian Hoene >>> >>> Interactive Communication Systems (ICS), University of T=FCbingen >>> >>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >>> http://www.net.uni-tuebingen.de/ >>> >>> >>> >>> *From:* stephen botzko [mailto:stephen.botzko@gmail.com] >>> *Sent:* Tuesday, April 13, 2010 3:21 PM >>> *To:* Kevin P. Fleming >>> *Cc:* Christian Hoene; codec@ietf.org >>> *Subject:* Re: [codec] #8: Sample rates? >>> >>> >>> >>> Though I generally avoid MAY, this could be a case where it makes sense= . >>> >>> Something like: >>> >>> CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to >>> optimize audio quality. >>> >>> This is free of any technology assumption about *how* the acoustic >>> bandwidth is reduced. The MAY indicates that it is permissible. But i= f >>> the >>> CODEC algorithm doesn't need to reduce the acoustic bandwidth, then we >>> are >>> making no statement that it SHOULD (or SHOULD NOT). >>> >>> Kevin is distinguishing dynamic changes to the sample rate (for bandwid= th >>> management) from multiple fixed sample rates; and I agree that is a key >>> distinction. >>> >>> I have not heard any clear application requirement for more than one >>> fixed >>> sampling rate. Though if there is such a requirement, IMHO we would ha= ve >>> to >>> negotiate the rate within SDP in the usual way, and it would affect the >>> RTP >>> timestamps, jitter buffers, etc. G.722.1 / G.722.1C is one precedent - >>> it >>> is the same core codec, but can run at two different sample rates >>> (negotiated by SDP). >>> >>> Stephen Botzko >>> >>> On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming >>> wrote: >>> >>> stephen botzko wrote: >>> >>> > Dynamically changing sample rates on the system level adds some >>> > complexity for RTP, since the timestamp granularity is supposed to be >>> > the sample rate. >>> >>> And jitter buffers, and anything else that is based on timestamps and >>> sample rates/counts. If the desire is for the codec to be able to chang= e >>> sample rates to adjust to network conditions, then I agree with >>> Stephen... the 'external' sample rate (input to the encoder and output >>> from the decoder) should be fixed, and this is what would be negotiated >>> in SDP and used for RTP timestamps. The codec can downsample in the >>> encoder and upsample in the decoder if it has decided to transmit fewer >>> bits across the network. >>> >>> -- >>> Kevin P. Fleming >>> Digium, Inc. | Director of Software Technologies >>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >>> skype: kpfleming | jabber: kfleming@digium.com >>> Check us out at www.digium.com & www.asterisk.org >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016e68ea0a7d4a1f30484276351 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not sure exactly what you mean by=A0 "API rate".=A0 Seems to= me that the reference encoder source code might accept any sample rate, bu= t convert it to 48 kHz before encoding. If that is what you mean, then the = two API rates are never signaled?

I rather like the idea of negotiating maximum audio bandwidth.=A0 For m= e that is=20 different from dynamic complexity management, and is being signaled for a different purpose (wasting coded bits on unheard spectrum degrades the qua= lity of the heard spectrum). Signaling the bandwidth, and defining the inte= rnal codec rate as fullband should let us lock down the RTP timestamp rate = at 48 kHz (which I think is desirable).

Stephen Botzko


On Tue, Apr 13, 20= 10 at 7:48 PM, Koen Vos <koen.vos@skype.net> wrote:
My 2 cents on this thread:

- Going beyond WB quality matters a lot, even for speech. =A0See for exampl= e slides 2, 3 of http://www.ietf.org/proceedings/10mar/slides/c= odec-3.pdf. =A0Agree with Ben that we might as well go full-band.

- The codec has 3 sampling rates:
=A01. Encoder API
=A02. Codec internal (not strictly sampling rate, more audio bandwidth as = Stephen pointed out)
=A03. Decoder API
I don't see a reason to impose that some or all of these be identical. = =A0For (conference) mixing of several streams it helps if all decoders run = at the same API sampling rate. It would be unreasonable to require that eve= ry encoder also runs at that API sampling rate. =A0Some encoders may for in= stance sit in a PSTN gateway, dealing strictly with narrowband signals.

- To keep RTP timestamps simple, they could always be based on the same sam= pling rate, irrespective of any of the ones above. Maybe 48 kHz is a good c= hoice?

- Sometimes a decoder runs on hardware with limited audio bandwidth playbac= k capabilities (e.g. mobile devices). =A0In th?ose cases it helps if the de= coder can request a maximum internal audio bandwidth to the encoder, during= call setup. Otherwise the encoder may be wasting bits on unused audio spec= trum. =A0So I agree with Christian on this.

- Agree with Raymond that fast switching of audio bandwidth sounds unpleasa= nt. =A0SILK has a hysteresis mechanism for this, and we rarely get more tha= n one or two switches during a Skype call.

best,
koen.




Quoting stephen botzko <stephen.botzko@gmail.com>:

I agree.

The changes in audio bandwidth will certainly be audible, and personally I<= br> would prefer a stable experience.

Also, increasing the audio bandwidth might result in audible temporary echo=
(in the newly opened frequencies), since the acoustic echo cancellers will<= br> often need to re-adapt. =A0The acoustic feedback paths can change pretty quickly at higher frequencies.

Stephen Botzko

On Tue, Apr 13, 2010 at 3:23 PM, Raymond (Juin-Hwey) Chen <
rchen@broadcom.com<= /a>> wrote:

=A0I would agree with Roman that for speech the difference between wideband=
(16 kHz sampling) and super-wideband/full-band (32 ~ 48 kHz sampling) is there but very small and many people cannot even distinguish between them,<= br> while for music the difference can be much more noticeable. From all the codec WG emails dating back to last year, it appears to me that most people=
want the IETF codec to handle music as well as speech. =A0Therefore, it see= ms
appropriate to have the maximum sampling rate up to 48 kHz if we want to th= e
codec to handle music.



Regarding the dynamic switching of the sampling rate or audio bandwidth, if=
this is to be done, I think we need to be careful not to change the audio bandwidth too frequently, otherwise the frequent change of the audio
bandwidth can be quite disturbing to the listener. =A0It would certainly be=
disturbing to me personally if the audio bandwidth changes more frequently<= br> than once every few seconds, but if it changes once every few minutes,
that's probably tolerable to me.



Raymond



*From:* codec-b= ounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf
Of *stephen botzko
*Sent:* Tuesday, April 13, 2010 11:43 AM
*To:* Roman Shpount

*Cc:* codec@ietf.org
*Subject:* Re: [codec] #8: Sample rates?



>>>

I will not argue superwideband vs wideband, even though we did some, not very scientific, blind tests, and in most cases people (especially men)
cannot even distinguish wideband from superwideband when =A0 =A0listening t= o
voice samples. Only a very small percentage of voice energy is even present=
above 8 Khz.

>>>
Though there isn't much voice energy over 8 kHz, in our (equally
unscientific) tests, sibilants and fricatives are easier to distinguish if<= br> you are using superwideband or better. =A0That was one reason we added Anne= c C
to G.722.1.

Fullband is (IMHO) a specsmanship thing for speech (and probably for music<= br> also for most of us). =A0Though it may not be that hard to get it, if we ar= e
shooting for superwideband anyway.

Stephen Botzko

=A0On Tue, Apr 13, 2010 at 2:11 PM, Roman Shpount <roman@telurix.com> wrote:

I will not argue superwideband vs wideband, even though we did some, not very scientific, blind tests, and in most cases people (especially men)
cannot even distinguish wideband from superwideband when listening to voice=
samples. Only a very small percentage of voice energy is even present above=
8 Khz.

Music on the other hand, especially past 24Khz sampling rate, gets affected=
by the CODEC more then by bandwidth. For instance 8KHz G.711 encoded music<= br> sounds poor, but reasonable, and G.729 encoded music cannot be listened to.=
In most cases (apart from critical listening), music sampled at 16Khz is acceptable, especially for generation iPod.

My remark about RTPC was to try to develop a CODEC that will function
properly with RTCP absent. If we require RTCP based mechanisms in order for=
the CODEC to operate properly, this can impede the adoption of this CODEC.<= br> In no way do I propose to create new signaling mechanisms.


______________________________
Roman Shpount - www.te= lurix.com

=A0 On Tue, Apr 13, 2010 at 1:29 PM, stephen botzko <
stephen.botzk= o@gmail.com> wrote:

Superwideband (and even fullband) do make speech somewhat more
intelligible, and also reduce listener fatigue. =A0Telepresence and other videoconferencing equipment use those acoustic bandwidths today, so it woul= d
be nice if CODEC supported at least superwideband also.

Personally I see some value in carriage of music. =A0Sometimes our equipmen= t
is used for music performance. =A0Distance learning is another use case whe= re
music has some value, since course and training materials frequently do
include videos with music. =A0Though of course conversational speech is the=
dominant use case.

BTW, Videoconferencing devices do almost always support RTCP. =A0It is
regrettable that so many VOIP devices do not. =A0Anyway, I do not think our=
charter scope includes invention of a new mechanism for signaling the
network quality.

Stephen Botzko



On Tue, Apr 13, 2010 at 12:41 PM, Roman Shpount <roman@telurix.com> wrote:

I am not sure if this was decided, but should this new CODEC support music<= br> encoding? If we don't plan to support music, we should probably stick t= o 16
Khz sampling rate. If we need music, I would suggest to have a 24 Khz (or higher sampling rate) variant. I am not sure how many people here care abou= t
a non-voice CODEC. For all the practical purposes I don't. I would argu= e,
at least, for a fixed 16 KHz sampling rate CODEC variant.

P.S. On the same note, does anybody here cares about using this CODEC with<= br> multicast? Is there a single commercial multicast voice deployment? From what I've seen all multicast does is making IETF voice standards harder= to
understand or implement.

P.P.S. RTCP is almost universally not implemented. The biggest VoIP gateway=
on the market does not generate RTCP. If we will rely on any RTCP
functionality for bandwidth control it will probably be ignored.
______________________________
Roman Shpount - =A0www= .telurix.com

=A0On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko <
stephen.botzk= o@gmail.com> wrote:

=A0TCP is a different case, since for this we are using RTCP to signal our<= br> feedback, and I don't think it has the facility you are envisioning.
Also, I disagree with your presumption that multicast is out of scope. =A0I=
don't know of any other packetization RFCs that expressly rule out
multicast, and multicast can be used for interactive applications.

This concept seems pretty theoretical to me. =A0If we need to manage
complexity / quality tradeoffs, why not just use profiles (as AVC/H.264
does) or create a low complexity variant (like G.729A). =A0I really don'= ;t see
the need for *dynamic* complexity management.

BTW, you seem to be assuming that a lower sample rate results in
significantly less complexity. =A0The savings there might not be as great a= s
you think, especially if the receiver needs to resample anyway (to prevent<= br> those sound card limitations you were talking about before).

Stephen Botzko

On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene <hoene@uni-tuebingen.de>
wrote:

Hi,



comments inline:





*From:* stephen botzko [mailto:stephen.botzko@gmail.com]
*Sent:* Tuesday, April 13, 2010 4:56 PM
*To:* Christian Hoene
*Cc:* codec@ietf.org


*Subject:* Re: [codec] #8: Sample rates?



This would make the signaling more complicated - personally I am not
convinced it is worth it.

CH: It is a difficult tradeoff. However, signaling overload is done in
Skype. =A0Such as signaling might be very useful for mobile devices, which<= br> want to save power and thus lower their CPU clock. Or wireless IP based
headphones which do not have large batteries. I am thinking of signaling th= e
states: overloaded, fine, and low. That should be enough for most
operational cases.


I think a better avenue is to bound overall complexity, and to focus on
dynamically adapting to network conditions (as opposed to dynamic complexit= y
management).

CH: I just like to remind that the good old TCP does support both:
congestion control to adapt to network conditions and flow control take int= o
account an overloaded (=3Dfull) receiver.

You can't dynamically negotiate complexity in many scenarios anyway - f= or
instance it makes no sense if you are using multicast.

CH: Multicast is out of scope anyhow. We are considering an interactive
codec.

CH: The conferencing scenario might be some more difficult to handle but will not a big problem.

Christian



Stephen Botzko

On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene <hoene@uni-tuebingen.de>
wrote:

Hi,



It still might make sense to negotiate the maximal supported sampling rate<= br> via SDP or, if possible, to select one out of multiple sampling rates, if the audio receiver can cope with multiple rates well. The internal sampling=
frequency of the codec NEEDS NOT to be affected by the external sampling frequency.



However, the decoder might want to signal to the encoder that the decoding<= br> is requiring too many computational resources and that a less complex codin= g
mode (or a lower sampling frequency) should be taken.



Christian





---------------------------------------------------------------

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.n= et.uni-tuebingen.de/



*From:* stephen botzko [mailto:stephen.botzko@gmail.com]
*Sent:* Tuesday, April 13, 2010 3:21 PM
*To:* Kevin P. Fleming
*Cc:* Christian Hoene; = codec@ietf.org
*Subject:* Re: [codec] #8: Sample rates?



Though I generally avoid MAY, this could be a case where it makes sense.
Something like:

CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to
optimize audio quality.

This is free of any technology assumption about *how* the acoustic
bandwidth is reduced. =A0The MAY indicates that it is permissible. =A0But i= f the
CODEC algorithm doesn't need to reduce the acoustic bandwidth, then we = are
making no statement that it SHOULD (or SHOULD NOT).

Kevin is distinguishing dynamic changes to the sample rate (for bandwidth management) from multiple fixed sample rates; and I agree that is a key
distinction.

I have not heard any clear application requirement for more than one fixed<= br> sampling rate. =A0Though if there is such a requirement, IMHO we would have= to
negotiate the rate within SDP in the usual way, and it would affect the RTP=
timestamps, jitter buffers, etc. =A0G.722.1 / G.722.1C is one precedent - i= t
is the same core codec, but can run at two different sample rates
(negotiated by SDP).

Stephen Botzko

On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming <kpfleming@digium.com>
wrote:

stephen botzko wrote:

> Dynamically changing sample rates on the system level adds some
> complexity for RTP, since the timestamp granularity is supposed to be<= br> > the sample rate.

And jitter buffers, and anything else that is based on timestamps and
sample rates/counts. If the desire is for the codec to be able to change sample rates to adjust to network conditions, then I agree with
Stephen... the 'external' sample rate (input to the encoder and out= put
from the decoder) should be fixed, and this is what would be negotiated
in SDP and used for RTP timestamps. The codec can downsample in the
encoder and upsample in the decoder if it has decided to transmit fewer
bits across the network.

--
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.dig= ium.com & www= .asterisk.org







_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec











_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016e68ea0a7d4a1f30484276351-- From koen.vos@skype.net Tue Apr 13 17:57:39 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1468D28C1C4 for ; Tue, 13 Apr 2010 17:57:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.602 X-Spam-Level: X-Spam-Status: No, score=-4.602 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, J_CHICKENPOX_23=0.6, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jxj5d9z0uGAE for ; Tue, 13 Apr 2010 17:57:37 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id B6D6D28C1DD for ; Tue, 13 Apr 2010 17:57:32 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id BFF6260133B87; Wed, 14 Apr 2010 01:57:26 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=Y9xnqSIRKv7M DRdPrwMtEiE3+bY=; b=XgGIasTIm/7Erbk1Gg6TMRaj0PZYJj7area82Ow9W/KE smAXjH/TOkEU2NkdFyuFF1R2nWiwFizwSJ3WWYgtMNf+jPoS9NTdadyd59Zpa4s9 RuWO4ifj6Z1e+uG0kjdaIThHUF3HQOOriSBppD5iYH+xM9ajO71MoZWfQhYCDT0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=BcJSX1zrkr0yclkUD1qs k5YSNCiEEMNbAoFv0UxZt4BnQ+N/HJMrX7ek1F9Xzl+GsUlltw3RgQ5HQ323lYv4 ZCwxc+eQ6y6AZxDji7YcM/Ks0KfpY/zcgJdO5b7vRePf7NSlubjsiwCOjLBuiR2C 0jA1u6QcMMGlCwjKwuToKtg= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id BDCF96013365C; Wed, 14 Apr 2010 01:57:26 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jq2zjCLUc9FT; Wed, 14 Apr 2010 01:57:25 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 43FE560133B86; Wed, 14 Apr 2010 01:57:25 +0100 (IST) Received: from adsl-71-141-129-119.dsl.snfc21.pacbell.net (adsl-71-141-129-119.dsl.snfc21.pacbell.net [71.141.129.119]) by mail.skype.net (Horde Framework) with HTTP; Tue, 13 Apr 2010 17:57:25 -0700 Message-ID: <20100413175725.19971pdv7otmomph@mail.skype.net> Date: Tue, 13 Apr 2010 17:57:25 -0700 From: Koen Vos To: stephen botzko References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <003101cadb1c$828b3990$87a1acb0$@de> <20100413164818.546929eae97cjjr6@mail.skype.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 00:57:39 -0000 Quoting stephen botzko: > If that is what you mean, then the two API rates are never signaled? Right, that's what I meant. koen. > I am not sure exactly what you mean by "API rate". Seems to me that the > reference encoder source code might accept any sample rate, but convert it > to 48 kHz before encoding. If that is what you mean, then the two API rate= s > are never signaled? > > I rather like the idea of negotiating maximum audio bandwidth. For me tha= t > is different from dynamic complexity management, and is being signaled for= a > different purpose (wasting coded bits on unheard spectrum degrades the > quality of the heard spectrum). Signaling the bandwidth, and defining the > internal codec rate as fullband should let us lock down the RTP timestamp > rate at 48 kHz (which I think is desirable). > > Stephen Botzko > > > On Tue, Apr 13, 2010 at 7:48 PM, Koen Vos wrote: > >> My 2 cents on this thread: >> >> - Going beyond WB quality matters a lot, even for speech. See for exampl= e >> slides 2, 3 of http://www.ietf.org/proceedings/10mar/slides/codec-3.pdf. >> Agree with Ben that we might as well go full-band. >> >> - The codec has 3 sampling rates: >> 1. Encoder API >> 2. Codec internal (not strictly sampling rate, more audio bandwidth as >> Stephen pointed out) >> 3. Decoder API >> I don't see a reason to impose that some or all of these be identical. F= or >> (conference) mixing of several streams it helps if all decoders run at th= e >> same API sampling rate. It would be unreasonable to require that every >> encoder also runs at that API sampling rate. Some encoders may for insta= nce >> sit in a PSTN gateway, dealing strictly with narrowband signals. >> >> - To keep RTP timestamps simple, they could always be based on the same >> sampling rate, irrespective of any of the ones above. Maybe 48 kHz is a g= ood >> choice? >> >> - Sometimes a decoder runs on hardware with limited audio bandwidth >> playback capabilities (e.g. mobile devices). In th?ose cases it helps if >> the decoder can request a maximum internal audio bandwidth to the encoder= , >> during call setup. Otherwise the encoder may be wasting bits on unused au= dio >> spectrum. So I agree with Christian on this. >> >> - Agree with Raymond that fast switching of audio bandwidth sounds >> unpleasant. SILK has a hysteresis mechanism for this, and we rarely get >> more than one or two switches during a Skype call. >> >> best, >> koen. >> >> >> >> >> Quoting stephen botzko : >> >> I agree. >>> >>> The changes in audio bandwidth will certainly be audible, and personally= I >>> would prefer a stable experience. >>> >>> Also, increasing the audio bandwidth might result in audible temporary >>> echo >>> (in the newly opened frequencies), since the acoustic echo cancellers wi= ll >>> often need to re-adapt. The acoustic feedback paths can change pretty >>> quickly at higher frequencies. >>> >>> Stephen Botzko >>> >>> On Tue, Apr 13, 2010 at 3:23 PM, Raymond (Juin-Hwey) Chen < >>> rchen@broadcom.com> wrote: >>> >>> I would agree with Roman that for speech the difference between wideba= nd >>>> (16 kHz sampling) and super-wideband/full-band (32 ~ 48 kHz sampling) i= s >>>> there but very small and many people cannot even distinguish between >>>> them, >>>> while for music the difference can be much more noticeable. From all th= e >>>> codec WG emails dating back to last year, it appears to me that most >>>> people >>>> want the IETF codec to handle music as well as speech. Therefore, it >>>> seems >>>> appropriate to have the maximum sampling rate up to 48 kHz if we want t= o >>>> the >>>> codec to handle music. >>>> >>>> >>>> >>>> Regarding the dynamic switching of the sampling rate or audio bandwidth= , >>>> if >>>> this is to be done, I think we need to be careful not to change the aud= io >>>> bandwidth too frequently, otherwise the frequent change of the audio >>>> bandwidth can be quite disturbing to the listener. It would certainly = be >>>> disturbing to me personally if the audio bandwidth changes more >>>> frequently >>>> than once every few seconds, but if it changes once every few minutes, >>>> that's probably tolerable to me. >>>> >>>> >>>> >>>> Raymond >>>> >>>> >>>> >>>> *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On >>>> Behalf >>>> Of *stephen botzko >>>> *Sent:* Tuesday, April 13, 2010 11:43 AM >>>> *To:* Roman Shpount >>>> >>>> *Cc:* codec@ietf.org >>>> *Subject:* Re: [codec] #8: Sample rates? >>>> >>>> >>>> >>>> >>> >>>> >>>> I will not argue superwideband vs wideband, even though we did some, no= t >>>> very scientific, blind tests, and in most cases people (especially men) >>>> cannot even distinguish wideband from superwideband when listening t= o >>>> voice samples. Only a very small percentage of voice energy is even >>>> present >>>> above 8 Khz. >>>> >>>> >>> >>>> Though there isn't much voice energy over 8 kHz, in our (equally >>>> unscientific) tests, sibilants and fricatives are easier to distinguish >>>> if >>>> you are using superwideband or better. That was one reason we added >>>> Annec C >>>> to G.722.1. >>>> >>>> Fullband is (IMHO) a specsmanship thing for speech (and probably for >>>> music >>>> also for most of us). Though it may not be that hard to get it, if we >>>> are >>>> shooting for superwideband anyway. >>>> >>>> Stephen Botzko >>>> >>>> On Tue, Apr 13, 2010 at 2:11 PM, Roman Shpount >>>> wrote: >>>> >>>> I will not argue superwideband vs wideband, even though we did some, no= t >>>> very scientific, blind tests, and in most cases people (especially men) >>>> cannot even distinguish wideband from superwideband when listening to >>>> voice >>>> samples. Only a very small percentage of voice energy is even present >>>> above >>>> 8 Khz. >>>> >>>> Music on the other hand, especially past 24Khz sampling rate, gets >>>> affected >>>> by the CODEC more then by bandwidth. For instance 8KHz G.711 encoded >>>> music >>>> sounds poor, but reasonable, and G.729 encoded music cannot be listened >>>> to. >>>> In most cases (apart from critical listening), music sampled at 16Khz i= s >>>> acceptable, especially for generation iPod. >>>> >>>> My remark about RTPC was to try to develop a CODEC that will function >>>> properly with RTCP absent. If we require RTCP based mechanisms in order >>>> for >>>> the CODEC to operate properly, this can impede the adoption of this >>>> CODEC. >>>> In no way do I propose to create new signaling mechanisms. >>>> >>>> >>>> ______________________________ >>>> Roman Shpount - www.telurix.com >>>> >>>> On Tue, Apr 13, 2010 at 1:29 PM, stephen botzko < >>>> stephen.botzko@gmail.com> wrote: >>>> >>>> Superwideband (and even fullband) do make speech somewhat more >>>> intelligible, and also reduce listener fatigue. Telepresence and other >>>> videoconferencing equipment use those acoustic bandwidths today, so it >>>> would >>>> be nice if CODEC supported at least superwideband also. >>>> >>>> Personally I see some value in carriage of music. Sometimes our >>>> equipment >>>> is used for music performance. Distance learning is another use case >>>> where >>>> music has some value, since course and training materials frequently do >>>> include videos with music. Though of course conversational speech is t= he >>>> dominant use case. >>>> >>>> BTW, Videoconferencing devices do almost always support RTCP. It is >>>> regrettable that so many VOIP devices do not. Anyway, I do not think o= ur >>>> charter scope includes invention of a new mechanism for signaling the >>>> network quality. >>>> >>>> Stephen Botzko >>>> >>>> >>>> >>>> On Tue, Apr 13, 2010 at 12:41 PM, Roman Shpount >>>> wrote: >>>> >>>> I am not sure if this was decided, but should this new CODEC support >>>> music >>>> encoding? If we don't plan to support music, we should probably stick t= o >>>> 16 >>>> Khz sampling rate. If we need music, I would suggest to have a 24 Khz (= or >>>> higher sampling rate) variant. I am not sure how many people here care >>>> about >>>> a non-voice CODEC. For all the practical purposes I don't. I would argu= e, >>>> at least, for a fixed 16 KHz sampling rate CODEC variant. >>>> >>>> P.S. On the same note, does anybody here cares about using this CODEC >>>> with >>>> multicast? Is there a single commercial multicast voice deployment? Fro= m >>>> what I've seen all multicast does is making IETF voice standards harder >>>> to >>>> understand or implement. >>>> >>>> P.P.S. RTCP is almost universally not implemented. The biggest VoIP >>>> gateway >>>> on the market does not generate RTCP. If we will rely on any RTCP >>>> functionality for bandwidth control it will probably be ignored. >>>> ______________________________ >>>> Roman Shpount - www.telurix.com >>>> >>>> On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko < >>>> stephen.botzko@gmail.com> wrote: >>>> >>>> TCP is a different case, since for this we are using RTCP to signal ou= r >>>> feedback, and I don't think it has the facility you are envisioning. >>>> >>>> Also, I disagree with your presumption that multicast is out of scope. = I >>>> don't know of any other packetization RFCs that expressly rule out >>>> multicast, and multicast can be used for interactive applications. >>>> >>>> This concept seems pretty theoretical to me. If we need to manage >>>> complexity / quality tradeoffs, why not just use profiles (as AVC/H.264 >>>> does) or create a low complexity variant (like G.729A). I really don't >>>> see >>>> the need for *dynamic* complexity management. >>>> >>>> BTW, you seem to be assuming that a lower sample rate results in >>>> significantly less complexity. The savings there might not be as great >>>> as >>>> you think, especially if the receiver needs to resample anyway (to >>>> prevent >>>> those sound card limitations you were talking about before). >>>> >>>> Stephen Botzko >>>> >>>> On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene < >>>> hoene@uni-tuebingen.de> >>>> wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>> comments inline: >>>> >>>> >>>> >>>> >>>> >>>> *From:* stephen botzko [mailto:stephen.botzko@gmail.com] >>>> *Sent:* Tuesday, April 13, 2010 4:56 PM >>>> *To:* Christian Hoene >>>> *Cc:* codec@ietf.org >>>> >>>> >>>> *Subject:* Re: [codec] #8: Sample rates? >>>> >>>> >>>> >>>> This would make the signaling more complicated - personally I am not >>>> convinced it is worth it. >>>> >>>> CH: It is a difficult tradeoff. However, signaling overload is done in >>>> Skype. Such as signaling might be very useful for mobile devices, whic= h >>>> want to save power and thus lower their CPU clock. Or wireless IP based >>>> headphones which do not have large batteries. I am thinking of signalin= g >>>> the >>>> states: overloaded, fine, and low. That should be enough for most >>>> operational cases. >>>> >>>> >>>> I think a better avenue is to bound overall complexity, and to focus on >>>> dynamically adapting to network conditions (as opposed to dynamic >>>> complexity >>>> management). >>>> >>>> CH: I just like to remind that the good old TCP does support both: >>>> congestion control to adapt to network conditions and flow control take >>>> into >>>> account an overloaded (=3Dfull) receiver. >>>> >>>> You can't dynamically negotiate complexity in many scenarios anyway - f= or >>>> instance it makes no sense if you are using multicast. >>>> >>>> CH: Multicast is out of scope anyhow. We are considering an interactive >>>> codec. >>>> >>>> CH: The conferencing scenario might be some more difficult to handle bu= t >>>> will not a big problem. >>>> >>>> Christian >>>> >>>> >>>> >>>> Stephen Botzko >>>> >>>> On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene < >>>> hoene@uni-tuebingen.de> >>>> wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>> It still might make sense to negotiate the maximal supported sampling >>>> rate >>>> via SDP or, if possible, to select one out of multiple sampling rates, = if >>>> the audio receiver can cope with multiple rates well. The internal >>>> sampling >>>> frequency of the codec NEEDS NOT to be affected by the external samplin= g >>>> frequency. >>>> >>>> >>>> >>>> However, the decoder might want to signal to the encoder that the >>>> decoding >>>> is requiring too many computational resources and that a less complex >>>> coding >>>> mode (or a lower sampling frequency) should be taken. >>>> >>>> >>>> >>>> Christian >>>> >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------- >>>> >>>> Dr.-Ing. Christian Hoene >>>> >>>> Interactive Communication Systems (ICS), University of T=FCbingen >>>> >>>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >>>> http://www.net.uni-tuebingen.de/ >>>> >>>> >>>> >>>> *From:* stephen botzko [mailto:stephen.botzko@gmail.com] >>>> *Sent:* Tuesday, April 13, 2010 3:21 PM >>>> *To:* Kevin P. Fleming >>>> *Cc:* Christian Hoene; codec@ietf.org >>>> *Subject:* Re: [codec] #8: Sample rates? >>>> >>>> >>>> >>>> Though I generally avoid MAY, this could be a case where it makes sense= . >>>> >>>> Something like: >>>> >>>> CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to >>>> optimize audio quality. >>>> >>>> This is free of any technology assumption about *how* the acoustic >>>> bandwidth is reduced. The MAY indicates that it is permissible. But i= f >>>> the >>>> CODEC algorithm doesn't need to reduce the acoustic bandwidth, then we >>>> are >>>> making no statement that it SHOULD (or SHOULD NOT). >>>> >>>> Kevin is distinguishing dynamic changes to the sample rate (for bandwid= th >>>> management) from multiple fixed sample rates; and I agree that is a key >>>> distinction. >>>> >>>> I have not heard any clear application requirement for more than one >>>> fixed >>>> sampling rate. Though if there is such a requirement, IMHO we would ha= ve >>>> to >>>> negotiate the rate within SDP in the usual way, and it would affect the >>>> RTP >>>> timestamps, jitter buffers, etc. G.722.1 / G.722.1C is one precedent - >>>> it >>>> is the same core codec, but can run at two different sample rates >>>> (negotiated by SDP). >>>> >>>> Stephen Botzko >>>> >>>> On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming >>>> wrote: >>>> >>>> stephen botzko wrote: >>>> >>>> > Dynamically changing sample rates on the system level adds some >>>> > complexity for RTP, since the timestamp granularity is supposed to be >>>> > the sample rate. >>>> >>>> And jitter buffers, and anything else that is based on timestamps and >>>> sample rates/counts. If the desire is for the codec to be able to chang= e >>>> sample rates to adjust to network conditions, then I agree with >>>> Stephen... the 'external' sample rate (input to the encoder and output >>>> from the decoder) should be fixed, and this is what would be negotiated >>>> in SDP and used for RTP timestamps. The codec can downsample in the >>>> encoder and upsample in the decoder if it has decided to transmit fewer >>>> bits across the network. >>>> >>>> -- >>>> Kevin P. Fleming >>>> Digium, Inc. | Director of Software Technologies >>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >>>> skype: kpfleming | jabber: kfleming@digium.com >>>> Check us out at www.digium.com & www.asterisk.org >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> codec mailing list >>>> codec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codec >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> > From bmschwar@fas.harvard.edu Tue Apr 13 18:05:29 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DE493A6837 for ; Tue, 13 Apr 2010 18:05:29 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoI6ttKBmoPt for ; Tue, 13 Apr 2010 18:05:28 -0700 (PDT) Received: from us18.unix.fas.harvard.edu (us18.unix.fas.harvard.edu [140.247.35.198]) by core3.amsl.com (Postfix) with ESMTP id 123603A677E for ; Tue, 13 Apr 2010 18:05:28 -0700 (PDT) Received: from us18.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us18.unix.fas.harvard.edu (Postfix) with ESMTP id A75BF4D5CC4; Tue, 13 Apr 2010 21:05:21 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; s=mail; bh=erwR+1CoSQFCRCy oESIKxMaxILLnIMcZmS8VKyH4g6I=; b=suffwfGAoPgVGpzv4Cvft87+sbLQ0c3 BWpYEpThe3SN17RBrBjVQl9MDwRWfMLNhAKfJLQbg/xf9ORKk7bshC1B10JMFZNl bQzZXtvsPp5b3FuTL1FpSK2IR4WLEX2+I0zst7t3rU2pOF+ojed7HZBgTf8tPGWF PoeljbXaqmug= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; q=dns; s=mail; b=OHqLE3oo8 qjszuYEWatKbo9lds//haZ4J91aMlMW5wne0C0Nr0xg/Cl7DVcBQSuyf9DXNcnfM uNydXb3POLmlzWEFP9knSV1AY5k8/PnX9TtFG9ebXZODc+9BxxniGTci+6sOhtP3 i2q6fIm0MiEMPCIoh70ozyA2wAsi2dyaNs= Received: from [192.168.1.100] (c-71-192-160-188.hsd1.nh.comcast.net [71.192.160.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us18.unix.fas.harvard.edu (Postfix) with ESMTPSA id 8F6504D5CC2; Tue, 13 Apr 2010 21:05:21 -0400 (EDT) Message-ID: <4BC514CE.2080800@fas.harvard.edu> Date: Tue, 13 Apr 2010 21:05:18 -0400 From: "Benjamin M. Schwartz" User-Agent: Thunderbird 2.0.0.23 (X11/20091019) MIME-Version: 1.0 To: stephen botzko References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <003101cadb1c$828b3990$87a1acb0$@de> <20100413164818.546929eae97cjjr6@mail.skype.net> In-Reply-To: X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig3D73C36EA5148630817524CD" Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 01:05:29 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig3D73C36EA5148630817524CD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable stephen botzko wrote: > I rather like the idea of negotiating maximum audio bandwidth. For me = that > is different from dynamic complexity management, and is being signaled = for a > different purpose (wasting coded bits on unheard spectrum degrades the > quality of the heard spectrum). 1. Why would high frequencies be unheard? Cheap speakers and microphones= have difficulties with low frequencies, but not high frequencies, and routinely go all the way up past the limit of hearing. 2. Why would it need to be negotiated? For a suitably designed format, the encoder could choose not to waste bits on high frequencies without an= y negotiation or extra signalling. > Signaling the bandwidth, and defining the > internal codec rate as fullband should let us lock down the RTP timesta= mp > rate at 48 kHz (which I think is desirable). I do agree that having "only one mode" would be ideal, to maximize interoperability. I wonder whether we can achieve high enough computational efficiency for this to be viable. --Ben --------------enig3D73C36EA5148630817524CD Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkvFFM4ACgkQUJT6e6HFtqT1PwCfZhJB8iWrNCTu0rbMd22GlDOM /PMAn0Lerg18KJay77jYkoZoKH3pAgD2 =m3TJ -----END PGP SIGNATURE----- --------------enig3D73C36EA5148630817524CD-- From koen.vos@skype.net Tue Apr 13 18:36:11 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9E1B3A6B54 for ; Tue, 13 Apr 2010 18:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.6 X-Spam-Level: X-Spam-Status: No, score=-5.6 tagged_above=-999 required=5 tests=[AWL=0.999, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CI7BZwiRKk9C for ; Tue, 13 Apr 2010 18:36:10 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 97F2C3A6AF2 for ; Tue, 13 Apr 2010 18:36:10 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 025D860133B88; Wed, 14 Apr 2010 02:36:04 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=XiT4NPECZnvM mVkwyuEnTRbW2jk=; b=FupK0WFO9kO+hlF9asJMW+KQQlY3kSG0AIoE8krRRgHn wEf8yyu3eqkRje6W3jsZWm33Ac7cl/TVd5B2kwavx6Gl7U4o5ffcmXWa5YIjBzuI L3Zv9rItoRCA5pC3GWVmOpOnAEcJN9txT7/5OkRlWEl9bnZheevNQw2LzBLHgVI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=J3yVb2dKdALNIGA2CJSM CidXbmuZ38KZ16nKqXeHN9Mm9bMptoeAkdrhgUgNahVcEnUBow5qluRWchDf0zza wgJwjVlbqNzDxTht9lKMTjPBZJnlB77RD9YBwIKLlce6hyFlLhsoNK2TgQihcDxC SEzMP9+Vt4b+2aEdKJti7YU= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id ED94260133BA8; Wed, 14 Apr 2010 02:36:03 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V-gck9IxIt-h; Wed, 14 Apr 2010 02:36:02 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id D316F60133B88; Wed, 14 Apr 2010 02:36:02 +0100 (IST) Received: from adsl-71-141-129-119.dsl.snfc21.pacbell.net (adsl-71-141-129-119.dsl.snfc21.pacbell.net [71.141.129.119]) by mail.skype.net (Horde Framework) with HTTP; Tue, 13 Apr 2010 18:36:02 -0700 Message-ID: <20100413183602.86565rmv5hve5d6q@mail.skype.net> Date: Tue, 13 Apr 2010 18:36:02 -0700 From: Koen Vos To: bens@alum.mit.edu, "Benjamin M. Schwartz" References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <003101cadb1c$828b3990$87a1acb0$@de> <20100413164818.546929eae97cjjr6@mail.skype.net> <4BC514CE.2080800@fas.harvard.edu> In-Reply-To: <4BC514CE.2080800@fas.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: codec@ietf.org, stephen botzko Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 01:36:12 -0000 Quoting "Benjamin M. Schwartz": > 1. Why would high frequencies be unheard? Cheap speakers and microphones > have difficulties with low frequencies, but not high frequencies, and > routinely go all the way up past the limit of hearing. Not all hardware supports arbitrary/high sampling rates. PSTN gateways don't go above 8 kHz. Same for some mobile devices. > 2. Why would it need to be negotiated? For a suitably designed format, > the encoder could choose not to waste bits on high frequencies without any > negotiation or extra signalling. Without signaling, how would the encoder know that the farend decoder will not take advantage of frequencies above a certain threshold? > >> Signaling the bandwidth, and defining the >> internal codec rate as fullband should let us lock down the RTP timestamp >> rate at 48 kHz (which I think is desirable). > > I do agree that having "only one mode" would be ideal, to maximize > interoperability. I wonder whether we can achieve high enough > computational efficiency for this to be viable. Changing the RTP timestamp sampling rate causes no computational complexity, does it? Perhaps an extra multiplication for each packet or so? The point was that RTP timestamp sampling rate should disconnected from the actual audio signals. koen. From bmschwar@fas.harvard.edu Tue Apr 13 18:54:56 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E62DD3A6808 for ; Tue, 13 Apr 2010 18:54:56 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iz9vSrppZ7jh for ; Tue, 13 Apr 2010 18:54:55 -0700 (PDT) Received: from us26.unix.fas.harvard.edu (us26.unix.fas.harvard.edu [140.247.35.202]) by core3.amsl.com (Postfix) with ESMTP id B35D43A63EC for ; Tue, 13 Apr 2010 18:54:55 -0700 (PDT) Received: from us26.unix.fas.harvard.edu (localhost.localdomain [127.0.0.1]) by us26.unix.fas.harvard.edu (Postfix) with ESMTP id 3FEB71F726E; Tue, 13 Apr 2010 21:54:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; s=mail; bh=u1r0hIbiiyUompK MBlobsMAh+o+jg7jYkYq2p0IlY0g=; b=s2o29c9FwLZ0x2vdnRGTmpb7fEbm0pR oixav0bRG2lf5Ys9Vo7E4sLXDyDsu1P/HBzTA8VmxoBSLp15uSx25Ki4tO7YMXRU Ry0htP49bgYjRk62C/Yoq9c63dQoeovmiQQlYFo1wEHvpkkCGCR870ZprvJCh0Cd w/BEfSG3sCNQ= DomainKey-Signature: a=rsa-sha1; c=simple; d=fas.harvard.edu; h= message-id:date:from:reply-to:mime-version:to:cc:subject :references:in-reply-to:content-type; q=dns; s=mail; b=feRxZmCYT Dd7DvTkaaDJZsk4NS8eZcltEuTSPqxrlvV5VvarFyt7cP7zDBf8IG1IUsZud+IIR EpCwsw1NXQGa5n/yshep/ZNLlKSW4pyb9YelGK4icCWLQ7amQLJ1iZb5VQzvOWBP Xt3ZUAsp40RxbWE/UZCsyoTADMvNgmq7TI= Received: from [192.168.1.100] (c-71-192-160-188.hsd1.nh.comcast.net [71.192.160.188]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: bmschwar@fas) by us26.unix.fas.harvard.edu (Postfix) with ESMTPSA id 224A81F7269; Tue, 13 Apr 2010 21:54:49 -0400 (EDT) Message-ID: <4BC52068.1080906@fas.harvard.edu> Date: Tue, 13 Apr 2010 21:54:48 -0400 From: "Benjamin M. Schwartz" User-Agent: Thunderbird 2.0.0.23 (X11/20091019) MIME-Version: 1.0 To: Koen Vos References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <003101cadb1c$828b3990$87a1acb0$@de> <20100413164818.546929eae97cjjr6@mail.skype.net> <4BC514CE.2080800@fas.harvard.edu> <20100413183602.86565rmv5hve5d6q@mail.skype.net> In-Reply-To: <20100413183602.86565rmv5hve5d6q@mail.skype.net> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig501F2A1B87538068C3844442" Cc: codec@ietf.org, stephen botzko Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 01:54:57 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig501F2A1B87538068C3844442 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Koen Vos wrote: > Quoting "Benjamin M. Schwartz": >> 1. Why would high frequencies be unheard? Cheap speakers and micropho= nes >> have difficulties with low frequencies, but not high frequencies, and >> routinely go all the way up past the limit of hearing. >=20 > Not all hardware supports arbitrary/high sampling rates. PSTN gateways= > don't go above 8 kHz. Same for some mobile devices. True. >> 2. Why would it need to be negotiated? For a suitably designed format= , >> the encoder could choose not to waste bits on high frequencies without= >> any >> negotiation or extra signalling. >=20 > Without signaling, how would the encoder know that the farend decoder > will not take advantage of frequencies above a certain threshold? When I say signalling, I mean signalling within the codec bitstream. The= encoder can change its behavior based on knowledge of the receiver's configuration, but the bitstream does not need any extra signalling to indicate the change in behavior. >>> Signaling the bandwidth, and defining the >>> internal codec rate as fullband should let us lock down the RTP >>> timestamp >>> rate at 48 kHz (which I think is desirable). >> >> I do agree that having "only one mode" would be ideal, to maximize >> interoperability. I wonder whether we can achieve high enough >> computational efficiency for this to be viable. >=20 > Changing the RTP timestamp sampling rate causes no computational > complexity, does it? Perhaps an extra multiplication for each packet o= r > so? The point was that RTP timestamp sampling rate should disconnected= > from the actual audio signals. Right, but Stephen also suggested "defining the internal codec rate as fullband". From this, I imagined a scenario in which all (compliant) IWA= C implementations MUST decode all IWAC streams, which always have a samplin= g rate of 48 KHz. I think this is a great idea, to achieve really good interoperability. If the receiver is a PSTN gateway, then an "internal codec rate" of 8 KHz= would presumably produce as good quality/bitrate with lower encoder and decoder complexity. However, if we can make IWAC sufficiently low-complexity, operating at 48 KHz may be acceptable. It will help if w= e can structure the codec so that operating at lower bandwidth is very efficient. For example, it may be possible to structure a transform code= c such that unneeded high frequencies can cheaply be zero'd on encode and ignored on decode. --Ben --------------enig501F2A1B87538068C3844442 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkvFIGgACgkQUJT6e6HFtqT1JgCggtw9PEzYC7SY0wIq3uMiKqyy dasAnRsA8mY8lzAyyHfOYo0917UUruXH =pMr6 -----END PGP SIGNATURE----- --------------enig501F2A1B87538068C3844442-- From stephen.botzko@gmail.com Tue Apr 13 19:55:22 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 378873A67B5 for ; Tue, 13 Apr 2010 19:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.087, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r0hb8HHcJMTs for ; Tue, 13 Apr 2010 19:55:21 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 04CD23A687F for ; Tue, 13 Apr 2010 19:55:17 -0700 (PDT) Received: by iwn27 with SMTP id 27so6109174iwn.5 for ; Tue, 13 Apr 2010 19:55:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=eOggVza0YUkLwHNq2Y4NhXpXe2+d4rUqAF5yNXbExUo=; b=V/qVfUV+ErizIrWmXwC0/pwbNVWqASwUgzgD66MlgscTWZba0B5pILZ3SOK3MBWK9w UVeGZtK191Q41cZonfxwnUhtiXvVP2OivrE33D+Afi4bVZ06Oq3NBEFI94QupxdxVD3H bJbjdas+gqLtvc5wdCNarCvTRL/Bo1YxkDT5Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=enZKL4ZD9Pl3ghY+gOwfvV3yMbBG1CC3zzqrXA3VViR8rdgGssbUI2BH+aS6Ns7SSn ICSBWfJsSYRv7OS55IUF4KpeOqGlBVEiSaoqKL/E8pIVD5eRrjQW4Ca3/PVpf2y8twWW lObCKXwcdqgnisyLFfaL3UTPyPNJt3XgFY7k4= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Tue, 13 Apr 2010 19:55:08 -0700 (PDT) In-Reply-To: <4BC52068.1080906@fas.harvard.edu> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <20100413164818.546929eae97cjjr6@mail.skype.net> <4BC514CE.2080800@fas.harvard.edu> <20100413183602.86565rmv5hve5d6q@mail.skype.net> <4BC52068.1080906@fas.harvard.edu> Date: Tue, 13 Apr 2010 22:55:08 -0400 Received: by 10.231.147.2 with SMTP id j2mr3048318ibv.65.1271213709023; Tue, 13 Apr 2010 19:55:09 -0700 (PDT) Message-ID: From: stephen botzko To: bens@alum.mit.edu Content-Type: multipart/alternative; boundary=0016e64354568fac3e048429816c Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 02:55:22 -0000 --0016e64354568fac3e048429816c Content-Type: text/plain; charset=ISO-8859-1 When I said signaling I meant SDP, not anything in the bitstream itself. I was not excluding audio bandwidth changes mid-call as part of network adaptation. Though as we all agree this needs to be carefully designed. I agree it is best if the decoder does not require any knowledge of the SDP negotiation (or any other information beyond the RTP packet stream itself) in order to correctly decode the audio -- which I think is what you were concerned about. It would be a nice property if reducing the acoustic bandwidth also allowed the MIPS to be reduced, but I do not think it is a requirement; I'd personally rather manage complexity with a Low Complexity profile (if that is really needed), since then I could keep the acoustic bandwidth (accepting a higher bit rate instead). Stephen Botzko On Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwartz < bmschwar@fas.harvard.edu> wrote: > Koen Vos wrote: > > Quoting "Benjamin M. Schwartz": > >> 1. Why would high frequencies be unheard? Cheap speakers and > microphones > >> have difficulties with low frequencies, but not high frequencies, and > >> routinely go all the way up past the limit of hearing. > > > > Not all hardware supports arbitrary/high sampling rates. PSTN gateways > > don't go above 8 kHz. Same for some mobile devices. > > True. > > >> 2. Why would it need to be negotiated? For a suitably designed format, > >> the encoder could choose not to waste bits on high frequencies without > >> any > >> negotiation or extra signalling. > > > > Without signaling, how would the encoder know that the farend decoder > > will not take advantage of frequencies above a certain threshold? > > When I say signalling, I mean signalling within the codec bitstream. The > encoder can change its behavior based on knowledge of the receiver's > configuration, but the bitstream does not need any extra signalling to > indicate the change in behavior. > > >>> Signaling the bandwidth, and defining the > >>> internal codec rate as fullband should let us lock down the RTP > >>> timestamp > >>> rate at 48 kHz (which I think is desirable). > >> > >> I do agree that having "only one mode" would be ideal, to maximize > >> interoperability. I wonder whether we can achieve high enough > >> computational efficiency for this to be viable. > > > > Changing the RTP timestamp sampling rate causes no computational > > complexity, does it? Perhaps an extra multiplication for each packet or > > so? The point was that RTP timestamp sampling rate should disconnected > > from the actual audio signals. > > Right, but Stephen also suggested "defining the internal codec rate as > fullband". From this, I imagined a scenario in which all (compliant) IWAC > implementations MUST decode all IWAC streams, which always have a sampling > rate of 48 KHz. I think this is a great idea, to achieve really good > interoperability. > > If the receiver is a PSTN gateway, then an "internal codec rate" of 8 KHz > would presumably produce as good quality/bitrate with lower encoder and > decoder complexity. However, if we can make IWAC sufficiently > low-complexity, operating at 48 KHz may be acceptable. It will help if we > can structure the codec so that operating at lower bandwidth is very > efficient. For example, it may be possible to structure a transform codec > such that unneeded high frequencies can cheaply be zero'd on encode and > ignored on decode. > > --Ben > > --0016e64354568fac3e048429816c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable When I said signaling I meant SDP, not anything in the bitstream itself.=A0= I was not excluding audio bandwidth changes mid-call as part of network ad= aptation.=A0 Though as we all agree this needs to be carefully designed.
I agree it is best if the decoder does not require any knowledge of the= SDP negotiation (or any other information beyond the RTP packet stream its= elf) in order to correctly decode the audio -- which I think is what you we= re concerned about.

It would be a nice property if reducing the acoustic bandwidth also all= owed the MIPS to be reduced, but I do not think it is a requirement;=A0 I&#= 39;d personally rather manage complexity with a Low Complexity profile (if = that is really needed), since then I could keep the acoustic bandwidth (acc= epting a higher bit rate instead).

Stephen Botzko

On Tue, Apr 13, 2010 a= t 9:54 PM, Benjamin M. Schwartz <bmschwar@fas.harvard.edu> wrote:
Koen Vos wrote:
> Quoting "Benjamin M. Schwartz":
>> 1. Why would high frequencies be unheard? =A0Cheap speakers and mi= crophones
>> have difficulties with low frequencies, but not high frequencies, = and
>> routinely go all the way up past the limit of hearing.
>
> Not all hardware supports arbitrary/high sampling rates. =A0PSTN gatew= ays
> don't go above 8 kHz. =A0Same for some mobile devices.

True.

>> 2. Why would it need to be negotiated? =A0For a suitably designed = format,
>> the encoder could choose not to waste bits on high frequencies wit= hout
>> any
>> negotiation or extra signalling.
>
> Without signaling, how would the encoder know that the farend decoder<= br> > will not take advantage of frequencies above a certain threshold?

When I say signalling, I mean signalling within the codec bitstream. = =A0The
encoder can change its behavior based on knowledge of the receiver's configuration, but the bitstream does not need any extra signalling to
indicate the change in behavior.

>>> Signaling the bandwidth, and defining the
>>> internal codec rate as fullband should let us lock down the RT= P
>>> timestamp
>>> rate at 48 kHz (which I think is desirable).
>>
>> I do agree that having "only one mode" would be ideal, t= o maximize
>> interoperability. =A0I wonder whether we can achieve high enough >> computational efficiency for this to be viable.
>
> Changing the RTP timestamp sampling rate causes no computational
> complexity, does it? =A0Perhaps an extra multiplication for each packe= t or
> so? =A0The point was that RTP timestamp sampling rate should disconnec= ted
> from the actual audio signals.

Right, but Stephen also suggested "defining the internal codec r= ate as
fullband". =A0From this, I imagined a scenario in which all (compliant= ) IWAC
implementations MUST decode all IWAC streams, which always have a sampling<= br> rate of 48 KHz. =A0I think this is a great idea, to achieve really good
interoperability.

If the receiver is a PSTN gateway, then an "internal codec rate" = of 8 KHz
would presumably produce as good quality/bitrate with lower encoder and
decoder complexity. =A0However, if we can make IWAC sufficiently
low-complexity, operating at 48 KHz may be acceptable. =A0It will help if w= e
can structure the codec so that operating at lower bandwidth is very
efficient. =A0For example, it may be possible to structure a transform code= c
such that unneeded high frequencies can cheaply be zero'd on encode and=
ignored on decode.

--Ben


--0016e64354568fac3e048429816c-- From roman@telurix.com Tue Apr 13 21:37:47 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9719728C248 for ; Tue, 13 Apr 2010 21:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.976 X-Spam-Level: X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7mtyGAqodCc0 for ; Tue, 13 Apr 2010 21:37:44 -0700 (PDT) Received: from mail-ww0-f66.google.com (mail-ww0-f66.google.com [74.125.82.66]) by core3.amsl.com (Postfix) with ESMTP id 01C0A28C130 for ; Tue, 13 Apr 2010 21:37:39 -0700 (PDT) Received: by wwb29 with SMTP id 29so349631wwb.1 for ; Tue, 13 Apr 2010 21:37:29 -0700 (PDT) Received: by 10.216.87.205 with SMTP id y55mr4340249wee.188.1271219849404; Tue, 13 Apr 2010 21:37:29 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by mx.google.com with ESMTPS id r29sm6452922wbv.3.2010.04.13.21.37.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 13 Apr 2010 21:37:28 -0700 (PDT) Received: by iwn27 with SMTP id 27so6159804iwn.5 for ; Tue, 13 Apr 2010 21:37:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.14.205 with HTTP; Tue, 13 Apr 2010 21:37:23 -0700 (PDT) In-Reply-To: <20100413164818.546929eae97cjjr6@mail.skype.net> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <003101cadb1c$828b3990$87a1acb0$@de> <20100413164818.546929eae97cjjr6@mail.skype.net> Date: Wed, 14 Apr 2010 00:37:23 -0400 Received: by 10.231.147.199 with SMTP id m7mr3074747ibv.87.1271219843387; Tue, 13 Apr 2010 21:37:23 -0700 (PDT) Message-ID: From: Roman Shpount To: Koen Vos Content-Type: multipart/alternative; boundary=0016e647ecc432531204842aefc6 Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 04:37:47 -0000 --0016e647ecc432531204842aefc6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable To be honest, your slides show that SILK works better at superwideband, not that superwideband is better then wideband. Normally, G.711 at 8 KHz has a higher MOS (4.4) score then SILK at superwideband (3.9). To compare wideban= d vs superwideband (or full rate) you need to compare 16 Khz linear PCM vs superwideband (or full rate) linear PCM. As far as full rate is concerned, most men cannot hear above 12-14 khz. In side by side listening tests we did, using high end headsets (AKG K-701, Sennheiser HD 650) and professiona= l DAC/headphone AMP (Benchmark DAC-1) using prerecorded voice samples (English, adult voices, no kids), nobody could distinguish wideband from superwideband, but this can be us, our samples, and untrained listeners. I understand the motivation for defining the codec that will go all the way to full band, but I think, it would make sense to define at least two codec profiles: 16 KHz mono, and compatible full rate codec with support for join= t multichannel encoding, similar to AMR-WB and AMR-WB+. _____________________________ Roman Shpount - www.telurix.com On Tue, Apr 13, 2010 at 7:48 PM, Koen Vos wrote: > My 2 cents on this thread: > > - Going beyond WB quality matters a lot, even for speech. See for exampl= e > slides 2, 3 of http://www.ietf.org/proceedings/10mar/slides/codec-3.pdf. > Agree with Ben that we might as well go full-band. > > - The codec has 3 sampling rates: > 1. Encoder API > 2. Codec internal (not strictly sampling rate, more audio bandwidth as > Stephen pointed out) > 3. Decoder API > I don't see a reason to impose that some or all of these be identical. F= or > (conference) mixing of several streams it helps if all decoders run at th= e > same API sampling rate. It would be unreasonable to require that every > encoder also runs at that API sampling rate. Some encoders may for insta= nce > sit in a PSTN gateway, dealing strictly with narrowband signals. > > - To keep RTP timestamps simple, they could always be based on the same > sampling rate, irrespective of any of the ones above. Maybe 48 kHz is a g= ood > choice? > > - Sometimes a decoder runs on hardware with limited audio bandwidth > playback capabilities (e.g. mobile devices). In those cases it helps if = the > decoder can request a maximum internal audio bandwidth to the encoder, > during call setup. Otherwise the encoder may be wasting bits on unused au= dio > spectrum. So I agree with Christian on this. > > - Agree with Raymond that fast switching of audio bandwidth sounds > unpleasant. SILK has a hysteresis mechanism for this, and we rarely get > more than one or two switches during a Skype call. > > best, > koen. > > > > Quoting stephen botzko : > > I agree. >> >> The changes in audio bandwidth will certainly be audible, and personally= I >> would prefer a stable experience. >> >> Also, increasing the audio bandwidth might result in audible temporary >> echo >> (in the newly opened frequencies), since the acoustic echo cancellers wi= ll >> often need to re-adapt. The acoustic feedback paths can change pretty >> quickly at higher frequencies. >> >> Stephen Botzko >> >> On Tue, Apr 13, 2010 at 3:23 PM, Raymond (Juin-Hwey) Chen < >> rchen@broadcom.com> wrote: >> >> I would agree with Roman that for speech the difference between wideban= d >>> (16 kHz sampling) and super-wideband/full-band (32 ~ 48 kHz sampling) i= s >>> there but very small and many people cannot even distinguish between >>> them, >>> while for music the difference can be much more noticeable. From all th= e >>> codec WG emails dating back to last year, it appears to me that most >>> people >>> want the IETF codec to handle music as well as speech. Therefore, it >>> seems >>> appropriate to have the maximum sampling rate up to 48 kHz if we want t= o >>> the >>> codec to handle music. >>> >>> >>> >>> Regarding the dynamic switching of the sampling rate or audio bandwidth= , >>> if >>> this is to be done, I think we need to be careful not to change the aud= io >>> bandwidth too frequently, otherwise the frequent change of the audio >>> bandwidth can be quite disturbing to the listener. It would certainly = be >>> disturbing to me personally if the audio bandwidth changes more >>> frequently >>> than once every few seconds, but if it changes once every few minutes, >>> that's probably tolerable to me. >>> >>> >>> >>> Raymond >>> >>> >>> >>> *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On >>> Behalf >>> Of *stephen botzko >>> *Sent:* Tuesday, April 13, 2010 11:43 AM >>> *To:* Roman Shpount >>> >>> *Cc:* codec@ietf.org >>> *Subject:* Re: [codec] #8: Sample rates? >>> >>> >>> >>> >>> >>> >>> I will not argue superwideband vs wideband, even though we did some, no= t >>> very scientific, blind tests, and in most cases people (especially men) >>> cannot even distinguish wideband from superwideband when listening t= o >>> voice samples. Only a very small percentage of voice energy is even >>> present >>> above 8 Khz. >>> >>> >>> >>> Though there isn't much voice energy over 8 kHz, in our (equally >>> unscientific) tests, sibilants and fricatives are easier to distinguish >>> if >>> you are using superwideband or better. That was one reason we added >>> Annec C >>> to G.722.1. >>> >>> Fullband is (IMHO) a specsmanship thing for speech (and probably for >>> music >>> also for most of us). Though it may not be that hard to get it, if we >>> are >>> shooting for superwideband anyway. >>> >>> Stephen Botzko >>> >>> On Tue, Apr 13, 2010 at 2:11 PM, Roman Shpount >>> wrote: >>> >>> I will not argue superwideband vs wideband, even though we did some, no= t >>> very scientific, blind tests, and in most cases people (especially men) >>> cannot even distinguish wideband from superwideband when listening to >>> voice >>> samples. Only a very small percentage of voice energy is even present >>> above >>> 8 Khz. >>> >>> Music on the other hand, especially past 24Khz sampling rate, gets >>> affected >>> by the CODEC more then by bandwidth. For instance 8KHz G.711 encoded >>> music >>> sounds poor, but reasonable, and G.729 encoded music cannot be listened >>> to. >>> In most cases (apart from critical listening), music sampled at 16Khz i= s >>> acceptable, especially for generation iPod. >>> >>> My remark about RTPC was to try to develop a CODEC that will function >>> properly with RTCP absent. If we require RTCP based mechanisms in order >>> for >>> the CODEC to operate properly, this can impede the adoption of this >>> CODEC. >>> In no way do I propose to create new signaling mechanisms. >>> >>> >>> ______________________________ >>> Roman Shpount - www.telurix.com >>> >>> On Tue, Apr 13, 2010 at 1:29 PM, stephen botzko < >>> stephen.botzko@gmail.com> wrote: >>> >>> Superwideband (and even fullband) do make speech somewhat more >>> intelligible, and also reduce listener fatigue. Telepresence and other >>> videoconferencing equipment use those acoustic bandwidths today, so it >>> would >>> be nice if CODEC supported at least superwideband also. >>> >>> Personally I see some value in carriage of music. Sometimes our >>> equipment >>> is used for music performance. Distance learning is another use case >>> where >>> music has some value, since course and training materials frequently do >>> include videos with music. Though of course conversational speech is t= he >>> dominant use case. >>> >>> BTW, Videoconferencing devices do almost always support RTCP. It is >>> regrettable that so many VOIP devices do not. Anyway, I do not think o= ur >>> charter scope includes invention of a new mechanism for signaling the >>> network quality. >>> >>> Stephen Botzko >>> >>> >>> >>> On Tue, Apr 13, 2010 at 12:41 PM, Roman Shpount >>> wrote: >>> >>> I am not sure if this was decided, but should this new CODEC support >>> music >>> encoding? If we don't plan to support music, we should probably stick t= o >>> 16 >>> Khz sampling rate. If we need music, I would suggest to have a 24 Khz (= or >>> higher sampling rate) variant. I am not sure how many people here care >>> about >>> a non-voice CODEC. For all the practical purposes I don't. I would argu= e, >>> at least, for a fixed 16 KHz sampling rate CODEC variant. >>> >>> P.S. On the same note, does anybody here cares about using this CODEC >>> with >>> multicast? Is there a single commercial multicast voice deployment? Fro= m >>> what I've seen all multicast does is making IETF voice standards harder >>> to >>> understand or implement. >>> >>> P.P.S. RTCP is almost universally not implemented. The biggest VoIP >>> gateway >>> on the market does not generate RTCP. If we will rely on any RTCP >>> functionality for bandwidth control it will probably be ignored. >>> ______________________________ >>> Roman Shpount - www.telurix.com >>> >>> On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko < >>> stephen.botzko@gmail.com> wrote: >>> >>> TCP is a different case, since for this we are using RTCP to signal ou= r >>> feedback, and I don't think it has the facility you are envisioning. >>> >>> Also, I disagree with your presumption that multicast is out of scope. = I >>> don't know of any other packetization RFCs that expressly rule out >>> multicast, and multicast can be used for interactive applications. >>> >>> This concept seems pretty theoretical to me. If we need to manage >>> complexity / quality tradeoffs, why not just use profiles (as AVC/H.264 >>> does) or create a low complexity variant (like G.729A). I really don't >>> see >>> the need for *dynamic* complexity management. >>> >>> BTW, you seem to be assuming that a lower sample rate results in >>> significantly less complexity. The savings there might not be as great >>> as >>> you think, especially if the receiver needs to resample anyway (to >>> prevent >>> those sound card limitations you were talking about before). >>> >>> Stephen Botzko >>> >>> On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene < >>> hoene@uni-tuebingen.de> >>> wrote: >>> >>> Hi, >>> >>> >>> >>> comments inline: >>> >>> >>> >>> >>> >>> *From:* stephen botzko [mailto:stephen.botzko@gmail.com] >>> *Sent:* Tuesday, April 13, 2010 4:56 PM >>> *To:* Christian Hoene >>> *Cc:* codec@ietf.org >>> >>> >>> *Subject:* Re: [codec] #8: Sample rates? >>> >>> >>> >>> This would make the signaling more complicated - personally I am not >>> convinced it is worth it. >>> >>> CH: It is a difficult tradeoff. However, signaling overload is done in >>> Skype. Such as signaling might be very useful for mobile devices, whic= h >>> want to save power and thus lower their CPU clock. Or wireless IP based >>> headphones which do not have large batteries. I am thinking of signalin= g >>> the >>> states: overloaded, fine, and low. That should be enough for most >>> operational cases. >>> >>> >>> I think a better avenue is to bound overall complexity, and to focus on >>> dynamically adapting to network conditions (as opposed to dynamic >>> complexity >>> management). >>> >>> CH: I just like to remind that the good old TCP does support both: >>> congestion control to adapt to network conditions and flow control take >>> into >>> account an overloaded (=3Dfull) receiver. >>> >>> You can't dynamically negotiate complexity in many scenarios anyway - f= or >>> instance it makes no sense if you are using multicast. >>> >>> CH: Multicast is out of scope anyhow. We are considering an interactive >>> codec. >>> >>> CH: The conferencing scenario might be some more difficult to handle bu= t >>> will not a big problem. >>> >>> Christian >>> >>> >>> >>> Stephen Botzko >>> >>> On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene < >>> hoene@uni-tuebingen.de> >>> wrote: >>> >>> Hi, >>> >>> >>> >>> It still might make sense to negotiate the maximal supported sampling >>> rate >>> via SDP or, if possible, to select one out of multiple sampling rates, = if >>> the audio receiver can cope with multiple rates well. The internal >>> sampling >>> frequency of the codec NEEDS NOT to be affected by the external samplin= g >>> frequency. >>> >>> >>> >>> However, the decoder might want to signal to the encoder that the >>> decoding >>> is requiring too many computational resources and that a less complex >>> coding >>> mode (or a lower sampling frequency) should be taken. >>> >>> >>> >>> Christian >>> >>> >>> >>> >>> >>> --------------------------------------------------------------- >>> >>> Dr.-Ing. Christian Hoene >>> >>> Interactive Communication Systems (ICS), University of T=FCbingen >>> >>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >>> http://www.net.uni-tuebingen.de/ >>> >>> >>> >>> *From:* stephen botzko [mailto:stephen.botzko@gmail.com] >>> *Sent:* Tuesday, April 13, 2010 3:21 PM >>> *To:* Kevin P. Fleming >>> *Cc:* Christian Hoene; codec@ietf.org >>> *Subject:* Re: [codec] #8: Sample rates? >>> >>> >>> >>> Though I generally avoid MAY, this could be a case where it makes sense= . >>> >>> Something like: >>> >>> CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to >>> optimize audio quality. >>> >>> This is free of any technology assumption about *how* the acoustic >>> bandwidth is reduced. The MAY indicates that it is permissible. But i= f >>> the >>> CODEC algorithm doesn't need to reduce the acoustic bandwidth, then we >>> are >>> making no statement that it SHOULD (or SHOULD NOT). >>> >>> Kevin is distinguishing dynamic changes to the sample rate (for bandwid= th >>> management) from multiple fixed sample rates; and I agree that is a key >>> distinction. >>> >>> I have not heard any clear application requirement for more than one >>> fixed >>> sampling rate. Though if there is such a requirement, IMHO we would ha= ve >>> to >>> negotiate the rate within SDP in the usual way, and it would affect the >>> RTP >>> timestamps, jitter buffers, etc. G.722.1 / G.722.1C is one precedent - >>> it >>> is the same core codec, but can run at two different sample rates >>> (negotiated by SDP). >>> >>> Stephen Botzko >>> >>> On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming >>> wrote: >>> >>> stephen botzko wrote: >>> >>> > Dynamically changing sample rates on the system level adds some >>> > complexity for RTP, since the timestamp granularity is supposed to be >>> > the sample rate. >>> >>> And jitter buffers, and anything else that is based on timestamps and >>> sample rates/counts. If the desire is for the codec to be able to chang= e >>> sample rates to adjust to network conditions, then I agree with >>> Stephen... the 'external' sample rate (input to the encoder and output >>> from the decoder) should be fixed, and this is what would be negotiated >>> in SDP and used for RTP timestamps. The codec can downsample in the >>> encoder and upsample in the decoder if it has decided to transmit fewer >>> bits across the network. >>> >>> -- >>> Kevin P. Fleming >>> Digium, Inc. | Director of Software Technologies >>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >>> skype: kpfleming | jabber: kfleming@digium.com >>> Check us out at www.digium.com & www.asterisk.org >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >> > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016e647ecc432531204842aefc6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
To be honest, your slides show that SILK works better at superwideband= , not that superwideband is better then wideband. Normally, G.711 at=A08 KH= z has a higher MOS (4.4) score then SILK at superwideband (3.9). To compare= wideband vs superwideband (or full=A0rate)=A0you need to compare 16 Khz li= near PCM vs superwideband (or full rate) linear PCM. As far as full rate is= concerned, most men cannot hear above 12-14 khz. In side by side listening= tests we did, using high end headsets (AKG K-701, Sennheiser HD 650) and p= rofessional DAC/headphone AMP (Benchmark DAC-1) using prerecorded voice sam= ples (English, adult voices, no kids), nobody could distinguish wideband fr= om superwideband, but this can be us, our samples,=A0and untrained listener= s.
=A0
I understand the motivation for defining the codec that will go all th= e way to full band, but I think,=A0it would make sense to define at least t= wo codec profiles: 16 KHz mono, and compatible full rate codec with support= for joint multichannel encoding, similar to AMR-WB and AMR-WB+.
_____________________________
Roman Shpount - www.telurix.com


On Tue, Apr 13, 2010 at 7:48 PM, Koen Vos <koen.vos@skype.net> wrote:
My 2 cents on this thread:
- Going beyond WB quality matters a lot, even for speech. =A0See for exam= ple slides 2, 3 of http://www.ietf.org/proceedings/10mar/slides= /codec-3.pdf. =A0Agree with Ben that we might as well go full-band.

- The codec has 3 sampling rates:
=A01. Encoder API
=A02. Codec i= nternal (not strictly sampling rate, more audio bandwidth as Stephen pointe= d out)
=A03. Decoder API
I don't see a reason to impose that some= or all of these be identical. =A0For (conference) mixing of several stream= s it helps if all decoders run at the same API sampling rate. It would be u= nreasonable to require that every encoder also runs at that API sampling ra= te. =A0Some encoders may for instance sit in a PSTN gateway, dealing strict= ly with narrowband signals.

- To keep RTP timestamps simple, they could always be based on the same= sampling rate, irrespective of any of the ones above. Maybe 48 kHz is a go= od choice?

- Sometimes a decoder runs on hardware with limited audio= bandwidth playback capabilities (e.g. mobile devices). =A0In those cases i= t helps if the decoder can request a maximum internal audio bandwidth to th= e encoder, during call setup. Otherwise the encoder may be wasting bits on = unused audio spectrum. =A0So I agree with Christian on this.

- Agree with Raymond that fast switching of audio bandwidth sounds unpl= easant. =A0SILK has a hysteresis mechanism for this, and we rarely get more= than one or two switches during a Skype call.

best,
koen.


Quoting stephen botzko <stephen.botzko@gmail.com>:

I agree.

The changes in a= udio bandwidth will certainly be audible, and personally I
would prefer = a stable experience.

Also, increasing the audio bandwidth might result in audible temporary = echo
(in the newly opened frequencies), since the acoustic echo cancelle= rs will
often need to re-adapt. =A0The acoustic feedback paths can chang= e pretty
quickly at higher frequencies.

Stephen Botzko

On Tue, Apr 13,= 2010 at 3:23 PM, Raymond (Juin-Hwey) Chen <
rchen@broadcom.com> wrote:

=A0I would agree with Roman that= for speech the difference between wideband
(16 kHz sampling) and super-= wideband/full-band (32 ~ 48 kHz sampling) is
there but very small and many people cannot even distinguish between them,<= br>while for music the difference can be much more noticeable. From all the=
codec WG emails dating back to last year, it appears to me that most pe= ople
want the IETF codec to handle music as well as speech. =A0Therefore, it see= ms
appropriate to have the maximum sampling rate up to 48 kHz if we want= to the
codec to handle music.



Regarding the dynamic swit= ching of the sampling rate or audio bandwidth, if
this is to be done, I think we need to be careful not to change the audiobandwidth too frequently, otherwise the frequent change of the audio
b= andwidth can be quite disturbing to the listener. =A0It would certainly be<= br> disturbing to me personally if the audio bandwidth changes more frequently<= br>than once every few seconds, but if it changes once every few minutes,that's probably tolerable to me.



Raymond



*From:* cod= ec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf
Of *stephen botz= ko
*Sent:* Tuesday, April 13, 2010 11:43 AM
*To:* Roman Shpount

*Cc:= * codec@ietf.org*Subject:* Re: [codec] #8: Sample rates?



>>>
I will not argue superwideband vs wideband, even though we did some, notvery scientific, blind tests, and in most cases people (especially men)cannot even distinguish wideband from superwideband when =A0 =A0listening = to
voice samples. Only a very small percentage of voice energy is even present=
above 8 Khz.

>>>
Though there isn't much voice e= nergy over 8 kHz, in our (equally
unscientific) tests, sibilants and fri= catives are easier to distinguish if
you are using superwideband or better. =A0That was one reason we added Anne= c C
to G.722.1.

Fullband is (IMHO) a specsmanship thing for speec= h (and probably for music
also for most of us). =A0Though it may not be = that hard to get it, if we are
shooting for superwideband anyway.

Stephen Botzko

=A0On Tue, = Apr 13, 2010 at 2:11 PM, Roman Shpount <roman@telurix.com> wrote:

I will not a= rgue superwideband vs wideband, even though we did some, not
very scientific, blind tests, and in most cases people (especially men)
= cannot even distinguish wideband from superwideband when listening to voice=
samples. Only a very small percentage of voice energy is even present a= bove
8 Khz.

Music on the other hand, especially past 24Khz sampling rate,= gets affected
by the CODEC more then by bandwidth. For instance 8KHz G.= 711 encoded music
sounds poor, but reasonable, and G.729 encoded music c= annot be listened to.
In most cases (apart from critical listening), music sampled at 16Khz isacceptable, especially for generation iPod.

My remark about RTPC wa= s to try to develop a CODEC that will function
properly with RTCP absent= . If we require RTCP based mechanisms in order for
the CODEC to operate properly, this can impede the adoption of this CODEC.<= br>In no way do I propose to create new signaling mechanisms.


__= ____________________________
Roman Shpount - www.telurix.com

=A0 On Tue, Apr 13, 2010 at 1:29 PM, stephen botzko <
stephen.botzko@gmail.com= > wrote:

Superwideband (and even fullband) do make speech som= ewhat more
intelligible, and also reduce listener fatigue. =A0Telepresence and othervideoconferencing equipment use those acoustic bandwidths today, so it wo= uld
be nice if CODEC supported at least superwideband also.

Perso= nally I see some value in carriage of music. =A0Sometimes our equipment
is used for music performance. =A0Distance learning is another use case whe= re
music has some value, since course and training materials frequently = do
include videos with music. =A0Though of course conversational speech = is the
dominant use case.

BTW, Videoconferencing devices do almost always s= upport RTCP. =A0It is
regrettable that so many VOIP devices do not. =A0A= nyway, I do not think our
charter scope includes invention of a new mech= anism for signaling the
network quality.

Stephen Botzko



On Tue, Apr 13, 2010 = at 12:41 PM, Roman Shpount <roman@telurix.com> wrote:

I am not sure if this w= as decided, but should this new CODEC support music
encoding? If we don't plan to support music, we should probably stick t= o 16
Khz sampling rate. If we need music, I would suggest to have a 24 K= hz (or
higher sampling rate) variant. I am not sure how many people here= care about
a non-voice CODEC. For all the practical purposes I don't. I would argu= e,
at least, for a fixed 16 KHz sampling rate CODEC variant.

P.S.= On the same note, does anybody here cares about using this CODEC with
multicast? Is there a single commercial multicast voice deployment? Fromwhat I've seen all multicast does is making IETF voice standards harde= r to
understand or implement.

P.P.S. RTCP is almost universally n= ot implemented. The biggest VoIP gateway
on the market does not generate RTCP. If we will rely on any RTCP
functi= onality for bandwidth control it will probably be ignored.
_____________= _________________
Roman Shpount - =A0www.telurix.com

=A0On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko <
stephen.botzko@gmail.com= > wrote:

=A0TCP is a different case, since for this we are us= ing RTCP to signal our
feedback, and I don't think it has the facility you are envisioning.
Also, I disagree with your presumption that multicast is out of scope.= =A0I
don't know of any other packetization RFCs that expressly rule= out
multicast, and multicast can be used for interactive applications.

T= his concept seems pretty theoretical to me. =A0If we need to manage
comp= lexity / quality tradeoffs, why not just use profiles (as AVC/H.264
does= ) or create a low complexity variant (like G.729A). =A0I really don't s= ee
the need for *dynamic* complexity management.

BTW, you seem to be as= suming that a lower sample rate results in
significantly less complexity= . =A0The savings there might not be as great as
you think, especially if= the receiver needs to resample anyway (to prevent
those sound card limitations you were talking about before).

Stephen= Botzko

On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene <hoene@uni-tuebingen.d= e>
wrote:

Hi,



comments inline:





*F= rom:* stephen botzko [mailto:stephen.botzko@gmail.com]
*Sent:* Tuesday, April 13,= 2010 4:56 PM
*To:* Christian Hoene
*Cc:* codec@ietf.org


*Subject:* Re: [codec] #8: Sample rat= es?



This would make the signaling more complicated - persona= lly I am not
convinced it is worth it.

CH: It is a difficult tradeoff. However, s= ignaling overload is done in
Skype. =A0Such as signaling might be very u= seful for mobile devices, which
want to save power and thus lower their = CPU clock. Or wireless IP based
headphones which do not have large batteries. I am thinking of signaling th= e
states: overloaded, fine, and low. That should be enough for most
o= perational cases.


I think a better avenue is to bound overall co= mplexity, and to focus on
dynamically adapting to network conditions (as opposed to dynamic complexit= y
management).

CH: I just like to remind that the good old TCP do= es support both:
congestion control to adapt to network conditions and f= low control take into
account an overloaded (=3Dfull) receiver.

You can't dynamically = negotiate complexity in many scenarios anyway - for
instance it makes no= sense if you are using multicast.

CH: Multicast is out of scope any= how. We are considering an interactive
codec.

CH: The conferencing scenario might be some more difficult to= handle but
will not a big problem.

Christian



Step= hen Botzko

On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene <hoene@uni-tuebinge= n.de>
wrote:

Hi,



It still might make sense to negotiate the= maximal supported sampling rate
via SDP or, if possible, to select one = out of multiple sampling rates, if
the audio receiver can cope with mult= iple rates well. The internal sampling
frequency of the codec NEEDS NOT to be affected by the external samplingfrequency.



However, the decoder might want to signal to the= encoder that the decoding
is requiring too many computational resources= and that a less complex coding
mode (or a lower sampling frequency) should be taken.



Christ= ian





------------------------------------------------= ---------------

Dr.-Ing. Christian Hoene

Interactive Communic= ation Systems (ICS), University of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-= tuebingen.de/



*From:* stephen botzko [mailto:stephen.botzko@gmail.com= ]
*Sent:* Tuesday, April 13, 2010 3:21 PM
*To:* Kevin P. Fleming
*Cc:* = Christian Hoene; codec@= ietf.org
*Subject:* Re: [codec] #8: Sample rates?



Tho= ugh I generally avoid MAY, this could be a case where it makes sense.

Something like:

CODEC MAY reduce the acoustic bandwidth at lower= bit rates in order to
optimize audio quality.

This is free of an= y technology assumption about *how* the acoustic
bandwidth is reduced. = =A0The MAY indicates that it is permissible. =A0But if the
CODEC algorithm doesn't need to reduce the acoustic bandwidth, then we = are
making no statement that it SHOULD (or SHOULD NOT).

Kevin is = distinguishing dynamic changes to the sample rate (for bandwidth
managem= ent) from multiple fixed sample rates; and I agree that is a key
distinction.

I have not heard any clear application requirement for = more than one fixed
sampling rate. =A0Though if there is such a requirem= ent, IMHO we would have to
negotiate the rate within SDP in the usual wa= y, and it would affect the RTP
timestamps, jitter buffers, etc. =A0G.722.1 / G.722.1C is one precedent - i= t
is the same core codec, but can run at two different sample rates
(= negotiated by SDP).

Stephen Botzko

On Tue, Apr 13, 2010 at 7:= 41 AM, Kevin P. Fleming <kpfleming@digium.com>
wrote:

stephen botzko wrote:

> Dynamically changing sample= rates on the system level adds some
> complexity for RTP, since the = timestamp granularity is supposed to be
> the sample rate.

And jitter buffers, and anything else that is based on timestamps and
sa= mple rates/counts. If the desire is for the codec to be able to change
s= ample rates to adjust to network conditions, then I agree with
Stephen..= . the 'external' sample rate (input to the encoder and output
from the decoder) should be fixed, and this is what would be negotiated
= in SDP and used for RTP timestamps. The codec can downsample in the
enco= der and upsample in the decoder if it has decided to transmit fewer
bits across the network.

--
Kevin P. Fleming
Digium, Inc. | Di= rector of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL = 35806 - USA
skype: kpfleming | jabber: kfleming@digium.com
Check us out at www.di= gium.com & w= ww.asterisk.org







________________________= _______________________
codec mailing list
c= odec@ietf.org
https://www.ietf.org/mailman/listinfo/codec

=









_____________= __________________________________
codec mailing list
codec@ietf.org
https://www.ietf.= org/mailman/listinfo/codec

--0016e647ecc432531204842aefc6-- From koen.vos@skype.net Tue Apr 13 22:20:28 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B2AC228C251 for ; Tue, 13 Apr 2010 22:20:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.152 X-Spam-Level: X-Spam-Status: No, score=-5.152 tagged_above=-999 required=5 tests=[AWL=0.051, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zmkmp6i3wHYs for ; Tue, 13 Apr 2010 22:20:10 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 455593A67CC for ; Tue, 13 Apr 2010 22:19:06 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 5F50160133D57; Wed, 14 Apr 2010 06:18:53 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=8nWxtCalPDi3 oD+WOq9/H3MmZT8=; b=rlgBU1rNasyVZd68FR8Sa280FI1A15GnlvEt2OE6QCdR V1q0xBZiwcBanN4duiDyJA2vxEhk5grd9XO4M8Ro/WLBIpSr5C5PKHXoZQCghjCI fWnz4SdVObdt7YO5BIxbiZhS2ElC+yam2SwWkLQotcq//kK7b5Gi3zzG1dHUcf0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=mSYUR2YnNa2zDtA7nSpR Xsj9m7rUdLfamOPnmwHBrunhiZfjq6o0w1Cdjkn9wlA/jWtlMbWbXZDVGqIajPII d2lWsrUKuSvdMTJDTz0esJwC8HWvbP2mKAU8SnchKMyVcQAm+nqDPP/zVLYtieFe FD2rky4qBBvAuzq6wcEWdd0= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 5D1CA60133D51; Wed, 14 Apr 2010 06:18:53 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gY7ta3Zq9FDz; Wed, 14 Apr 2010 06:18:51 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id E774360133D5A; Wed, 14 Apr 2010 06:18:51 +0100 (IST) Received: from adsl-71-141-129-119.dsl.snfc21.pacbell.net (adsl-71-141-129-119.dsl.snfc21.pacbell.net [71.141.129.119]) by mail.skype.net (Horde Framework) with HTTP; Tue, 13 Apr 2010 22:18:51 -0700 Message-ID: <20100413221851.32876potjzfwv0hn@mail.skype.net> Date: Tue, 13 Apr 2010 22:18:51 -0700 From: Koen Vos To: Roman Shpount References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <003101cadb1c$828b3990$87a1acb0$@de> <20100413164818.546929eae97cjjr6@mail.skype.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 05:20:31 -0000 Roman - good observation. However, these graphs were based on only calls where the codec ran at =20 the maximum bitrate (30 kbps for SILK WB). At this bitrate, SILK is =20 (virtually) transparent, according to Dynastat tests we did. See the =20 MOS scores here https://developer.skype.com/silk?action=3DAttachFile&do=3Dget&target=3DSILKD= ataSheet.pdf There could be many reasons why we got only MOS scores around 3.8 in =20 the client-based testing.. Perhaps users in an official listening =20 test score more optimistically than anonymous users behind their =20 PCs... Or factors outside the codec, like background noise, a crappy =20 headset or network problems, may have limited the audio quality. (There is one minor "flaw" in the test: SILK SWB has a higher maximum =20 bitrate (40 kbps) than SILK WB; and the other modes have even lower =20 max rates. So SWB calls that were included (>=3D 40 kbps) had on =20 average better network bandwidth than WB calls (>=3D 30 kbps). This may =20 have meant that SWB calls just had better networks with less packet =20 loss etc., on average. However, if we exclude the filtering on max =20 bitrates then the pattern still exists, just slightly weakened. And =20 in that case, SILK SWB would occasionally be running in WB mode or =20 less, because it automatically switches down at lower bitrates.) best, koen. Quoting Roman Shpount : > To be honest, your slides show that SILK works better at superwideband, no= t > that superwideband is better then wideband. Normally, G.711 at 8 KHz has a > higher MOS (4.4) score then SILK at superwideband (3.9). To compare wideba= nd > vs superwideband (or full rate) you need to compare 16 Khz linear PCM vs > superwideband (or full rate) linear PCM. As far as full rate is concerned, > most men cannot hear above 12-14 khz. In side by side listening tests we > did, using high end headsets (AKG K-701, Sennheiser HD 650) and profession= al > DAC/headphone AMP (Benchmark DAC-1) using prerecorded voice samples > (English, adult voices, no kids), nobody could distinguish wideband from > superwideband, but this can be us, our samples, and untrained listeners. > > I understand the motivation for defining the codec that will go all the wa= y > to full band, but I think, it would make sense to define at least two code= c > profiles: 16 KHz mono, and compatible full rate codec with support for joi= nt > multichannel encoding, similar to AMR-WB and AMR-WB+. > _____________________________ > Roman Shpount - www.telurix.com > > > On Tue, Apr 13, 2010 at 7:48 PM, Koen Vos wrote: > >> My 2 cents on this thread: >> >> - Going beyond WB quality matters a lot, even for speech. See for exampl= e >> slides 2, 3 of http://www.ietf.org/proceedings/10mar/slides/codec-3.pdf. >> Agree with Ben that we might as well go full-band. >> >> - The codec has 3 sampling rates: >> 1. Encoder API >> 2. Codec internal (not strictly sampling rate, more audio bandwidth as >> Stephen pointed out) >> 3. Decoder API >> I don't see a reason to impose that some or all of these be identical. F= or >> (conference) mixing of several streams it helps if all decoders run at th= e >> same API sampling rate. It would be unreasonable to require that every >> encoder also runs at that API sampling rate. Some encoders may for insta= nce >> sit in a PSTN gateway, dealing strictly with narrowband signals. >> >> - To keep RTP timestamps simple, they could always be based on the same >> sampling rate, irrespective of any of the ones above. Maybe 48 kHz is a g= ood >> choice? >> >> - Sometimes a decoder runs on hardware with limited audio bandwidth >> playback capabilities (e.g. mobile devices). In those cases it helps if = the >> decoder can request a maximum internal audio bandwidth to the encoder, >> during call setup. Otherwise the encoder may be wasting bits on unused au= dio >> spectrum. So I agree with Christian on this. >> >> - Agree with Raymond that fast switching of audio bandwidth sounds >> unpleasant. SILK has a hysteresis mechanism for this, and we rarely get >> more than one or two switches during a Skype call. >> >> best, >> koen. >> >> >> >> Quoting stephen botzko : >> >> I agree. >>> >>> The changes in audio bandwidth will certainly be audible, and personally= I >>> would prefer a stable experience. >>> >>> Also, increasing the audio bandwidth might result in audible temporary >>> echo >>> (in the newly opened frequencies), since the acoustic echo cancellers wi= ll >>> often need to re-adapt. The acoustic feedback paths can change pretty >>> quickly at higher frequencies. >>> >>> Stephen Botzko >>> >>> On Tue, Apr 13, 2010 at 3:23 PM, Raymond (Juin-Hwey) Chen < >>> rchen@broadcom.com> wrote: >>> >>> I would agree with Roman that for speech the difference between wideban= d >>>> (16 kHz sampling) and super-wideband/full-band (32 ~ 48 kHz sampling) i= s >>>> there but very small and many people cannot even distinguish between >>>> them, >>>> while for music the difference can be much more noticeable. From all th= e >>>> codec WG emails dating back to last year, it appears to me that most >>>> people >>>> want the IETF codec to handle music as well as speech. Therefore, it >>>> seems >>>> appropriate to have the maximum sampling rate up to 48 kHz if we want t= o >>>> the >>>> codec to handle music. >>>> >>>> >>>> >>>> Regarding the dynamic switching of the sampling rate or audio bandwidth= , >>>> if >>>> this is to be done, I think we need to be careful not to change the aud= io >>>> bandwidth too frequently, otherwise the frequent change of the audio >>>> bandwidth can be quite disturbing to the listener. It would certainly = be >>>> disturbing to me personally if the audio bandwidth changes more >>>> frequently >>>> than once every few seconds, but if it changes once every few minutes, >>>> that's probably tolerable to me. >>>> >>>> >>>> >>>> Raymond >>>> >>>> >>>> >>>> *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On >>>> Behalf >>>> Of *stephen botzko >>>> *Sent:* Tuesday, April 13, 2010 11:43 AM >>>> *To:* Roman Shpount >>>> >>>> *Cc:* codec@ietf.org >>>> *Subject:* Re: [codec] #8: Sample rates? >>>> >>>> >>>> >>>> >>> >>>> >>>> I will not argue superwideband vs wideband, even though we did some, no= t >>>> very scientific, blind tests, and in most cases people (especially men) >>>> cannot even distinguish wideband from superwideband when listening t= o >>>> voice samples. Only a very small percentage of voice energy is even >>>> present >>>> above 8 Khz. >>>> >>>> >>> >>>> Though there isn't much voice energy over 8 kHz, in our (equally >>>> unscientific) tests, sibilants and fricatives are easier to distinguish >>>> if >>>> you are using superwideband or better. That was one reason we added >>>> Annec C >>>> to G.722.1. >>>> >>>> Fullband is (IMHO) a specsmanship thing for speech (and probably for >>>> music >>>> also for most of us). Though it may not be that hard to get it, if we >>>> are >>>> shooting for superwideband anyway. >>>> >>>> Stephen Botzko >>>> >>>> On Tue, Apr 13, 2010 at 2:11 PM, Roman Shpount >>>> wrote: >>>> >>>> I will not argue superwideband vs wideband, even though we did some, no= t >>>> very scientific, blind tests, and in most cases people (especially men) >>>> cannot even distinguish wideband from superwideband when listening to >>>> voice >>>> samples. Only a very small percentage of voice energy is even present >>>> above >>>> 8 Khz. >>>> >>>> Music on the other hand, especially past 24Khz sampling rate, gets >>>> affected >>>> by the CODEC more then by bandwidth. For instance 8KHz G.711 encoded >>>> music >>>> sounds poor, but reasonable, and G.729 encoded music cannot be listened >>>> to. >>>> In most cases (apart from critical listening), music sampled at 16Khz i= s >>>> acceptable, especially for generation iPod. >>>> >>>> My remark about RTPC was to try to develop a CODEC that will function >>>> properly with RTCP absent. If we require RTCP based mechanisms in order >>>> for >>>> the CODEC to operate properly, this can impede the adoption of this >>>> CODEC. >>>> In no way do I propose to create new signaling mechanisms. >>>> >>>> >>>> ______________________________ >>>> Roman Shpount - www.telurix.com >>>> >>>> On Tue, Apr 13, 2010 at 1:29 PM, stephen botzko < >>>> stephen.botzko@gmail.com> wrote: >>>> >>>> Superwideband (and even fullband) do make speech somewhat more >>>> intelligible, and also reduce listener fatigue. Telepresence and other >>>> videoconferencing equipment use those acoustic bandwidths today, so it >>>> would >>>> be nice if CODEC supported at least superwideband also. >>>> >>>> Personally I see some value in carriage of music. Sometimes our >>>> equipment >>>> is used for music performance. Distance learning is another use case >>>> where >>>> music has some value, since course and training materials frequently do >>>> include videos with music. Though of course conversational speech is t= he >>>> dominant use case. >>>> >>>> BTW, Videoconferencing devices do almost always support RTCP. It is >>>> regrettable that so many VOIP devices do not. Anyway, I do not think o= ur >>>> charter scope includes invention of a new mechanism for signaling the >>>> network quality. >>>> >>>> Stephen Botzko >>>> >>>> >>>> >>>> On Tue, Apr 13, 2010 at 12:41 PM, Roman Shpount >>>> wrote: >>>> >>>> I am not sure if this was decided, but should this new CODEC support >>>> music >>>> encoding? If we don't plan to support music, we should probably stick t= o >>>> 16 >>>> Khz sampling rate. If we need music, I would suggest to have a 24 Khz (= or >>>> higher sampling rate) variant. I am not sure how many people here care >>>> about >>>> a non-voice CODEC. For all the practical purposes I don't. I would argu= e, >>>> at least, for a fixed 16 KHz sampling rate CODEC variant. >>>> >>>> P.S. On the same note, does anybody here cares about using this CODEC >>>> with >>>> multicast? Is there a single commercial multicast voice deployment? Fro= m >>>> what I've seen all multicast does is making IETF voice standards harder >>>> to >>>> understand or implement. >>>> >>>> P.P.S. RTCP is almost universally not implemented. The biggest VoIP >>>> gateway >>>> on the market does not generate RTCP. If we will rely on any RTCP >>>> functionality for bandwidth control it will probably be ignored. >>>> ______________________________ >>>> Roman Shpount - www.telurix.com >>>> >>>> On Tue, Apr 13, 2010 at 12:26 PM, stephen botzko < >>>> stephen.botzko@gmail.com> wrote: >>>> >>>> TCP is a different case, since for this we are using RTCP to signal ou= r >>>> feedback, and I don't think it has the facility you are envisioning. >>>> >>>> Also, I disagree with your presumption that multicast is out of scope. = I >>>> don't know of any other packetization RFCs that expressly rule out >>>> multicast, and multicast can be used for interactive applications. >>>> >>>> This concept seems pretty theoretical to me. If we need to manage >>>> complexity / quality tradeoffs, why not just use profiles (as AVC/H.264 >>>> does) or create a low complexity variant (like G.729A). I really don't >>>> see >>>> the need for *dynamic* complexity management. >>>> >>>> BTW, you seem to be assuming that a lower sample rate results in >>>> significantly less complexity. The savings there might not be as great >>>> as >>>> you think, especially if the receiver needs to resample anyway (to >>>> prevent >>>> those sound card limitations you were talking about before). >>>> >>>> Stephen Botzko >>>> >>>> On Tue, Apr 13, 2010 at 11:18 AM, Christian Hoene < >>>> hoene@uni-tuebingen.de> >>>> wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>> comments inline: >>>> >>>> >>>> >>>> >>>> >>>> *From:* stephen botzko [mailto:stephen.botzko@gmail.com] >>>> *Sent:* Tuesday, April 13, 2010 4:56 PM >>>> *To:* Christian Hoene >>>> *Cc:* codec@ietf.org >>>> >>>> >>>> *Subject:* Re: [codec] #8: Sample rates? >>>> >>>> >>>> >>>> This would make the signaling more complicated - personally I am not >>>> convinced it is worth it. >>>> >>>> CH: It is a difficult tradeoff. However, signaling overload is done in >>>> Skype. Such as signaling might be very useful for mobile devices, whic= h >>>> want to save power and thus lower their CPU clock. Or wireless IP based >>>> headphones which do not have large batteries. I am thinking of signalin= g >>>> the >>>> states: overloaded, fine, and low. That should be enough for most >>>> operational cases. >>>> >>>> >>>> I think a better avenue is to bound overall complexity, and to focus on >>>> dynamically adapting to network conditions (as opposed to dynamic >>>> complexity >>>> management). >>>> >>>> CH: I just like to remind that the good old TCP does support both: >>>> congestion control to adapt to network conditions and flow control take >>>> into >>>> account an overloaded (=3Dfull) receiver. >>>> >>>> You can't dynamically negotiate complexity in many scenarios anyway - f= or >>>> instance it makes no sense if you are using multicast. >>>> >>>> CH: Multicast is out of scope anyhow. We are considering an interactive >>>> codec. >>>> >>>> CH: The conferencing scenario might be some more difficult to handle bu= t >>>> will not a big problem. >>>> >>>> Christian >>>> >>>> >>>> >>>> Stephen Botzko >>>> >>>> On Tue, Apr 13, 2010 at 10:42 AM, Christian Hoene < >>>> hoene@uni-tuebingen.de> >>>> wrote: >>>> >>>> Hi, >>>> >>>> >>>> >>>> It still might make sense to negotiate the maximal supported sampling >>>> rate >>>> via SDP or, if possible, to select one out of multiple sampling rates, = if >>>> the audio receiver can cope with multiple rates well. The internal >>>> sampling >>>> frequency of the codec NEEDS NOT to be affected by the external samplin= g >>>> frequency. >>>> >>>> >>>> >>>> However, the decoder might want to signal to the encoder that the >>>> decoding >>>> is requiring too many computational resources and that a less complex >>>> coding >>>> mode (or a lower sampling frequency) should be taken. >>>> >>>> >>>> >>>> Christian >>>> >>>> >>>> >>>> >>>> >>>> --------------------------------------------------------------- >>>> >>>> Dr.-Ing. Christian Hoene >>>> >>>> Interactive Communication Systems (ICS), University of T=FCbingen >>>> >>>> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >>>> http://www.net.uni-tuebingen.de/ >>>> >>>> >>>> >>>> *From:* stephen botzko [mailto:stephen.botzko@gmail.com] >>>> *Sent:* Tuesday, April 13, 2010 3:21 PM >>>> *To:* Kevin P. Fleming >>>> *Cc:* Christian Hoene; codec@ietf.org >>>> *Subject:* Re: [codec] #8: Sample rates? >>>> >>>> >>>> >>>> Though I generally avoid MAY, this could be a case where it makes sense= . >>>> >>>> Something like: >>>> >>>> CODEC MAY reduce the acoustic bandwidth at lower bit rates in order to >>>> optimize audio quality. >>>> >>>> This is free of any technology assumption about *how* the acoustic >>>> bandwidth is reduced. The MAY indicates that it is permissible. But i= f >>>> the >>>> CODEC algorithm doesn't need to reduce the acoustic bandwidth, then we >>>> are >>>> making no statement that it SHOULD (or SHOULD NOT). >>>> >>>> Kevin is distinguishing dynamic changes to the sample rate (for bandwid= th >>>> management) from multiple fixed sample rates; and I agree that is a key >>>> distinction. >>>> >>>> I have not heard any clear application requirement for more than one >>>> fixed >>>> sampling rate. Though if there is such a requirement, IMHO we would ha= ve >>>> to >>>> negotiate the rate within SDP in the usual way, and it would affect the >>>> RTP >>>> timestamps, jitter buffers, etc. G.722.1 / G.722.1C is one precedent - >>>> it >>>> is the same core codec, but can run at two different sample rates >>>> (negotiated by SDP). >>>> >>>> Stephen Botzko >>>> >>>> On Tue, Apr 13, 2010 at 7:41 AM, Kevin P. Fleming >>>> wrote: >>>> >>>> stephen botzko wrote: >>>> >>>> > Dynamically changing sample rates on the system level adds some >>>> > complexity for RTP, since the timestamp granularity is supposed to be >>>> > the sample rate. >>>> >>>> And jitter buffers, and anything else that is based on timestamps and >>>> sample rates/counts. If the desire is for the codec to be able to chang= e >>>> sample rates to adjust to network conditions, then I agree with >>>> Stephen... the 'external' sample rate (input to the encoder and output >>>> from the decoder) should be fixed, and this is what would be negotiated >>>> in SDP and used for RTP timestamps. The codec can downsample in the >>>> encoder and upsample in the decoder if it has decided to transmit fewer >>>> bits across the network. >>>> >>>> -- >>>> Kevin P. Fleming >>>> Digium, Inc. | Director of Software Technologies >>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >>>> skype: kpfleming | jabber: kfleming@digium.com >>>> Check us out at www.digium.com & www.asterisk.org >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> codec mailing list >>>> codec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codec >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> > From jean-marc.valin@usherbrooke.ca Tue Apr 13 22:32:20 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7C0FA28C246 for ; Tue, 13 Apr 2010 22:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q-nsOWrZREx0 for ; Tue, 13 Apr 2010 22:32:19 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id D3F6628C260 for ; Tue, 13 Apr 2010 22:30:24 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [192.168.1.10] ([70.81.109.112]) by VL-MH-MR003.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0L0U00LKQPYH34X0@VL-MH-MR003.ip.videotron.ca> for codec@ietf.org; Wed, 14 Apr 2010 01:30:17 -0400 (EDT) Message-id: <4BC552E8.9090701@usherbrooke.ca> Date: Wed, 14 Apr 2010 01:30:16 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 To: Roman Shpount References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <003101cadb1c$828b3990$87a1acb0$@de> <20100413164818.546929eae97cjjr6@mail.skype.net> In-reply-to: Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 05:32:20 -0000 On 2010-04-14 00:37, Roman Shpount wrote: > To be honest, your slides show that SILK works better at superwideband, > not that superwideband is better then wideband. Then I suggest you have a look at the left graph in slide 7 of: http://www.ietf.org/proceedings/10mar/slides/codec-6.pdf The blue bars show speech quality and the bar that's marked with "7 kHz" means 7 kHz bandwidth, which means *uncompressed* wideband audio. > Normally, G.711 at 8 KHz > has a higher MOS (4.4) score then SILK at superwideband (3.9). Note that MOS is not an absolute measurement and MOS scored can only be compared when they come from the same test. > To > compare wideband vs superwideband (or full rate) you need to compare 16 > Khz linear PCM vs superwideband (or full rate) linear PCM. As far as > full rate is concerned, most men cannot hear above 12-14 khz. I disagree here. Don't know where you got that data, but it doesn't sound right. FTR, like many others, I'm over 30 and still easily hear the NSTC hozontal sync (15.3 kHz) coming out of CRT TVs. > In side by > side listening tests we did, using high end headsets (AKG K-701, > Sennheiser HD 650) and professional DAC/headphone AMP (Benchmark DAC-1) > using prerecorded voice samples (English, adult voices, no kids), nobody > could distinguish wideband from superwideband, but this can be us, our > samples, and untrained listeners. Well, my listening tests that I linked above clearly disagree with your results. Maybe you were using samples that were already low-passed at 7 kHz! Not saying that wideband (and even narrowband) doesn't have a use, just that full-band is definitely useful. Cheers, Jean-Marc From swmike@swm.pp.se Tue Apr 13 23:34:07 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 106783A67FE for ; Tue, 13 Apr 2010 23:34:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.76 X-Spam-Level: X-Spam-Status: No, score=-4.76 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PI7JCpsOwQjF for ; Tue, 13 Apr 2010 23:34:06 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id 330493A6BB1 for ; Tue, 13 Apr 2010 23:34:06 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 8D0869E; Wed, 14 Apr 2010 08:33:54 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 8B8A49C; Wed, 14 Apr 2010 08:33:54 +0200 (CEST) Date: Wed, 14 Apr 2010 08:33:54 +0200 (CEST) From: Mikael Abrahamsson To: bens@alum.mit.edu In-Reply-To: <4BC4BF26.9060008@fas.harvard.edu> Message-ID: References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <4BC4586F.1010709@digium.com> <001e01cadb17$886fcec0$994f6c40$@de> <003101cadb1c$828b3990$87a1acb0$@de> <4BC4BF26.9060008@fas.harvard.edu> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: codec@ietf.org, stephen botzko Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 06:34:07 -0000 On Tue, 13 Apr 2010, Benjamin M. Schwartz wrote: > I think scaling up to fullband and total transparency is important, so > that we never have to do this* again. > > --Ben > > *: "this" being standardizing a low-latency audio codec. Of course, we > can do this again if we want to, but we have an opportunity to be somewhat > "future-proof", and we might as well take it. Developing an Internet audio transmission standard without being able to handle music would be a mistake in my opinion. Most people think that 128kbit/s mp3 is good enough for music, and I think the codec chosen should have ability to deliver equivalent music sound quality. -- Mikael Abrahamsson email: swmike@swm.pp.se From roman@telurix.com Tue Apr 13 23:51:40 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EFE0A28C1AE for ; Tue, 13 Apr 2010 23:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.046 X-Spam-Level: X-Spam-Status: No, score=-1.046 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 72jjyDFd-zUA for ; Tue, 13 Apr 2010 23:51:39 -0700 (PDT) Received: from mail-qy0-f180.google.com (mail-qy0-f180.google.com [209.85.221.180]) by core3.amsl.com (Postfix) with ESMTP id C1FA428C1A6 for ; Tue, 13 Apr 2010 23:51:39 -0700 (PDT) Received: by qyk10 with SMTP id 10so3053333qyk.25 for ; Tue, 13 Apr 2010 23:51:31 -0700 (PDT) Received: by 10.229.26.135 with SMTP id e7mr7840656qcc.58.1271227869508; Tue, 13 Apr 2010 23:51:09 -0700 (PDT) Received: from mail-yw0-f186.google.com (mail-yw0-f186.google.com [209.85.211.186]) by mx.google.com with ESMTPS id y41sm2241qce.17.2010.04.13.23.51.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 13 Apr 2010 23:51:08 -0700 (PDT) Received: by ywh16 with SMTP id 16so2496564ywh.32 for ; Tue, 13 Apr 2010 23:51:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.14.205 with HTTP; Tue, 13 Apr 2010 23:51:06 -0700 (PDT) In-Reply-To: References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <003101cadb1c$828b3990$87a1acb0$@de> <4BC4BF26.9060008@fas.harvard.edu> Date: Wed, 14 Apr 2010 02:51:06 -0400 Received: by 10.150.237.1 with SMTP id k1mr5932199ybh.309.1271227866700; Tue, 13 Apr 2010 23:51:06 -0700 (PDT) Message-ID: From: Roman Shpount To: codec@ietf.org Content-Type: multipart/alternative; boundary=000e0cd2dc326c5d3904842ccdd1 Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 06:51:41 -0000 --000e0cd2dc326c5d3904842ccdd1 Content-Type: text/plain; charset=ISO-8859-1 Actually, since we are on the topic of full band, should this CODEC also support 20 and 24-bit audio samples? In music I can hear the difference between 16 and 24 bit encoded material. _____________________________ Roman Shpount - www.telurix.com --000e0cd2dc326c5d3904842ccdd1 Content-Type: text/html; charset=ISO-8859-1 Actually, since we are on the topic of full band, should this CODEC also support 20 and 24-bit audio samples? In music I can hear the difference between 16 and 24 bit encoded material.
_____________________________
Roman Shpount - www.telurix.com

--000e0cd2dc326c5d3904842ccdd1-- From hoene@uni-tuebingen.de Wed Apr 14 03:59:28 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A21493A68C1 for ; Wed, 14 Apr 2010 03:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.345 X-Spam-Level: X-Spam-Status: No, score=-4.345 tagged_above=-999 required=5 tests=[AWL=-0.697, BAYES_50=0.001, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5wpJ1dlS088a for ; Wed, 14 Apr 2010 03:59:27 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 6DFA03A68DF for ; Wed, 14 Apr 2010 03:59:25 -0700 (PDT) Received: from hoeneT60 (u-173-c009.cs.uni-tuebingen.de [134.2.173.9]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o3EAxGxX028249 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Apr 2010 12:59:16 +0200 From: "Christian Hoene" To: "'stephen botzko'" References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <20100413164818.546929eae97cjjr6@mail.skype.net> <4BC514CE.2080800@fas.harvard.edu> <20100413183602.86565rmv5hve5d6q@mail.skype.net> <4BC52068.1080906@fas.harvard.edu> In-Reply-To: Date: Wed, 14 Apr 2010 12:59:15 +0200 Message-ID: <000c01cadbc1$86a14f10$93e3ed30$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01CADBD2.4A2A1F10" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrbffKJ+ou/PejfTNWfUZGMsNLnmAAQucIg Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 10:59:28 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_000D_01CADBD2.4A2A1F10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi , =20 comments inline: =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of stephen botzko Sent: Wednesday, April 14, 2010 4:55 AM To: bens@alum.mit.edu Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? =20 When I said signaling I meant SDP, not anything in the bitstream itself. = I was not excluding audio bandwidth changes mid-call as part of network adaptation. Though as we all agree this needs to be = carefully designed. I agree it is best if the decoder does not require any knowledge of the = SDP negotiation (or any other information beyond the RTP packet stream itself) in order to correctly decode the audio -- which I = think is what you were concerned about. CH: Negotiating codec parameters with SDP has a long tradition. Take for = example =B5Law (RTP payload type 0): Here you negotiate the sampling rate. Also, the number of channels are negotiated for many = codecs. I think sampling rate and number of channels can be done with SDP. However, I would avoid other codec specific parameters. = Especially, in case of AMR the negotiation is quite complex should be avoided for the Internet CODEC. Christian It would be a nice property if reducing the acoustic bandwidth also = allowed the MIPS to be reduced, but I do not think it is a requirement; I'd personally rather manage complexity with a Low = Complexity profile (if that is really needed), since then I could keep the acoustic bandwidth (accepting a higher bit rate instead). Stephen Botzko On Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwartz = wrote: Koen Vos wrote: > Quoting "Benjamin M. Schwartz": >> 1. Why would high frequencies be unheard? Cheap speakers and = microphones >> have difficulties with low frequencies, but not high frequencies, and >> routinely go all the way up past the limit of hearing. > > Not all hardware supports arbitrary/high sampling rates. PSTN = gateways > don't go above 8 kHz. Same for some mobile devices. True. >> 2. Why would it need to be negotiated? For a suitably designed = format, >> the encoder could choose not to waste bits on high frequencies = without >> any >> negotiation or extra signalling. > > Without signaling, how would the encoder know that the farend decoder > will not take advantage of frequencies above a certain threshold? When I say signalling, I mean signalling within the codec bitstream. = The encoder can change its behavior based on knowledge of the receiver's configuration, but the bitstream does not need any extra signalling to indicate the change in behavior. >>> Signaling the bandwidth, and defining the >>> internal codec rate as fullband should let us lock down the RTP >>> timestamp >>> rate at 48 kHz (which I think is desirable). >> >> I do agree that having "only one mode" would be ideal, to maximize >> interoperability. I wonder whether we can achieve high enough >> computational efficiency for this to be viable. > > Changing the RTP timestamp sampling rate causes no computational > complexity, does it? Perhaps an extra multiplication for each packet = or > so? The point was that RTP timestamp sampling rate should = disconnected > from the actual audio signals. Right, but Stephen also suggested "defining the internal codec rate as fullband". From this, I imagined a scenario in which all (compliant) = IWAC implementations MUST decode all IWAC streams, which always have a = sampling rate of 48 KHz. I think this is a great idea, to achieve really good interoperability. If the receiver is a PSTN gateway, then an "internal codec rate" of 8 = KHz would presumably produce as good quality/bitrate with lower encoder and decoder complexity. However, if we can make IWAC sufficiently low-complexity, operating at 48 KHz may be acceptable. It will help if = we can structure the codec so that operating at lower bandwidth is very efficient. For example, it may be possible to structure a transform = codec such that unneeded high frequencies can cheaply be zero'd on encode and ignored on decode. --Ben =20 ------=_NextPart_000_000D_01CADBD2.4A2A1F10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi ,

 

comments inline:

 

From:<= font size=3D2 face=3DTahoma> = codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On = Behalf Of stephen botzko
Sent: Wednesday, April = 14, 2010 4:55 AM
To: bens@alum.mit.edu
Cc: codec@ietf.org
Subject: Re: [codec] #8: = Sample rates?

 

When I said signaling = I meant SDP, not anything in the bitstream itself.  I was not excluding = audio bandwidth changes mid-call as part of network adaptation.  Though as we all agree = this needs to be carefully designed.

I agree it is best if the decoder does not require any knowledge of the = SDP negotiation (or any other information beyond the RTP packet stream = itself) in order to correctly decode the audio -- which I think is what you were = concerned about.

CH: Negotiating codec parameters with SDP has a long tradition. Take for = example =B5Law (RTP payload type 0): Here you negotiate the sampling rate. Also, = the number of channels are negotiated for many codecs. I think sampling rate and number of channels can be done with SDP. = However, I would avoid other codec specific parameters. Especially, in case of AMR = the negotiation is quite complex should be avoided for the Internet =A0CODEC.

Christian

It would be a nice property if reducing the acoustic bandwidth also = allowed the MIPS to be reduced, but I do not think it is a requirement;  I'd personally rather manage complexity with a Low Complexity profile (if = that is really needed), since then I could keep the acoustic bandwidth = (accepting a higher bit rate instead).


Stephen Botzko

On Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwartz <bmschwar@fas.harvard.edu>= wrote:

Koen Vos = wrote:
> Quoting "Benjamin M. Schwartz":
>> 1. Why would high frequencies be unheard?  Cheap speakers = and microphones
>> have difficulties with low frequencies, but not high = frequencies, and
>> routinely go all the way up past the limit of hearing.
>
> Not all hardware supports arbitrary/high sampling rates.  PSTN gateways
> don't go above 8 kHz.  Same for some mobile = devices.

True.


>> 2. Why would it need to be negotiated?  For a suitably = designed format,
>> the encoder could choose not to waste bits on high frequencies = without
>> any
>> negotiation or extra signalling.
>
> Without signaling, how would the encoder know that the farend = decoder
> will not take advantage of frequencies above a certain = threshold?

When I say signalling, I mean signalling within the codec = bitstream.  The
encoder can change its behavior based on knowledge of the receiver's
configuration, but the bitstream does not need any extra signalling = to
indicate the change in behavior.


>>> Signaling the bandwidth, and defining the
>>> internal codec rate as fullband should let us lock down the = RTP
>>> timestamp
>>> rate at 48 kHz (which I think is desirable).
>>
>> I do agree that having "only one mode" would be = ideal, to maximize
>> interoperability.  I wonder whether we can achieve high = enough
>> computational efficiency for this to be viable.
>
> Changing the RTP timestamp sampling rate causes no = computational
> complexity, does it?  Perhaps an extra multiplication for each = packet or
> so?  The point was that RTP timestamp sampling rate should disconnected
> from the actual audio signals.

Right, but = Stephen also suggested "defining the internal codec rate as
fullband".  From this, I imagined a scenario in which all = (compliant) IWAC
implementations MUST decode all IWAC streams, which always have a = sampling
rate of 48 KHz.  I think this is a great idea, to achieve really = good
interoperability.

If the receiver is a PSTN gateway, then an "internal codec = rate" of 8 KHz
would presumably produce as good quality/bitrate with lower encoder = and
decoder complexity.  However, if we can make IWAC sufficiently
low-complexity, operating at 48 KHz may be acceptable.  It will = help if we
can structure the codec so that operating at lower bandwidth is very
efficient.  For example, it may be possible to structure a = transform codec
such that unneeded high frequencies can cheaply be zero'd on encode = and
ignored on decode.

--Ben

 

------=_NextPart_000_000D_01CADBD2.4A2A1F10-- From stephen.botzko@gmail.com Wed Apr 14 04:39:20 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6E68A28C318 for ; Wed, 14 Apr 2010 04:39:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.518 X-Spam-Level: X-Spam-Status: No, score=-2.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L7AuFEKy5DG5 for ; Wed, 14 Apr 2010 04:39:15 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id 875A428C278 for ; Wed, 14 Apr 2010 04:32:25 -0700 (PDT) Received: by iwn27 with SMTP id 27so6299245iwn.5 for ; Wed, 14 Apr 2010 04:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=0T0L8XcJVHgKtfst+mixCPyGOdWENdERtVoIbsnrO5Q=; b=rOX6ocj5w1a30bNqb2mhKZqm7ZfgNG1EQ+HjaJpPlFOj9XV+G+1Rd2+yPWgKql+hnr 71c3OK/ix74K2aAipEy0JSce9QxZ6vvvQVWhkfWH8ceixVbb0j55SAlLzTIjdYJKNyYu GTQmDRAcdlaOvknSj9+1uPnb3F7d/XZIHymeA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RfAhsye0Bz5F0uOWn0M6FcSij1pWeHTqw9qfDjVA6l+0xpIkqRKV1WCLwNlief1J7D 9oIIub9sC7ap2Qu3qW30qWC3DsgqpsVeoyV1SK0tu6ST0z0rOXDyNk8uhRGLqt+63PrL k60JefnB1uYJr0Ceon18j4AtLXcWQ3fNODILg= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Wed, 14 Apr 2010 04:32:15 -0700 (PDT) In-Reply-To: <000c01cadbc1$86a14f10$93e3ed30$@de> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <20100413164818.546929eae97cjjr6@mail.skype.net> <4BC514CE.2080800@fas.harvard.edu> <20100413183602.86565rmv5hve5d6q@mail.skype.net> <4BC52068.1080906@fas.harvard.edu> <000c01cadbc1$86a14f10$93e3ed30$@de> Date: Wed, 14 Apr 2010 07:32:15 -0400 Received: by 10.231.156.80 with SMTP id v16mr3259568ibw.99.1271244735275; Wed, 14 Apr 2010 04:32:15 -0700 (PDT) Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=001636ed793fde64d7048430ba63 Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 11:39:20 -0000 --001636ed793fde64d7048430ba63 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Christian I think I might not have been very clear. Certainly SDP negotiation of parameters is the normal practice, and with good reason. >>> I agree it is best if the decoder does not require any knowledge of the SDP negotiation (or any other information beyond the RTP packet stream itself) in order to correctly decode the audio >>> My point here was not that SDP negotiation should be avoided. I was tryiin= g to say that it is best if the RTP payload is complete (in the sense that it can be fully decoded even if you ignore the signaling, as long as you know the codec itself). For instance, if you negotiate the number of channels, it should be possible for the decoder to identify the number of channels from the RTP payload. There are codecs where this is not done. Though personally I think it is the best architectural approach, even if it costs some payload bits. One reason is that I think changing modes should be seamless, and there is a race condition between the signaling and the RTP payload. If you are adapting to network conditions, it is particularly useful to change on the fly. On Wed, Apr 14, 2010 at 6:59 AM, Christian Hoene wr= ote: > Hi , > > > > comments inline: > > > > *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf > Of *stephen botzko > *Sent:* Wednesday, April 14, 2010 4:55 AM > *To:* bens@alum.mit.edu > > *Cc:* codec@ietf.org > *Subject:* Re: [codec] #8: Sample rates? > > > > When I said signaling I meant SDP, not anything in the bitstream itself. > I was not excluding audio bandwidth changes mid-call as part of network > adaptation. Though as we all agree this needs to be carefully designed. > > > I agree it is best if the decoder does not require any knowledge of the S= DP > negotiation (or any other information beyond the RTP packet stream itself= ) > in order to correctly decode the audio -- which I think is what you were > concerned about. > > CH: Negotiating codec parameters with SDP has a long tradition. Take for > example =B5Law (RTP payload type 0): Here you negotiate the sampling rate= . > Also, the number of channels are negotiated for many codecs. I think > sampling rate and number of channels can be done with SDP. However, I wou= ld > avoid other codec specific parameters. Especially, in case of AMR the > negotiation is quite complex should be avoided for the Internet CODEC. > > Christian > > > It would be a nice property if reducing the acoustic bandwidth also allow= ed > the MIPS to be reduced, but I do not think it is a requirement; I'd > personally rather manage complexity with a Low Complexity profile (if tha= t > is really needed), since then I could keep the acoustic bandwidth (accept= ing > a higher bit rate instead). > > > Stephen Botzko > > On Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwartz < > bmschwar@fas.harvard.edu> wrote: > > Koen Vos wrote: > > Quoting "Benjamin M. Schwartz": > >> 1. Why would high frequencies be unheard? Cheap speakers and > microphones > >> have difficulties with low frequencies, but not high frequencies, and > >> routinely go all the way up past the limit of hearing. > > > > Not all hardware supports arbitrary/high sampling rates. PSTN gateways > > don't go above 8 kHz. Same for some mobile devices. > > True. > > > >> 2. Why would it need to be negotiated? For a suitably designed format= , > >> the encoder could choose not to waste bits on high frequencies without > >> any > >> negotiation or extra signalling. > > > > Without signaling, how would the encoder know that the farend decoder > > will not take advantage of frequencies above a certain threshold? > > When I say signalling, I mean signalling within the codec bitstream. The > encoder can change its behavior based on knowledge of the receiver's > configuration, but the bitstream does not need any extra signalling to > indicate the change in behavior. > > > >>> Signaling the bandwidth, and defining the > >>> internal codec rate as fullband should let us lock down the RTP > >>> timestamp > >>> rate at 48 kHz (which I think is desirable). > >> > >> I do agree that having "only one mode" would be ideal, to maximize > >> interoperability. I wonder whether we can achieve high enough > >> computational efficiency for this to be viable. > > > > Changing the RTP timestamp sampling rate causes no computational > > complexity, does it? Perhaps an extra multiplication for each packet o= r > > so? The point was that RTP timestamp sampling rate should disconnected > > from the actual audio signals. > > Right, but Stephen also suggested "defining the internal codec rate as > fullband". From this, I imagined a scenario in which all (compliant) IWA= C > implementations MUST decode all IWAC streams, which always have a samplin= g > rate of 48 KHz. I think this is a great idea, to achieve really good > interoperability. > > If the receiver is a PSTN gateway, then an "internal codec rate" of 8 KHz > would presumably produce as good quality/bitrate with lower encoder and > decoder complexity. However, if we can make IWAC sufficiently > low-complexity, operating at 48 KHz may be acceptable. It will help if w= e > can structure the codec so that operating at lower bandwidth is very > efficient. For example, it may be possible to structure a transform code= c > such that unneeded high frequencies can cheaply be zero'd on encode and > ignored on decode. > > --Ben > > > --001636ed793fde64d7048430ba63 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Christian

I think I might not have been very clear.

Certai= nly SDP negotiation of parameters is the normal practice, and with good rea= son.

>>>
I agree it is best if the = decoder does not require=20 any knowledge of the SDP negotiation (or any other information beyond the RTP packet stream=20 itself) in order to correctly decode the audio
>>>
My point here= was not that SDP negotiation should be avoided.=A0 I was tryiing to say th= at it is best if the RTP payload is complete (in the sense that it can be f= ully decoded even if you ignore the signaling, as long as you=A0 know the c= odec itself).=A0 For instance, if you negotiate the number of channels, it = should be possible for the decoder to identify the number of channels from = the RTP payload.

There are codecs where this is not done.=A0 Though personally I think i= t is the best architectural approach, even if it costs some payload bits.= =A0 One reason is that I think changing modes should be seamless, and there= is a race condition between the signaling and the RTP payload. If you are = adapting to network conditions, it is particularly useful to change on the = fly.

On Wed, Apr 14, 2010 at 6:59 AM, Christian H= oene <hoene@= uni-tuebingen.de> wrote:

= Hi ,

= =A0=

comments inline:

= = =A0

From:<= font size=3D"2" face=3D"Tahoma"> codec-bou= nces@ietf.org [mailto:codec-b= ounces@ietf.org] On Behalf Of stephen botzko
Sent: Wednesday, April 14,= 2010 4:55 AM
To: bens@alum.mit.edu

Cc: codec@ietf.org
Subject: Re: [codec] #8: S= ample rates?

=A0

When I said signaling I meant SDP, not anything in the bitstream itself.=A0 I was not excluding audio bandwidth changes mid-call as part of network adaptation.=A0 Though as we all agree this needs to be carefully designed.



I agree it is best if the decoder does not require any knowledge of the SDP negotiation (or any other information beyond the RTP packet stream itself) = in order to correctly decode the audio -- which I think is what you were conce= rned about.

CH: Negotiating codec parameters with SDP has a long tradition. Take for exampl= e =B5Law (RTP payload type 0): Here you negotiate the sampling rate. Also, th= e number of channels are negotiated for many codecs. I think sampling rate and number of channels can be done with SDP. However, I would avoid other codec specific parameters. Especially, in case of AMR the negotiation is quite complex should be avoided for the Internet =A0CODEC.

Christian

<= /div>


It would be a nice property if reducing the acoustic bandwidth also allowed= the MIPS to be reduced, but I do not think it is a requirement;=A0 I'd personally rather manage complexity with a Low Complexity profile (if that = is really needed), since then I could keep the acoustic bandwidth (accepting a higher bit rate instead).


Stephen Botzko

On Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwart= z <bmschwa= r@fas.harvard.edu> wrote:

Koen Vos wrote:
> Quoting "Benjamin M. Schwartz":
>> 1. Why would high frequencies be unheard? =A0Cheap speakers and microphones
>> have difficulties with low frequencies, but not high frequencies, = and
>> routinely go all the way up past the limit of hearing.
>
> Not all hardware supports arbitrary/high sampling rates. =A0PSTN gateways
> don't go above 8 kHz. =A0Same for some mobile devices.

True.


>> 2. Why would it need to be negotiated? =A0For a suitably designed format,
>> the encoder could choose not to waste bits on high frequencies wit= hout
>> any
>> negotiation or extra signalling.
>
> Without signaling, how would the encoder know that the farend decoder<= br> > will not take advantage of frequencies above a certain threshold?

When I say signalling, I mean signalling within the = codec bitstream. =A0The
encoder can change its behavior based on knowledge of the receiver's configuration, but the bitstream does not need any extra signalling to
indicate the change in behavior.


>>> Signaling the bandwidth, and defining the
>>> internal codec rate as fullband should let us lock down the RT= P
>>> timestamp
>>> rate at 48 kHz (which I think is desirable).
>>
>> I do agree that having "only one mode" would be ideal, t= o maximize
>> interoperability. =A0I wonder whether we can achieve high enough >> computational efficiency for this to be viable.
>
> Changing the RTP timestamp sampling rate causes no computational
> complexity, does it? =A0Perhaps an extra multiplication for each packe= t or
> so? =A0The point was that RTP timestamp sampling rate should disconnected
> from the actual audio signals.

Right, but Stephen al= so suggested "defining the internal codec rate as
fullband". =A0From this, I imagined a scenario in which all (compliant= ) IWAC
implementations MUST decode all IWAC streams, which always have a sampling<= br> rate of 48 KHz. =A0I think this is a great idea, to achieve really good
interoperability.

If the receiver is a PSTN gateway, then an "internal codec rate" = of 8 KHz
would presumably produce as good quality/bitrate with lower encoder and
decoder complexity. =A0However, if we can make IWAC sufficiently
low-complexity, operating at 48 KHz may be acceptable. =A0It will help if w= e
can structure the codec so that operating at lower bandwidth is very
efficient. =A0For example, it may be possible to structure a transform code= c
such that unneeded high frequencies can cheaply be zero'd on encode and=
ignored on decode.

--Ben

=A0


--001636ed793fde64d7048430ba63-- From ron.even.tlv@gmail.com Wed Apr 14 04:42:51 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 538CC28C160 for ; Wed, 14 Apr 2010 04:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.979 X-Spam-Level: X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uKLmxr89Ust5 for ; Wed, 14 Apr 2010 04:42:50 -0700 (PDT) Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223]) by core3.amsl.com (Postfix) with ESMTP id 0DB0128C2DF for ; Wed, 14 Apr 2010 04:36:49 -0700 (PDT) Received: by bwz23 with SMTP id 23so4924087bwz.26 for ; Wed, 14 Apr 2010 04:36:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:content-language:thread-index; bh=83C4DH4ck/DGPmxMU2EEWTIi+DQ6ESuklZh5Ag62GPs=; b=yBYRkul//AYQ5uf7SFTd9fxALDi0IyivawoBCngvZWaSjYzoFUsSzHO0wzPLrTNCAl 2VgHHOETAWKAknJqyYfnqvTnbynT15HGNyLY+JEaybglOCrQZNK92coBVVYTgt43szmq /DI9DUhtMZl/6luAHkgTi++Ern87PgniYQKqk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:x-mailer:content-language:thread-index; b=Ck4lM18FJQdnQs2sFoINPKL90KYT8A2nNqraaJU1oBzIbn6GnMhpQc05VXB309aw70 Aj83q5BQeNHjbSyCvK+GUzoYRpdQbgETTy8Vgrk7Y9UoRIQbcD50TJUkLuz+ltXJPn3z DAz7cON0grXDtXgy78vvN1pTY8IOhyXx0Q/Co= Received: by 10.103.86.39 with SMTP id o39mr4092304mul.58.1271244998504; Wed, 14 Apr 2010 04:36:38 -0700 (PDT) Received: from windows8d787f9 (bzq-79-178-26-146.red.bezeqint.net [79.178.26.146]) by mx.google.com with ESMTPS id n7sm1481401mue.15.2010.04.14.04.36.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 14 Apr 2010 04:36:36 -0700 (PDT) From: "Roni Even" To: "'Christian Hoene'" , "'stephen botzko'" References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <20100413164818.546929eae97cjjr6@mail.skype.net> <4BC514CE.2080800@fas.harvard.edu> <20100413183602.86565rmv5hve5d6q@mail.skype.net> <4BC52068.1080906@fas.harvard.edu> <000c01cadbc1$86a14f10$93e3ed30$@de> In-Reply-To: <000c01cadbc1$86a14f10$93e3ed30$@de> Date: Wed, 14 Apr 2010 14:35:54 +0300 Message-ID: <4bc5a8c4.07a5660a.30ee.5382@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0488_01CADBDF.CB1A0330" X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: AcrbffKJ+ou/PejfTNWfUZGMsNLnmAAQucIgAAE0HgA= Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 11:42:51 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0488_01CADBDF.CB1A0330 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, Negotiation of codec parameters is not a tradition it is needed if = there are optional modes that the decoder can support in order to allow the = sender to know if the receiver can receive the specific mode. If there are mandatory modes you may be able to provide the information in-band but = this is not negotiation. Also note that while the signaling may use reliable channel the media path is not reliable and may suffer packet loss that = may cause the loss of important parameters. We have such example in the = H.264 parameter sets where they can be carried in the SDP for reliability on in-band as part of the payload. =20 Roni Even =20 =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Christian Hoene Sent: Wednesday, April 14, 2010 1:59 PM To: 'stephen botzko' Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? =20 Hi , =20 comments inline: =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of stephen botzko Sent: Wednesday, April 14, 2010 4:55 AM To: bens@alum.mit.edu Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? =20 When I said signaling I meant SDP, not anything in the bitstream itself. = I was not excluding audio bandwidth changes mid-call as part of network adaptation. Though as we all agree this needs to be carefully designed. I agree it is best if the decoder does not require any knowledge of the = SDP negotiation (or any other information beyond the RTP packet stream = itself) in order to correctly decode the audio -- which I think is what you were concerned about. CH: Negotiating codec parameters with SDP has a long tradition. Take for example =B5Law (RTP payload type 0): Here you negotiate the sampling = rate. Also, the number of channels are negotiated for many codecs. I think sampling rate and number of channels can be done with SDP. However, I = would avoid other codec specific parameters. Especially, in case of AMR the negotiation is quite complex should be avoided for the Internet CODEC. Christian It would be a nice property if reducing the acoustic bandwidth also = allowed the MIPS to be reduced, but I do not think it is a requirement; I'd personally rather manage complexity with a Low Complexity profile (if = that is really needed), since then I could keep the acoustic bandwidth = (accepting a higher bit rate instead). Stephen Botzko On Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwartz wrote: Koen Vos wrote: > Quoting "Benjamin M. Schwartz": >> 1. Why would high frequencies be unheard? Cheap speakers and = microphones >> have difficulties with low frequencies, but not high frequencies, and >> routinely go all the way up past the limit of hearing. > > Not all hardware supports arbitrary/high sampling rates. PSTN = gateways > don't go above 8 kHz. Same for some mobile devices. True. >> 2. Why would it need to be negotiated? For a suitably designed = format, >> the encoder could choose not to waste bits on high frequencies = without >> any >> negotiation or extra signalling. > > Without signaling, how would the encoder know that the farend decoder > will not take advantage of frequencies above a certain threshold? When I say signalling, I mean signalling within the codec bitstream. = The encoder can change its behavior based on knowledge of the receiver's configuration, but the bitstream does not need any extra signalling to indicate the change in behavior. >>> Signaling the bandwidth, and defining the >>> internal codec rate as fullband should let us lock down the RTP >>> timestamp >>> rate at 48 kHz (which I think is desirable). >> >> I do agree that having "only one mode" would be ideal, to maximize >> interoperability. I wonder whether we can achieve high enough >> computational efficiency for this to be viable. > > Changing the RTP timestamp sampling rate causes no computational > complexity, does it? Perhaps an extra multiplication for each packet = or > so? The point was that RTP timestamp sampling rate should = disconnected > from the actual audio signals. Right, but Stephen also suggested "defining the internal codec rate as fullband". From this, I imagined a scenario in which all (compliant) = IWAC implementations MUST decode all IWAC streams, which always have a = sampling rate of 48 KHz. I think this is a great idea, to achieve really good interoperability. If the receiver is a PSTN gateway, then an "internal codec rate" of 8 = KHz would presumably produce as good quality/bitrate with lower encoder and decoder complexity. However, if we can make IWAC sufficiently low-complexity, operating at 48 KHz may be acceptable. It will help if = we can structure the codec so that operating at lower bandwidth is very efficient. For example, it may be possible to structure a transform = codec such that unneeded high frequencies can cheaply be zero'd on encode and ignored on decode. --Ben =20 ------=_NextPart_000_0488_01CADBDF.CB1A0330 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable

Hi,

Negotiation of codec parameters is not a tradition it = =A0is needed if there are optional modes that the decoder can support in order to = allow the sender to know if the receiver can receive the specific mode. If there = are mandatory modes you may be able to provide the information in-band but this is not = negotiation. Also note that while the signaling may use reliable channel the media = path is not reliable and may suffer packet loss that may cause the loss of = important parameters. We have such example in the H.264 parameter sets where they = can be carried in the SDP for reliability on in-band as part of the = payload.

 

Roni Even

 

 

From:= codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Christian Hoene
Sent: Wednesday, April 14, 2010 1:59 PM
To: 'stephen botzko'
Cc: codec@ietf.org
Subject: Re: [codec] #8: Sample rates?

 

Hi ,

 

comments inline:

 

From:= codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = stephen botzko
Sent: Wednesday, April 14, 2010 4:55 AM
To: bens@alum.mit.edu
Cc: codec@ietf.org
Subject: Re: [codec] #8: Sample rates?

 

When = I said signaling I meant SDP, not anything in the bitstream itself.  I was = not excluding audio bandwidth changes mid-call as part of network = adaptation.  Though as we all agree this needs to be carefully designed.

I agree it is best if the decoder does not require any knowledge of the = SDP negotiation (or any other information beyond the RTP packet stream = itself) in order to correctly decode the audio -- which I think is what you were = concerned about.

CH: Negotiating codec parameters with SDP has a long tradition. Take for example =B5Law (RTP = payload type 0): Here you negotiate the sampling rate. Also, the number of = channels are negotiated for many codecs. I think sampling rate and number of channels = can be done with SDP. However, I would avoid other codec specific parameters. Especially, in case of AMR the negotiation is quite complex should be = avoided for the Internet=A0 CODEC.

Christian

It would be a nice property if reducing the acoustic bandwidth also = allowed the MIPS to be reduced, but I do not think it is a requirement;  I'd personally rather manage complexity with a Low Complexity profile (if = that is really needed), since then I could keep the acoustic bandwidth = (accepting a higher bit rate instead).


Stephen Botzko

On Tue, Apr 13, 2010 at 9:54 PM, = Benjamin M. Schwartz <bmschwar@fas.harvard.edu>= wrote:

Koen = Vos wrote:
> Quoting "Benjamin M. Schwartz":
>> 1. Why would high frequencies be unheard?  Cheap speakers = and microphones
>> have difficulties with low frequencies, but not high = frequencies, and
>> routinely go all the way up past the limit of hearing.
>
> Not all hardware supports arbitrary/high sampling rates.  PSTN gateways
> don't go above 8 kHz.  Same for some mobile = devices.

True.


>> 2. Why would it need to be negotiated?  For a suitably = designed format,
>> the encoder could choose not to waste bits on high frequencies = without
>> any
>> negotiation or extra signalling.
>
> Without signaling, how would the encoder know that the farend = decoder
> will not take advantage of frequencies above a certain = threshold?

When I say signalling, I mean = signalling within the codec bitstream.  The
encoder can change its behavior based on knowledge of the receiver's
configuration, but the bitstream does not need any extra signalling = to
indicate the change in behavior.


>>> Signaling the bandwidth, and defining the
>>> internal codec rate as fullband should let us lock down the = RTP
>>> timestamp
>>> rate at 48 kHz (which I think is desirable).
>>
>> I do agree that having "only one mode" would be = ideal, to maximize
>> interoperability.  I wonder whether we can achieve high = enough
>> computational efficiency for this to be viable.
>
> Changing the RTP timestamp sampling rate causes no = computational
> complexity, does it?  Perhaps an extra multiplication for each = packet or
> so?  The point was that RTP timestamp sampling rate should disconnected
> from the actual audio signals.

Right, but Stephen also suggested "defining the internal codec rate as
fullband".  From this, I imagined a scenario in which all = (compliant) IWAC
implementations MUST decode all IWAC streams, which always have a = sampling
rate of 48 KHz.  I think this is a great idea, to achieve really = good
interoperability.

If the receiver is a PSTN gateway, then an "internal codec = rate" of 8 KHz
would presumably produce as good quality/bitrate with lower encoder = and
decoder complexity.  However, if we can make IWAC sufficiently
low-complexity, operating at 48 KHz may be acceptable.  It will = help if we
can structure the codec so that operating at lower bandwidth is very
efficient.  For example, it may be possible to structure a = transform codec
such that unneeded high frequencies can cheaply be zero'd on encode = and
ignored on decode.

--Ben

 

------=_NextPart_000_0488_01CADBDF.CB1A0330-- From stephen.botzko@gmail.com Wed Apr 14 04:56:20 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 216583A699F for ; Wed, 14 Apr 2010 04:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hO9dIBm1COYu for ; Wed, 14 Apr 2010 04:56:18 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 9A15A28C1C5 for ; Wed, 14 Apr 2010 04:51:46 -0700 (PDT) Received: by gwb1 with SMTP id 1so5166gwb.31 for ; Wed, 14 Apr 2010 04:51:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=+FL+s08PfCsjnVKofG9Kt+SVzz3wJaeW4VoUBqSOtso=; b=Q77bChHHfBbCXUnmnoSzdo/Qg1w1K843SJ14qURQBdSvp8XBi9sLcvPn04bidoGEMN 2izU3hnpmYHwC8wFGA0VBKZWz7TxBQm/cu1SJyojPT0ljO2KxLB/GtP4enWT4asnu/pD 3qPbnypBYhTPS0L/4iQHF8IVdh+eFhjHjBfAQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=xsJGxFQrwbIn+X2j0FR2FM0q8e/l1/F7Qnry2oSl4qVGPs0OA9e+mSYSomooA7EEOq dgoJQLMbaNlIc81yVGU32bSVVrfe75AKOujjKxqUysMckTK6LvX/+L3Lx5QntjEp7etx 4Q2cplyMK80TNpsMcY1q4UfeBT7p7U2gs2PJE= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Wed, 14 Apr 2010 04:51:35 -0700 (PDT) In-Reply-To: <4bc5a8c4.07a5660a.30ee.5382@mx.google.com> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <20100413164818.546929eae97cjjr6@mail.skype.net> <4BC514CE.2080800@fas.harvard.edu> <20100413183602.86565rmv5hve5d6q@mail.skype.net> <4BC52068.1080906@fas.harvard.edu> <000c01cadbc1$86a14f10$93e3ed30$@de> <4bc5a8c4.07a5660a.30ee.5382@mx.google.com> Date: Wed, 14 Apr 2010 07:51:35 -0400 Received: by 10.101.101.2 with SMTP id d2mr12291555anm.240.1271245896060; Wed, 14 Apr 2010 04:51:36 -0700 (PDT) Message-ID: From: stephen botzko To: Roni Even Content-Type: multipart/alternative; boundary=001636ed70fe0ef22104843100fc Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 11:56:20 -0000 --001636ed70fe0ef22104843100fc Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Good points, thanks for clarifying.. Personally I favor carrying those H.264 parameter sets on the media path, since there are situations (switched multipoint calls for one) where the timing matters. With that use case, if reliable-but-too-late delivery occurs, there are decoding errors even if there is no packet loss. Though of course SDP transmission alone may be suitable for other applications, and it is perfectly legal to send them both ways. Stephen Botzko 2010/4/14 Roni Even > Hi, > > Negotiation of codec parameters is not a tradition it is needed if there > are optional modes that the decoder can support in order to allow the sen= der > to know if the receiver can receive the specific mode. If there are > mandatory modes you may be able to provide the information in-band but th= is > is not negotiation. Also note that while the signaling may use reliable > channel the media path is not reliable and may suffer packet loss that ma= y > cause the loss of important parameters. We have such example in the H.264 > parameter sets where they can be carried in the SDP for reliability on > in-band as part of the payload. > > > > Roni Even > > > > > > *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf > Of *Christian Hoene > *Sent:* Wednesday, April 14, 2010 1:59 PM > *To:* 'stephen botzko' > > *Cc:* codec@ietf.org > *Subject:* Re: [codec] #8: Sample rates? > > > > Hi , > > > > comments inline: > > > > *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf > Of *stephen botzko > *Sent:* Wednesday, April 14, 2010 4:55 AM > *To:* bens@alum.mit.edu > *Cc:* codec@ietf.org > *Subject:* Re: [codec] #8: Sample rates? > > > > When I said signaling I meant SDP, not anything in the bitstream itself. = I > was not excluding audio bandwidth changes mid-call as part of network > adaptation. Though as we all agree this needs to be carefully designed. > > I agree it is best if the decoder does not require any knowledge of the S= DP > negotiation (or any other information beyond the RTP packet stream itself= ) > in order to correctly decode the audio -- which I think is what you were > concerned about. > > CH: Negotiating codec parameters with SDP has a long tradition. Take for > example =B5Law (RTP payload type 0): Here you negotiate the sampling rate= . > Also, the number of channels are negotiated for many codecs. I think > sampling rate and number of channels can be done with SDP. However, I wou= ld > avoid other codec specific parameters. Especially, in case of AMR the > negotiation is quite complex should be avoided for the Internet CODEC. > > Christian > > It would be a nice property if reducing the acoustic bandwidth also allow= ed > the MIPS to be reduced, but I do not think it is a requirement; I'd > personally rather manage complexity with a Low Complexity profile (if tha= t > is really needed), since then I could keep the acoustic bandwidth (accept= ing > a higher bit rate instead). > > > Stephen Botzko > > On Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwartz < > bmschwar@fas.harvard.edu> wrote: > > Koen Vos wrote: > > Quoting "Benjamin M. Schwartz": > >> 1. Why would high frequencies be unheard? Cheap speakers and > microphones > >> have difficulties with low frequencies, but not high frequencies, and > >> routinely go all the way up past the limit of hearing. > > > > Not all hardware supports arbitrary/high sampling rates. PSTN gateways > > don't go above 8 kHz. Same for some mobile devices. > > True. > > > >> 2. Why would it need to be negotiated? For a suitably designed format= , > >> the encoder could choose not to waste bits on high frequencies without > >> any > >> negotiation or extra signalling. > > > > Without signaling, how would the encoder know that the farend decoder > > will not take advantage of frequencies above a certain threshold? > > When I say signalling, I mean signalling within the codec bitstream. The > encoder can change its behavior based on knowledge of the receiver's > configuration, but the bitstream does not need any extra signalling to > indicate the change in behavior. > > > >>> Signaling the bandwidth, and defining the > >>> internal codec rate as fullband should let us lock down the RTP > >>> timestamp > >>> rate at 48 kHz (which I think is desirable). > >> > >> I do agree that having "only one mode" would be ideal, to maximize > >> interoperability. I wonder whether we can achieve high enough > >> computational efficiency for this to be viable. > > > > Changing the RTP timestamp sampling rate causes no computational > > complexity, does it? Perhaps an extra multiplication for each packet o= r > > so? The point was that RTP timestamp sampling rate should disconnected > > from the actual audio signals. > > Right, but Stephen also suggested "defining the internal codec rate as > fullband". From this, I imagined a scenario in which all (compliant) IWA= C > implementations MUST decode all IWAC streams, which always have a samplin= g > rate of 48 KHz. I think this is a great idea, to achieve really good > interoperability. > > If the receiver is a PSTN gateway, then an "internal codec rate" of 8 KHz > would presumably produce as good quality/bitrate with lower encoder and > decoder complexity. However, if we can make IWAC sufficiently > low-complexity, operating at 48 KHz may be acceptable. It will help if w= e > can structure the codec so that operating at lower bandwidth is very > efficient. For example, it may be possible to structure a transform code= c > such that unneeded high frequencies can cheaply be zero'd on encode and > ignored on decode. > > --Ben > > > --001636ed70fe0ef22104843100fc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Good points, thanks for clarifying..

Personally I favor carrying tho= se H.264 parameter sets on the media path, since there are situations (swit= ched multipoint calls for one) where the timing matters.=A0 With that use c= ase, if reliable-but-too-late delivery occurs, there are decoding errors ev= en if there is no packet loss.=A0

Though of course SDP transmission alone may be suitable for other appli= cations, and it is perfectly legal to send them both ways.

Stephen B= otzko

2010/4/14 Roni Even <ron.even.tlv@gmail.com= >

Hi,

Negotiation of codec parameters is not a tradition it =A0is needed if there are optional modes that the decoder can support in order to allow = the sender to know if the receiver can receive the specific mode. If there are = mandatory modes you may be able to provide the information in-band but this is not ne= gotiation. Also note that while the signaling may use reliable channel the media path = is not reliable and may suffer packet loss that may cause the loss of importan= t parameters. We have such example in the H.264 parameter sets where they can= be carried in the SDP for reliability on in-band as part of the payload.

=A0

Roni Even

=A0

=A0

From:= codec-bounces@i= etf.org [mailto:codec-bounces@ietf.org] On Behalf Of Christian Hoene
Sent: Wednesday, April 14, 2010 1:59 PM
To: 'stephen botzko'


Cc: codec@ietf.o= rg
Subject: Re: [codec] #8: Sample rates?

=A0

Hi ,

=A0

comments inline:

=A0

From:= codec-bounces@i= etf.org [mailto:codec-bounces@ietf.org] On Behalf Of stephen botzko
Sent: Wednesday, April 14, 2010 4:55 AM
To: bens@alum= .mit.edu
Cc: codec@ietf.o= rg
Subject: Re: [codec] #8: Sample rates?

=A0

Whe= n I said signaling I meant SDP, not anything in the bitstream itself.=A0 I was not excluding audio bandwidth changes mid-call as part of network adaptation.= =A0 Though as we all agree this needs to be carefully designed.

I agree it is best if the decoder does not require any knowledge of the SDP negotiation (or any other information beyond the RTP packet stream itself) = in order to correctly decode the audio -- which I think is what you were conce= rned about.

CH: Negotiating codec parameters with SDP has a long tradition. Take for example =B5Law (RTP payl= oad type 0): Here you negotiate the sampling rate. Also, the number of channels= are negotiated for many codecs. I think sampling rate and number of channels ca= n be done with SDP. However, I would avoid other codec specific parameters. Especially, in case of AMR the negotiation is quite complex should be avoid= ed for the Internet=A0 CODEC.

Christian

It would be a nice property if reducing the acoustic bandwidth also allowed= the MIPS to be reduced, but I do not think it is a requirement;=A0 I'd personally rather manage complexity with a Low Complexity profile (if that = is really needed), since then I could keep the acoustic bandwidth (accepting a higher bit rate instead).


Stephen Botzko

On Tue, Apr 13, 2010 at 9:54 PM, B= enjamin M. Schwartz <= bmschwar@fas.harvard.edu> wrote:

Koe= n Vos wrote:
> Quoting "Benjamin M. Schwartz":
>> 1. Why would high frequencies be unheard? =A0Cheap speakers and microphones
>> have difficulties with low frequencies, but not high frequencies, = and
>> routinely go all the way up past the limit of hearing.
>
> Not all hardware supports arbitrary/high sampling rates. =A0PSTN gateways
> don't go above 8 kHz. =A0Same for some mobile devices.

True.

>> 2. Why would it need to be negotiated? =A0For a suitably designed format,
>> the encoder could choose not to waste bits on high frequencies wit= hout
>> any
>> negotiation or extra signalling.
>
> Without signaling, how would the encoder know that the farend decoder<= br> > will not take advantage of frequencies above a certain threshold?

When I say signalling, I mean sign= alling within the codec bitstream. =A0The
encoder can change its behavior based on knowledge of the receiver's configuration, but the bitstream does not need any extra signalling to
indicate the change in behavior.

>>> Signaling the bandwidth, and defining the
>>> internal codec rate as fullband should let us lock down the RT= P
>>> timestamp
>>> rate at 48 kHz (which I think is desirable).
>>
>> I do agree that having "only one mode" would be ideal, t= o maximize
>> interoperability. =A0I wonder whether we can achieve high enough >> computational efficiency for this to be viable.
>
> Changing the RTP timestamp sampling rate causes no computational
> complexity, does it? =A0Perhaps an extra multiplication for each packe= t or
> so? =A0The point was that RTP timestamp sampling rate should disconnected
> from the actual audio signals.

Rig= ht, but Stephen also suggested "defining the internal codec rate as
fullband". =A0From this, I imagined a scenario in which all (compliant= ) IWAC
implementations MUST decode all IWAC streams, which always have a sampling<= br> rate of 48 KHz. =A0I think this is a great idea, to achieve really good
interoperability.

If the receiver is a PSTN gateway, then an "internal codec rate" = of 8 KHz
would presumably produce as good quality/bitrate with lower encoder and
decoder complexity. =A0However, if we can make IWAC sufficiently
low-complexity, operating at 48 KHz may be acceptable. =A0It will help if w= e
can structure the codec so that operating at lower bandwidth is very
efficient. =A0For example, it may be possible to structure a transform code= c
such that unneeded high frequencies can cheaply be zero'd on encode and=
ignored on decode.

--Ben

=A0


--001636ed70fe0ef22104843100fc-- From hoene@uni-tuebingen.de Wed Apr 14 05:11:43 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3F1F28C154 for ; Wed, 14 Apr 2010 05:11:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.412 X-Spam-Level: X-Spam-Status: No, score=-5.412 tagged_above=-999 required=5 tests=[AWL=0.836, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jv0WQ+qjqFvQ for ; Wed, 14 Apr 2010 05:11:39 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id B30EB28C1C2 for ; Wed, 14 Apr 2010 05:08:42 -0700 (PDT) Received: from hoeneT60 (u-173-c009.cs.uni-tuebingen.de [134.2.173.9]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o3EC8UaM012005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Apr 2010 14:08:30 +0200 From: "Christian Hoene" To: "'stephen botzko'" , "'Roni Even'" References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <20100413164818.546929eae97cjjr6@mail.skype.net> <4BC514CE.2080800@fas.harvard.edu> <20100413183602.86565rmv5hve5d6q@mail.skype.net> <4BC52068.1080906@fas.harvard.edu> <000c01cadbc1$86a14f10$93e3ed30$@de> <4bc5a8c4.07a5660a.30ee.5382@mx.google.com> In-Reply-To: Date: Wed, 14 Apr 2010 14:08:29 +0200 Message-ID: <003d01cadbcb$32653ce0$972fb6a0$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003E_01CADBDB.F5EE0CE0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrbyNxVdSPqsxByRdGy9ACHAqxUjAAAUpRg Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 12:11:46 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_003E_01CADBDB.F5EE0CE0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 I am fine with dropping any SDP negotiation on codec parameters = including sampling rate and channels. I like the idea of splitting signaling and transportation issues. =20 But one question remain. We had the question on limiting the complexity = for some kind of devices by choosing a lower sampling rate or a low number of channels. Shall this negotiation be done with SDP or = inband? =20 Christian =20 =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 From: stephen botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Wednesday, April 14, 2010 1:52 PM To: Roni Even Cc: Christian Hoene; codec@ietf.org Subject: Re: [codec] #8: Sample rates? =20 Good points, thanks for clarifying.. Personally I favor carrying those H.264 parameter sets on the media = path, since there are situations (switched multipoint calls for one) where the timing matters. With that use case, if = reliable-but-too-late delivery occurs, there are decoding errors even if there is no packet loss. =20 Though of course SDP transmission alone may be suitable for other = applications, and it is perfectly legal to send them both ways. Stephen Botzko 2010/4/14 Roni Even Hi, Negotiation of codec parameters is not a tradition it is needed if = there are optional modes that the decoder can support in order to allow the sender to know if the receiver can receive the specific = mode. If there are mandatory modes you may be able to provide the information in-band but this is not negotiation. Also note that = while the signaling may use reliable channel the media path is not reliable and may suffer packet loss that may cause the loss of = important parameters. We have such example in the H.264 parameter sets where they can be carried in the SDP for reliability on in-band as = part of the payload. =20 Roni Even =20 =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Christian Hoene Sent: Wednesday, April 14, 2010 1:59 PM To: 'stephen botzko' Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? =20 Hi , =20 comments inline: =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of stephen botzko Sent: Wednesday, April 14, 2010 4:55 AM To: bens@alum.mit.edu Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? =20 When I said signaling I meant SDP, not anything in the bitstream itself. = I was not excluding audio bandwidth changes mid-call as part of network adaptation. Though as we all agree this needs to be = carefully designed. I agree it is best if the decoder does not require any knowledge of the = SDP negotiation (or any other information beyond the RTP packet stream itself) in order to correctly decode the audio -- which I = think is what you were concerned about. CH: Negotiating codec parameters with SDP has a long tradition. Take for = example =B5Law (RTP payload type 0): Here you negotiate the sampling rate. Also, the number of channels are negotiated for many = codecs. I think sampling rate and number of channels can be done with SDP. However, I would avoid other codec specific parameters. = Especially, in case of AMR the negotiation is quite complex should be avoided for the Internet CODEC. Christian It would be a nice property if reducing the acoustic bandwidth also = allowed the MIPS to be reduced, but I do not think it is a requirement; I'd personally rather manage complexity with a Low = Complexity profile (if that is really needed), since then I could keep the acoustic bandwidth (accepting a higher bit rate instead). Stephen Botzko On Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwartz = wrote: Koen Vos wrote: > Quoting "Benjamin M. Schwartz": >> 1. Why would high frequencies be unheard? Cheap speakers and = microphones >> have difficulties with low frequencies, but not high frequencies, and >> routinely go all the way up past the limit of hearing. > > Not all hardware supports arbitrary/high sampling rates. PSTN = gateways > don't go above 8 kHz. Same for some mobile devices. True. >> 2. Why would it need to be negotiated? For a suitably designed = format, >> the encoder could choose not to waste bits on high frequencies = without >> any >> negotiation or extra signalling. > > Without signaling, how would the encoder know that the farend decoder > will not take advantage of frequencies above a certain threshold? When I say signalling, I mean signalling within the codec bitstream. = The encoder can change its behavior based on knowledge of the receiver's configuration, but the bitstream does not need any extra signalling to indicate the change in behavior. >>> Signaling the bandwidth, and defining the >>> internal codec rate as fullband should let us lock down the RTP >>> timestamp >>> rate at 48 kHz (which I think is desirable). >> >> I do agree that having "only one mode" would be ideal, to maximize >> interoperability. I wonder whether we can achieve high enough >> computational efficiency for this to be viable. > > Changing the RTP timestamp sampling rate causes no computational > complexity, does it? Perhaps an extra multiplication for each packet = or > so? The point was that RTP timestamp sampling rate should = disconnected > from the actual audio signals. Right, but Stephen also suggested "defining the internal codec rate as fullband". From this, I imagined a scenario in which all (compliant) = IWAC implementations MUST decode all IWAC streams, which always have a = sampling rate of 48 KHz. I think this is a great idea, to achieve really good interoperability. If the receiver is a PSTN gateway, then an "internal codec rate" of 8 = KHz would presumably produce as good quality/bitrate with lower encoder and decoder complexity. However, if we can make IWAC sufficiently low-complexity, operating at 48 KHz may be acceptable. It will help if = we can structure the codec so that operating at lower bandwidth is very efficient. For example, it may be possible to structure a transform = codec such that unneeded high frequencies can cheaply be zero'd on encode and ignored on decode. --Ben =20 =20 ------=_NextPart_000_003E_01CADBDB.F5EE0CE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I am fine with dropping any SDP negotiation on codec parameters including sampling rate = and channels. I like the idea of splitting signaling and transportation = issues.

 

But one = question remain. We had the question on limiting the complexity for some kind of = devices by choosing a lower sampling rate or a low number of channels. Shall = this negotiation be done with SDP or inband?

 

Christian=

 

 

---------------------------------------------------------------=

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen =

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen= .de/

 

From: stephen botzko [mailto:stephen.botzko@gmail.com] =
Sent: Wednesday, April = 14, 2010 1:52 PM
To: Roni Even
Cc: Christian Hoene; codec@ietf.org
Subject: Re: [codec] #8: = Sample rates?

 

Good points, = thanks for clarifying..

Personally I favor carrying those H.264 parameter sets on the media = path, since there are situations (switched multipoint calls for one) where the = timing matters.  With that use case, if reliable-but-too-late delivery = occurs, there are decoding errors even if there is no packet loss. 

Though of course SDP transmission alone may be suitable for other = applications, and it is perfectly legal to send them both ways.

Stephen Botzko

2010/4/14 Roni Even <ron.even.tlv@gmail.com>

Hi,

Negotiat= ion of codec parameters is not a tradition it  is needed if there are = optional modes that the decoder can support in order to allow the sender to know = if the receiver can receive the specific mode. If there are mandatory modes you = may be able to provide the information in-band but this is not negotiation. = Also note that while the signaling may use reliable channel the media path is not = reliable and may suffer packet loss that may cause the loss of important = parameters. We have such example in the H.264 parameter sets where they can be carried = in the SDP for reliability on in-band as part of the = payload.

 

Roni = Even

 

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Christian = Hoene
Sent: Wednesday, April = 14, 2010 1:59 PM
To: 'stephen = botzko'


Cc: codec@ietf.org
Subject: Re: [codec] #8: = Sample rates?

 

Hi ,

 

comments inline:

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of stephen = botzko
Sent: Wednesday, April = 14, 2010 4:55 AM
To: bens@alum.mit.edu
Cc: codec@ietf.org
Subject: Re: [codec] #8: = Sample rates?

 

When = I said signaling I meant SDP, not anything in the bitstream itself.  I was = not excluding audio bandwidth changes mid-call as part of network = adaptation.  Though as we all agree this needs to be carefully designed.

I agree it is best if the decoder does not require any knowledge of the = SDP negotiation (or any other information beyond the RTP packet stream = itself) in order to correctly decode the audio -- which I think is what you were = concerned about.

CH: = Negotiating codec parameters with SDP has a long tradition. Take for example =B5Law = (RTP payload type 0): Here you negotiate the sampling rate. Also, the number = of channels are negotiated for many codecs. I think sampling rate and = number of channels can be done with SDP. However, I would avoid other codec = specific parameters. Especially, in case of AMR the negotiation is quite complex = should be avoided for the Internet  CODEC.

Christia= n

It would be a nice property if reducing the acoustic bandwidth also = allowed the MIPS to be reduced, but I do not think it is a requirement;  I'd personally rather manage complexity with a Low Complexity profile (if = that is really needed), since then I could keep the acoustic bandwidth = (accepting a higher bit rate instead).


Stephen Botzko

On = Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwartz <bmschwar@fas.harvard.edu> wrote:

Koen = Vos wrote:
> Quoting "Benjamin M. Schwartz":
>> 1. Why would high frequencies be unheard?  Cheap speakers = and microphones
>> have difficulties with low frequencies, but not high = frequencies, and
>> routinely go all the way up past the limit of hearing.
>
> Not all hardware supports arbitrary/high sampling rates.  PSTN gateways
> don't go above 8 kHz.  Same for some mobile = devices.

True.


>> 2. Why would it need to be negotiated?  For a suitably = designed format,
>> the encoder could choose not to waste bits on high frequencies = without
>> any
>> negotiation or extra signalling.
>
> Without signaling, how would the encoder know that the farend = decoder
> will not take advantage of frequencies above a certain = threshold?

When = I say signalling, I mean signalling within the codec bitstream.  The
encoder can change its behavior based on knowledge of the receiver's
configuration, but the bitstream does not need any extra signalling = to
indicate the change in behavior.


>>> Signaling the bandwidth, and defining the
>>> internal codec rate as fullband should let us lock down the = RTP
>>> timestamp
>>> rate at 48 kHz (which I think is desirable).
>>
>> I do agree that having "only one mode" would be = ideal, to maximize
>> interoperability.  I wonder whether we can achieve high = enough
>> computational efficiency for this to be viable.
>
> Changing the RTP timestamp sampling rate causes no = computational
> complexity, does it?  Perhaps an extra multiplication for each = packet or
> so?  The point was that RTP timestamp sampling rate should disconnected
> from the actual audio signals.

Right, but Stephen also suggested "defining the internal codec rate as
fullband".  From this, I imagined a scenario in which all = (compliant) IWAC
implementations MUST decode all IWAC streams, which always have a = sampling
rate of 48 KHz.  I think this is a great idea, to achieve really = good
interoperability.

If the receiver is a PSTN gateway, then an "internal codec = rate" of 8 KHz
would presumably produce as good quality/bitrate with lower encoder = and
decoder complexity.  However, if we can make IWAC sufficiently
low-complexity, operating at 48 KHz may be acceptable.  It will = help if we
can structure the codec so that operating at lower bandwidth is very
efficient.  For example, it may be possible to structure a = transform codec
such that unneeded high frequencies can cheaply be zero'd on encode = and
ignored on decode.

--Ben

 

 

------=_NextPart_000_003E_01CADBDB.F5EE0CE0-- From stephen.botzko@gmail.com Wed Apr 14 05:32:21 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 361C43A6BD2 for ; Wed, 14 Apr 2010 05:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DcbU5R0Wrprb for ; Wed, 14 Apr 2010 05:32:19 -0700 (PDT) Received: from mail-yx0-f184.google.com (mail-yx0-f184.google.com [209.85.210.184]) by core3.amsl.com (Postfix) with ESMTP id 53E3D28C2B3 for ; Wed, 14 Apr 2010 05:25:32 -0700 (PDT) Received: by yxe14 with SMTP id 14so27415yxe.5 for ; Wed, 14 Apr 2010 05:25:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=eKzJTXSoXG6jg4J0lQmh7IS2S0c5K120SyTmGaaIeBM=; b=DU310LVi4rirD/87Oz5t7CTeExFbCL+A5iJA43w4Ay7Qsu4zp/dw3PNPRhADxplgil lle0Rf+zJ/kwWffOcXUttrC16lDPT/qvDAO3jtIIpT4/ME3dLoBnDjAWF03jqc5ZXRE1 gbDj8B2Ua75d9+tInC6TGlfS7A6s8rBTxqVqM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NFxrK9xJOFfV8/IBp5PbAoqVU4RCh5quoi5AVXD0fe2RauyGowN8CU810H2dwf+fwk FW8vTbzyltZTaOL983kLpbpNm39h8e+78bFEe2hNfN8thZvKyX21V2paBck6y7Kqz+yR +vkymfzMFvmOlRBj4GNbLCoVkabD/jhuZVbDY= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Wed, 14 Apr 2010 05:25:22 -0700 (PDT) In-Reply-To: <003d01cadbcb$32653ce0$972fb6a0$@de> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <4BC514CE.2080800@fas.harvard.edu> <20100413183602.86565rmv5hve5d6q@mail.skype.net> <4BC52068.1080906@fas.harvard.edu> <000c01cadbc1$86a14f10$93e3ed30$@de> <4bc5a8c4.07a5660a.30ee.5382@mx.google.com> <003d01cadbcb$32653ce0$972fb6a0$@de> Date: Wed, 14 Apr 2010 08:25:22 -0400 Received: by 10.100.50.1 with SMTP id x1mr13769320anx.149.1271247923148; Wed, 14 Apr 2010 05:25:23 -0700 (PDT) Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=001485f7d7ace193ed04843178d5 Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 12:32:21 -0000 --001485f7d7ace193ed04843178d5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All negotiation should be done with SDP (and should *never* be done in-band= ) And the RTP transport should be robust enough to permit seamless changes to any mode that is consistent with the negotiation (with no signaling). The first point I think is essential. The second reflects my own view on how RTP packetization should be done. Stephen Botzko On Wed, Apr 14, 2010 at 8:08 AM, Christian Hoene wr= ote: > Hi, > > > > I am fine with dropping any SDP negotiation on codec parameters including > sampling rate and channels. I like the idea of splitting signaling and > transportation issues. > > > > But one question remain. We had the question on limiting the complexity f= or > some kind of devices by choosing a lower sampling rate or a low number of > channels. Shall this negotiation be done with SDP or inband? > > > > Christian > > > > > > --------------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of T=FCbingen > > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > > > *From:* stephen botzko [mailto:stephen.botzko@gmail.com] > *Sent:* Wednesday, April 14, 2010 1:52 PM > *To:* Roni Even > *Cc:* Christian Hoene; codec@ietf.org > > *Subject:* Re: [codec] #8: Sample rates? > > > > Good points, thanks for clarifying.. > > Personally I favor carrying those H.264 parameter sets on the media path, > since there are situations (switched multipoint calls for one) where the > timing matters. With that use case, if reliable-but-too-late delivery > occurs, there are decoding errors even if there is no packet loss. > > Though of course SDP transmission alone may be suitable for other > applications, and it is perfectly legal to send them both ways. > > Stephen Botzko > > 2010/4/14 Roni Even > > Hi, > > Negotiation of codec parameters is not a tradition it is needed if there > are optional modes that the decoder can support in order to allow the sen= der > to know if the receiver can receive the specific mode. If there are > mandatory modes you may be able to provide the information in-band but th= is > is not negotiation. Also note that while the signaling may use reliable > channel the media path is not reliable and may suffer packet loss that ma= y > cause the loss of important parameters. We have such example in the H.264 > parameter sets where they can be carried in the SDP for reliability on > in-band as part of the payload. > > > > Roni Even > > > > > > *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf > Of *Christian Hoene > *Sent:* Wednesday, April 14, 2010 1:59 PM > *To:* 'stephen botzko' > > > *Cc:* codec@ietf.org > *Subject:* Re: [codec] #8: Sample rates? > > > > Hi , > > > > comments inline: > > > > *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf > Of *stephen botzko > *Sent:* Wednesday, April 14, 2010 4:55 AM > *To:* bens@alum.mit.edu > *Cc:* codec@ietf.org > *Subject:* Re: [codec] #8: Sample rates? > > > > When I said signaling I meant SDP, not anything in the bitstream itself. = I > was not excluding audio bandwidth changes mid-call as part of network > adaptation. Though as we all agree this needs to be carefully designed. > > I agree it is best if the decoder does not require any knowledge of the S= DP > negotiation (or any other information beyond the RTP packet stream itself= ) > in order to correctly decode the audio -- which I think is what you were > concerned about. > > CH: Negotiating codec parameters with SDP has a long tradition. Take for > example =B5Law (RTP payload type 0): Here you negotiate the sampling rate= . > Also, the number of channels are negotiated for many codecs. I think > sampling rate and number of channels can be done with SDP. However, I wou= ld > avoid other codec specific parameters. Especially, in case of AMR the > negotiation is quite complex should be avoided for the Internet CODEC. > > Christian > > It would be a nice property if reducing the acoustic bandwidth also allow= ed > the MIPS to be reduced, but I do not think it is a requirement; I'd > personally rather manage complexity with a Low Complexity profile (if tha= t > is really needed), since then I could keep the acoustic bandwidth (accept= ing > a higher bit rate instead). > > > Stephen Botzko > > On Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwartz < > bmschwar@fas.harvard.edu> wrote: > > Koen Vos wrote: > > Quoting "Benjamin M. Schwartz": > >> 1. Why would high frequencies be unheard? Cheap speakers and > microphones > >> have difficulties with low frequencies, but not high frequencies, and > >> routinely go all the way up past the limit of hearing. > > > > Not all hardware supports arbitrary/high sampling rates. PSTN gateways > > don't go above 8 kHz. Same for some mobile devices. > > True. > > > >> 2. Why would it need to be negotiated? For a suitably designed format= , > >> the encoder could choose not to waste bits on high frequencies without > >> any > >> negotiation or extra signalling. > > > > Without signaling, how would the encoder know that the farend decoder > > will not take advantage of frequencies above a certain threshold? > > When I say signalling, I mean signalling within the codec bitstream. The > encoder can change its behavior based on knowledge of the receiver's > configuration, but the bitstream does not need any extra signalling to > indicate the change in behavior. > > > >>> Signaling the bandwidth, and defining the > >>> internal codec rate as fullband should let us lock down the RTP > >>> timestamp > >>> rate at 48 kHz (which I think is desirable). > >> > >> I do agree that having "only one mode" would be ideal, to maximize > >> interoperability. I wonder whether we can achieve high enough > >> computational efficiency for this to be viable. > > > > Changing the RTP timestamp sampling rate causes no computational > > complexity, does it? Perhaps an extra multiplication for each packet o= r > > so? The point was that RTP timestamp sampling rate should disconnected > > from the actual audio signals. > > Right, but Stephen also suggested "defining the internal codec rate as > fullband". From this, I imagined a scenario in which all (compliant) IWA= C > implementations MUST decode all IWAC streams, which always have a samplin= g > rate of 48 KHz. I think this is a great idea, to achieve really good > interoperability. > > If the receiver is a PSTN gateway, then an "internal codec rate" of 8 KHz > would presumably produce as good quality/bitrate with lower encoder and > decoder complexity. However, if we can make IWAC sufficiently > low-complexity, operating at 48 KHz may be acceptable. It will help if w= e > can structure the codec so that operating at lower bandwidth is very > efficient. For example, it may be possible to structure a transform code= c > such that unneeded high frequencies can cheaply be zero'd on encode and > ignored on decode. > > --Ben > > > > > --001485f7d7ace193ed04843178d5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All negotiation should be done with SDP (and should never be done in= -band)

And the RTP transport should be robust enough to permit seaml= ess changes to any mode that is consistent with the negotiation (with no si= gnaling).=A0

The first point I think is essential.=A0 The second reflects my own vie= w on how RTP packetization should be done.

Stephen Botzko

On Wed, Apr 14, 2010 at 8:08 AM, Christian Hoene <hoene@uni-tue= bingen.de> wrote:

= Hi,=

= =A0=

= I = am fine with dropping any SDP negotiation on codec parameters including sampling rate an= d channels. I like the idea of splitting signaling and transportation issues.=

= = =A0

= Bu= t one question remain. We had the question on limiting the complexity for some kind of dev= ices by choosing a lower sampling rate or a low number of channels. Shall this n= egotiation be done with SDP or inband?

= = =A0

= Ch= ristian

= = =A0

= = =A0

---------------------------------------------------= ------------

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University= of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 = 2970532
= http://www.net.uni-tu= ebingen.de/

= = =A0

From: stephen botzko [mailto:<= a href=3D"mailto:stephen.botzko@gmail.com" target=3D"_blank">stephen.botzko= @gmail.com]
Sent: Wednesday, April 14,= 2010 1:52 PM
To: Roni Even
Cc: Christian Hoene; codec@ietf.org

=

Subject: Re: [codec] #8: S= ample rates?

=A0

Good points, thanks f= or clarifying..

Personally I favor carrying those H.264 parameter sets on the media path, s= ince there are situations (switched multipoint calls for one) where the timing matters.=A0 With that use case, if reliable-but-too-late delivery occurs, there are decoding errors even if there is no packet loss.=A0

Though of course SDP transmission alone may be suitable for other applicati= ons, and it is perfectly legal to send them both ways.

Stephen Botzko

2010/4/14 Roni Even <ron.even.tlv@gmail.com>

Hi,

Negotiation of codec parameters is not a tradition it =A0is needed if there are optional modes that the decoder can support in order to allow the sender to know if = the receiver can receive the specific mode. If there are mandatory modes you ma= y be able to provide the information in-band but this is not negotiation. Also n= ote that while the signaling may use reliable channel the media path is not rel= iable and may suffer packet loss that may cause the loss of important parameters.= We have such example in the H.264 parameter sets where they can be carried in = the SDP for reliability on in-band as part of the payload.

=A0

Roni Even

=A0

=A0

From: <= a href=3D"mailto:codec-bounces@ietf.org" target=3D"_blank">codec-bounces@ie= tf.org [mailto:codec-b= ounces@ietf.org] On Behalf Of Christian Hoe= ne
Sent: Wednesday, April 14,= 2010 1:59 PM
To: 'stephen botzko= 9;


Cc: codec@ietf.org
Subject: Re: [codec] #8: S= ample rates?

=A0

Hi ,

=A0

comments = inline:

=A0

From: <= a href=3D"mailto:codec-bounces@ietf.org" target=3D"_blank">codec-bounces@ie= tf.org [mailto:codec-b= ounces@ietf.org] On Behalf Of stephen botzk= o
Sent: Wednesday, April 14,= 2010 4:55 AM
To: bens@alum.mit.edu
Cc: codec@ietf.org
Subject: Re: [codec] #8: S= ample rates?

=A0

When I said signaling I meant SDP, not anything in the bitstream itself.=A0 I was not excluding audio bandwidth changes mid-call as part of network adaptation.= =A0 Though as we all agree this needs to be carefully designed.

I agree it is best if the decoder does not require any knowledge of the SDP negotiation (or any other information beyond the RTP packet stream itself) = in order to correctly decode the audio -- which I think is what you were conce= rned about.

CH: Negotiating codec parameters with SDP has a long tradition. Take for example =B5Law (RT= P payload type 0): Here you negotiate the sampling rate. Also, the number of channels are negotiated for many codecs. I think sampling rate and number o= f channels can be done with SDP. However, I would avoid other codec specific parameters. Especially, in case of AMR the negotiation is quite complex sho= uld be avoided for the Internet=A0 CODEC.

Christian

It would be a nice property if reducing the acoustic bandwidth also allowed= the MIPS to be reduced, but I do not think it is a requirement;=A0 I'd personally rather manage complexity with a Low Complexity profile (if that = is really needed), since then I could keep the acoustic bandwidth (accepting a higher bit rate instead).


Stephen Botzko

On Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwartz <bmschwar@fas.harvard.edu> wrote:

Koen Vos wrote:
> Quoting "Benjamin M. Schwartz":
>> 1. Why would high frequencies be unheard? =A0Cheap speakers and microphones
>> have difficulties with low frequencies, but not high frequencies, = and
>> routinely go all the way up past the limit of hearing.
>
> Not all hardware supports arbitrary/high sampling rates. =A0PSTN gateways
> don't go above 8 kHz. =A0Same for some mobile devices.

True.


>> 2. Why would it need to be negotiated? =A0For a suitably designed format,
>> the encoder could choose not to waste bits on high frequencies wit= hout
>> any
>> negotiation or extra signalling.
>
> Without signaling, how would the encoder know that the farend decoder<= br> > will not take advantage of frequencies above a certain threshold?

When I say signalling, I mean signalling within the codec bitstream. =A0The
encoder can change its behavior based on knowledge of the receiver's configuration, but the bitstream does not need any extra signalling to
indicate the change in behavior.<= /p>


>>> Signaling the bandwidth, and defining the
>>> internal codec rate as fullband should let us lock down the RT= P
>>> timestamp
>>> rate at 48 kHz (which I think is desirable).
>>
>> I do agree that having "only one mode" would be ideal, t= o maximize
>> interoperability. =A0I wonder whether we can achieve high enough >> computational efficiency for this to be viable.
>
> Changing the RTP timestamp sampling rate causes no computational
> complexity, does it? =A0Perhaps an extra multiplication for each packe= t or
> so? =A0The point was that RTP timestamp sampling rate should disconnected
> from the actual audio signals.

Right, but Stephen also suggested "defining the internal codec rate as
fullband". =A0From this, I imagined a scenario in which all (compliant= ) IWAC
implementations MUST decode all IWAC streams, which always have a sampling<= br> rate of 48 KHz. =A0I think this is a great idea, to achieve really good
interoperability.

If the receiver is a PSTN gateway, then an "internal codec rate" = of 8 KHz
would presumably produce as good quality/bitrate with lower encoder and
decoder complexity. =A0However, if we can make IWAC sufficiently
low-complexity, operating at 48 KHz may be acceptable. =A0It will help if w= e
can structure the codec so that operating at lower bandwidth is very
efficient. =A0For example, it may be possible to structure a transform code= c
such that unneeded high frequencies can cheaply be zero'd on encode and=
ignored on decode.

--Ben

=A0

=A0


--001485f7d7ace193ed04843178d5-- From hoene@uni-tuebingen.de Wed Apr 14 05:43:16 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B610C28C152 for ; Wed, 14 Apr 2010 05:43:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.621 X-Spam-Level: X-Spam-Status: No, score=-5.621 tagged_above=-999 required=5 tests=[AWL=0.627, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B1QIbixamilS for ; Wed, 14 Apr 2010 05:43:05 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id C5B623A6BB8 for ; Wed, 14 Apr 2010 05:37:32 -0700 (PDT) Received: from hoeneT60 (u-173-c009.cs.uni-tuebingen.de [134.2.173.9]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o3ECbMgx019280 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 14 Apr 2010 14:37:23 +0200 From: "Christian Hoene" To: "'stephen botzko'" References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <4BC514CE.2080800@fas.harvard.edu> <20100413183602.86565rmv5hve5d6q@mail.skype.net> <4BC52068.1080906@fas.harvard.edu> <000c01cadbc1$86a14f10$93e3ed30$@de> <4bc5a8c4.07a5660a.30ee.5382@mx.google.com> <003d01cadbcb$32653ce0$972fb6a0$@de> In-Reply-To: Date: Wed, 14 Apr 2010 14:37:22 +0200 Message-ID: <004d01cadbcf$3b43c210$b1cb4630$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01CADBDF.FECC9210" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrbzZW2GrcfMTl/QbCd4SfdMD3YuQAAGFiw Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 12:43:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_004E_01CADBDF.FECC9210 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stephen, =20 I am getting confused=85 Do you mean that the parameter about sampling = rate MUST be negotiated with SDP and not transmitted in-band? Or MUST NOT be negotiated inband but only transmitted inband? Inband means within RTP/RTCP/RTPextentions and/or the Internet CODEC = payload. =20 What do you think about my second question on sampling rate limits? =20 With best regards, Christian =20 =20 =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 From: stephen botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Wednesday, April 14, 2010 2:25 PM To: Christian Hoene Cc: Roni Even; codec@ietf.org Subject: Re: [codec] #8: Sample rates? =20 All negotiation should be done with SDP (and should never be done = in-band) And the RTP transport should be robust enough to permit seamless changes = to any mode that is consistent with the negotiation (with no signaling). =20 The first point I think is essential. The second reflects my own view = on how RTP packetization should be done. Stephen Botzko On Wed, Apr 14, 2010 at 8:08 AM, Christian Hoene = wrote: Hi, =20 I am fine with dropping any SDP negotiation on codec parameters = including sampling rate and channels. I like the idea of splitting signaling and transportation issues. =20 But one question remain. We had the question on limiting the complexity = for some kind of devices by choosing a lower sampling rate or a low number of channels. Shall this negotiation be done with SDP or = inband? =20 Christian =20 =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 From: stephen botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Wednesday, April 14, 2010 1:52 PM To: Roni Even Cc: Christian Hoene; codec@ietf.org Subject: Re: [codec] #8: Sample rates? =20 Good points, thanks for clarifying.. Personally I favor carrying those H.264 parameter sets on the media = path, since there are situations (switched multipoint calls for one) where the timing matters. With that use case, if = reliable-but-too-late delivery occurs, there are decoding errors even if there is no packet loss. =20 Though of course SDP transmission alone may be suitable for other = applications, and it is perfectly legal to send them both ways. Stephen Botzko 2010/4/14 Roni Even Hi, Negotiation of codec parameters is not a tradition it is needed if = there are optional modes that the decoder can support in order to allow the sender to know if the receiver can receive the specific = mode. If there are mandatory modes you may be able to provide the information in-band but this is not negotiation. Also note that = while the signaling may use reliable channel the media path is not reliable and may suffer packet loss that may cause the loss of = important parameters. We have such example in the H.264 parameter sets where they can be carried in the SDP for reliability on in-band as = part of the payload. =20 Roni Even =20 =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Christian Hoene Sent: Wednesday, April 14, 2010 1:59 PM To: 'stephen botzko' Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? =20 Hi , =20 comments inline: =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of stephen botzko Sent: Wednesday, April 14, 2010 4:55 AM To: bens@alum.mit.edu Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? =20 When I said signaling I meant SDP, not anything in the bitstream itself. = I was not excluding audio bandwidth changes mid-call as part of network adaptation. Though as we all agree this needs to be = carefully designed. I agree it is best if the decoder does not require any knowledge of the = SDP negotiation (or any other information beyond the RTP packet stream itself) in order to correctly decode the audio -- which I = think is what you were concerned about. CH: Negotiating codec parameters with SDP has a long tradition. Take for = example =B5Law (RTP payload type 0): Here you negotiate the sampling rate. Also, the number of channels are negotiated for many = codecs. I think sampling rate and number of channels can be done with SDP. However, I would avoid other codec specific parameters. = Especially, in case of AMR the negotiation is quite complex should be avoided for the Internet CODEC. Christian It would be a nice property if reducing the acoustic bandwidth also = allowed the MIPS to be reduced, but I do not think it is a requirement; I'd personally rather manage complexity with a Low = Complexity profile (if that is really needed), since then I could keep the acoustic bandwidth (accepting a higher bit rate instead). Stephen Botzko On Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwartz = wrote: Koen Vos wrote: > Quoting "Benjamin M. Schwartz": >> 1. Why would high frequencies be unheard? Cheap speakers and = microphones >> have difficulties with low frequencies, but not high frequencies, and >> routinely go all the way up past the limit of hearing. > > Not all hardware supports arbitrary/high sampling rates. PSTN = gateways > don't go above 8 kHz. Same for some mobile devices. True. >> 2. Why would it need to be negotiated? For a suitably designed = format, >> the encoder could choose not to waste bits on high frequencies = without >> any >> negotiation or extra signalling. > > Without signaling, how would the encoder know that the farend decoder > will not take advantage of frequencies above a certain threshold? When I say signalling, I mean signalling within the codec bitstream. = The encoder can change its behavior based on knowledge of the receiver's configuration, but the bitstream does not need any extra signalling to indicate the change in behavior. >>> Signaling the bandwidth, and defining the >>> internal codec rate as fullband should let us lock down the RTP >>> timestamp >>> rate at 48 kHz (which I think is desirable). >> >> I do agree that having "only one mode" would be ideal, to maximize >> interoperability. I wonder whether we can achieve high enough >> computational efficiency for this to be viable. > > Changing the RTP timestamp sampling rate causes no computational > complexity, does it? Perhaps an extra multiplication for each packet = or > so? The point was that RTP timestamp sampling rate should = disconnected > from the actual audio signals. Right, but Stephen also suggested "defining the internal codec rate as fullband". From this, I imagined a scenario in which all (compliant) = IWAC implementations MUST decode all IWAC streams, which always have a = sampling rate of 48 KHz. I think this is a great idea, to achieve really good interoperability. If the receiver is a PSTN gateway, then an "internal codec rate" of 8 = KHz would presumably produce as good quality/bitrate with lower encoder and decoder complexity. However, if we can make IWAC sufficiently low-complexity, operating at 48 KHz may be acceptable. It will help if = we can structure the codec so that operating at lower bandwidth is very efficient. For example, it may be possible to structure a transform = codec such that unneeded high frequencies can cheaply be zero'd on encode and ignored on decode. --Ben =20 =20 =20 ------=_NextPart_000_004E_01CADBDF.FECC9210 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Stephen,

 

I am getting = confused… Do you mean that the parameter about sampling rate MUST be negotiated = with SDP and not transmitted in-band?

Or MUST NOT be negotiated inband but only transmitted inband?

Inband= means within RTP/RTCP/RTPextentions and/or the Internet CODEC = payload.

 

What do you = think about my second question on sampling rate limits?

 

With best = regards,

=A0Christian

 

 

 

---------------------------------------------------------------=

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen =

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen= .de/

 

From: stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Wednesday, April = 14, 2010 2:25 PM
To: Christian Hoene
Cc: Roni Even; = codec@ietf.org
Subject: Re: [codec] #8: = Sample rates?

 

All = negotiation should be done with SDP (and should never be done in-band)

And the RTP transport should be robust enough to permit seamless changes = to any mode that is consistent with the negotiation (with no signaling).  =

The first point I think is essential.  The second reflects my own = view on how RTP packetization should be done.

Stephen Botzko

On Wed, Apr 14, 2010 at 8:08 AM, Christian Hoene <hoene@uni-tuebingen.de> = wrote:

Hi,

 

=

I am fine with dropping any SDP negotiation on codec parameters including = sampling rate and channels. I like the idea of splitting signaling and = transportation issues.

 

But one question remain. We had the question on limiting the complexity for = some kind of devices by choosing a lower sampling rate or a low number of = channels. Shall this negotiation be done with SDP or = inband?

 

Christian

 

 

-------------= --------------------------------------------------

Dr.-Ing. = Christian Hoene

Interactive = Communication Systems (ICS), University of T=FCbingen

Sand 13, = 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen.de/=

 

From: stephen = botzko [mailto:stephen.botzko@gmail.com]
Sent: Wednesday, April = 14, 2010 1:52 PM
To: Roni Even
Cc: Christian Hoene; codec@ietf.org


Subject: Re: [codec] #8: = Sample rates?

 

Good = points, thanks for clarifying..

Personally I favor carrying those H.264 parameter sets on the media = path, since there are situations (switched multipoint calls for one) where the = timing matters.  With that use case, if reliable-but-too-late delivery = occurs, there are decoding errors even if there is no packet loss. 

Though of course SDP transmission alone may be suitable for other = applications, and it is perfectly legal to send them both ways.

Stephen Botzko

2010/4/14 Roni Even <ron.even.tlv@gmail.com>=

Hi,

Negotiat= ion of codec parameters is not a tradition it  is needed if there are = optional modes that the decoder can support in order to allow the sender to know = if the receiver can receive the specific mode. If there are mandatory modes you = may be able to provide the information in-band but this is not negotiation. = Also note that while the signaling may use reliable channel the media path is not reliable and may suffer packet loss that may cause the loss of important parameters. We have such example in the H.264 parameter sets where they = can be carried in the SDP for reliability on in-band as part of the = payload.

 

Roni = Even

 

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Christian = Hoene
Sent: Wednesday, April = 14, 2010 1:59 PM
To: 'stephen = botzko'


Cc: codec@ietf.org
Subject: Re: [codec] #8: = Sample rates?

 

Hi ,

 

comments inline:

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of stephen = botzko
Sent: Wednesday, April = 14, 2010 4:55 AM
To: bens@alum.mit.edu
Cc: codec@ietf.org
Subject: Re: [codec] #8: = Sample rates?

 

When = I said signaling I meant SDP, not anything in the bitstream itself.  I was = not excluding audio bandwidth changes mid-call as part of network = adaptation.  Though as we all agree this needs to be carefully designed.

I agree it is best if the decoder does not require any knowledge of the = SDP negotiation (or any other information beyond the RTP packet stream = itself) in order to correctly decode the audio -- which I think is what you were = concerned about.

CH: = Negotiating codec parameters with SDP has a long tradition. Take for example =B5Law = (RTP payload type 0): Here you negotiate the sampling rate. Also, the number = of channels are negotiated for many codecs. I think sampling rate and = number of channels can be done with SDP. However, I would avoid other codec = specific parameters. Especially, in case of AMR the negotiation is quite complex = should be avoided for the Internet  CODEC.

Christia= n

It would be a nice property if reducing the acoustic bandwidth also = allowed the MIPS to be reduced, but I do not think it is a requirement;  I'd personally rather manage complexity with a Low Complexity profile (if = that is really needed), since then I could keep the acoustic bandwidth = (accepting a higher bit rate instead).


Stephen Botzko

On = Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwartz <bmschwar@fas.harvard.edu> wrote:

Koen = Vos wrote:
> Quoting "Benjamin M. Schwartz":
>> 1. Why would high frequencies be unheard?  Cheap speakers = and microphones
>> have difficulties with low frequencies, but not high = frequencies, and
>> routinely go all the way up past the limit of hearing.
>
> Not all hardware supports arbitrary/high sampling rates.  PSTN gateways
> don't go above 8 kHz.  Same for some mobile = devices.

True.


>> 2. Why would it need to be negotiated?  For a suitably = designed format,
>> the encoder could choose not to waste bits on high frequencies = without
>> any
>> negotiation or extra signalling.
>
> Without signaling, how would the encoder know that the farend = decoder
> will not take advantage of frequencies above a certain = threshold?

When = I say signalling, I mean signalling within the codec bitstream.  The
encoder can change its behavior based on knowledge of the receiver's
configuration, but the bitstream does not need any extra signalling = to
indicate the change in behavior.


>>> Signaling the bandwidth, and defining the
>>> internal codec rate as fullband should let us lock down the = RTP
>>> timestamp
>>> rate at 48 kHz (which I think is desirable).
>>
>> I do agree that having "only one mode" would be = ideal, to maximize
>> interoperability.  I wonder whether we can achieve high = enough
>> computational efficiency for this to be viable.
>
> Changing the RTP timestamp sampling rate causes no = computational
> complexity, does it?  Perhaps an extra multiplication for each = packet or
> so?  The point was that RTP timestamp sampling rate should disconnected
> from the actual audio signals.

Right, but Stephen also suggested "defining the internal codec rate as
fullband".  From this, I imagined a scenario in which all = (compliant) IWAC
implementations MUST decode all IWAC streams, which always have a = sampling
rate of 48 KHz.  I think this is a great idea, to achieve really = good
interoperability.

If the receiver is a PSTN gateway, then an "internal codec = rate" of 8 KHz
would presumably produce as good quality/bitrate with lower encoder = and
decoder complexity.  However, if we can make IWAC sufficiently
low-complexity, operating at 48 KHz may be acceptable.  It will = help if we
can structure the codec so that operating at lower bandwidth is very
efficient.  For example, it may be possible to structure a = transform codec
such that unneeded high frequencies can cheaply be zero'd on encode = and
ignored on decode.

--Ben

 

 

 

------=_NextPart_000_004E_01CADBDF.FECC9210-- From stephen.botzko@gmail.com Wed Apr 14 06:55:49 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 18ACD3A689A for ; Wed, 14 Apr 2010 06:55:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z2YcLijJUc5c for ; Wed, 14 Apr 2010 06:55:46 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id A24CD3A6A58 for ; Wed, 14 Apr 2010 06:55:43 -0700 (PDT) Received: by iwn27 with SMTP id 27so69968iwn.5 for ; Wed, 14 Apr 2010 06:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=43Cc7l+dUZ/2SzrhSBbFIizffnpVKJ360CCnV9fErmI=; b=ZyfIxnE5XksRQG5Zd1R8I8AIzVCwxr4GvPYSHNO0s869JnPe2vmJA4Y23W8swfPfib +DY6bqE02SElOYRqG1UKJd/Q9AqbLf2+8r5PqLIPodifHdW59hSD5O81vOQYOD7wamr+ Gl7jrMzuAKCLXxdnrpERxff2z5jDNrYxV8I9A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=OWdbMP4Gg4qMUiQVnEUaOPex23Ghk5TFJGwaQWpD9aPrAMi4VnX0HziulvcEAuvzA2 XlmRisq0e7qvQStf9W65MbXWNeERrfOUdU3JxBlEYxmH0+eVZp61F5b2DZ8aECSpOz1o InOSF3NzFqTH8TadgQg/NcQwxgNeBpdWOqt8k= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Wed, 14 Apr 2010 06:55:32 -0700 (PDT) In-Reply-To: <004d01cadbcf$3b43c210$b1cb4630$@de> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <20100413183602.86565rmv5hve5d6q@mail.skype.net> <4BC52068.1080906@fas.harvard.edu> <000c01cadbc1$86a14f10$93e3ed30$@de> <4bc5a8c4.07a5660a.30ee.5382@mx.google.com> <003d01cadbcb$32653ce0$972fb6a0$@de> <004d01cadbcf$3b43c210$b1cb4630$@de> Date: Wed, 14 Apr 2010 09:55:32 -0400 Received: by 10.231.170.14 with SMTP id b14mr3335488ibz.54.1271253333028; Wed, 14 Apr 2010 06:55:33 -0700 (PDT) Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=001636d34a9b55b1a6048432bb81 Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 13:55:49 -0000 --001636d34a9b55b1a6048432bb81 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In-band for me in this case means RTP only. Or in some other contexts RTP payload only. I think there is (a) negotiation - particularly defining what optional modes the receiver * can* handle. In the case of sample rates, number of channels, and any optional facilities, this is generally not changing mid-call. SDP is the right place for this. (SDP SHALL be used for this) (b) Feedback - messages related to QOS, packet loss, etc are what I mean by this. This should be done in RTCP, though given the lack of VOIP support perhaps there should be a SIP INFO backup path. Feedback should not be don= e with RTP. (c) Control - Per RFC 3551, RTCP can be used for "loosely controlled" sessions, but "may be fully or partially subsumed by a separate session control protocol". Given the statements on RTCP support in the VOIP infrastructure, we should be careful about putting unique controls in RTCP. However, it should not be done in RTP. Since most other audio codecs don't require this stuff, I suspect we won't either. Though we will see... (d) In-band (RTP). Not sure how else to say this. Ideally RTP streams carrying CODEC (with no out-of-band, no RTCP, no SDP parameter knowledge) can be decoded. That is, I think it should be possible to fully decode unencrypted CODEC bitstreams with only the RTP packets abstracted from Wireshark. Even if the operating mode changes mid-flight. RFC 5404 (G.719= ) is one example of a packetization that accomplishes this, but there are other packetization RFCs which do not. Is this more clear? Regards Stephen Botzko On Wed, Apr 14, 2010 at 8:37 AM, Christian Hoene wr= ote: > Hi Stephen, > > > > I am getting confused=85 Do you mean that the parameter about sampling ra= te > MUST be negotiated with SDP and not transmitted in-band? > > Or MUST NOT be negotiated inband but only transmitted inband? > > Inband means within RTP/RTCP/RTPextentions and/or the Internet CODEC > payload. > > > > What do you think about my second question on sampling rate limits? > > > > With best regards, > > Christian > > > > > > > > --------------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of T=FCbingen > > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > > > *From**:* stephen botzko [mailto:stephen.botzko@gmail.com] > *Sent:* Wednesday, April 14, 2010 2:25 PM > *To:* Christian Hoene > *Cc:* Roni Even; codec@ietf.org > > *Subject:* Re: [codec] #8: Sample rates? > > > > All negotiation should be done with SDP (and should *never* be done > in-band) > > And the RTP transport should be robust enough to permit seamless changes = to > any mode that is consistent with the negotiation (with no signaling). > > The first point I think is essential. The second reflects my own view on > how RTP packetization should be done. > > Stephen Botzko > > On Wed, Apr 14, 2010 at 8:08 AM, Christian Hoene > wrote: > > Hi, > > > > I am fine with dropping any SDP negotiation on codec parameters including > sampling rate and channels. I like the idea of splitting signaling and > transportation issues. > > > > But one question remain. We had the question on limiting the complexity f= or > some kind of devices by choosing a lower sampling rate or a low number of > channels. Shall this negotiation be done with SDP or inband? > > > > Christian > > > > > > --------------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of T=FCbingen > > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > > > *From:* stephen botzko [mailto:stephen.botzko@gmail.com] > *Sent:* Wednesday, April 14, 2010 1:52 PM > *To:* Roni Even > *Cc:* Christian Hoene; codec@ietf.org > > > *Subject:* Re: [codec] #8: Sample rates? > > > > Good points, thanks for clarifying.. > > Personally I favor carrying those H.264 parameter sets on the media path, > since there are situations (switched multipoint calls for one) where the > timing matters. With that use case, if reliable-but-too-late delivery > occurs, there are decoding errors even if there is no packet loss. > > Though of course SDP transmission alone may be suitable for other > applications, and it is perfectly legal to send them both ways. > > Stephen Botzko > > 2010/4/14 Roni Even > > Hi, > > Negotiation of codec parameters is not a tradition it is needed if there > are optional modes that the decoder can support in order to allow the sen= der > to know if the receiver can receive the specific mode. If there are > mandatory modes you may be able to provide the information in-band but th= is > is not negotiation. Also note that while the signaling may use reliable > channel the media path is not reliable and may suffer packet loss that ma= y > cause the loss of important parameters. We have such example in the H.264 > parameter sets where they can be carried in the SDP for reliability on > in-band as part of the payload. > > > > Roni Even > > > > > > *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf > Of *Christian Hoene > *Sent:* Wednesday, April 14, 2010 1:59 PM > *To:* 'stephen botzko' > > > *Cc:* codec@ietf.org > *Subject:* Re: [codec] #8: Sample rates? > > > > Hi , > > > > comments inline: > > > > *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf > Of *stephen botzko > *Sent:* Wednesday, April 14, 2010 4:55 AM > *To:* bens@alum.mit.edu > *Cc:* codec@ietf.org > *Subject:* Re: [codec] #8: Sample rates? > > > > When I said signaling I meant SDP, not anything in the bitstream itself. = I > was not excluding audio bandwidth changes mid-call as part of network > adaptation. Though as we all agree this needs to be carefully designed. > > I agree it is best if the decoder does not require any knowledge of the S= DP > negotiation (or any other information beyond the RTP packet stream itself= ) > in order to correctly decode the audio -- which I think is what you were > concerned about. > > CH: Negotiating codec parameters with SDP has a long tradition. Take for > example =B5Law (RTP payload type 0): Here you negotiate the sampling rate= . > Also, the number of channels are negotiated for many codecs. I think > sampling rate and number of channels can be done with SDP. However, I wou= ld > avoid other codec specific parameters. Especially, in case of AMR the > negotiation is quite complex should be avoided for the Internet CODEC. > > Christian > > It would be a nice property if reducing the acoustic bandwidth also allow= ed > the MIPS to be reduced, but I do not think it is a requirement; I'd > personally rather manage complexity with a Low Complexity profile (if tha= t > is really needed), since then I could keep the acoustic bandwidth (accept= ing > a higher bit rate instead). > > > Stephen Botzko > > On Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwartz < > bmschwar@fas.harvard.edu> wrote: > > Koen Vos wrote: > > Quoting "Benjamin M. Schwartz": > >> 1. Why would high frequencies be unheard? Cheap speakers and > microphones > >> have difficulties with low frequencies, but not high frequencies, and > >> routinely go all the way up past the limit of hearing. > > > > Not all hardware supports arbitrary/high sampling rates. PSTN gateways > > don't go above 8 kHz. Same for some mobile devices. > > True. > > > >> 2. Why would it need to be negotiated? For a suitably designed format= , > >> the encoder could choose not to waste bits on high frequencies without > >> any > >> negotiation or extra signalling. > > > > Without signaling, how would the encoder know that the farend decoder > > will not take advantage of frequencies above a certain threshold? > > When I say signalling, I mean signalling within the codec bitstream. The > encoder can change its behavior based on knowledge of the receiver's > configuration, but the bitstream does not need any extra signalling to > indicate the change in behavior. > > > >>> Signaling the bandwidth, and defining the > >>> internal codec rate as fullband should let us lock down the RTP > >>> timestamp > >>> rate at 48 kHz (which I think is desirable). > >> > >> I do agree that having "only one mode" would be ideal, to maximize > >> interoperability. I wonder whether we can achieve high enough > >> computational efficiency for this to be viable. > > > > Changing the RTP timestamp sampling rate causes no computational > > complexity, does it? Perhaps an extra multiplication for each packet o= r > > so? The point was that RTP timestamp sampling rate should disconnected > > from the actual audio signals. > > Right, but Stephen also suggested "defining the internal codec rate as > fullband". From this, I imagined a scenario in which all (compliant) IWA= C > implementations MUST decode all IWAC streams, which always have a samplin= g > rate of 48 KHz. I think this is a great idea, to achieve really good > interoperability. > > If the receiver is a PSTN gateway, then an "internal codec rate" of 8 KHz > would presumably produce as good quality/bitrate with lower encoder and > decoder complexity. However, if we can make IWAC sufficiently > low-complexity, operating at 48 KHz may be acceptable. It will help if w= e > can structure the codec so that operating at lower bandwidth is very > efficient. For example, it may be possible to structure a transform code= c > such that unneeded high frequencies can cheaply be zero'd on encode and > ignored on decode. > > --Ben > > > > > > > --001636d34a9b55b1a6048432bb81 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable In-band for me in this case means RTP only.=A0 Or in some other contexts RT= P payload only.

I think there is
(a) negotiation - particularly = defining what optional modes the receiver can handle.=A0 In the case= of sample rates, number of channels, and any optional facilities, this is = generally not changing mid-call.=A0 SDP is the right place for this. (SDP S= HALL be used for this)

(b) Feedback - messages related to QOS, packet loss, etc are what I mea= n by this.=A0 This should be done in RTCP, though given the lack of VOIP su= pport perhaps there should be a SIP INFO backup path.=A0 Feedback should no= t be done with RTP.

(c) Control - Per RFC 3551, RTCP can be used for "loosely controll= ed" sessions, but "may be fully or partially subsumed by a separa= te session control protocol".=A0 Given the statements on RTCP support = in the VOIP infrastructure, we should be careful about putting unique contr= ols in RTCP.=A0 However, it should not be done in RTP.=A0 Since most other = audio codecs don't require this stuff, I suspect we won't either.= =A0 Though we will see...

(d) In-band (RTP).=A0 Not sure how else to say this.=A0 Ideally RTP str= eams carrying CODEC (with no out-of-band, no RTCP, no SDP parameter knowled= ge) can be decoded.=A0 That is, I think it should be possible to fully deco= de unencrypted CODEC bitstreams with only the RTP packets abstracted from W= ireshark.=A0 Even if the operating mode changes mid-flight.=A0 RFC 5404 (G.= 719) is one example of a packetization that accomplishes this, but there ar= e other packetization RFCs which do not.

Is this more clear?

Regards
Stephen Botzko



On Wed, Apr 14, 2010 at 8:37 AM, Christian Hoene <hoene@uni-tue= bingen.de> wrote:

= Hi= Stephen,

= = =A0

= I = am getting confused=85 Do you mean that the parameter about sampling rate MUST be negotiated with = SDP and not transmitted in-band?

= Or= MUST NOT be negotiated inband but only transmitted inband?

Inband means within RTP/RTCP/RTPextentions and/or the Internet= CODEC payload.

= = =A0

= Wh= at do you think about my second question on sampling rate limits?

= = =A0

= Wi= th best regards,

= =A0Christian

= = =A0

= = =A0

= = =A0

---------------------------------------------------= ------------

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University= of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 = 2970532
= http://www.net.uni-tu= ebingen.de/

= = =A0

From<= font size=3D"2" face=3D"Tahoma">: stephen botzko [mailto:steph= en.botzko@gmail.com]
Sent: Wednesday, April 14,= 2010 2:25 PM
To: Christian Hoene
Cc: Roni Even; codec@ietf.org

=

Subject: Re: [codec] #8: S= ample rates?

=A0

All negotiation shoul= d be done with SDP (and should never be done in-band)

And the RTP transport should be robust enough to permit seamless changes to= any mode that is consistent with the negotiation (with no signaling).=A0

The first point I think is essential.=A0 The second reflects my own view on how RTP packetization should be done.

Stephen Botzko

On Wed, Apr 14, 2010 at 8:08 AM, Christian Hoene <= ;hoene@uni-tueb= ingen.de> wrote:

= Hi,=

= =A0=

= I = am fine with dropping any SDP negotiation on codec parameters including sampli= ng rate and channels. I like the idea of splitting signaling and transportatio= n issues.

= = =A0

= Bu= t one question remain. We had the question on limiting the complexity for som= e kind of devices by choosing a lower sampling rate or a low number of channe= ls. Shall this negotiation be done with SDP or inband?

= = =A0

= Ch= ristian

= = =A0

= = =A0

---------------------------------------------------= ------------

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
= http://www.net.uni-tuebingen.de/

= = =A0

From: stephen botzko [mailto:steph= en.botzko@gmail.com]
Sent: Wednesday, April 14,= 2010 1:52 PM
To: Roni Even
Cc: Christian Hoene; codec@ietf.org


Subject: Re: [codec] #8: S= ample rates?

=A0

Good points, thanks for clarifying..

Personally I favor carrying those H.264 parameter sets on the media path, s= ince there are situations (switched multipoint calls for one) where the timing matters.=A0 With that use case, if reliable-but-too-late delivery occurs, there are decoding errors even if there is no packet loss.=A0

Though of course SDP transmission alone may be suitable for other applicati= ons, and it is perfectly legal to send them both ways.

Stephen Botzko

2010/4/14 Roni Even <ron.ev= en.tlv@gmail.com>

Hi,

Negotiation of codec parameters is not a tradition it =A0is needed if there are optional modes that the decoder can support in order to allow the sender to know if = the receiver can receive the specific mode. If there are mandatory modes you ma= y be able to provide the information in-band but this is not negotiation. Also n= ote that while the signaling may use reliable channel the media path is not reliable and may suffer packet loss that may cause the loss of important parameters. We have such example in the H.264 parameter sets where they can= be carried in the SDP for reliability on in-band as part of the payload.

=A0

Roni Even

=A0

=A0

From: <= a href=3D"mailto:codec-bounces@ietf.org" target=3D"_blank">codec-bounces@ie= tf.org [mailto:codec-b= ounces@ietf.org] On Behalf Of Christian Hoe= ne
Sent: Wednesday, April 14,= 2010 1:59 PM
To: 'stephen botzko= 9;


Cc: codec@ietf.org
Subject: Re: [codec] #8: S= ample rates?

=A0

Hi ,

=A0

comments = inline:

=A0

From: <= a href=3D"mailto:codec-bounces@ietf.org" target=3D"_blank">codec-bounces@ie= tf.org [mailto:codec-b= ounces@ietf.org] On Behalf Of stephen botzk= o
Sent: Wednesday, April 14,= 2010 4:55 AM
To: bens@alum.mit.edu
Cc: codec@ietf.org
Subject: Re: [codec] #8: S= ample rates?

=A0

When I said signaling I meant SDP, not anything in the bitstream itself.=A0 I was not excluding audio bandwidth changes mid-call as part of network adaptation.= =A0 Though as we all agree this needs to be carefully designed.

I agree it is best if the decoder does not require any knowledge of the SDP negotiation (or any other information beyond the RTP packet stream itself) = in order to correctly decode the audio -- which I think is what you were conce= rned about.

CH: Negotiating codec parameters with SDP has a long tradition. Take for example =B5Law (RT= P payload type 0): Here you negotiate the sampling rate. Also, the number of channels are negotiated for many codecs. I think sampling rate and number o= f channels can be done with SDP. However, I would avoid other codec specific parameters. Especially, in case of AMR the negotiation is quite complex sho= uld be avoided for the Internet=A0 CODEC.

Christian

It would be a nice property if reducing the acoustic bandwidth also allowed= the MIPS to be reduced, but I do not think it is a requirement;=A0 I'd personally rather manage complexity with a Low Complexity profile (if that = is really needed), since then I could keep the acoustic bandwidth (accepting a higher bit rate instead).


Stephen Botzko

On Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwartz <bmschwar@fas.harvard.edu> wrote:

Koen Vos wrote:
> Quoting "Benjamin M. Schwartz":
>> 1. Why would high frequencies be unheard? =A0Cheap speakers and microphones
>> have difficulties with low frequencies, but not high frequencies, = and
>> routinely go all the way up past the limit of hearing.
>
> Not all hardware supports arbitrary/high sampling rates. =A0PSTN gateways
> don't go above 8 kHz. =A0Same for some mobile devices.

True.


>> 2. Why would it need to be negotiated? =A0For a suitably designed format,
>> the encoder could choose not to waste bits on high frequencies wit= hout
>> any
>> negotiation or extra signalling.
>
> Without signaling, how would the encoder know that the farend decoder<= br> > will not take advantage of frequencies above a certain threshold?

When I say signalling, I mean signalling within the codec bitstream. =A0The
encoder can change its behavior based on knowledge of the receiver's configuration, but the bitstream does not need any extra signalling to
indicate the change in behavior.


>>> Signaling the bandwidth, and defining the
>>> internal codec rate as fullband should let us lock down the RT= P
>>> timestamp
>>> rate at 48 kHz (which I think is desirable).
>>
>> I do agree that having "only one mode" would be ideal, t= o maximize
>> interoperability. =A0I wonder whether we can achieve high enough >> computational efficiency for this to be viable.
>
> Changing the RTP timestamp sampling rate causes no computational
> complexity, does it? =A0Perhaps an extra multiplication for each packe= t or
> so? =A0The point was that RTP timestamp sampling rate should disconnected
> from the actual audio signals.

Right, but Stephen also suggested "defining the internal codec rate as
fullband". =A0From this, I imagined a scenario in which all (compliant= ) IWAC
implementations MUST decode all IWAC streams, which always have a sampling<= br> rate of 48 KHz. =A0I think this is a great idea, to achieve really good
interoperability.

If the receiver is a PSTN gateway, then an "internal codec rate" = of 8 KHz
would presumably produce as good quality/bitrate with lower encoder and
decoder complexity. =A0However, if we can make IWAC sufficiently
low-complexity, operating at 48 KHz may be acceptable. =A0It will help if w= e
can structure the codec so that operating at lower bandwidth is very
efficient. =A0For example, it may be possible to structure a transform code= c
such that unneeded high frequencies can cheaply be zero'd on encode and=
ignored on decode.

--Ben

=A0

=A0

=A0


--001636d34a9b55b1a6048432bb81-- From Albrecht.Schwarz@alcatel-lucent.com Wed Apr 14 08:30:05 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60F9B3A682F for ; Wed, 14 Apr 2010 08:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.716 X-Spam-Level: X-Spam-Status: No, score=0.716 tagged_above=-999 required=5 tests=[AWL=2.964, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZkQoNGpzyD59 for ; Wed, 14 Apr 2010 08:30:03 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id D46043A6858 for ; Wed, 14 Apr 2010 08:30:01 -0700 (PDT) Received: from FRVELSBHS03.ad2.ad.alcatel.com (frvelsbhs03.dc-m.alcatel-lucent.com [155.132.6.75]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o3EFTetn032258; Wed, 14 Apr 2010 17:29:41 +0200 Received: from FRVELSMBS23.ad2.ad.alcatel.com ([155.132.6.51]) by FRVELSBHS03.ad2.ad.alcatel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 14 Apr 2010 17:29:39 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CADBE7.4C185D0E" Date: Wed, 14 Apr 2010 17:25:33 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] #8: Sample rates? Thread-Index: Acrb2jDQSN+FCik0R/ODIK3Z5HE5XQAC3rhg References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org><20100413183602.86565rmv5hve5d6q@mail.skype.net><4BC52068.1080906@fas.harvard.edu><000c01cadbc1$86a14f10$93e3ed30$@de><4bc5a8c4.07a5660a.30ee.5382@mx.google.com><003d01cadbcb$32653ce0$972fb6a0$@de><004d01cadbcf$3b43c210$b1cb4630$@de> From: "Schwarz Albrecht" To: "stephen botzko" , "Christian Hoene" X-OriginalArrivalTime: 14 Apr 2010 15:29:39.0908 (UTC) FILETIME=[4C64C040:01CADBE7] X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Apr 2010 15:30:05 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CADBE7.4C185D0E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable You should replace "SDP" by "SDP Offer/Anser" (protocol), in order to = emphasize the requirement for a) indication and possibly b) negotiation = of codec configurations. The number of potential parameters you are mentioning could result in a = number of various codec configurations. If this is the case, then the SDP O/A extensions would be recommended: http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-sdp-media-capabilities/= which implies also support of http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-sdp-capability-negotiat= ion/ =20 [Instead of RFC 3264 defined SDP Offer/Answer, which may be sufficient = for a single codec configuration, but definetely insufficient in case of = multiple codec configurations] ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of stephen botzko Sent: Mittwoch, 14. April 2010 15:56 To: Christian Hoene Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? =09 =09 In-band for me in this case means RTP only. Or in some other contexts = RTP payload only. =09 I think there is=20 (a) negotiation - particularly defining what optional modes the = receiver can handle. In the case of sample rates, number of channels, = and any optional facilities, this is generally not changing mid-call. = SDP is the right place for this. (SDP SHALL be used for this) =09 (b) Feedback - messages related to QOS, packet loss, etc are what I = mean by this. This should be done in RTCP, though given the lack of = VOIP support perhaps there should be a SIP INFO backup path. Feedback = should not be done with RTP. =09 (c) Control - Per RFC 3551, RTCP can be used for "loosely controlled" = sessions, but "may be fully or partially subsumed by a separate session = control protocol". Given the statements on RTCP support in the VOIP = infrastructure, we should be careful about putting unique controls in = RTCP. However, it should not be done in RTP. Since most other audio = codecs don't require this stuff, I suspect we won't either. Though we = will see...=20 =09 (d) In-band (RTP). Not sure how else to say this. Ideally RTP streams = carrying CODEC (with no out-of-band, no RTCP, no SDP parameter = knowledge) can be decoded. That is, I think it should be possible to = fully decode unencrypted CODEC bitstreams with only the RTP packets = abstracted from Wireshark. Even if the operating mode changes = mid-flight. RFC 5404 (G.719) is one example of a packetization that = accomplishes this, but there are other packetization RFCs which do not. =09 Is this more clear? =09 Regards Stephen Botzko =09 =09 =09 =09 On Wed, Apr 14, 2010 at 8:37 AM, Christian Hoene = wrote: =09 Hi Stephen, =20 I am getting confused... Do you mean that the parameter about sampling = rate MUST be negotiated with SDP and not transmitted in-band? Or MUST NOT be negotiated inband but only transmitted inband? Inband means within RTP/RTCP/RTPextentions and/or the Internet CODEC = payload. =20 What do you think about my second question on sampling rate limits? =20 With best regards, Christian =20 =20 =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 =20 From: stephen botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Wednesday, April 14, 2010 2:25 PM To: Christian Hoene Cc: Roni Even; codec@ietf.org=20 Subject: Re: [codec] #8: Sample rates? =09 =20 All negotiation should be done with SDP (and should never be done = in-band) =09 And the RTP transport should be robust enough to permit seamless = changes to any mode that is consistent with the negotiation (with no = signaling). =20 =09 The first point I think is essential. The second reflects my own view = on how RTP packetization should be done. =09 Stephen Botzko On Wed, Apr 14, 2010 at 8:08 AM, Christian Hoene = wrote: Hi, =20 I am fine with dropping any SDP negotiation on codec parameters = including sampling rate and channels. I like the idea of splitting = signaling and transportation issues. =20 But one question remain. We had the question on limiting the = complexity for some kind of devices by choosing a lower sampling rate or = a low number of channels. Shall this negotiation be done with SDP or = inband? =20 Christian =20 =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 =20 From: stephen botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Wednesday, April 14, 2010 1:52 PM To: Roni Even Cc: Christian Hoene; codec@ietf.org =09 Subject: Re: [codec] #8: Sample rates? =20 Good points, thanks for clarifying.. =09 Personally I favor carrying those H.264 parameter sets on the media = path, since there are situations (switched multipoint calls for one) = where the timing matters. With that use case, if reliable-but-too-late = delivery occurs, there are decoding errors even if there is no packet = loss. =20 =09 Though of course SDP transmission alone may be suitable for other = applications, and it is perfectly legal to send them both ways. =09 Stephen Botzko 2010/4/14 Roni Even Hi, Negotiation of codec parameters is not a tradition it is needed if = there are optional modes that the decoder can support in order to allow = the sender to know if the receiver can receive the specific mode. If = there are mandatory modes you may be able to provide the information = in-band but this is not negotiation. Also note that while the signaling = may use reliable channel the media path is not reliable and may suffer = packet loss that may cause the loss of important parameters. We have = such example in the H.264 parameter sets where they can be carried in = the SDP for reliability on in-band as part of the payload. =20 Roni Even =20 =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Christian Hoene Sent: Wednesday, April 14, 2010 1:59 PM To: 'stephen botzko' =09 Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? =20 Hi , =20 comments inline: =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of stephen botzko Sent: Wednesday, April 14, 2010 4:55 AM To: bens@alum.mit.edu Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? =20 When I said signaling I meant SDP, not anything in the bitstream = itself. I was not excluding audio bandwidth changes mid-call as part of = network adaptation. Though as we all agree this needs to be carefully = designed. =09 I agree it is best if the decoder does not require any knowledge of = the SDP negotiation (or any other information beyond the RTP packet = stream itself) in order to correctly decode the audio -- which I think = is what you were concerned about. CH: Negotiating codec parameters with SDP has a long tradition. Take = for example =B5Law (RTP payload type 0): Here you negotiate the sampling = rate. Also, the number of channels are negotiated for many codecs. I = think sampling rate and number of channels can be done with SDP. = However, I would avoid other codec specific parameters. Especially, in = case of AMR the negotiation is quite complex should be avoided for the = Internet CODEC. Christian =09 It would be a nice property if reducing the acoustic bandwidth also = allowed the MIPS to be reduced, but I do not think it is a requirement; = I'd personally rather manage complexity with a Low Complexity profile = (if that is really needed), since then I could keep the acoustic = bandwidth (accepting a higher bit rate instead). =09 Stephen Botzko On Tue, Apr 13, 2010 at 9:54 PM, Benjamin M. Schwartz = wrote: Koen Vos wrote: > Quoting "Benjamin M. Schwartz": >> 1. Why would high frequencies be unheard? Cheap speakers and = microphones >> have difficulties with low frequencies, but not high frequencies, = and >> routinely go all the way up past the limit of hearing. > > Not all hardware supports arbitrary/high sampling rates. PSTN = gateways > don't go above 8 kHz. Same for some mobile devices. True. =09 >> 2. Why would it need to be negotiated? For a suitably designed = format, >> the encoder could choose not to waste bits on high frequencies = without >> any >> negotiation or extra signalling. > > Without signaling, how would the encoder know that the farend = decoder > will not take advantage of frequencies above a certain threshold? When I say signalling, I mean signalling within the codec bitstream. = The encoder can change its behavior based on knowledge of the receiver's configuration, but the bitstream does not need any extra signalling to indicate the change in behavior. =09 >>> Signaling the bandwidth, and defining the >>> internal codec rate as fullband should let us lock down the RTP >>> timestamp >>> rate at 48 kHz (which I think is desirable). >> >> I do agree that having "only one mode" would be ideal, to maximize >> interoperability. I wonder whether we can achieve high enough >> computational efficiency for this to be viable. > > Changing the RTP timestamp sampling rate causes no computational > complexity, does it? Perhaps an extra multiplication for each = packet or > so? The point was that RTP timestamp sampling rate should = disconnected > from the actual audio signals. Right, but Stephen also suggested "defining the internal codec rate as fullband". From this, I imagined a scenario in which all (compliant) = IWAC implementations MUST decode all IWAC streams, which always have a = sampling rate of 48 KHz. I think this is a great idea, to achieve really good interoperability. =09 If the receiver is a PSTN gateway, then an "internal codec rate" of 8 = KHz would presumably produce as good quality/bitrate with lower encoder = and decoder complexity. However, if we can make IWAC sufficiently low-complexity, operating at 48 KHz may be acceptable. It will help = if we can structure the codec so that operating at lower bandwidth is very efficient. For example, it may be possible to structure a transform = codec such that unneeded high frequencies can cheaply be zero'd on encode = and ignored on decode. =09 --Ben =20 =20 =20 ------_=_NextPart_001_01CADBE7.4C185D0E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
You should replace "SDP" by "SDP Offer/Anser" = (protocol), in order to emphasize the requirement for a) indication = and=20 possibly b) negotiation of codec configurations.
The number of potential parameters you are = mentioning=20 could result in a number of various codec = configurations.
If this is the case, then the SDP O/A = extensions would=20 be recommended:
http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-sdp-media-cap= abilities/
which implies also support = of
http://tools.ietf.org/wg/mmusic/draft-ietf-mmusic-sdp-capab= ility-negotiation/
 
[Instead of RFC 3264 defined SDP Offer/Answer, = which may be=20 sufficient for a single codec configuration, but definetely insufficient = in case=20 of multiple codec configurations]

From: codec-bounces@ietf.org=20 [mailto:codec-bounces@ietf.org] On Behalf Of stephen=20 botzko
Sent: Mittwoch, 14. April 2010 15:56
To: = Christian=20 Hoene
Cc: codec@ietf.org
Subject: Re: [codec] #8: = Sample=20 rates?

In-band for me in this case means RTP only.  Or in = some other=20 contexts RTP payload only.

I think there is
(a) negotiation = -=20 particularly defining what optional modes the receiver can=20 handle.  In the case of sample rates, number of channels, and any = optional facilities, this is generally not changing mid-call.  = SDP is the=20 right place for this. (SDP SHALL be used for this)

(b) Feedback = -=20 messages related to QOS, packet loss, etc are what I mean by = this.  This=20 should be done in RTCP, though given the lack of VOIP support perhaps = there=20 should be a SIP INFO backup path.  Feedback should not be done = with=20 RTP.

(c) Control - Per RFC 3551, RTCP can be used for "loosely=20 controlled" sessions, but "may be fully or partially subsumed by a = separate=20 session control protocol".  Given the statements on RTCP support = in the=20 VOIP infrastructure, we should be careful about putting unique = controls in=20 RTCP.  However, it should not be done in RTP.  Since most = other=20 audio codecs don't require this stuff, I suspect we won't = either.  Though=20 we will see...

(d) In-band (RTP).  Not sure how else to = say=20 this.  Ideally RTP streams carrying CODEC (with no out-of-band, = no RTCP,=20 no SDP parameter knowledge) can be decoded.  That is, I think it = should=20 be possible to fully decode unencrypted CODEC bitstreams with only the = RTP=20 packets abstracted from Wireshark.  Even if the operating mode = changes=20 mid-flight.  RFC 5404 (G.719) is one example of a packetization = that=20 accomplishes this, but there are other packetization RFCs which do=20 not.

Is this more clear?

Regards
Stephen=20 Botzko



On Wed, Apr 14, 2010 at 8:37 AM, Christian = Hoene <hoene@uni-tuebingen.de>=20 wrote:

Hi = Stephen,

 

I am getting = confused=85 Do you=20 mean that the parameter about sampling rate MUST be negotiated with = SDP and=20 not transmitted in-band?

Or MUST NOT be = negotiated=20 inband but only transmitted=20 inband?

Inband means within=20 RTP/RTCP/RTPextentions and/or the Internet CODEC=20 payload.

 

What do you think = about my=20 second question on sampling rate limits?

 

With best=20 regards,

 Christian

 

 

 

---------------------------------------------------------------=

Dr.-Ing.=20 Christian Hoene

Interactive=20 Communication Systems (ICS), University of T=FCbingen =

Sand=20 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 =
http://www.net.uni-tuebingen.de/

 

From: stephen = botzko [mailto:stephen.botzko@gmail.com]
Sent: Wednesday, April 14, = 2010 2:25=20 PM
To: Christian=20 Hoene
Cc: Roni = Even; codec@ietf.org


Subject: Re:=20 [codec] #8: Sample rates?

 

All negotiation should be = done with SDP=20 (and should never be done in-band)

And the RTP = transport=20 should be robust enough to permit seamless changes to any mode that = is=20 consistent with the negotiation (with no signaling).  =

The first=20 point I think is essential.  The second reflects my own view on = how RTP=20 packetization should be done.

Stephen = Botzko

On Wed, Apr 14, 2010 at 8:08 AM, Christian = Hoene=20 <hoene@uni-tuebingen.de> = wrote:

Hi,

 

I am fine with = dropping any=20 SDP negotiation on codec parameters including sampling rate and = channels. I=20 like the idea of splitting signaling and transportation=20 issues.

 

But one question = remain. We=20 had the question on limiting the complexity for some kind of devices = by=20 choosing a lower sampling rate or a low number of channels. Shall = this=20 negotiation be done with SDP or inband?

 

Christian

 

 

---------------------------------------------------------------=

Dr.-Ing.=20 Christian Hoene

Interactive=20 Communication Systems (ICS), University of T=FCbingen =

Sand=20 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 =
http://www.net.uni-tuebingen.de/

 

From: stephen = botzko [mailto:stephen.botzko@gmail.com]
Sent: Wednesday, April 14, = 2010 1:52=20 PM
To: Roni=20 Even
Cc: = Christian Hoene;=20 codec@ietf.org


Subject: Re: [codec] #8: = Sample=20 rates?

 

Good points, thanks for=20 clarifying..

Personally I favor carrying those H.264 = parameter sets=20 on the media path, since there are situations (switched multipoint = calls for=20 one) where the timing matters.  With that use case, if=20 reliable-but-too-late delivery occurs, there are decoding errors = even if=20 there is no packet loss. 

Though of course SDP = transmission=20 alone may be suitable for other applications, and it is perfectly = legal to=20 send them both ways.

Stephen Botzko

2010/4/14 Roni Even <ron.even.tlv@gmail.com>

Hi,

Negotiation of=20 codec parameters is not a tradition it  is needed if there are = optional=20 modes that the decoder can support in order to allow the sender to = know if=20 the receiver can receive the specific mode. If there are mandatory = modes you=20 may be able to provide the information in-band but this is not = negotiation.=20 Also note that while the signaling may use reliable channel the = media path=20 is not reliable and may suffer packet loss that may cause the loss = of=20 important parameters. We have such example in the H.264 parameter = sets where=20 they can be carried in the SDP for reliability on in-band as part of = the=20 payload.

 

Roni=20 Even

 

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Christian=20 Hoene
Sent: = Wednesday,=20 April 14, 2010 1:59 PM
To:=20 'stephen botzko'


Cc: codec@ietf.org
Subject: Re: [codec] #8: = Sample=20 rates?

 

Hi = ,

 

comments=20 inline:

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of stephen = botzko
Sent: Wednesday, April 14, = 2010 4:55=20 AM
To: bens@alum.mit.edu
Cc: codec@ietf.org
Subject: Re: [codec] #8: = Sample=20 rates?

 

When I said signaling I = meant SDP, not=20 anything in the bitstream itself.  I was not excluding audio = bandwidth=20 changes mid-call as part of network adaptation.  = Though as we all agree this needs to be carefully=20 designed.

I agree it is best if the decoder does not require = any=20 knowledge of the SDP negotiation (or any other information beyond = the RTP=20 packet stream itself) in order to correctly decode the audio -- = which I=20 think is what you were concerned about.

CH: Negotiating = codec=20 parameters with SDP has a long tradition. Take for example =B5Law = (RTP payload=20 type 0): Here you negotiate the sampling rate. Also, the number of = channels=20 are negotiated for many codecs. I think sampling rate and number of = channels=20 can be done with SDP. However, I would avoid other codec specific=20 parameters. Especially, in case of AMR the negotiation is quite = complex=20 should be avoided for the Internet  CODEC.

Christian

It would be a nice property if reducing the = acoustic=20 bandwidth also allowed the MIPS to be reduced, but I do not think it = is a=20 requirement;  I'd personally rather manage complexity with a = Low=20 Complexity profile (if that is really needed), since then I could = keep the=20 acoustic bandwidth (accepting a higher bit rate instead).


Stephen=20 Botzko

On Tue, Apr 13, 2010 at 9:54 PM, Benjamin = M.=20 Schwartz <bmschwar@fas.harvard.edu> = wrote:

Koen Vos wrote:
> = Quoting=20 "Benjamin M. Schwartz":
>> 1. Why would high frequencies be = unheard?  Cheap speakers and microphones
>> have = difficulties=20 with low frequencies, but not high frequencies, and
>> = routinely go=20 all the way up past the limit of hearing.
>
> Not all = hardware=20 supports arbitrary/high sampling rates.  PSTN gateways
> = don't go=20 above 8 kHz.  Same for some mobile = devices.

True.


>> 2. Why would = it need to be=20 negotiated?  For a suitably designed format,
>> the = encoder=20 could choose not to waste bits on high frequencies = without
>>=20 any
>> negotiation or extra signalling.
>
> = Without=20 signaling, how would the encoder know that the farend = decoder
> will=20 not take advantage of frequencies above a certain=20 threshold?

When I say signalling, I mean signalling = within the=20 codec bitstream.  The
encoder can change its behavior based = on=20 knowledge of the receiver's
configuration, but the bitstream does = not=20 need any extra signalling to
indicate the change in=20 behavior.


>>> Signaling = the=20 bandwidth, and defining the
>>> internal codec rate as = fullband=20 should let us lock down the RTP
>>> = timestamp
>>>=20 rate at 48 kHz (which I think is desirable).
>>
>> = I do=20 agree that having "only one mode" would be ideal, to = maximize
>>=20 interoperability.  I wonder whether we can achieve high=20 enough
>> computational efficiency for this to be=20 viable.
>
> Changing the RTP timestamp sampling rate = causes no=20 computational
> complexity, does it?  Perhaps an extra=20 multiplication for each packet or
> so?  The point was = that RTP=20 timestamp sampling rate should disconnected
> from the actual = audio=20 signals.

Right, but Stephen also = suggested=20 "defining the internal codec rate as
fullband".  From this, = I=20 imagined a scenario in which all (compliant) IWAC
implementations = MUST=20 decode all IWAC streams, which always have a sampling
rate of 48 = KHz.=20  I think this is a great idea, to achieve really=20 good
interoperability.

If the receiver is a PSTN gateway, = then an=20 "internal codec rate" of 8 KHz
would presumably produce as good=20 quality/bitrate with lower encoder and
decoder complexity. =  However,=20 if we can make IWAC sufficiently
low-complexity, operating at 48 = KHz may=20 be acceptable.  It will help if we
can structure the codec = so that=20 operating at lower bandwidth is very
efficient.  For = example, it may=20 be possible to structure a transform codec
such that unneeded = high=20 frequencies can cheaply be zero'd on encode and
ignored on=20 decode.

--Ben

 

 

 

=
------_=_NextPart_001_01CADBE7.4C185D0E-- From hoene@uni-tuebingen.de Thu Apr 15 21:45:00 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21C7A3A6852 for ; Thu, 15 Apr 2010 21:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.717 X-Spam-Level: X-Spam-Status: No, score=-2.717 tagged_above=-999 required=5 tests=[AWL=-0.067, BAYES_60=1, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tVfsEO5gqIy6 for ; Thu, 15 Apr 2010 21:44:59 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 0FBAA3A6804 for ; Thu, 15 Apr 2010 21:44:58 -0700 (PDT) Received: from hoeneT60 ([178.2.210.31]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o3G4ihgM026632 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 16 Apr 2010 06:44:49 +0200 From: "Christian Hoene" To: References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> <002a01cadac8$68dbf380$3a93da80$@de> In-Reply-To: <002a01cadac8$68dbf380$3a93da80$@de> Date: Fri, 16 Apr 2010 06:44:42 +0200 Message-ID: <002301cadd1f$8b936da0$a2ba48e0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acrakw+V6xvPUJfsSoq0LvVBy0a63wANC0KQAJWqC5A= Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Subject: Re: [codec] #8: Sample rates? 44.1kHz? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 04:45:00 -0000 Hi all, >It might be useful to state that it is not recommended to use 44100 Hz, = because the conversion to >16kHz and 32kHz is computational more demanding than 48kHz and requires = more power/time. Currently, proposed codec run at sampling rates of=20 BroadVoice: 8, 16 kHz SILK: 8, 12, 16, 24 kHz CELT: 32 kHz to 96 kHz. I do have a question. In order to make the RTP handling and the = resampling simpler, it might be useful to skip the 44.1kHz compression = mode. If only 8, 12, 16, 24, 32, and 48 kHz sampling rates are used, = then the RTP timestamp can be easily counted in 96 kHz units. Supporting = 44.1 kHz would require fractions of time stamp units that are difficult = to handle with. Also, the resampling take more computational resource if = it has to be done at high quality. Thus, my question: Is 44.1 kHz really much-needed or can we use 32 or 48 = kHz instead? Christian From koen.vos@skype.net Thu Apr 15 23:35:41 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB2333A6876 for ; Thu, 15 Apr 2010 23:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.931 X-Spam-Level: X-Spam-Status: No, score=-4.931 tagged_above=-999 required=5 tests=[AWL=-0.191, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xfhxE0rCX1h for ; Thu, 15 Apr 2010 23:35:40 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id C28663A6842 for ; Thu, 15 Apr 2010 23:35:39 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 5BF50607ABBF8; Fri, 16 Apr 2010 07:35:32 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=1B5hvyiBMY9Z IbFVrUCNZH31OTU=; b=YDoQnTDovsZxH9n32iITEWcBVZcHxv2eVpBzKRAz3aui Lq9Ljdw5XgbqN2BcqnU77f6tuOFznccQTe5TFBfhsMUn8/4O0SWDaFMlqoAeKqzC XXUFYSCialXuT4C+hAm2Fi92gkllh9yxq7BomE8yfo/jJLzPnoI8qSuonU8puHY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=wQkPasVt8H8ShBWKlqUP 5uVupc3Zkj2AhYkqJeOO/y+Pm3WtuzD00mHRjdiG99WTevL/da73lzoRcTDtF4ZK Zbxmx88cauvDFqQYezXrDG3FmveRyn6kdKK0T60LL83Gllc2WHCPz2GcyHjz4xYT XusPzvADFLuIAWQ8JLD3kY0= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 5A021607ABBF7; Fri, 16 Apr 2010 07:35:32 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtuzsSn4+Yre; Fri, 16 Apr 2010 07:35:31 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 871A6607ABBF6; Fri, 16 Apr 2010 07:35:31 +0100 (IST) Received: from adsl-71-141-129-119.dsl.snfc21.pacbell.net (adsl-71-141-129-119.dsl.snfc21.pacbell.net [71.141.129.119]) by mail.skype.net (Horde Framework) with HTTP; Thu, 15 Apr 2010 23:35:31 -0700 Message-ID: <20100415233531.265740nulcub9elv@mail.skype.net> Date: Thu, 15 Apr 2010 23:35:31 -0700 From: Koen Vos To: Christian Hoene References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> <002a01cadac8$68dbf380$3a93da80$@de> <002301cadd1f$8b936da0$a2ba48e0$@de> In-Reply-To: <002301cadd1f$8b936da0$a2ba48e0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? 44.1kHz? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 06:35:41 -0000 Quoting Christian Hoene: > Supporting 44.1 kHz would require fractions of time stamp units It would be better to base the RTP time stamp on a fixed sampling rate, independent of the sampling rates used at the API level and internally. The reason is that the API and internal sampling rates may change at any time. My proposal would be to count RTP time stamps at 48 kHz always. >> It might be useful to state that it is not recommended to use 44100 >> Hz because the conversion is computational more demanding Not sure I see the need.. The CPU cost of resampling is negligible on many devices (certainly on PCs). And if all other elements in the chain run at 44.1 kHz, then supporting it in the codec API could actually reduce the number of resamplers. best, koen. > Hi all, > >> It might be useful to state that it is not recommended to use 44100 >> Hz, because the conversion to >> 16kHz and 32kHz is computational more demanding than 48kHz and >> requires more power/time. > > Currently, proposed codec run at sampling rates of > > BroadVoice: 8, 16 kHz > SILK: 8, 12, 16, 24 kHz > CELT: 32 kHz to 96 kHz. > > I do have a question. In order to make the RTP handling and the > resampling simpler, it might be useful to skip the 44.1kHz > compression mode. If only 8, 12, 16, 24, 32, and 48 kHz sampling > rates are used, then the RTP timestamp can be easily counted in 96 > kHz units. Supporting 44.1 kHz would require fractions of time stamp > units that are difficult to handle with. Also, the resampling take > more computational resource if it has to be done at high quality. > > Thus, my question: Is 44.1 kHz really much-needed or can we use 32 > or 48 kHz instead? > > Christian > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From hoene@uni-tuebingen.de Fri Apr 16 00:44:30 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A60193A68E9 for ; Fri, 16 Apr 2010 00:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.818 X-Spam-Level: X-Spam-Status: No, score=-4.818 tagged_above=-999 required=5 tests=[AWL=-0.428, BAYES_20=-0.74, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id udlOqdkPPyvl for ; Fri, 16 Apr 2010 00:44:29 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 6849F3A685E for ; Fri, 16 Apr 2010 00:44:22 -0700 (PDT) Received: from hoeneT60 (u-173-c009.cs.uni-tuebingen.de [134.2.173.9]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o3G7i8K8027693 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 16 Apr 2010 09:44:09 +0200 From: "Christian Hoene" To: "'Koen Vos'" References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> <002a01cadac8$68dbf380$3a93da80$@de> <002301cadd1f$8b936da0$a2ba48e0$@de> <20100415233531.265740nulcub9elv@mail.skype.net> In-Reply-To: <20100415233531.265740nulcub9elv@mail.skype.net> Date: Fri, 16 Apr 2010 09:44:08 +0200 Message-ID: <000601cadd38$9b8210e0$d28632a0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrdLwm8QOZN9Q0pT6OEdJcYvFhP0AABR6RQ Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.220; VDF: 7.10.6.110; host: mx05); id=12376-JuX2TI Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? 44.1kHz? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 07:44:30 -0000 Hi Koen, >> Supporting 44.1 kHz would require fractions of time stamp units > >It would be better to base the RTP time stamp on a fixed sampling >rate, independent of the sampling rates used at the API level and >internally. The reason is that the API and internal sampling rates >may change at any time. My proposal would be to count RTP time stamps >at 48 kHz always. Using 48 kHz as RTP time stamp basis might be difficult for a 32 kHz internal sampling rate because you then might need to count 1,5 units of time. However, this might not be a problem if the frame size is a multiple of 3 or if we define a proper, bijective rounding mechanisms for RTP time stamps. In case of 44.1 kHz mapping to 48 kHz, a similar round function must be defined. Actually, some time ago I had a similar discussion regarding the support of multiple sampling rates in the draft-hoene-sbc. The AVT guys suggested me to either use the least common multiple of the sampling rates as RTP time stamp rate (which would be 96 kHz if 44.1 is not support), or to use different RTP payload types for different sampling rates. A rounding function for RTP time stamps has not yet been defined in any RTP payload RFC. Thus, AVT guys might complain if we introduce a rounding function. But then again, if it is well defined it should not be a technical problem... Best, Christian > >best, >koen. > > > >> Hi all, >> >>> It might be useful to state that it is not recommended to use 44100 >>> Hz, because the conversion to >>> 16kHz and 32kHz is computational more demanding than 48kHz and >>> requires more power/time. >> >> Currently, proposed codec run at sampling rates of >> >> BroadVoice: 8, 16 kHz >> SILK: 8, 12, 16, 24 kHz >> CELT: 32 kHz to 96 kHz. >> >> I do have a question. In order to make the RTP handling and the >> resampling simpler, it might be useful to skip the 44.1kHz >> compression mode. If only 8, 12, 16, 24, 32, and 48 kHz sampling >> rates are used, then the RTP timestamp can be easily counted in 96 >> kHz units. Supporting 44.1 kHz would require fractions of time stamp >> units that are difficult to handle with. Also, the resampling take >> more computational resource if it has to be done at high quality. >> >> Thus, my question: Is 44.1 kHz really much-needed or can we use 32 >> or 48 kHz instead? >> >> Christian >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> From stephen.botzko@gmail.com Fri Apr 16 03:53:02 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 877F63A694D for ; Fri, 16 Apr 2010 03:53:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=-0.679, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z+HARQfIDAof for ; Fri, 16 Apr 2010 03:53:01 -0700 (PDT) Received: from mail-iw0-f189.google.com (mail-iw0-f189.google.com [209.85.223.189]) by core3.amsl.com (Postfix) with ESMTP id D70473A6932 for ; Fri, 16 Apr 2010 03:52:57 -0700 (PDT) Received: by iwn27 with SMTP id 27so1324427iwn.5 for ; Fri, 16 Apr 2010 03:52:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=pM7ooLMEqYBt44ofTzvbY8A47lZBKOJQ3weonqxqAfM=; b=Bw6lPeKUxYF0N2Duwn0lTg5dZ6ZJWYKQV9AtIfy/0NU6fbObMB7hMxp2NA6PJcDqSa pRj7t+Trg+sq+TOGgJ0P1IV14kJJpOO7Wc/iBMuOu8zjTc+CMu8ns5pObhc+kGkFFvlF 9wao2V9slMYFNt5Bx6eYyEOW1i1fFgSOQ30k8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=f6JEkDqc/j/uK9Ej7ht7nQ6LW5J/C8DxlXfed1qzGoFfXh6Hw6dDmZwcQWaYg7JNH/ O1elYfqLYcFeXpHVhwbt44eC0JJwM+C2g+raAJT2OoZ6Weyzs7UxC3+SAjaI+wk+6CGM /APAAiGdbqEzOEeBUKoVGB9Ehd16F0RY1t/pA= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Fri, 16 Apr 2010 03:52:47 -0700 (PDT) In-Reply-To: <002301cadd1f$8b936da0$a2ba48e0$@de> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> <002a01cadac8$68dbf380$3a93da80$@de> <002301cadd1f$8b936da0$a2ba48e0$@de> Date: Fri, 16 Apr 2010 06:52:47 -0400 Received: by 10.231.147.148 with SMTP id l20mr505092ibv.77.1271415167934; Fri, 16 Apr 2010 03:52:47 -0700 (PDT) Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=0016e6498a5c7260f904845869bd Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? 44.1kHz? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 10:53:02 -0000 --0016e6498a5c7260f904845869bd Content-Type: text/plain; charset=ISO-8859-1 -Support of 48 kHz in sound cards, etc. is quite widespread, so personally I see no requirement for 44.1 kHz (or 22.05, 11.025). -RTP timestamp granularity of 96 kHz would be pretty hard to get through, unless we actually have a 96 kHz mode of operation. I don't see any requirement for such a mode (though CELT happens to do it) Might be worth summarizing where we are at this point: -There appears to be a consensus that the RTP time base needs to remain constant despite any changes to acoustic bandwidth. (due to network adaptation) - There is a consensus that frequent changes to acoustic bandwidth results in a disturbing / unpleasant listening experience. - There is consensus that it is ok to reduce the acoustic bandwidths at lower bitrates, - There is no consensus (as of yet) as to how many or which sampling rates we need for the "internal codec", including no consensus that we need more than one. It is important to note that no one has *objected* to multiple sample rates either. Though it has been observed that multiple sample rates makes compressed domain mixing problematic. Stephen Botzko On Fri, Apr 16, 2010 at 12:44 AM, Christian Hoene wrote: > Hi all, > > >It might be useful to state that it is not recommended to use 44100 Hz, > because the conversion to > >16kHz and 32kHz is computational more demanding than 48kHz and requires > more power/time. > > Currently, proposed codec run at sampling rates of > > BroadVoice: 8, 16 kHz > SILK: 8, 12, 16, 24 kHz > CELT: 32 kHz to 96 kHz. > > I do have a question. In order to make the RTP handling and the resampling > simpler, it might be useful to skip the 44.1kHz compression mode. If only 8, > 12, 16, 24, 32, and 48 kHz sampling rates are used, then the RTP timestamp > can be easily counted in 96 kHz units. Supporting 44.1 kHz would require > fractions of time stamp units that are difficult to handle with. Also, the > resampling take more computational resource if it has to be done at high > quality. > > Thus, my question: Is 44.1 kHz really much-needed or can we use 32 or 48 > kHz instead? > > Christian > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016e6498a5c7260f904845869bd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable -Support of 48 kHz in sound cards, etc. is quite widespread, so personally = I see no requirement for 44.1 kHz (or 22.05, 11.025).

-RTP timestam= p granularity of 96 kHz would be pretty hard to get through, unless we actu= ally have a 96 kHz mode of operation.=A0 I don't see any requirement fo= r such a mode (though CELT happens to do it)=A0

Might be worth summarizing where we are at this point:

-There appears to be a consensus that the RTP time= base needs to remain constant despite any changes to acoustic bandwidth. (= due to network adaptation)

- There is a consensus that fre= quent changes to acoustic bandwidth results in a disturbing / unpleasant li= stening experience.

- There is consensus that it is ok to reduce the= acoustic bandwidths at=20 lower bitrates,

- There is no consensus (as of yet) as to how m= any or which sampling rates we need for the "internal codec", inc= luding no consensus that we need more than one.=A0 It is important to note = that no one has objected to multiple sample rates either. Though it = has been observed that multiple sample rates makes compressed domain mixing= problematic.


Stephen Botzko


On Fri, = Apr 16, 2010 at 12:44 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:=
Hi all,

>It might be useful to state that it is not recommended to use 44100 Hz,= because the conversion to
>16kHz and 32kHz is computational more demanding than 48kHz and requires= more power/time.

Currently, proposed codec run at sampling rates of

BroadVoice: 8, 16 kHz
SILK: 8, 12, 16, 24 kHz
CELT: 32 kHz to 96 kHz.

I do have a question. In order to make the RTP handling and the resampling = simpler, it might be useful to skip the 44.1kHz compression mode. If only 8= , 12, 16, 24, 32, and 48 kHz sampling rates are used, then the RTP timestam= p can be easily counted in 96 kHz units. Supporting 44.1 kHz would require = fractions of time stamp units that are difficult to handle with. Also, the = resampling take more computational resource if it has to be done at high qu= ality.

Thus, my question: Is 44.1 kHz really much-needed or can we use 32 or 48 kH= z instead?

Christian


_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016e6498a5c7260f904845869bd-- From stephen.botzko@gmail.com Fri Apr 16 03:58:29 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB9D73A6A0F for ; Fri, 16 Apr 2010 03:58:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.493 X-Spam-Level: X-Spam-Status: No, score=-2.493 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7WvURjSzxoI for ; Fri, 16 Apr 2010 03:58:28 -0700 (PDT) Received: from mail-yw0-f200.google.com (mail-yw0-f200.google.com [209.85.211.200]) by core3.amsl.com (Postfix) with ESMTP id 2B3983A67AB for ; Fri, 16 Apr 2010 03:58:18 -0700 (PDT) Received: by ywh38 with SMTP id 38so1270302ywh.29 for ; Fri, 16 Apr 2010 03:58:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=cKo9acsUxDeLVKlXSiPtqtxlDwpwv9bNQd+YhkExjmc=; b=d5Y66yxH6UqA12lwrRe8AjhfMtQwZQHysnpqB5dW0Fb3I2SYRe63WdQOkdFCdlo3sl LIQyCp4Vt8OIzzeh8OCGiMdxE3JuwGKNfIIUKJ5xgTVSBTqEjn+0hVpa/XbQHBfvXqS3 oscqJPQBocKjcEmUzLXMGBevwDfNwoWgT6fic= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=TizXjL0R6SXgG8YPOzG/m0aTJTOWTGX3SPN8J28xMJfWKmHTETCV2Ky9NcE+0zkPVh u/msngsQPeGqwxFUmSW/v1FhA3aDcVE1Neb+kP8UZyffBetbi7cIBIUiupfb4+ZN7ytO 3fR6c03XCWvo68i8zY8/cgCdTj4zS36CMdG9M= MIME-Version: 1.0 Received: by 10.231.85.133 with HTTP; Fri, 16 Apr 2010 03:58:06 -0700 (PDT) In-Reply-To: References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> <002a01cadac8$68dbf380$3a93da80$@de> <002301cadd1f$8b936da0$a2ba48e0$@de> Date: Fri, 16 Apr 2010 06:58:06 -0400 Received: by 10.101.195.20 with SMTP id x20mr2463114anp.244.1271415486486; Fri, 16 Apr 2010 03:58:06 -0700 (PDT) Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=0016e68e7f686f26b20484587c25 Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? 44.1kHz? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 10:58:29 -0000 --0016e68e7f686f26b20484587c25 Content-Type: text/plain; charset=ISO-8859-1 One more, added in line--- On Fri, Apr 16, 2010 at 6:52 AM, stephen botzko wrote: > -Support of 48 kHz in sound cards, etc. is quite widespread, so personally > I see no requirement for 44.1 kHz (or 22.05, 11.025). > > -RTP timestamp granularity of 96 kHz would be pretty hard to get through, > unless we actually have a 96 kHz mode of operation. I don't see any > requirement for such a mode (though CELT happens to do it) > > Might be worth summarizing where we are at this point: > > -There appears to be a consensus that the RTP time base needs to remain > constant despite any changes to acoustic bandwidth. (due to network > adaptation) > > - There is a consensus that frequent changes to acoustic bandwidth results > in a disturbing / unpleasant listening experience. > > - There is consensus that it is ok to reduce the acoustic bandwidths at > lower bitrates, > * - There is consensus that 48 kHz (fullband) operation is a requirement.* > > - There is no consensus (as of yet) as to how many or which sampling rates > we need for the "internal codec", including no consensus that we need more > than one. It is important to note that no one has *objected* to multiple > sample rates either. Though it has been observed that multiple sample rates > makes compressed domain mixing problematic. > > > Stephen Botzko > > > > On Fri, Apr 16, 2010 at 12:44 AM, Christian Hoene wrote: > >> Hi all, >> >> >It might be useful to state that it is not recommended to use 44100 Hz, >> because the conversion to >> >16kHz and 32kHz is computational more demanding than 48kHz and requires >> more power/time. >> >> Currently, proposed codec run at sampling rates of >> >> BroadVoice: 8, 16 kHz >> SILK: 8, 12, 16, 24 kHz >> CELT: 32 kHz to 96 kHz. >> >> I do have a question. In order to make the RTP handling and the resampling >> simpler, it might be useful to skip the 44.1kHz compression mode. If only 8, >> 12, 16, 24, 32, and 48 kHz sampling rates are used, then the RTP timestamp >> can be easily counted in 96 kHz units. Supporting 44.1 kHz would require >> fractions of time stamp units that are difficult to handle with. Also, the >> resampling take more computational resource if it has to be done at high >> quality. >> >> Thus, my question: Is 44.1 kHz really much-needed or can we use 32 or 48 >> kHz instead? >> >> Christian >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> > > --0016e68e7f686f26b20484587c25 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable One more, added in line---

On Fri, Apr 16= , 2010 at 6:52 AM, stephen botzko <stephen.botzko@gmail.com> wrote:
=
-Support of 48 kHz in sound cards, etc. is quite widespread, so personally = I see no requirement for 44.1 kHz (or 22.05, 11.025).

-RTP timestam= p granularity of 96 kHz would be pretty hard to get through, unless we actu= ally have a 96 kHz mode of operation.=A0 I don't see any requirement fo= r such a mode (though CELT happens to do it)=A0

Might be worth summarizing where we are at this point:

-There appears to be a consensus that the RTP time= base needs to remain constant despite any changes to acoustic bandwidth. (= due to network adaptation)

- There is a consensus that fre= quent changes to acoustic bandwidth results in a disturbing / unpleasant li= stening experience.

- There is consensus that it is ok to reduce the= acoustic bandwidths at=20 lower bitrates,
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 - There is cons= ensus that 48 kHz (fullband) operation is a requirement.
<= br>
- There is no consensus (as of y= et) as to how many or which sampling rates we need for the "internal c= odec", including no consensus that we need more than one.=A0 It is imp= ortant to note that no one has objected to multiple sample rates eit= her. Though it has been observed that multiple sample rates makes compresse= d domain mixing problematic.


Stephen Botzko



<= div class=3D"gmail_quote">On Fri, Apr 16, 2010 at 12:44 AM, Christian Hoene= <hoene@uni-tuebingen.de> wrote:
Hi all,

>It might be useful to state that it is not recommended to use 44100 Hz,= because the conversion to
>16kHz and 32kHz is computational more demanding than 48kHz and requires= more power/time.

Currently, proposed codec run at sampling rates of

BroadVoice: 8, 16 kHz
SILK: 8, 12, 16, 24 kHz
CELT: 32 kHz to 96 kHz.

I do have a question. In order to make the RTP handling and the resampling = simpler, it might be useful to skip the 44.1kHz compression mode. If only 8= , 12, 16, 24, 32, and 48 kHz sampling rates are used, then the RTP timestam= p can be easily counted in 96 kHz units. Supporting 44.1 kHz would require = fractions of time stamp units that are difficult to handle with. Also, the = resampling take more computational resource if it has to be done at high qu= ality.

Thus, my question: Is 44.1 kHz really much-needed or can we use 32 or 48 kH= z instead?

Christian


_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec


--0016e68e7f686f26b20484587c25-- From brian@freeswitch.org Fri Apr 16 06:35:30 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E5153A6C0F for ; Fri, 16 Apr 2010 06:35:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4-EIjzoYlcaa for ; Fri, 16 Apr 2010 06:35:29 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 096DF28C192 for ; Fri, 16 Apr 2010 06:28:13 -0700 (PDT) Received: by pwj2 with SMTP id 2so1901632pwj.31 for ; Fri, 16 Apr 2010 06:28:04 -0700 (PDT) Received: by 10.142.119.22 with SMTP id r22mr849778wfc.191.1271424484658; Fri, 16 Apr 2010 06:28:04 -0700 (PDT) Received: from [192.168.1.33] (adsl-70-234-189-29.dsl.tul2ok.sbcglobal.net [70.234.189.29]) by mx.google.com with ESMTPS id 23sm1921253iwn.2.2010.04.16.06.28.03 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 16 Apr 2010 06:28:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii From: Brian West In-Reply-To: Date: Fri, 16 Apr 2010 08:28:01 -0500 Content-Transfer-Encoding: 7bit Message-Id: <08DE0B70-F3AA-4DCA-8662-DE88155DE016@freeswitch.org> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> <071.0bc6655c98ff0335ad26ee705d9f5ce9@tools.ietf.org> <002a01cadac8$68dbf380$3a93da80$@de> <002301cadd1f$8b936da0$a2ba48e0$@de> To: stephen botzko X-Mailer: Apple Mail (2.1078) Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? 44.1kHz? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 13:35:30 -0000 I agree these sampling rates shouldn't be a requirement. /b On Apr 16, 2010, at 5:52 AM, stephen botzko wrote: > - I see no requirement for 44.1 kHz (or 22.05, 11.025). From mknappe@juniper.net Fri Apr 16 09:31:40 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 150233A69DB for ; Fri, 16 Apr 2010 09:31:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.009 X-Spam-Level: X-Spam-Status: No, score=-6.009 tagged_above=-999 required=5 tests=[AWL=0.590, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MpeRvCbDkUdD for ; Fri, 16 Apr 2010 09:31:38 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id 4DD7A3A69E7 for ; Fri, 16 Apr 2010 09:31:21 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKS8iQyrDrCUXOoB3ZJBr05WXclwXJ0afH@postini.com; Fri, 16 Apr 2010 09:31:14 PDT Received: from EMBX02-HQ.jnpr.net ([fe80::18fe:d666:b43e:f97e]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Fri, 16 Apr 2010 09:28:52 -0700 From: Michael Knappe To: Brian West , stephen botzko Date: Fri, 16 Apr 2010 09:28:49 -0700 Thread-Topic: [codec] #8: Sample rates? 44.1kHz? Thread-Index: Acrdaav4TjSSU61QQsCphiZ7/dngNQAGDisj Message-ID: In-Reply-To: <08DE0B70-F3AA-4DCA-8662-DE88155DE016@freeswitch.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-Entourage/13.3.0.091002 acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] #8: Sample rates? 44.1kHz? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 16:31:40 -0000 I agree as well, let's stick to the 48 kHz family and its common divisors. Here's an interesting blurb on the origins of the 44.1 kHz sample rate and its choice for the CD format. http://www.cardinalpeak.com/blog/?p=3D150 Mike On 4/16/10 6:28 AM, "Brian West" wrote: > I agree these sampling rates shouldn't be a requirement. >=20 > /b >=20 > On Apr 16, 2010, at 5:52 AM, stephen botzko wrote: >=20 >> - I see no requirement for 44.1 kHz (or 22.05, 11.025). >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From trac@tools.ietf.org Wed Apr 21 02:34:05 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABB9528C0F2 for ; Wed, 21 Apr 2010 02:34:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.238 X-Spam-Level: X-Spam-Status: No, score=-101.238 tagged_above=-999 required=5 tests=[AWL=-1.238, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VtvmRNQtIJfb for ; Wed, 21 Apr 2010 02:34:04 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 903E13A6B34 for ; Wed, 21 Apr 2010 02:33:56 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4WJE-0007fx-9q; Wed, 21 Apr 2010 02:33:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: jean-marc.valin@usherbrooke.ca, hoene@uni-tuebingen.de, kpfleming@digium.com X-Trac-Project: codec Date: Wed, 21 Apr 2010 09:33:28 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/codec/trac/ticket/8#comment:2 Message-ID: <071.a4bb2956b80f6b227cecb27d61046b90@tools.ietf.org> References: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> X-Trac-Ticket-ID: 8 In-Reply-To: <062.89d7aa91c79b145b798b83610e45ce71@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: jean-marc.valin@usherbrooke.ca, hoene@uni-tuebingen.de, kpfleming@digium.com, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #8: Sample rates? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 09:34:05 -0000 #8: Sample rates? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: jean-marc.valin@… Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Changes (by hoene@…): * owner: => jean-marc.valin@… Comment: KOEN wrote: - The codec has 3 sampling rates: 1. Encoder API 2. Codec internal (not strictly sampling rate, more audio bandwidth as Stephen pointed out) 3. Decoder API I don't see a reason to impose that some or all of these be identical. CH: Number four is the RTP time stamp rate... On Fri, Apr 16, 2010 at 6:52 AM, stephen botzko wrote: -Support of 48 kHz in sound cards, etc. is quite widespread, so personally I see no requirement for 44.1 kHz (or 22.05, 11.025). CH: Many others agreed. -RTP timestamp granularity of 96 kHz would be pretty hard to get through, unless we actually have a 96 kHz mode of operation. I don't see any requirement for such a mode (though CELT happens to do it). CH: Using 48 kHz as RTP time stamp basis might be difficult for a 32 kHz internal sampling rate because you then might need to count 1,5 units of time. ... The AVT guys suggested me to either use the least common multiple of the sampling rates as RTP time stamp rate (which would be 96 kHz if 44.1 is not support), or to use different RTP payload types for different sampling rates. BOTZKO: Might be worth summarizing where we are at this point: -There appears to be a consensus that the RTP time base needs to remain constant despite any changes to acoustic bandwidth. (due to network adaptation) - There is a consensus that frequent changes to acoustic bandwidth results in a disturbing / unpleasant listening experience. - There is consensus that it is ok to reduce the acoustic bandwidths at lower bitrates, - There is consensus that 48 kHz (fullband) operation is a requirement. - There is no consensus (as of yet) as to how many or which sampling rates we need for the "internal codec", including no consensus that we need more than one. It is important to note that no one has objected to multiple sample rates either. Though it has been observed that multiple sample rates makes compressed domain mixing problematic. -- Ticket URL: codec From trac@tools.ietf.org Wed Apr 21 02:38:49 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A0B5C3A6A70 for ; Wed, 21 Apr 2010 02:38:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.531 X-Spam-Level: X-Spam-Status: No, score=-102.531 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0X96yilnmXvp for ; Wed, 21 Apr 2010 02:38:49 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 637EE3A659C for ; Wed, 21 Apr 2010 02:38:48 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4WOD-0007lV-FC; Wed, 21 Apr 2010 02:38:37 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: mknappe@juniper.net, hoene@uni-tuebingen.de X-Trac-Project: codec Date: Wed, 21 Apr 2010 09:38:37 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/codec/trac/ticket/4#comment:2 Message-ID: <071.f156f66ef5bd3390f4e9a784c4d3c152@tools.ietf.org> References: <062.4d96e1ea7b54b22a7110b0760f29dc5d@tools.ietf.org> X-Trac-Ticket-ID: 4 In-Reply-To: <062.4d96e1ea7b54b22a7110b0760f29dc5d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: mknappe@juniper.net, hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #4: Remove the word "wideband" from the WG title. X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 09:38:49 -0000 #4: Remove the word "wideband" from the WG title. ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: mknappe@… Type: defect | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: - | Keywords: ------------------------------------+--------------------------------------- Changes (by hoene@…): * owner: => mknappe@… -- Ticket URL: codec From trac@tools.ietf.org Wed Apr 21 02:42:41 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B48093A6827 for ; Wed, 21 Apr 2010 02:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFB+D1cZoBqj for ; Wed, 21 Apr 2010 02:42:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0C1843A67AB for ; Wed, 21 Apr 2010 02:42:37 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4WRw-0007uC-4M; Wed, 21 Apr 2010 02:42:28 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Wed, 21 Apr 2010 09:42:28 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/16 Message-ID: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> X-Trac-Ticket-ID: 16 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 09:42:41 -0000 #16: Multicast? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- The question arrose whether the interactive CODEC MUST support multicast in addition to teleconferencing. On 04/13/2010 11:35 AM, Christian Hoene wrote: >>> P.S. On the same note, does anybody here cares about using this >>> CODEC with multicast? Is there a single commercial multicast voice deployment? >>> From what I've seen all multicast does is making IETF voice >>> standards harder to understand or implement. >> >> I think that would be a mistake to ignore multicast - not because of >> multicast itself, but because of Xcast (RFC 5058) which is a >> promising technology to replace centralized conference bridges. > > Regarding multicast: > > I think we shall start at user requirements and scenarios. > Teleconference (including mono or spatial audio) might be good > starting point. Virtual environments like second live would require multicast communication, too. If the requirements of these scenarios are well understand, we can start to talk about potential solutions like IP multicast, Xcast or conference bridges. > -- Ticket URL: codec From trac@tools.ietf.org Wed Apr 21 02:49:01 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 842553A6890 for ; Wed, 21 Apr 2010 02:49:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U0RBsi5+dD+3 for ; Wed, 21 Apr 2010 02:49:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6A0D13A6A7A for ; Wed, 21 Apr 2010 02:48:58 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4WY5-0001Ue-GX; Wed, 21 Apr 2010 02:48:49 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Wed, 21 Apr 2010 09:48:49 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/17 Message-ID: <062.4d06e5df10a25734771c5c65c2b40c5c@tools.ietf.org> X-Trac-Ticket-ID: 17 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: [codec] #17: Feedback and control loop? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 09:49:01 -0000 #17: Feedback and control loop? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: new Priority: minor | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- On 04/13/2010 11:35 AM, Christian Hoene wrote: > > The other thing that will get difficult is to support rate control and > feedback loops. Especially, the feedback mechanism of RTCP are not > very good. It has every high overhead and it is allowed only every 5s. That is be fine with multicast, but in case of interactive scenarios (and potential feedback loops within a bidirectional codec) a bit of overkill and too imprecise. No, with unicast RTP, the minimum is 360 divided by the session bandwidth in kilobits/second (RFC 3550 section 6.2), with the first RTCP packet sent immediately. Even for multicast the value can be reduced for active senders. RTP/(S)AVPF can use immediate feedback which seems to be what you need here. COLIN: RTCP provides relatively low-rate feedback suitable for rate adaptation, to avoid persistent congestion, and to provide codec control functions. RTCP can't, in general, provide a fast (per-RTT) feedback loop. If you need such rapid adaptation, you should run RTP over a congestion controlled transport protocol, such as TCP or DCCP, and adjust the sending rate based on the transport layer feedback. BOTZKO: (b) Feedback - messages related to QOS, packet loss, etc are what I mean by this. This should be done in RTCP, though given the lack of VOIP support perhaps there should be a SIP INFO backup path. Feedback should not be done with RTP. (c) Control - Per RFC 3551, RTCP can be used for "loosely controlled" sessions, but "may be fully or partially subsumed by a separate session control protocol". Given the statements on RTCP support in the VOIP infrastructure, we should be careful about putting unique controls in RTCP. However, it should not be done in RTP. Since most other audio codecs don't require this stuff, I suspect we won't either. Though we will see... SHPOUNT: RTCP is almost universally not implemented. The biggest VoIP gateway on the market does not generate RTCP. If we will rely on any RTCP functionality for bandwidth control it will probably be ignored. -- Ticket URL: codec From trac@tools.ietf.org Wed Apr 21 02:54:42 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BD393A6B22 for ; Wed, 21 Apr 2010 02:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVj-ivyT9aaC for ; Wed, 21 Apr 2010 02:54:42 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id DAC643A6B2D for ; Wed, 21 Apr 2010 02:54:34 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O4WdW-0001a7-0E; Wed, 21 Apr 2010 02:54:26 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Wed, 21 Apr 2010 09:54:25 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/13#comment:1 Message-ID: <071.5e023ebb9f76cbef6eb8421c4bc0c385@tools.ietf.org> References: <062.407382d901e5e6b8dea15d6e3ae1a2c8@tools.ietf.org> X-Trac-Ticket-ID: 13 In-Reply-To: <062.407382d901e5e6b8dea15d6e3ae1a2c8@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #13: reference use-cases and topologies! X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: trac@localhost.amsl.com List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 09:54:42 -0000 #13: reference use-cases and topologies! ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+--------------------------------------- Comment(by hoene@…): The current draft http://tools.ietf.org/id/draft-ietf-codec-requirements-00.txt mentions: 2. Applications The following applications should be considered for Internet audio codecs, along with their requirements: o Point to point calls o Conferencing o Telepresence o Teleoperation o In-game voice chat o Live distributed music performances / Internet music lessons o Other applications -- Ticket URL: codec From hoene@uni-tuebingen.de Wed Apr 21 03:09:28 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F08628C0E7 for ; Wed, 21 Apr 2010 03:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.07 X-Spam-Level: X-Spam-Status: No, score=-1.07 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IoaPS4Y+HwKV for ; Wed, 21 Apr 2010 03:09:27 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id A93283A6A70 for ; Wed, 21 Apr 2010 03:09:26 -0700 (PDT) Received: from hoeneT60 ([82.113.106.221]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o3LA95p4026792 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 21 Apr 2010 12:09:13 +0200 From: "Christian Hoene" To: References: <062.407382d901e5e6b8dea15d6e3ae1a2c8@tools.ietf.org> <071.5e023ebb9f76cbef6eb8421c4bc0c385@tools.ietf.org> In-Reply-To: <071.5e023ebb9f76cbef6eb8421c4bc0c385@tools.ietf.org> Date: Wed, 21 Apr 2010 12:09:02 +0200 Message-ID: <002001cae13a$b0f290c0$12d7b240$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrhOKZsXYXf9oe/TrGNk6AZJJBbTAAAKKsg Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Subject: Re: [codec] #13: reference use-cases and topologies! X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 10:09:28 -0000 Hello all, this topic is of primal importance. Are all reference use-cases already listed in the requirements-draft? = Currently, "Point to point calls, Conferencing, Telepresence, Teleoperation, = In-game voice chat, Live distributed music performances / Internet music = lessons" are listed. Is this list complete? Is this list order rightly? At least use usages were mentioned previously:=20 a) removing the need for echo cancelation because of ultra-low delay, = when echoes are called side tones... b) Push-to-talk (see below) With are the topologies under study? a) IPend-to-IPend? b) IPend-to-transcoding_gateway-to-PSTNend? c) n to n (decentralized conferencing) e) IPend-to-legal_interception-to-X What is important, what is missing? Christian PS: "Scenario: Push-to-talk like service (PTT) In spite of the development of broadband access (xDSL), a lot of users = would only have service access via PSTN modems or mobile links. Also, on = these links the available bandwidth might be shared among multiple flows = and is subjected to congestion. Then, even low coding rates at about 8 = kbps are too high. If transmission capacity hardly exists, one still can degrade the = quality of a telephone call to something like a push-to-talk (PTT) like = service having very high latencies. Technically, this scenario takes = advantage of bandwidth gains due to disruptive transmission (DTX) modes = and very large packets containing multiple speech frames causing a very = low packetization overhead." --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=C3=BCbingen=20 Sand 13, 72076 T=C3=BCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ >-----Original Message----- >From: codec issue tracker [mailto:trac@tools.ietf.org] >Sent: Wednesday, April 21, 2010 11:54 AM >To: hoene@uni-tuebingen.de >Cc: codec@ietf.org >Subject: Re: [codec] #13: reference use-cases and topologies! > >#13: reference use-cases and topologies! >------------------------------------+-----------------------------------= ---- > Reporter: hoene@=E2=80=A6 | Owner: > Type: defect | Status: new > Priority: critical | Milestone: >Component: requirements | Version: > Severity: Active WG Document | Keywords: >------------------------------------+-----------------------------------= ---- > >Comment(by hoene@=E2=80=A6): > > The current draft > http://tools.ietf.org/id/draft-ietf-codec-requirements-00.txt > mentions: > > 2. Applications > > The following applications should be considered for Internet audio > codecs, along with their requirements: > > o Point to point calls > > o Conferencing > > o Telepresence > > o Teleoperation > > o In-game voice chat > > o Live distributed music performances / Internet music lessons > > o Other applications > >-- >Ticket URL: = >codec From csp@csperkins.org Wed Apr 21 03:48:35 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959413A69FF for ; Wed, 21 Apr 2010 03:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.274 X-Spam-Level: X-Spam-Status: No, score=-3.274 tagged_above=-999 required=5 tests=[AWL=0.325, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NbsSTYneyfaa for ; Wed, 21 Apr 2010 03:48:34 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by core3.amsl.com (Postfix) with ESMTP id 839D33A694C for ; Wed, 21 Apr 2010 03:48:34 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1O4XTk-0001sf-j4; Wed, 21 Apr 2010 10:48:25 +0000 Message-Id: <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> From: Colin Perkins To: codec@ietf.org In-Reply-To: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Apr 2010 11:48:24 +0100 References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> X-Mailer: Apple Mail (2.936) Cc: trac@tools.ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 10:48:35 -0000 On 21 Apr 2010, at 10:42, codec issue tracker wrote: > #16: Multicast? > ------------------------------------=20 > +---------------------------------- > Reporter: hoene@=85 | Owner: > Type: enhancement | Status: new > Priority: trivial | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Keywords: > ------------------------------------=20 > +---------------------------------- > The question arrose whether the interactive CODEC MUST support =20 > multicast in addition to teleconferencing. > > On 04/13/2010 11:35 AM, Christian Hoene wrote: >>>> P.S. On the same note, does anybody here cares about using this =20 >>>> CODEC with multicast? Is there a single commercial multicast =20 >>>> voice deployment? =46rom what I've seen all multicast does is =20 >>>> making IETF voice standards harder to understand or implement. >>> >>> I think that would be a mistake to ignore multicast - not because =20= >>> of multicast itself, but because of Xcast (RFC 5058) which is a =20 >>> promising technology to replace centralized conference bridges. >> >> Regarding multicast: >> >> I think we shall start at user requirements and scenarios. =20 >> Teleconference (including mono or spatial audio) might be good =20 >> starting point. Virtual environments like second live would require =20= >> multicast communication, too. If the requirements of these =20 >> scenarios are well understand, we can start to talk about potential =20= >> solutions like IP multicast, Xcast or conference bridges. RTP is inherently a group communication protocol, and any codec =20 designed for use with RTP should consider operation in various =20 different types of group communication scenario (not just multicast). =20= RFC 5117 is a good place to start when considering the different types =20= of topology in which RTP is used, and the possible placement of mixing =20= and switching functions which the codec will need to work with. --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Wed Apr 21 03:58:00 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64A823A6B49 for ; Wed, 21 Apr 2010 03:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.382 X-Spam-Level: X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxdjkqbTvr9C for ; Wed, 21 Apr 2010 03:57:59 -0700 (PDT) Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by core3.amsl.com (Postfix) with ESMTP id 3BA5B3A694C for ; Wed, 21 Apr 2010 03:57:59 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1O4XcN-0005l1-fE; Wed, 21 Apr 2010 10:57:49 +0000 Message-Id: <83E16843-6B66-4C04-A3E2-E3DAD0FB704F@csperkins.org> From: Colin Perkins To: codec@ietf.org In-Reply-To: <062.4d06e5df10a25734771c5c65c2b40c5c@tools.ietf.org> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Apr 2010 11:57:18 +0100 References: <062.4d06e5df10a25734771c5c65c2b40c5c@tools.ietf.org> X-Mailer: Apple Mail (2.936) Cc: trac@tools.ietf.org Subject: Re: [codec] #17: Feedback and control loop? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 10:58:00 -0000 On 21 Apr 2010, at 10:48, codec issue tracker wrote: > #17: Feedback and control loop? > ------------------------------------=20 > +---------------------------------- > Reporter: hoene@=85 | Owner: > Type: enhancement | Status: new > Priority: minor | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Keywords: > ------------------------------------=20 > +---------------------------------- > On 04/13/2010 11:35 AM, Christian Hoene wrote: >> >> The other thing that will get difficult is to support rate control =20= >> and feedback loops. Especially, the feedback mechanism of RTCP are =20= >> not very good. It has every high overhead and it is allowed only =20 >> every 5s. > That is be fine with multicast, but in case of interactive scenarios =20= > (and potential feedback loops within a bidirectional codec) a bit of =20= > overkill and too imprecise. > > No, with unicast RTP, the minimum is 360 divided by the session =20 > bandwidth in kilobits/second (RFC 3550 section 6.2), with the first =20= > RTCP packet sent immediately. Even for multicast the value can be =20 > reduced for active senders. > > RTP/(S)AVPF can use immediate feedback which seems to be what you need > here. > > COLIN: RTCP provides relatively low-rate feedback suitable for rate =20= > adaptation, to avoid persistent congestion, and to provide codec =20 > control functions. RTCP can't, in general, provide a fast (per-RTT) =20= > feedback loop. If you need such rapid adaptation, you should run RTP =20= > over a congestion controlled transport protocol, such as TCP or =20 > DCCP, and adjust the sending rate based on the transport layer =20 > feedback. > > BOTZKO: (b) Feedback - messages related to QOS, packet loss, etc are =20= > what I mean by this. This should be done in RTCP, though given the =20= > lack of VOIP support perhaps there should be a SIP INFO backup =20 > path. Feedback should not be done with RTP. > (c) Control - Per RFC 3551, RTCP can be used for "loosely =20 > controlled" sessions, but "may be fully or partially subsumed by a =20 > separate session control protocol". Given the statements on RTCP =20 > support in the VOIP infrastructure, we should be careful about =20 > putting unique controls in RTCP. However, it should not be done in =20= > RTP. Since most other audio codecs don't require this stuff, I =20 > suspect we won't either. Though we will see... > > SHPOUNT: RTCP is almost universally not implemented. The biggest =20 > VoIP gateway on the market does not generate RTCP. If we will rely =20 > on any RTCP functionality for bandwidth control it will probably be =20= > ignored. My suggestion would be that you specify how the codec can adapt based =20= on the feedback that RTP/RTCP, and its various extensions, can =20 provide. More on the style of "if you have this information, this is =20 how you can adapt" than "you must use this information to adapt in =20 this way". --=20 Colin Perkins http://csperkins.org/ From csp@csperkins.org Wed Apr 21 03:58:20 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E9D13A6B4F for ; Wed, 21 Apr 2010 03:58:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.113 X-Spam-Level: X-Spam-Status: No, score=-3.113 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qdKNlcsku0I for ; Wed, 21 Apr 2010 03:58:20 -0700 (PDT) Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by core3.amsl.com (Postfix) with ESMTP id D403F3A694C for ; Wed, 21 Apr 2010 03:58:19 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1O4XdC-0005l1-e5; Wed, 21 Apr 2010 10:58:10 +0000 Message-Id: <41CEDB08-3A9E-44E4-9E45-CCC4A43FE8A6@csperkins.org> From: Colin Perkins To: codec@ietf.org In-Reply-To: <071.5e023ebb9f76cbef6eb8421c4bc0c385@tools.ietf.org> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Apr 2010 11:58:10 +0100 References: <062.407382d901e5e6b8dea15d6e3ae1a2c8@tools.ietf.org> <071.5e023ebb9f76cbef6eb8421c4bc0c385@tools.ietf.org> X-Mailer: Apple Mail (2.936) Cc: trac@tools.ietf.org Subject: Re: [codec] #13: reference use-cases and topologies! X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 10:58:20 -0000 On 21 Apr 2010, at 10:54, codec issue tracker wrote: > #13: reference use-cases and topologies! > ------------------------------------=20 > +---------------------------------- > Reporter: hoene@=85 | Owner: > Type: defect | Status: new > Priority: critical | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Keywords: > ------------------------------------=20 > +---------------------------------- > > Comment(by hoene@=85): > > The current draft > http://tools.ietf.org/id/draft-ietf-codec-requirements-00.txt > mentions: > > 2. Applications > > The following applications should be considered for Internet audio > codecs, along with their requirements: > > o Point to point calls > > o Conferencing > > o Telepresence > > o Teleoperation > > o In-game voice chat > > o Live distributed music performances / Internet music lessons > > o Other applications > See RFC 5117. --=20 Colin Perkins http://csperkins.org/ From hoene@uni-tuebingen.de Wed Apr 21 04:14:35 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C99FC3A68A2 for ; Wed, 21 Apr 2010 04:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.07 X-Spam-Level: X-Spam-Status: No, score=-1.07 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_BL_SPAMCOP_NET=1.96, RCVD_IN_DNSWL_MED=-4, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7EZ8JTJe-hg1 for ; Wed, 21 Apr 2010 04:14:34 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 7C37D3A6837 for ; Wed, 21 Apr 2010 04:14:26 -0700 (PDT) Received: from hoeneT60 ([82.113.106.218]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o3LBE6j2023381 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Apr 2010 13:14:13 +0200 From: "Christian Hoene" To: "'Colin Perkins'" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> In-Reply-To: <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> Date: Wed, 21 Apr 2010 13:14:04 +0200 Message-ID: <000401cae143$c57e07f0$507a17d0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrhQDSX8E/sGIYWS4+R2a+xsPWWvwAAMEhw Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.220; VDF: 7.10.6.147; host: mx05); id=20827-zrh0Yx Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 11:14:35 -0000 Hi, >On 21 Apr 2010, at 10:42, codec issue tracker wrote: >> #16: Multicast? >> ------------------------------------ >> +---------------------------------- >> Reporter: hoene@. | Owner: >> Type: enhancement | Status: new >> Priority: trivial | Milestone: >> Component: requirements | Version: >> Severity: Active WG Document | Keywords: >> ------------------------------------ >> +---------------------------------- >> The question arrose whether the interactive CODEC MUST support >> multicast in addition to teleconferencing. >> >> On 04/13/2010 11:35 AM, Christian Hoene wrote: >>>>> P.S. On the same note, does anybody here cares about using this >>>>> CODEC with multicast? Is there a single commercial multicast >>>>> voice deployment? From what I've seen all multicast does is >>>>> making IETF voice standards harder to understand or implement. >>>> >>>> I think that would be a mistake to ignore multicast - not because >>>> of multicast itself, but because of Xcast (RFC 5058) which is a >>>> promising technology to replace centralized conference bridges. >>> >>> Regarding multicast: >>> >>> I think we shall start at user requirements and scenarios. >>> Teleconference (including mono or spatial audio) might be good >>> starting point. Virtual environments like second live would require >>> multicast communication, too. If the requirements of these >>> scenarios are well understand, we can start to talk about potential >>> solutions like IP multicast, Xcast or conference bridges. > > >RTP is inherently a group communication protocol, and any codec >designed for use with RTP should consider operation in various >different types of group communication scenario (not just multicast). >RFC 5117 is a good place to start when considering the different types >of topology in which RTP is used, and the possible placement of mixing >and switching functions which the codec will need to work with. I have to admit that my thinking is complete different. I first start with user requirements, then look how to achieve them, and finally consider on how to map them on existing standards - not the other way around. Users do demand for teleconferencing, preferable at high quality (good spatial audio quality, low acoustic latency and reliable). Thus, this is a MUST requirement. I believe that multicast support NEEDS NOT to be particular optimized due to the following two reasons: a) RFC5117: 4.1.3. Per Domain Bit-Rate Adaptation Participants are most likely to be connected to each other with a heterogeneous set of paths. This makes congestion control in a Point to Multipoint set problematic. For the ASM and "relay" scenario, each individual sender has to adapt to the receiver with the least capable path. This is no longer necessary when Media Translators, Mixers, or MCUs are involved, as each participant only needs to adapt to the slowest path within its own domain. The Translator, Mixer, or MCU topologies all require their respective outgoing streams to adjust the bit-rate, packet-rate, etc., to adapt to the least capable path in each of the other domains. That way one can avoid lowering the quality to the least-capable participant in all the domains at the cost (complexity, delay, equipment) of the Mixer or Translator. Indeed, the CODEC SHOULD be adapted on each path to achieve best quality. b) Multicast is used (to my best knowledge) mainly locally and not throughout the Internet, thus if we want to support global interactive communication with a good CODEC support of MULTICAST cannot be considered as granted. Yours respectfully, Christian >-- >Colin Perkins >http://csperkins.org/ > > > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From tme@americafree.tv Wed Apr 21 04:20:46 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B357B3A6973 for ; Wed, 21 Apr 2010 04:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.057 X-Spam-Level: X-Spam-Status: No, score=-102.057 tagged_above=-999 required=5 tests=[AWL=0.542, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4b0cXzm8yyLc for ; Wed, 21 Apr 2010 04:20:40 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 6E0933A6AA0 for ; Wed, 21 Apr 2010 04:20:31 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id E71E46B5295A; Wed, 21 Apr 2010 07:20:11 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Colin Perkins In-Reply-To: <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Apr 2010 07:20:11 -0400 References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> X-Mailer: Apple Mail (2.936) Cc: trac@tools.ietf.org, codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 11:20:46 -0000 On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote: > On 21 Apr 2010, at 10:42, codec issue tracker wrote: >> #16: Multicast? >> ------------------------------------=20 >> +---------------------------------- >> Reporter: hoene@=85 | Owner: >> Type: enhancement | Status: new >> Priority: trivial | Milestone: >> Component: requirements | Version: >> Severity: Active WG Document | Keywords: >> ------------------------------------=20 >> +---------------------------------- >> The question arrose whether the interactive CODEC MUST support =20 >> multicast in addition to teleconferencing. >> >> On 04/13/2010 11:35 AM, Christian Hoene wrote: >>>>> P.S. On the same note, does anybody here cares about using this =20= >>>>> CODEC with multicast? Is there a single commercial multicast =20 >>>>> voice deployment? =46rom what I've seen all multicast does is =20 >>>>> making IETF voice standards harder to understand or implement. >>>> >>>> I think that would be a mistake to ignore multicast - not because =20= >>>> of multicast itself, but because of Xcast (RFC 5058) which is a =20 >>>> promising technology to replace centralized conference bridges. >>> >>> Regarding multicast: >>> >>> I think we shall start at user requirements and scenarios. =20 >>> Teleconference (including mono or spatial audio) might be good =20 >>> starting point. Virtual environments like second live would =20 >>> require multicast communication, too. If the requirements of these =20= >>> scenarios are well understand, we can start to talk about =20 >>> potential solutions like IP multicast, Xcast or conference bridges. > > > RTP is inherently a group communication protocol, and any codec =20 > designed for use with RTP should consider operation in various =20 > different types of group communication scenario (not just =20 > multicast). RFC 5117 is a good place to start when considering the =20 > different types of topology in which RTP is used, and the possible =20 > placement of mixing and switching functions which the codec will =20 > need to work with. > It is not clear to me what supporting multicast would entail here. If =20= this is a codec over RTP, then what is to stop it from being multicast ? Regards Marshall > --=20 > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From stephen.botzko@gmail.com Wed Apr 21 04:48:37 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4388C3A6B7F for ; Wed, 21 Apr 2010 04:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-ICnBJevoeg for ; Wed, 21 Apr 2010 04:48:35 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 87F6F3A695A for ; Wed, 21 Apr 2010 04:48:35 -0700 (PDT) Received: by gwaa12 with SMTP id a12so331553gwa.31 for ; Wed, 21 Apr 2010 04:48:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=zEPzGpARklXXBrv21R9cvGi5iTmqTeDFtpMLFMCPTNI=; b=L8IcHbEqe3mTx3zkxLQnOGgalYIA/GUvfvxuPKXmdAP9SfecfJYp+khfpQ9gCDbEcw QJ8O8Y6C1S+VfL7BM/wVbtiRWPZfZsP2ouzhVTa/8t87n3YbEtnRip6clA7gST1rqsc/ lC9drXCKci53CEFtf/uTpAduOv+/2JYKsiwQo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=MU7Ieu3b4YEVHL88fQHaziib1nfEfC5m4KInKDjvdalVLkrYn2lxRXp7OwZDpo9t7Y /6PFznZUAJqlERjCty5oV2r+3v/ENBDX2OdVKtHKn7NKqGRSP0BcghBbwKKgM1Do2ZMT OLM3N4NsbHvKhPblsytm3dCreWuoxNx9GnMf8= MIME-Version: 1.0 Received: by 10.231.79.213 with HTTP; Wed, 21 Apr 2010 04:48:21 -0700 (PDT) In-Reply-To: <000401cae143$c57e07f0$507a17d0$@de> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000401cae143$c57e07f0$507a17d0$@de> Date: Wed, 21 Apr 2010 07:48:21 -0400 Received: by 10.101.149.20 with SMTP id b20mr5014406ano.102.1271850502438; Wed, 21 Apr 2010 04:48:22 -0700 (PDT) Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=0016e68deca967d6de0484bdc5ed Cc: codec@ietf.org, Colin Perkins Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 11:48:37 -0000 --0016e68deca967d6de0484bdc5ed Content-Type: text/plain; charset=ISO-8859-1 Hi Christian Teleconferencing standards (both in the ITU-T and the IETF) support multicast.. It would be awkward if the codec decision was somehow coupled to the transport, and (IMHO) architecturally wrong. While it is probably true that multicast is more likely to be used on enterprise networks, I don't see that as terribly relevant. I see no technical reason to NEED NOT multicast. Regards, Stephen Botzko On Wed, Apr 21, 2010 at 7:14 AM, Christian Hoene wrote: > Hi, > > >On 21 Apr 2010, at 10:42, codec issue tracker wrote: > >> #16: Multicast? > >> ------------------------------------ > >> +---------------------------------- > >> Reporter: hoene@. | Owner: > >> Type: enhancement | Status: new > >> Priority: trivial | Milestone: > >> Component: requirements | Version: > >> Severity: Active WG Document | Keywords: > >> ------------------------------------ > >> +---------------------------------- > >> The question arrose whether the interactive CODEC MUST support > >> multicast in addition to teleconferencing. > >> > >> On 04/13/2010 11:35 AM, Christian Hoene wrote: > >>>>> P.S. On the same note, does anybody here cares about using this > >>>>> CODEC with multicast? Is there a single commercial multicast > >>>>> voice deployment? From what I've seen all multicast does is > >>>>> making IETF voice standards harder to understand or implement. > >>>> > >>>> I think that would be a mistake to ignore multicast - not because > >>>> of multicast itself, but because of Xcast (RFC 5058) which is a > >>>> promising technology to replace centralized conference bridges. > >>> > >>> Regarding multicast: > >>> > >>> I think we shall start at user requirements and scenarios. > >>> Teleconference (including mono or spatial audio) might be good > >>> starting point. Virtual environments like second live would require > >>> multicast communication, too. If the requirements of these > >>> scenarios are well understand, we can start to talk about potential > >>> solutions like IP multicast, Xcast or conference bridges. > > > > > >RTP is inherently a group communication protocol, and any codec > >designed for use with RTP should consider operation in various > >different types of group communication scenario (not just multicast). > >RFC 5117 is a good place to start when considering the different types > >of topology in which RTP is used, and the possible placement of mixing > >and switching functions which the codec will need to work with. > > I have to admit that my thinking is complete different. I first start with > user requirements, then look how to achieve them, and > finally consider on how to map them on existing standards - not the other > way around. > > Users do demand for teleconferencing, preferable at high quality (good > spatial audio quality, low acoustic latency and reliable). > Thus, this is a MUST requirement. > > I believe that multicast support NEEDS NOT to be particular optimized due > to the following two reasons: > > a) RFC5117: 4.1.3. Per Domain Bit-Rate Adaptation > > Participants are most likely to be connected to each other with a > heterogeneous set of paths. This makes congestion control in a Point > to Multipoint set problematic. For the ASM and "relay" scenario, > each individual sender has to adapt to the receiver with the least > capable path. This is no longer necessary when Media Translators, > Mixers, or MCUs are involved, as each participant only needs to adapt > to the slowest path within its own domain. The Translator, Mixer, or > MCU topologies all require their respective outgoing streams to > adjust the bit-rate, packet-rate, etc., to adapt to the least capable > path in each of the other domains. That way one can avoid lowering > the quality to the least-capable participant in all the domains at > the cost (complexity, delay, equipment) of the Mixer or Translator. > > Indeed, the CODEC SHOULD be adapted on each path to achieve best quality. > > b) Multicast is used (to my best knowledge) mainly locally and not > throughout the Internet, thus if we want to support global > interactive communication with a good CODEC support of MULTICAST cannot be > considered as granted. > > Yours respectfully, > > Christian > > >-- > >Colin Perkins > >http://csperkins.org/ > > > > > > > >_______________________________________________ > >codec mailing list > >codec@ietf.org > >https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016e68deca967d6de0484bdc5ed Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Christian

Teleconferencing standards (both in the ITU-T and the I= ETF) support multicast..=A0 It would be awkward if the codec decision was s= omehow coupled to the transport, and (IMHO) architecturally wrong.

While it is probably true that multicast is more likely to be used on enter= prise networks, I don't see that as terribly relevant.

I see no = technical reason to NEED NOT multicast.

Regards,
Stephen Botzko<= br>
On Wed, Apr 21, 2010 at 7:14 AM, Christian H= oene <hoene@= uni-tuebingen.de> wrote:
Hi,

>On 21 Apr 2010, at 10:42, codec issue tracker wrote:
>> #16: Multicast?
>> ------------------------------------
>> +----------------------------------
>> Reporter: =A0hoene@. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0= Owner:
>> =A0 =A0Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0S= tatus: =A0new
>> Priority: =A0trivial =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milesto= ne:
>> Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Versio= n:
>> Severity: =A0Active WG Document =A0 =A0 =A0| =A0 =A0Keywords:
>> ------------------------------------
>> +----------------------------------
>> The question arrose whether the interactive CODEC MUST support
>> multicast in addition to teleconferencing.
>>
>> On 04/13/2010 11:35 AM, Christian Hoene wrote:
>>>>> P.S. On the same note, does anybody here cares about u= sing this
>>>>> CODEC with multicast? Is there a single commercial mul= ticast
>>>>> voice deployment? From what I've seen all multicas= t does is
>>>>> making IETF voice standards harder to understand or im= plement.
>>>>
>>>> I think that would be a mistake to ignore multicast - not = because
>>>> of multicast itself, but because of Xcast (RFC 5058) which= is a
>>>> promising technology to replace centralized conference bri= dges.
>>>
>>> Regarding multicast:
>>>
>>> I think we shall start at user requirements and scenarios.
>>> Teleconference (including mono or spatial audio) might be good=
>>> starting point. Virtual environments like second live would re= quire
>>> multicast communication, too. If the requirements of these
>>> scenarios are well understand, we can start to talk about pote= ntial
>>> solutions like IP multicast, Xcast or conference bridges.
>
>
>RTP is inherently a group communication protocol, and any codec
>designed for use with RTP should consider operation in various
>different types of group communication scenario (not just multicast). >RFC 5117 is a good place to start when considering the different types<= br> >of topology in which RTP is used, and the possible placement of mixing<= br> >and switching functions which the codec will need to work with.

I have to admit that my thinking is complete different. I first= start with user requirements, then look how to achieve them, and
finally consider on how to map them on existing standards - not the other w= ay around.

Users do demand for teleconferencing, preferable at high quality (good spat= ial audio quality, low acoustic latency and reliable).
Thus, this is a MUST requirement.

I believe that multicast support NEEDS NOT to be particular optimized due t= o the following two reasons:

a) RFC5117: 4.1.3. =A0Per Domain Bit-Rate Adaptation

=A0 Participants are most likely to be connected to each other with a
=A0 heterogeneous set of paths. =A0This makes congestion control in a Poin= t
=A0 to Multipoint set problematic. =A0For the ASM and "relay" sc= enario,
=A0 each individual sender has to adapt to the receiver with the least
=A0 capable path. =A0This is no longer necessary when Media Translators, =A0 Mixers, or MCUs are involved, as each participant only needs to adapt<= br> =A0 to the slowest path within its own domain. =A0The Translator, Mixer, o= r
=A0 MCU topologies all require their respective outgoing streams to
=A0 adjust the bit-rate, packet-rate, etc., to adapt to the least capable<= br> =A0 path in each of the other domains. =A0That way one can avoid lowering<= br> =A0 the quality to the least-capable participant in all the domains at
=A0 the cost (complexity, delay, equipment) of the Mixer or Translator.
Indeed, the CODEC SHOULD be adapted on each path to achieve best quality.
b) Multicast is used (to my best knowledge) mainly locally and not througho= ut the Internet, thus if we want to support global
interactive communication with a good CODEC support of MULTICAST cannot be = considered as granted.

Yours respectfully,

=A0Christian

>--
>Colin Perkins
>http://csperkins.or= g/
>
>
>
>_______________________________________________
>codec mailing list
>codec@ietf.org
>https://www.ietf.org/mailman/listinfo/codec

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016e68deca967d6de0484bdc5ed-- From csp@csperkins.org Wed Apr 21 05:16:01 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE1A83A6C66 for ; Wed, 21 Apr 2010 05:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.399 X-Spam-Level: X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hMXv-1csU4uZ for ; Wed, 21 Apr 2010 05:16:00 -0700 (PDT) Received: from anchor-msapost-2.mail.demon.net (anchor-msapost-2.mail.demon.net [195.173.77.165]) by core3.amsl.com (Postfix) with ESMTP id 2B7F33A6C67 for ; Wed, 21 Apr 2010 05:13:39 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-2.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1O4Yo5-0004wy-kt; Wed, 21 Apr 2010 12:13:29 +0000 Message-Id: <8C096B53-EDB9-43D5-869A-D9B2AAE174B0@csperkins.org> From: Colin Perkins To: Christian Hoene In-Reply-To: <000401cae143$c57e07f0$507a17d0$@de> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Apr 2010 13:13:28 +0100 References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000401cae143$c57e07f0$507a17d0$@de> X-Mailer: Apple Mail (2.936) Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 12:16:01 -0000 On 21 Apr 2010, at 12:14, Christian Hoene wrote: >> On 21 Apr 2010, at 10:42, codec issue tracker wrote: >>> #16: Multicast? >>> ------------------------------------ >>> +---------------------------------- >>> Reporter: hoene@. | Owner: >>> Type: enhancement | Status: new >>> Priority: trivial | Milestone: >>> Component: requirements | Version: >>> Severity: Active WG Document | Keywords: >>> ------------------------------------ >>> +---------------------------------- >>> The question arrose whether the interactive CODEC MUST support >>> multicast in addition to teleconferencing. >>> >>> On 04/13/2010 11:35 AM, Christian Hoene wrote: >>>>>> P.S. On the same note, does anybody here cares about using this >>>>>> CODEC with multicast? Is there a single commercial multicast >>>>>> voice deployment? From what I've seen all multicast does is >>>>>> making IETF voice standards harder to understand or implement. >>>>> >>>>> I think that would be a mistake to ignore multicast - not because >>>>> of multicast itself, but because of Xcast (RFC 5058) which is a >>>>> promising technology to replace centralized conference bridges. >>>> >>>> Regarding multicast: >>>> >>>> I think we shall start at user requirements and scenarios. >>>> Teleconference (including mono or spatial audio) might be good >>>> starting point. Virtual environments like second live would require >>>> multicast communication, too. If the requirements of these >>>> scenarios are well understand, we can start to talk about potential >>>> solutions like IP multicast, Xcast or conference bridges. >> >> >> RTP is inherently a group communication protocol, and any codec >> designed for use with RTP should consider operation in various >> different types of group communication scenario (not just >> multicast). RFC 5117 is a good place to start when considering the >> different types of topology in which RTP is used, and the possible >> placement of mixing and switching functions which the codec will >> need to work with. > > I have to admit that my thinking is complete different. I first > start with user requirements, then look how to achieve them, and > finally consider on how to map them on existing standards - not the > other way around. > > Users do demand for teleconferencing, preferable at high quality > (good spatial audio quality, low acoustic latency and reliable). > Thus, this is a MUST requirement. > > I believe that multicast support NEEDS NOT to be particular > optimized due to the following two reasons: You'll notice that I said that RTP is a group communication protocol, not explicitly a multicast protocol. Multicast groups are one of many ways in which RTP is used for group communication, but not the only one. > a) RFC5117: 4.1.3. Per Domain Bit-Rate Adaptation > > Participants are most likely to be connected to each other with a > heterogeneous set of paths. This makes congestion control in a > Point > to Multipoint set problematic. For the ASM and "relay" scenario, > each individual sender has to adapt to the receiver with the least > capable path. This is no longer necessary when Media Translators, > Mixers, or MCUs are involved, as each participant only needs to > adapt > to the slowest path within its own domain. The Translator, Mixer, > or > MCU topologies all require their respective outgoing streams to > adjust the bit-rate, packet-rate, etc., to adapt to the least > capable > path in each of the other domains. That way one can avoid lowering > the quality to the least-capable participant in all the domains at > the cost (complexity, delay, equipment) of the Mixer or Translator. > > Indeed, the CODEC SHOULD be adapted on each path to achieve best > quality. > > b) Multicast is used (to my best knowledge) mainly locally and not > throughout the Internet, thus if we want to support global > interactive communication with a good CODEC support of MULTICAST > cannot be considered as granted. No-one said it should be taken for granted. A multicast group is one of the different group communication scenarios where the codec can be used. That there is a multicast group transport is, I would expect, largely irrelevant to the codec design. That such a group results in potentially many audio streams that must be mixed by the end systems, rather than by middleboxes, is probably more relevant. The other topologies discussed in RFC 5117 may require different a trade-off. This group should probably review them, to consider how (if) they affect the codec design. -- Colin Perkins http://csperkins.org/ From csp@csperkins.org Wed Apr 21 05:23:49 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66ECE28C27B for ; Wed, 21 Apr 2010 05:23:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.421 X-Spam-Level: X-Spam-Status: No, score=-3.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SK1u-xwNq7aA for ; Wed, 21 Apr 2010 05:23:46 -0700 (PDT) Received: from anchor-msapost-1.mail.demon.net (anchor-msapost-1.mail.demon.net [195.173.77.164]) by core3.amsl.com (Postfix) with ESMTP id F1B6728C1AB for ; Wed, 21 Apr 2010 05:18:02 -0700 (PDT) Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by anchor-post-1.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1O4YsL-0007Lg-hR; Wed, 21 Apr 2010 12:17:53 +0000 Message-Id: From: Colin Perkins To: Marshall Eubanks In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Apr 2010 13:17:51 +0100 References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> X-Mailer: Apple Mail (2.936) Cc: codec@ietf.org, trac@tools.ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 12:23:49 -0000 On 21 Apr 2010, at 12:20, Marshall Eubanks wrote: > On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote: >> On 21 Apr 2010, at 10:42, codec issue tracker wrote: >>> #16: Multicast? >>> ------------------------------------=20 >>> +---------------------------------- >>> Reporter: hoene@=85 | Owner: >>> Type: enhancement | Status: new >>> Priority: trivial | Milestone: >>> Component: requirements | Version: >>> Severity: Active WG Document | Keywords: >>> ------------------------------------=20 >>> +---------------------------------- >>> The question arrose whether the interactive CODEC MUST support =20 >>> multicast in addition to teleconferencing. >>> >>> On 04/13/2010 11:35 AM, Christian Hoene wrote: >>>>>> P.S. On the same note, does anybody here cares about using this =20= >>>>>> CODEC with multicast? Is there a single commercial multicast =20 >>>>>> voice deployment? =46rom what I've seen all multicast does is =20 >>>>>> making IETF voice standards harder to understand or implement. >>>>> >>>>> I think that would be a mistake to ignore multicast - not =20 >>>>> because of multicast itself, but because of Xcast (RFC 5058) =20 >>>>> which is a promising technology to replace centralized =20 >>>>> conference bridges. >>>> >>>> Regarding multicast: >>>> >>>> I think we shall start at user requirements and scenarios. =20 >>>> Teleconference (including mono or spatial audio) might be good =20 >>>> starting point. Virtual environments like second live would =20 >>>> require multicast communication, too. If the requirements of =20 >>>> these scenarios are well understand, we can start to talk about =20 >>>> potential solutions like IP multicast, Xcast or conference bridges. >> >> >> RTP is inherently a group communication protocol, and any codec =20 >> designed for use with RTP should consider operation in various =20 >> different types of group communication scenario (not just =20 >> multicast). RFC 5117 is a good place to start when considering the =20= >> different types of topology in which RTP is used, and the possible =20= >> placement of mixing and switching functions which the codec will =20 >> need to work with. >> > > It is not clear to me what supporting multicast would entail here. =20 > If this is a codec over RTP, then what is to stop it from being =20 > multicast ? Nothing. However group conferences implemented using multicast require =20= end system mixing of potentially large numbers of active audio =20 streams, whereas those implemented using conference bridges do the =20 mixing in a single central location, and generally suppress all but =20 one speaker. The differences in mixing and the number of simultaneous =20= active streams that might be received potentially affect the design of =20= the codec. --=20 Colin Perkins http://csperkins.org/ From stpeter@stpeter.im Wed Apr 21 07:05:20 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5CCBE28C41C for ; Wed, 21 Apr 2010 07:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.413 X-Spam-Level: X-Spam-Status: No, score=-2.413 tagged_above=-999 required=5 tests=[AWL=0.186, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m9og9i0LqXcC for ; Wed, 21 Apr 2010 07:05:18 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 47FF828C500 for ; Wed, 21 Apr 2010 06:45:24 -0700 (PDT) Received: from squire.local (dsl-140-220.dynamic-dsl.frii.net [216.17.140.220]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 24F8640E15 for ; Wed, 21 Apr 2010 07:45:14 -0600 (MDT) Message-ID: <4BCF0168.7080003@stpeter.im> Date: Wed, 21 Apr 2010 07:45:12 -0600 From: Peter Saint-Andre User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: codec@ietf.org References: <062.407382d901e5e6b8dea15d6e3ae1a2c8@tools.ietf.org> <071.5e023ebb9f76cbef6eb8421c4bc0c385@tools.ietf.org> <002001cae13a$b0f290c0$12d7b240$@de> In-Reply-To: <002001cae13a$b0f290c0$12d7b240$@de> X-Enigmail-Version: 1.0.1 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms000700030405010501040906" Subject: Re: [codec] #13: reference use-cases and topologies! X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 14:05:20 -0000 This is a cryptographically signed message in MIME format. --------------ms000700030405010501040906 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 4/21/10 4:09 AM, Christian Hoene wrote: > Hello all, >=20 > this topic is of primal importance. >=20 > Are all reference use-cases already listed in the requirements-draft? > Currently, "Point to point calls, Conferencing, Telepresence, > Teleoperation, In-game voice chat, Live distributed music > performances / Internet music lessons" are listed. Is this list > complete?=20 The list is illustrative, not complete. > Is this list order rightly? The list has no order. Peter --=20 Peter Saint-Andre https://stpeter.im/ --------------ms000700030405010501040906 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIWnDCC B1cwggY/oAMCAQICAVUwDQYJKoZIhvcNAQEFBQAwgYwxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBT aWduaW5nMTgwNgYDVQQDEy9TdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRl IENsaWVudCBDQTAeFw0wOTA3MDYwMDAwMDFaFw0xMDA3MDYyMzU5NTlaMIHCMQswCQYDVQQG EwJVUzERMA8GA1UECBMIQ29sb3JhZG8xDzANBgNVBAcTBkRlbnZlcjEiMCAGA1UEChMZWE1Q UCBTdGFuZGFyZHMgRm91bmRhdGlvbjEsMCoGA1UECxMjU3RhcnRDb20gVHJ1c3RlZCBDZXJ0 aWZpY2F0ZSBNZW1iZXIxGjAYBgNVBAMTEVBldGVyIFNhaW50LUFuZHJlMSEwHwYJKoZIhvcN AQkBFhJzdHBldGVyQHN0cGV0ZXIuaW0wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIB AQCas7Mrnh02GakN8sft+HJpU4MwBxEgrGDZ2ZzUxDDt2sEhM+9Q74h955MtgMhK3TeBf6Hs hDh/8Z9G//k2qNA0M2S5rejTqrmW0Jabca/L7BUZ0GhnU2N/2zeciFUmuZ4A2l1T5IMX2ZVP XnNIaefBtbImJAbDz3T0vxkzTtcqgW3wL83PMDiqiuM+e1k+VPvOW4f5ZSGkPIhYCDpWqNE5 wZvjrLNMc8jZOPs9DrsYuIVwU72Vhy1tkEh+w6YpYHrdEUAe+eKe6TuxqZ60e9z3O36uiV// Ms274iD6PbA/IGazJgaAdg6tvPehwTYGJAGmv3PsJKkLGjgoh+RrrM1LAgMBAAGjggOKMIID hjAJBgNVHRMEAjAAMAsGA1UdDwQEAwIEsDAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwHQYDVR0OBBYEFOyws3XWgIY9FP1POVqjdZP9Lu38MB0GA1UdEQQWMBSBEnN0cGV0ZXJA c3RwZXRlci5pbTCBqAYDVR0jBIGgMIGdgBR7iZySlyShhEcCy3T8LvSs3DLl86GBgaR/MH0x CzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUg RGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZp Y2F0aW9uIEF1dGhvcml0eYIBDzCCAUcGA1UdIASCAT4wggE6MIIBNgYLKwYBBAGBtTcBAgAw ggElMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQG CCsGAQUFBwIBFihodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMIG8 BggrBgEFBQcCAjCBrzAUFg1TdGFydENvbSBMdGQuMAMCAQEagZZMaW1pdGVkIExpYWJpbGl0 eSwgcmVhZCB0aGUgc2VjdGlvbiAqTGVnYWwgTGltaXRhdGlvbnMqIG9mIHRoZSBTdGFydENv bSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSBQb2xpY3kgYXZhaWxhYmxlIGF0IGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwYwYDVR0fBFwwWjAroCmgJ4YlaHR0cDovL3d3 dy5zdGFydHNzbC5jb20vY3J0dTMtY3JsLmNybDAroCmgJ4YlaHR0cDovL2NybC5zdGFydHNz bC5jb20vY3J0dTMtY3JsLmNybDCBjgYIKwYBBQUHAQEEgYEwfzA5BggrBgEFBQcwAYYtaHR0 cDovL29jc3Auc3RhcnRzc2wuY29tL3N1Yi9jbGFzczMvY2xpZW50L2NhMEIGCCsGAQUFBzAC hjZodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9jZXJ0cy9zdWIuY2xhc3MzLmNsaWVudC5jYS5j cnQwIwYDVR0SBBwwGoYYaHR0cDovL3d3dy5zdGFydHNzbC5jb20vMA0GCSqGSIb3DQEBBQUA A4IBAQBgv4xFXZqDKSOtnPOVbqOh1brj7oxRaVYk7N0MJG7x9Y/wkO3iwRwizVLcC1bA+D/R gyFilXx6IQWE63Ge2tu+Y4w5QoHYwuUFQuBZuxvZpOa3ykdgPlBQaBM8m+Ien0skwNggaizA X9Pc/sMLpP3jkO1iSF4agy4r5Ed+4G10mP5X0zO3gQwq9Uj4F9tX+58kU+fM1P8Sh+BYR4r/ kSbKE3tWcMaKblWPGwX0nYD26Je7Qb+uX/J5lCgozBrHXQWq8N98iklASf2pv+32Oi1dEjmM UgAm/J2+YmxaI02+c+H6QH8+F3RUjCiRg9XqUNjcrNrnTFnm/iMMZADktsXPMIIHVzCCBj+g AwIBAgIBVTANBgkqhkiG9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBMB4XDTA5MDcwNjAwMDAwMVoXDTEwMDcwNjIzNTk1OVowgcIxCzAJBgNVBAYTAlVTMREw DwYDVQQIEwhDb2xvcmFkbzEPMA0GA1UEBxMGRGVudmVyMSIwIAYDVQQKExlYTVBQIFN0YW5k YXJkcyBGb3VuZGF0aW9uMSwwKgYDVQQLEyNTdGFydENvbSBUcnVzdGVkIENlcnRpZmljYXRl IE1lbWJlcjEaMBgGA1UEAxMRUGV0ZXIgU2FpbnQtQW5kcmUxITAfBgkqhkiG9w0BCQEWEnN0 cGV0ZXJAc3RwZXRlci5pbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJqzsyue HTYZqQ3yx+34cmlTgzAHESCsYNnZnNTEMO3awSEz71DviH3nky2AyErdN4F/oeyEOH/xn0b/ +Tao0DQzZLmt6NOquZbQlptxr8vsFRnQaGdTY3/bN5yIVSa5ngDaXVPkgxfZlU9ec0hp58G1 siYkBsPPdPS/GTNO1yqBbfAvzc8wOKqK4z57WT5U+85bh/llIaQ8iFgIOlao0TnBm+Oss0xz yNk4+z0Ouxi4hXBTvZWHLW2QSH7Dpilget0RQB754p7pO7GpnrR73Pc7fq6JX/8yzbviIPo9 sD8gZrMmBoB2Dq2896HBNgYkAaa/c+wkqQsaOCiH5GuszUsCAwEAAaOCA4owggOGMAkGA1Ud EwQCMAAwCwYDVR0PBAQDAgSwMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDAdBgNV HQ4EFgQU7LCzddaAhj0U/U85WqN1k/0u7fwwHQYDVR0RBBYwFIESc3RwZXRlckBzdHBldGVy LmltMIGoBgNVHSMEgaAwgZ2AFHuJnJKXJKGERwLLdPwu9KzcMuXzoYGBpH8wfTELMAkGA1UE BhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFs IENlcnRpZmljYXRlIFNpZ25pbmcxKTAnBgNVBAMTIFN0YXJ0Q29tIENlcnRpZmljYXRpb24g QXV0aG9yaXR5ggEPMIIBRwYDVR0gBIIBPjCCATowggE2BgsrBgEEAYG1NwECADCCASUwLgYI KwYBBQUHAgEWImh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3BvbGljeS5wZGYwNAYIKwYBBQUH AgEWKGh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL2ludGVybWVkaWF0ZS5wZGYwgbwGCCsGAQUF BwICMIGvMBQWDVN0YXJ0Q29tIEx0ZC4wAwIBARqBlkxpbWl0ZWQgTGlhYmlsaXR5LCByZWFk IHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL3d3dy5zdGFy dHNzbC5jb20vcG9saWN5LnBkZjBjBgNVHR8EXDBaMCugKaAnhiVodHRwOi8vd3d3LnN0YXJ0 c3NsLmNvbS9jcnR1My1jcmwuY3JsMCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9j cnR1My1jcmwuY3JsMIGOBggrBgEFBQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2Nz cC5zdGFydHNzbC5jb20vc3ViL2NsYXNzMy9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL2NlcnRzL3N1Yi5jbGFzczMuY2xpZW50LmNhLmNydDAjBgNV HRIEHDAahhhodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAGC/ jEVdmoMpI62c85Vuo6HVuuPujFFpViTs3QwkbvH1j/CQ7eLBHCLNUtwLVsD4P9GDIWKVfHoh BYTrcZ7a275jjDlCgdjC5QVC4Fm7G9mk5rfKR2A+UFBoEzyb4h6fSyTA2CBqLMBf09z+wwuk /eOQ7WJIXhqDLivkR37gbXSY/lfTM7eBDCr1SPgX21f7nyRT58zU/xKH4FhHiv+RJsoTe1Zw xopuVY8bBfSdgPbol7tBv65f8nmUKCjMGsddBarw33yKSUBJ/am/7fY6LV0SOYxSACb8nb5i bFojTb5z4fpAfz4XdFSMKJGD1epQ2Nys2udMWeb+IwxkAOS2xc8wggfiMIIFyqADAgECAgEP MA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQu MSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0ZSBTaWduaW5nMSkwJwYDVQQD EyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzEwMjQyMTAzMzJaFw0x MjEwMjIyMTAzMzJaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjEr MCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMv U3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0EwggEiMA0G CSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC5o0luEj4gypQIp71Xi2TlXyLYrj9WkRy+d9BO 0FHPYnAsC99/jx/ibNRwIfAoFhZd+LDscdRSckvwuFSz0bKg3z+9o7cwlVAC9AwMWe8IM0Lx c+8etYxsX4WIamG9fjzzi5GAW5ESKzzIN3SxHSplyGCWFwx/pgf1f4y6O9/ym+4f6zaDYP6B x0r+SaJcr6eSGNm7X3EwX1v7XpRBY+aw019o7k72d0IX910F+XGt0OwNdM61Ff3FiTiexeUZ bWxCGm6GZl+SQVG9xYVIgHQaLXoQF+g2wzrmKCbVcZhqH+hrlRnD6PfCuEyX/BR6PlAPRDlQ 6f1u3wqik+LF5P15AgMBAAGjggNbMIIDVzAMBgNVHRMEBTADAQH/MAsGA1UdDwQEAwIBpjAd BgNVHQ4EFgQUe4mckpckoYRHAst0/C70rNwy5fMwgagGA1UdIwSBoDCBnYAUTgvvGqRAW6UX aYcwyjRoQ9BBrvKhgYGkfzB9MQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzEpMCcGA1UE AxMgU3RhcnRDb20gQ2VydGlmaWNhdGlvbiBBdXRob3JpdHmCAQEwCQYDVR0SBAIwADA9Bggr BgEFBQcBAQQxMC8wLQYIKwYBBQUHMAKGIWh0dHA6Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2Nh LmNydDBgBgNVHR8EWTBXMCygKqAohiZodHRwOi8vY2VydC5zdGFydGNvbS5vcmcvc2ZzY2Et Y3JsLmNybDAnoCWgI4YhaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMIIBXQYD VR0gBIIBVDCCAVAwggFMBgsrBgEEAYG1NwEBBDCCATswLwYIKwYBBQUHAgEWI2h0dHA6Ly9j ZXJ0LnN0YXJ0Y29tLm9yZy9wb2xpY3kucGRmMDUGCCsGAQUFBwIBFilodHRwOi8vY2VydC5z dGFydGNvbS5vcmcvaW50ZXJtZWRpYXRlLnBkZjCB0AYIKwYBBQUHAgIwgcMwJxYgU3RhcnQg Q29tbWVyY2lhbCAoU3RhcnRDb20pIEx0ZC4wAwIBARqBl0xpbWl0ZWQgTGlhYmlsaXR5LCBy ZWFkIHRoZSBzZWN0aW9uICpMZWdhbCBMaW1pdGF0aW9ucyogb2YgdGhlIFN0YXJ0Q29tIENl cnRpZmljYXRpb24gQXV0aG9yaXR5IFBvbGljeSBhdmFpbGFibGUgYXQgaHR0cDovL2NlcnQu c3RhcnRjb20ub3JnL3BvbGljeS5wZGYwEQYJYIZIAYb4QgEBBAQDAgAHMFAGCWCGSAGG+EIB DQRDFkFTdGFydENvbSBDbGFzcyAzIFByaW1hcnkgSW50ZXJtZWRpYXRlIEZyZWUgU1NMIEVt YWlsIENlcnRpZmljYXRlczANBgkqhkiG9w0BAQUFAAOCAgEAUpcEDdsKFRCxFBxcSm+8oMTT fpS7fbZkxWHx5fHDjvAgaBQ+oY0tk4xtbD6VxeHYjxI63+hj8jICnqeVXPe34Bu+XzekIn2T lrnPCQobKdQF2p52QgUvIxSURed0jcBaCBV22DSKaUqDOzD/Tx6VQy78zpblXjRH7OALE/+H jzJVmspdnBUUtQOLYgPo924xkxR25VDdgtEE5vAXa/g2oCeZhy0ZEO4NbgIayAYCJcJRDz0h dD2Ahec65Kw6LB3N7VXEjiRR5/WoKwH/QteRzPJbFDc1somrApjm2cyg+5nbm1RHeFIz+GxX luRrPztvhNcby0PtAjqwY1txi4sW0R6ZJPuZ2DZ1/dzckoFhyZgFyOX3SEkNXVLldjTzneFJ FnVSzDbc720vq184jR7pYoI9+f5QJ96a0iLxEAG8SJ5auBwXI/w2FmKmwmdMvJ8/17+B4sMC IRrXrDQl2xzpVXh/Qcmk5nf+w8HFmqATGy1OUAQbXga7AySAUaYhvvFk50u0bO5DiUGwzrJO 3TrwvaC2Ei4EFaBmIVgG7TfU5TaaY9IcJSCQ7AGUYE3RFSRpsLOoA3DsxP42YERgS/Nxw29+ YqZtPoO2QPbNpI7xnHVCfNBabx3oDIf438nFfv8spw5BQqBSbEF1izJA57eE64CzHnt7lB20 OFD11avYopwxggPKMIIDxgIBATCBkjCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0 Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcx ODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDMgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50 IENBAgFVMAkGBSsOAwIaBQCgggIMMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZI hvcNAQkFMQ8XDTEwMDQyMTEzNDUxMlowIwYJKoZIhvcNAQkEMRYEFPplLDMPv8SLMl5fnUxI FxtapHqqMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqG SIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBowYJ KwYBBAGCNxAEMYGVMIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRk LjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UE AxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAVUw gaUGCyqGSIb3DQEJEAILMYGVoIGSMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRD b20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4 MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMyBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQg Q0ECAVUwDQYJKoZIhvcNAQEBBQAEggEACdPj1X1dcSjXT94xV07wNLhKjsZLMDJhi5oyxsc2 YnGl8sz6hx1COEo+RxJmvkuYIAhMQ0GNavlERUnWpzEFzbkMsgrqCjCobj759dAtDtv6Y3LU TiGVloB27xL0sqnO+xr+2TVxp1wagLbwARKiw/wWv/b0xShpKQb2guXajy1UXNHjfEdK8XBq eyI5BH+PrSvdYRCc7FUGwKwNMkRRItMojoYtd9zZFbryP09HdjUdpihcUDULoi5mOn0d6lJh ZluJ+dLxQei2lf0x31JcXRvsS/QNr50oWSBCoo7F1a4LAMQB3CpQLkbKTfnFjpgcNLdrrXdb bVvFNzEC4Ym4MQAAAAAAAA== --------------ms000700030405010501040906-- From stephen.botzko@gmail.com Wed Apr 21 07:58:04 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4306728C4D0 for ; Wed, 21 Apr 2010 07:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.668 X-Spam-Level: X-Spam-Status: No, score=-1.668 tagged_above=-999 required=5 tests=[AWL=-0.929, BAYES_20=-0.74, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6Dei1mV4F9SW for ; Wed, 21 Apr 2010 07:58:02 -0700 (PDT) Received: from mail-pv0-f172.google.com (mail-pv0-f172.google.com [74.125.83.172]) by core3.amsl.com (Postfix) with ESMTP id 8B2253A6DA1 for ; Wed, 21 Apr 2010 07:33:57 -0700 (PDT) Received: by pvg7 with SMTP id 7so384102pvg.31 for ; Wed, 21 Apr 2010 07:33:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=EKeFe6wly72NLoe389KrY10WrNZQ4DU8jtlSsmZvhWU=; b=PlVbNuVNiJRiWK8mX6AnW6nfQCPgobrzekF0KXb7HYxV2R2UfxXbv4MLX7Wv1AUduZ eAQ9kxHL0Pq92tBR2GKBZHgIH61QPkusBZ4zG9eFUWQrjHYL7pv0vu4VCxQIDDW6vIoE avbvyk1kSX3RPIyZGCnp/1aEqDPjH5TAH6nfU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=XR73JogRZvgBkm6YcN225n2e8ISsAX33XMkFSEMC1LNoDrbaOoGyBD2U4bL+9L9EKW 2bu4Rd979tkWDLli9pLFUzCzJnVIGs/xu01Y3bdwhz+EjC0aBCtG1/C5O3Ty01cnSqVu OceODjwGTHS3TIAuaBR5xX2myOtHskT7rhBmQ= MIME-Version: 1.0 Received: by 10.231.79.213 with HTTP; Wed, 21 Apr 2010 07:33:44 -0700 (PDT) In-Reply-To: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> Date: Wed, 21 Apr 2010 10:33:44 -0400 Received: by 10.142.120.26 with SMTP id s26mr3778122wfc.141.1271860424959; Wed, 21 Apr 2010 07:33:44 -0700 (PDT) Message-ID: From: stephen botzko To: Colin Perkins Content-Type: multipart/alternative; boundary=001636e0a7a8d5690a0484c01416 Cc: trac@tools.ietf.org, codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 14:58:04 -0000 --001636e0a7a8d5690a0484c01416 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable in-line Stephen Botzko On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins wrote: > On 21 Apr 2010, at 12:20, Marshall Eubanks wrote: > >> On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote: >> >>> On 21 Apr 2010, at 10:42, codec issue tracker wrote: >>> >>>> #16: Multicast? >>>> ------------------------------------+---------------------------------= - >>>> Reporter: hoene@=85 | Owner: >>>> Type: enhancement | Status: new >>>> Priority: trivial | Milestone: >>>> Component: requirements | Version: >>>> Severity: Active WG Document | Keywords: >>>> ------------------------------------+---------------------------------= - >>>> The question arrose whether the interactive CODEC MUST support multica= st >>>> in addition to teleconferencing. >>>> >>>> On 04/13/2010 11:35 AM, Christian Hoene wrote: >>>> >>>>> P.S. On the same note, does anybody here cares about using this CODEC >>>>>>> with multicast? Is there a single commercial multicast voice deploy= ment? >>>>>>> From what I've seen all multicast does is making IETF voice standar= ds harder >>>>>>> to understand or implement. >>>>>>> >>>>>> >>>>>> I think that would be a mistake to ignore multicast - not because of >>>>>> multicast itself, but because of Xcast (RFC 5058) which is a promisi= ng >>>>>> technology to replace centralized conference bridges. >>>>>> >>>>> >>>>> Regarding multicast: >>>>> >>>>> I think we shall start at user requirements and scenarios. >>>>> Teleconference (including mono or spatial audio) might be good starti= ng >>>>> point. Virtual environments like second live would require multicast >>>>> communication, too. If the requirements of these scenarios are well >>>>> understand, we can start to talk about potential solutions like IP >>>>> multicast, Xcast or conference bridges. >>>>> >>>> >>> >>> RTP is inherently a group communication protocol, and any codec designe= d >>> for use with RTP should consider operation in various different types o= f >>> group communication scenario (not just multicast). RFC 5117 is a good p= lace >>> to start when considering the different types of topology in which RTP = is >>> used, and the possible placement of mixing and switching functions whic= h the >>> codec will need to work with. >>> >>> >> It is not clear to me what supporting multicast would entail here. If th= is >> is a codec over RTP, then what is to stop it from being multicast ? >> > > > Nothing. However group conferences implemented using multicast require en= d > system mixing of potentially large numbers of active audio streams, where= as > those implemented using conference bridges do the mixing in a single cent= ral > location, and generally suppress all but one speaker. The differences in > mixing and the number of simultaneous active streams that might be receiv= ed > potentially affect the design of the codec. > Conference bridges with central mixing almost always mix multiple speakers. As you add more streams into the mix, you reduce the chance of missing onse= t speech and interruptions, but raise the noise floor. So even if complexity is not a consideration, there is value in gating the mixer (instead of always doing a full mix-minus). More on point, compressed domain mixing and easy detection of VAD have both been advocated on these lists, and both simplify the large-scale mixing problem. > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636e0a7a8d5690a0484c01416 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable in-line

Stephen Botzko

On Wed, Apr= 21, 2010 at 8:17 AM, Colin Perkins <csp@csperkins.org> wrote:
On 21 Apr 2010, at 12:20, Marshall Eubanks wrote:
On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote:
On 21 Apr 2010, at 10:42, codec issue tracker wrote:
#16: Multicast?
------------------------------------+----------------------------------
Reporter: =A0hoene@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner:=
=A0Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new=
Priority: =A0trivial =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:
Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
Severity: =A0Active WG Document =A0 =A0 =A0| =A0 =A0Keywords:
------------------------------------+----------------------------------
The question arrose whether the interactive CODEC MUST support multicast in= addition to teleconferencing.

On 04/13/2010 11:35 AM, Christian Hoene wrote:
P.S. On the same note, does anybody here cares about using this CODEC with = multicast? Is there a single commercial multicast voice deployment? From wh= at I've seen all multicast does is making IETF voice standards harder t= o understand or implement.

I think that would be a mistake to ignore multicast - not because of multic= ast itself, but because of Xcast (RFC 5058) which is a promising technology= to replace centralized conference bridges.

Regarding multicast:

I think we shall start at user requirements and scenarios. Teleconference (= including mono or spatial audio) might be good starting point. Virtual envi= ronments like second live would require multicast communication, too. If th= e requirements of these scenarios are well understand, we can start to talk= about potential solutions like IP multicast, Xcast or conference bridges.<= br>


RTP is inherently a group communication protocol, and any codec designed fo= r use with RTP should consider operation in various different types of grou= p communication scenario (not just multicast). RFC 5117 is a good place to = start when considering the different types of topology in which RTP is used= , and the possible placement of mixing and switching functions which the co= dec will need to work with.


It is not clear to me what supporting multicast would entail here. If this = is a codec over RTP, then what is to stop it from being multicast ?


Nothing. However group conferences implemented using multicast require end = system mixing of potentially large numbers of active audio streams, whereas= those implemented using conference bridges do the mixing in a single centr= al location, and generally suppress all but one speaker. The differences in= mixing and the number of simultaneous active streams that might be receive= d potentially affect the design of the codec.

Conference b= ridges with central mixing almost always mix multiple speakers.=A0 As you a= dd more streams into the mix, you reduce the chance of missing onset speech= and interruptions, but raise the noise floor. So even if complexity is not= a consideration, there is value in gating the mixer (instead of always doi= ng a full mix-minus).

More on point, compressed domain mixing and easy detection of VAD have = both been advocated on these lists, and both simplify the large-scale mixing=20 problem.

--001636e0a7a8d5690a0484c01416-- From hoene@uni-tuebingen.de Wed Apr 21 10:12:01 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E6843A6A9E for ; Wed, 21 Apr 2010 10:12:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.494 X-Spam-Level: X-Spam-Status: No, score=-4.494 tagged_above=-999 required=5 tests=[AWL=1.754, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jfat4GCQePRk for ; Wed, 21 Apr 2010 10:11:49 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id DD2C828C117 for ; Wed, 21 Apr 2010 09:58:41 -0700 (PDT) Received: from hoeneT60 ([178.2.215.255]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o3LGwKYq016710 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Apr 2010 18:58:26 +0200 From: "Christian Hoene" To: "'stephen botzko'" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> In-Reply-To: Date: Wed, 21 Apr 2010 18:58:19 +0200 Message-ID: <000001cae173$dba012f0$92e038d0$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0001_01CAE184.9F28E2F0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrhYw2eWK/SpMeuSG2Wjx0gWq/NugAC+5GQ Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.220; VDF: 7.10.6.169; host: mx05); id=20827-qI3ox1 Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 17:12:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0001_01CAE184.9F28E2F0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 the teleconferencing issue gets complex. I am trying to compile the = different requirements that have been mentioned on this list. - low complexity (with just one active speaker) vs. multiple = speaker mixing vs. spatial audio/stereo mixing - centralized vs. distributed - few participants vs. hundreds of listeners and talkers - individual distribution of audio streams vs. IP multicast or = RTP group communication - efficient encoding of multiple streams having the same = content (but different quality). - I bet I missed some. =20 To make things easier, why not to split the teleconferencing scenario in = two: High quality and Scalable? =20 The high quality scenario, intended for a low number of users, could = have features like - Distributed processing and mixing - High computational resources to support spatial audio mixing = (at the receiver) and multiple encodings of the same audio stream at different qualities (at the sender) - Enough bandwidth to allow direct N to N transmissions of = audio streams (no multicast or group communication). This would be good for the latency, too. =20 The scalable scenario is the opposite: - Central processing and mixing for many participants . - N to 1 and 1 to N communication using efficient distribution = mechanisms (RTP group communication and IP multicast). - Low complexity mixing of many using tricks like VAD, encoding = at lowest rate to support many receivers having different paths, you name it... =20 Then, we need not to compare apples with oranges all the time. =20 Christian =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of stephen botzko Sent: Wednesday, April 21, 2010 4:34 PM To: Colin Perkins Cc: trac@tools.ietf.org; codec@ietf.org Subject: Re: [codec] #16: Multicast? =20 in-line Stephen Botzko On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins = wrote: On 21 Apr 2010, at 12:20, Marshall Eubanks wrote: On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote: On 21 Apr 2010, at 10:42, codec issue tracker wrote: #16: Multicast? ------------------------------------+---------------------------------- Reporter: hoene@=85 | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+---------------------------------- The question arrose whether the interactive CODEC MUST support multicast = in addition to teleconferencing. On 04/13/2010 11:35 AM, Christian Hoene wrote: P.S. On the same note, does anybody here cares about using this CODEC = with multicast? Is there a single commercial multicast voice deployment? From what I've seen all multicast does is making IETF voice = standards harder to understand or implement. I think that would be a mistake to ignore multicast - not because of = multicast itself, but because of Xcast (RFC 5058) which is a promising technology to replace centralized conference bridges. Regarding multicast: I think we shall start at user requirements and scenarios. = Teleconference (including mono or spatial audio) might be good starting point. Virtual environments like second live would require multicast = communication, too. If the requirements of these scenarios are well understand, we can start to talk about potential solutions like IP = multicast, Xcast or conference bridges. RTP is inherently a group communication protocol, and any codec designed = for use with RTP should consider operation in various different types of group communication scenario (not just multicast). = RFC 5117 is a good place to start when considering the different types of topology in which RTP is used, and the possible = placement of mixing and switching functions which the codec will need to work with. It is not clear to me what supporting multicast would entail here. If = this is a codec over RTP, then what is to stop it from being multicast ? =20 Nothing. However group conferences implemented using multicast require = end system mixing of potentially large numbers of active audio streams, whereas those implemented using conference bridges do the = mixing in a single central location, and generally suppress all but one speaker. The differences in mixing and the number of = simultaneous active streams that might be received potentially affect the design of the codec. Conference bridges with central mixing almost always mix multiple = speakers. As you add more streams into the mix, you reduce the chance of missing onset speech and interruptions, but raise the noise = floor. So even if complexity is not a consideration, there is value in gating the mixer (instead of always doing a full mix-minus). More on point, compressed domain mixing and easy detection of VAD have = both been advocated on these lists, and both simplify the large-scale mixing problem. --=20 Colin Perkins http://csperkins.org/ _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =20 ------=_NextPart_000_0001_01CAE184.9F28E2F0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi, =

 

the = teleconferencing issue gets complex. I am trying to compile the different requirements = that have been mentioned on this list.

-          low complexity (with just one active speaker) vs. multiple speaker mixing = vs. spatial audio/stereo mixing

-          centralized vs. distributed

-          few participants vs. hundreds of listeners and = talkers

-          individual distribution of audio streams vs. IP multicast or RTP group = communication

-          efficient encoding of multiple streams having the same content (but different = quality).

-          =A0I bet I missed = some.

 

To make things = easier, why not to split the teleconferencing scenario in two: High quality and = Scalable?

 

The high = quality scenario, intended for a low number of users, could have features = like

-          Distributed processing and mixing

-          High computational resources to support spatial audio mixing (at the = receiver) and multiple encodings of the same audio stream at different qualities (at = the sender)

-          Enough bandwidth to allow direct N to N transmissions of audio streams (no = multicast or group communication). This would be good for the latency, = too.

 

The scalable = scenario is the opposite:

-          Central processing and mixing for many participants = .

-          N to 1 and 1 to N communication using efficient distribution mechanisms = (RTP group communication and IP multicast).

-          Low complexity mixing of many using tricks like VAD, encoding at lowest rate = to support many receivers having different paths, you name = it...

 

Then, we need = not to compare apples with oranges all the time.

 

Christian=

 

---------------------------------------------------------------=

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen =

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen= .de/

 

From: codec-bounces@ietf.org = [mailto:codec-bounces@ietf.org] On Behalf Of stephen botzko
Sent: Wednesday, April = 21, 2010 4:34 PM
To: Colin Perkins
Cc: trac@tools.ietf.org; codec@ietf.org
Subject: Re: [codec] #16: Multicast?

 

in-line

Stephen Botzko

On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins <csp@csperkins.org> = wrote:

On 21 Apr 2010, at 12:20, Marshall Eubanks = wrote:

On Apr 21, 2010, at 6:48 AM, Colin Perkins = wrote:

On 21 Apr 2010, at 10:42, codec issue tracker = wrote:

#16: Multicast?
------------------------------------+---------------------------------- Reporter:  hoene@…             =     |       Owner:
 Type:  enhancement             = |      Status:  new
Priority:  trivial               =   |   Milestone:
Component:  requirements            | =     Version:
Severity:  Active WG Document      |   =  Keywords:
------------------------------------+---------------------------------- The question arrose whether the interactive CODEC MUST support multicast = in addition to teleconferencing.

On 04/13/2010 11:35 AM, Christian Hoene = wrote:

P.S. On the same note, does anybody here cares about using this = CODEC with multicast? Is there a single commercial multicast voice deployment? = From what I've seen all multicast does is making IETF voice standards harder = to understand or implement.


I think that would be a mistake to ignore multicast - not because of = multicast itself, but because of Xcast (RFC 5058) which is a promising technology = to replace centralized conference bridges.


Regarding multicast:

I think we shall start at user requirements and scenarios. = Teleconference (including mono or spatial audio) might be good starting point. Virtual environments like second live would require multicast communication, = too. If the requirements of these scenarios are well understand, we can start to = talk about potential solutions like IP multicast, Xcast or conference = bridges.



RTP is inherently a group communication protocol, and any codec designed = for use with RTP should consider operation in various different types of = group communication scenario (not just multicast). RFC 5117 is a good place to = start when considering the different types of topology in which RTP is used, = and the possible placement of mixing and switching functions which the codec = will need to work with.


It is not clear to me what supporting multicast would entail here. If = this is a codec over RTP, then what is to stop it from being multicast = ?

 

Nothing. However group conferences implemented using multicast = require end system mixing of potentially large numbers of active audio streams, = whereas those implemented using conference bridges do the mixing in a single = central location, and generally suppress all but one speaker. The differences in = mixing and the number of simultaneous active streams that might be received potentially affect the design of the codec.


Conference bridges with central mixing almost always mix multiple speakers.  As you add more streams into the mix, you reduce the = chance of missing onset speech and interruptions, but raise the noise floor. So = even if complexity is not a consideration, there is value in gating the mixer = (instead of always doing a full mix-minus).

More on point, compressed domain mixing and easy detection of VAD have = both been advocated on these lists, and both simplify the large-scale mixing problem.


--
Colin Perkins
http://csperkins.org/



_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec

 

------=_NextPart_000_0001_01CAE184.9F28E2F0-- From stephen.botzko@gmail.com Wed Apr 21 10:25:29 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF92D3A68EC for ; Wed, 21 Apr 2010 10:25:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OHCZ1Xnnf3qD for ; Wed, 21 Apr 2010 10:25:27 -0700 (PDT) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id BC3043A6C71 for ; Wed, 21 Apr 2010 10:10:25 -0700 (PDT) Received: by pwj2 with SMTP id 2so5296782pwj.31 for ; Wed, 21 Apr 2010 10:10:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=IkGRklmc74sfpPIMzoJ93cBfl7RabUfxwVXT1I24agE=; b=POozepS6MZWJ6VJUtVK6WznCLF6rjRpL7AQ1ZzBcZ/1tAHOy5hRvb9ubGfuwA4Id46 wntZIKCMxC+DL79qIwjrPg85Jj0IyyCMENOizxHZPQTRdRgT7nvj3MOpqgQN1ZysXtTs Lyl+2XuVNEvG7C0Z7Yn9Kpq8zCvwbUIV1+JRA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CI7wttU/xpjgyrLEz5R2MI2lFORYFTKbPJ/xbtOXJc8Epp7VABUMVnNyfeXCtT9kM8 dybInINLQMETOQWPZ+R/04UIMT8Hkz96RA66CLwryUjhqynirlF4XuO9xz8yvLgmGgYo qgy1jaXqkbbjYsF1Lk8YSpnAeTBwmi0xZ1zEs= MIME-Version: 1.0 Received: by 10.231.79.213 with HTTP; Wed, 21 Apr 2010 10:10:12 -0700 (PDT) In-Reply-To: <000001cae173$dba012f0$92e038d0$@de> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> Date: Wed, 21 Apr 2010 13:10:12 -0400 Received: by 10.141.100.21 with SMTP id c21mr3218175rvm.101.1271869813876; Wed, 21 Apr 2010 10:10:13 -0700 (PDT) Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=000e0cd1395474e7040484c24493 Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 17:25:29 -0000 --000e0cd1395474e7040484c24493 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree there are lots of use cases. Though I don't see why high quality has to be given up in order to be scalable. Also, I am not sure why you think central mixing is more scalable than multicast (or why you think it is lower quality either). Stephen Botzko On Wed, Apr 21, 2010 at 12:58 PM, Christian Hoene w= rote: > Hi, > > > > the teleconferencing issue gets complex. I am trying to compile the > different requirements that have been mentioned on this list. > > - low complexity (with just one active speaker) vs. multiple > speaker mixing vs. spatial audio/stereo mixing > > - centralized vs. distributed > > - few participants vs. hundreds of listeners and talkers > > - individual distribution of audio streams vs. IP multicast or > RTP group communication > > - efficient encoding of multiple streams having the same content > (but different quality). > > - I bet I missed some. > > > > To make things easier, why not to split the teleconferencing scenario in > two: High quality and Scalable? > > > > The high quality scenario, intended for a low number of users, could have > features like > > - Distributed processing and mixing > > - High computational resources to support spatial audio mixing > (at the receiver) and multiple encodings of the same audio stream at > different qualities (at the sender) > > - Enough bandwidth to allow direct N to N transmissions of audio > streams (no multicast or group communication). This would be good for the > latency, too. > > > > The scalable scenario is the opposite: > > - Central processing and mixing for many participants . > > - N to 1 and 1 to N communication using efficient distribution > mechanisms (RTP group communication and IP multicast). > > - Low complexity mixing of many using tricks like VAD, encoding > at lowest rate to support many receivers having different paths, you name > it... > > > > Then, we need not to compare apples with oranges all the time. > > > > Christian > > > > --------------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of T=FCbingen > > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > > > *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf > Of *stephen botzko > *Sent:* Wednesday, April 21, 2010 4:34 PM > *To:* Colin Perkins > *Cc:* trac@tools.ietf.org; codec@ietf.org > *Subject:* Re: [codec] #16: Multicast? > > > > in-line > > Stephen Botzko > > On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins wrote: > > On 21 Apr 2010, at 12:20, Marshall Eubanks wrote: > > On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote: > > On 21 Apr 2010, at 10:42, codec issue tracker wrote: > > #16: Multicast? > ------------------------------------+---------------------------------- > Reporter: hoene@=85 | Owner: > Type: enhancement | Status: new > Priority: trivial | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Keywords: > ------------------------------------+---------------------------------- > The question arrose whether the interactive CODEC MUST support multicast = in > addition to teleconferencing. > > On 04/13/2010 11:35 AM, Christian Hoene wrote: > > P.S. On the same note, does anybody here cares about using this CODEC > with multicast? Is there a single commercial multicast voice deployment? > From what I've seen all multicast does is making IETF voice standards har= der > to understand or implement. > > > I think that would be a mistake to ignore multicast - not because of > multicast itself, but because of Xcast (RFC 5058) which is a promising > technology to replace centralized conference bridges. > > > Regarding multicast: > > I think we shall start at user requirements and scenarios. Teleconference > (including mono or spatial audio) might be good starting point. Virtual > environments like second live would require multicast communication, too.= If > the requirements of these scenarios are well understand, we can start to > talk about potential solutions like IP multicast, Xcast or conference > bridges. > > > > RTP is inherently a group communication protocol, and any codec designed > for use with RTP should consider operation in various different types of > group communication scenario (not just multicast). RFC 5117 is a good pla= ce > to start when considering the different types of topology in which RTP is > used, and the possible placement of mixing and switching functions which = the > codec will need to work with. > > > It is not clear to me what supporting multicast would entail here. If thi= s > is a codec over RTP, then what is to stop it from being multicast ? > > > > Nothing. However group conferences implemented using multicast require en= d > system mixing of potentially large numbers of active audio streams, where= as > those implemented using conference bridges do the mixing in a single cent= ral > location, and generally suppress all but one speaker. The differences in > mixing and the number of simultaneous active streams that might be receiv= ed > potentially affect the design of the codec. > > > Conference bridges with central mixing almost always mix multiple > speakers. As you add more streams into the mix, you reduce the chance of > missing onset speech and interruptions, but raise the noise floor. So eve= n > if complexity is not a consideration, there is value in gating the mixer > (instead of always doing a full mix-minus). > > More on point, compressed domain mixing and easy detection of VAD have bo= th > been advocated on these lists, and both simplify the large-scale mixing > problem. > > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > --000e0cd1395474e7040484c24493 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable I agree there are lots of use cases.

Though I don't see why high= quality has to be given up in order to be scalable.=A0

Also, I am = not sure why you think central mixing is more scalable than multicast (or w= hy you think it is lower quality either).

Stephen Botzko

On Wed, Apr 21, 2010 = at 12:58 PM, Christian Hoene <hoene@uni-tuebingen.de> wrote:

= Hi= ,

= = =A0

= th= e teleconferencing issue gets complex. I am trying to compile the different requirements that = have been mentioned on this list.

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 low complexity (with just one active speaker) vs. multiple speaker mixing vs. s= patial audio/stereo mixing

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 centralized vs. distributed

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 few participants vs. hundreds of listeners and talkers

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 individual distribution of audio streams vs. IP multicast or RTP group communication

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 efficient encoding of multiple streams having the same content (but different quality= ).

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0I bet I missed some.

= = =A0

= To= make things easier, why not to split the teleconferencing scenario in two: High quality and Sca= lable?

= = =A0

= Th= e high quality scenario, intended for a low number of users, could have features like

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Distributed processing and mixing

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 High computational resources to support spatial audio mixing (at the receiver) a= nd multiple encodings of the same audio stream at different qualities (at the sender)

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Enough bandwidth to allow direct N to N transmissions of audio streams (no multica= st or group communication). This would be good for the latency, too.

= = =A0

= Th= e scalable scenario is the opposite:

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Central processing and mixing for many participants .

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 N to 1 and 1 to N communication using efficient distribution mechanisms (RTP group communication and IP multicast).

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Low complexity mixing of many using tricks like VAD, encoding at lowest rate to support many receivers having different paths, you name it...=

= = =A0

= Th= en, we need not to compare apples with oranges all the time.

= = =A0

= Ch= ristian

= = =A0

---------------------------------------------------= ------------

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University= of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 = 2970532
= http://www.net.uni-tu= ebingen.de/

= = =A0

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.= org] On Behalf Of step= hen botzko
Sent: Wednesday, April 21,= 2010 4:34 PM
To: Colin Perkins
Cc: trac@tools.ietf.org; codec@ietf.org
Subject: Re: [codec] #16: Multicast?

=A0

in-line

Stephen Botzko

On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins <<= a href=3D"mailto:csp@csperkins.org" target=3D"_blank">csp@csperkins.org= > wrote:

On 21 Apr 2010, at 12:20, Marshall Eubanks wrote:

On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote:

On 21 Apr 2010, at 10:42, codec issue tracker wrote:=

#16: Multicast?
------------------------------------+----------------------------------
Reporter: =A0hoene@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner:
=A0Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new
Priority: =A0trivial =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:
Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
Severity: =A0Active WG Document =A0 =A0 =A0| =A0 =A0Keywords:
------------------------------------+----------------------------------
The question arrose whether the interactive CODEC MUST support multicast in addition to teleconferencing.

On 04/13/2010 11:35 AM, Christian Hoene wrote:

P.S. On the same note, does anybody here cares about= using this CODEC with multicast? Is there a single commercial multicast voice deployment? Fr= om what I've seen all multicast does is making IETF voice standards harder= to understand or implement.


I think that would be a mistake to ignore multicast - not because of multic= ast itself, but because of Xcast (RFC 5058) which is a promising technology to replace centralized conference bridges.


Regarding multicast:

I think we shall start at user requirements and scenarios. Teleconference (including mono or spatial audio) might be good starting point. Virtual environments like second live would require multicast communication, too. I= f the requirements of these scenarios are well understand, we can start to ta= lk about potential solutions like IP multicast, Xcast or conference bridges.



RTP is inherently a group communication protocol, and any codec designed fo= r use with RTP should consider operation in various different types of group communication scenario (not just multicast). RFC 5117 is a good place to st= art when considering the different types of topology in which RTP is used, and = the possible placement of mixing and switching functions which the codec will n= eed to work with.


It is not clear to me what supporting multicast would entail here. If this = is a codec over RTP, then what is to stop it from being multicast ?

=A0

Nothing. However group conferences implemented using= multicast require end system mixing of potentially large numbers of active audio streams, whe= reas those implemented using conference bridges do the mixing in a single centra= l location, and generally suppress all but one speaker. The differences in mi= xing and the number of simultaneous active streams that might be received potentially affect the design of the codec.


Conference bridges with central mixing almost always mix multiple speakers.=A0 As you add more streams into the mix, you reduce the chance of missing onset speech and interruptions, but raise the noise floor. So even = if complexity is not a consideration, there is value in gating the mixer (inst= ead of always doing a full mix-minus).

More on point, compressed domain mixing and easy detection of VAD have both been advocated on these lists, and both simplify the large-scale mixing problem.

=A0


--000e0cd1395474e7040484c24493-- From tme@americafree.tv Wed Apr 21 10:34:50 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C54828C1FF for ; Wed, 21 Apr 2010 10:34:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.085 X-Spam-Level: X-Spam-Status: No, score=-102.085 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KBjHexQH6l3s for ; Wed, 21 Apr 2010 10:34:49 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 54D6728C329 for ; Wed, 21 Apr 2010 10:24:03 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 242D86B5F0C4; Wed, 21 Apr 2010 13:23:53 -0400 (EDT) Message-Id: <2B0895A4-66B1-4164-B42D-F82F8A46DE5F@americafree.tv> From: Marshall Eubanks To: Colin Perkins In-Reply-To: Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 21 Apr 2010 13:23:51 -0400 References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> X-Mailer: Apple Mail (2.936) Cc: codec@ietf.org, trac@tools.ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 17:34:50 -0000 On Apr 21, 2010, at 8:17 AM, Colin Perkins wrote: > On 21 Apr 2010, at 12:20, Marshall Eubanks wrote: >> On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote: >>> On 21 Apr 2010, at 10:42, codec issue tracker wrote: >>>> #16: Multicast? >>>> ------------------------------------=20 >>>> +---------------------------------- >>>> Reporter: hoene@=85 | Owner: >>>> Type: enhancement | Status: new >>>> Priority: trivial | Milestone: >>>> Component: requirements | Version: >>>> Severity: Active WG Document | Keywords: >>>> ------------------------------------=20 >>>> +---------------------------------- >>>> The question arrose whether the interactive CODEC MUST support =20 >>>> multicast in addition to teleconferencing. >>>> >>>> On 04/13/2010 11:35 AM, Christian Hoene wrote: >>>>>>> P.S. On the same note, does anybody here cares about using =20 >>>>>>> this CODEC with multicast? Is there a single commercial =20 >>>>>>> multicast voice deployment? =46rom what I've seen all multicast =20= >>>>>>> does is making IETF voice standards harder to understand or =20 >>>>>>> implement. >>>>>> >>>>>> I think that would be a mistake to ignore multicast - not =20 >>>>>> because of multicast itself, but because of Xcast (RFC 5058) =20 >>>>>> which is a promising technology to replace centralized =20 >>>>>> conference bridges. >>>>> >>>>> Regarding multicast: >>>>> >>>>> I think we shall start at user requirements and scenarios. =20 >>>>> Teleconference (including mono or spatial audio) might be good =20 >>>>> starting point. Virtual environments like second live would =20 >>>>> require multicast communication, too. If the requirements of =20 >>>>> these scenarios are well understand, we can start to talk about =20= >>>>> potential solutions like IP multicast, Xcast or conference =20 >>>>> bridges. >>> >>> >>> RTP is inherently a group communication protocol, and any codec =20 >>> designed for use with RTP should consider operation in various =20 >>> different types of group communication scenario (not just =20 >>> multicast). RFC 5117 is a good place to start when considering the =20= >>> different types of topology in which RTP is used, and the possible =20= >>> placement of mixing and switching functions which the codec will =20 >>> need to work with. >>> >> >> It is not clear to me what supporting multicast would entail here. =20= >> If this is a codec over RTP, then what is to stop it from being =20 >> multicast ? > > > Nothing. However group conferences implemented using multicast =20 > require end system mixing of potentially large numbers of active =20 > audio streams, whereas those implemented using conference bridges do =20= > the mixing in a single central location, and generally suppress all =20= > but one speaker. The differences in mixing and the number of =20 > simultaneous active streams that might be received potentially =20 > affect the design of the codec. > Yes, I can see that. However, this seems to be not so much a function =20= of the transport protocol as on the desired use - a distributed =20 conference or a large scale meeting with many simultaneous active =20 streams (such as the old Access Grid) is likely to have the same =20 issues whether the transport is unicast or multicast or P2P. At any rate, I would regard multicast support as a SHOULD. Regards Marshall > --=20 > Colin Perkins > http://csperkins.org/ > > > > From hoene@uni-tuebingen.de Wed Apr 21 10:38:55 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 189503A6AFD for ; Wed, 21 Apr 2010 10:38:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.932 X-Spam-Level: X-Spam-Status: No, score=-4.932 tagged_above=-999 required=5 tests=[AWL=1.316, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMIW50KVkt91 for ; Wed, 21 Apr 2010 10:38:47 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 363353A6C4F for ; Wed, 21 Apr 2010 10:27:45 -0700 (PDT) Received: from hoeneT60 ([178.2.215.255]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o3LHRLwC019501 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Apr 2010 19:27:27 +0200 From: "Christian Hoene" To: "'stephen botzko'" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> In-Reply-To: Date: Wed, 21 Apr 2010 19:27:19 +0200 Message-ID: <001101cae177$e8aa6780$b9ff3680$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01CAE188.AC333780" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrhdYc/NJFlALQxQ4qc66yWOj2bhQAAR/0A Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.220; VDF: 7.10.6.169; host: mx05); id=20827-hjnPJu Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 17:38:55 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0012_01CAE188.AC333780 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stephen, =20 not too bad. You answered faster than the mailing list distributes=85 =20 Comments inline: =20 =20 From: stephen botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Wednesday, April 21, 2010 7:10 PM To: Christian Hoene Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? =20 I agree there are lots of use cases. Though I don't see why high quality has to be given up in order to be = scalable. =20 CH: These are just experiences from our lab. A spatial audio conference = server including the acoustic 3D sound rendering needs a LOT of processing power. In the end, we have to remain realistic. Processing = power is always limited thus if we need a lot then we cannot serve many clients. Also, I am not sure why you think central mixing is more scalable than = multicast (or why you think it is lower quality either). CH: With multicast, you need N times 1:N multicast distribution trees = (somewhat small tan O(n)=3Dn=B2). With central mixing you need N times 2 transmission paths (O(n)=3Dn). Also, this distributed mixing you = need N times the mixing at each client. With centralized, you can live with one mixing for all (and some tricks for serving the = talkers). Cheers, Christian Stephen Botzko=20 On Wed, Apr 21, 2010 at 12:58 PM, Christian Hoene < = hoene@uni-tuebingen.de> wrote: Hi,=20 =20 the teleconferencing issue gets complex. I am trying to compile the = different requirements that have been mentioned on this list. - low complexity (with just one active speaker) vs. multiple = speaker mixing vs. spatial audio/stereo mixing - centralized vs. distributed - few participants vs. hundreds of listeners and talkers - individual distribution of audio streams vs. IP multicast or = RTP group communication - efficient encoding of multiple streams having the same = content (but different quality). - I bet I missed some. =20 To make things easier, why not to split the teleconferencing scenario in = two: High quality and Scalable? =20 The high quality scenario, intended for a low number of users, could = have features like - Distributed processing and mixing - High computational resources to support spatial audio mixing = (at the receiver) and multiple encodings of the same audio stream at different qualities (at the sender) - Enough bandwidth to allow direct N to N transmissions of = audio streams (no multicast or group communication). This would be good for the latency, too. =20 The scalable scenario is the opposite: - Central processing and mixing for many participants . - N to 1 and 1 to N communication using efficient distribution = mechanisms (RTP group communication and IP multicast). - Low complexity mixing of many using tricks like VAD, encoding = at lowest rate to support many receivers having different paths, you name it... =20 Then, we need not to compare apples with oranges all the time. =20 Christian =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of stephen botzko Sent: Wednesday, April 21, 2010 4:34 PM To: Colin Perkins Cc: trac@tools.ietf.org; codec@ietf.org Subject: Re: [codec] #16: Multicast? =20 in-line Stephen Botzko On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins = wrote: On 21 Apr 2010, at 12:20, Marshall Eubanks wrote: On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote: On 21 Apr 2010, at 10:42, codec issue tracker wrote: #16: Multicast? ------------------------------------+---------------------------------- Reporter: hoene@=85 | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+---------------------------------- The question arrose whether the interactive CODEC MUST support multicast = in addition to teleconferencing. On 04/13/2010 11:35 AM, Christian Hoene wrote: P.S. On the same note, does anybody here cares about using this CODEC = with multicast? Is there a single commercial multicast voice deployment? From what I've seen all multicast does is making IETF voice = standards harder to understand or implement. I think that would be a mistake to ignore multicast - not because of = multicast itself, but because of Xcast (RFC 5058) which is a promising technology to replace centralized conference bridges. Regarding multicast: I think we shall start at user requirements and scenarios. = Teleconference (including mono or spatial audio) might be good starting point. Virtual environments like second live would require multicast = communication, too. If the requirements of these scenarios are well understand, we can start to talk about potential solutions like IP = multicast, Xcast or conference bridges. RTP is inherently a group communication protocol, and any codec designed = for use with RTP should consider operation in various different types of group communication scenario (not just multicast). = RFC 5117 is a good place to start when considering the different types of topology in which RTP is used, and the possible = placement of mixing and switching functions which the codec will need to work with. It is not clear to me what supporting multicast would entail here. If = this is a codec over RTP, then what is to stop it from being multicast ? =20 Nothing. However group conferences implemented using multicast require = end system mixing of potentially large numbers of active audio streams, whereas those implemented using conference bridges do the = mixing in a single central location, and generally suppress all but one speaker. The differences in mixing and the number of = simultaneous active streams that might be received potentially affect the design of the codec. Conference bridges with central mixing almost always mix multiple = speakers. As you add more streams into the mix, you reduce the chance of missing onset speech and interruptions, but raise the noise = floor. So even if complexity is not a consideration, there is value in gating the mixer (instead of always doing a full mix-minus). More on point, compressed domain mixing and easy detection of VAD have = both been advocated on these lists, and both simplify the large-scale mixing problem. --=20 Colin Perkins http://csperkins.org/ _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =20 =20 ------=_NextPart_000_0012_01CAE188.AC333780 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = Stephen,

 

not too bad. = You answered faster than the mailing list = distributes…

 

Comments = inline:

 

 

From:<= font size=3D2 face=3DTahoma> = stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Wednesday, April = 21, 2010 7:10 PM
To: Christian Hoene
Cc: codec@ietf.org
Subject: Re: [codec] #16: Multicast?

 

I agree there are lots = of use cases.

Though I don't see why high quality has to be given up in order to be scalable. 

CH: These are just experiences from our lab. A spatial audio conference = server including the acoustic 3D sound rendering needs a LOT of processing power. In the = end, we have to remain realistic. Processing power is always limited thus if we = need a lot then we cannot serve many clients.

Also, I am not sure why you think central mixing is more scalable = than multicast (or why you think it is lower quality either).

CH: With multicast, you need N times 1:N multicast distribution trees = (somewhat small tan O(n)=3Dn=B2). =A0With = central mixing you need N times 2 transmission paths (O(n)=3Dn). Also, this distributed = mixing you need N times the mixing at each client. With centralized, you can = live with one mixing for all (and some tricks for serving the = talkers).

Cheers,

=A0Christian


Stephen Botzko

On Wed, Apr 21, 2010 = at 12:58 PM, Christian Hoene <hoene@uni-tuebingen.de> = wrote:

Hi,

 

the teleconferencing issue gets complex. I am trying to compile the = different requirements that have been mentioned on this = list.

-        =   low complexity (with just one active speaker) = vs. multiple speaker mixing vs. spatial audio/stereo = mixing

-        =   centralized vs. = distributed

-        =   few participants vs. hundreds of listeners and = talkers

-        =   individual distribution of audio streams vs. IP multicast or RTP group communication

-        =   efficient encoding of multiple streams having = the same content (but different quality).

-        =    I bet I missed = some.

 

To make things easier, why not to split the teleconferencing scenario in = two: High quality and Scalable?

 

The high quality scenario, intended for a low number of users, could have = features like

-        =   Distributed processing and = mixing

-        =   High computational resources to support spatial = audio mixing (at the receiver) and multiple encodings of the same audio stream = at different qualities (at the sender)

-        =   Enough bandwidth to allow direct N to N = transmissions of audio streams (no multicast or group communication). This would be = good for the latency, too.

 

The scalable scenario is the opposite:

-        =   Central processing and mixing for many = participants .

-        =   N to 1 and 1 to N communication using efficient distribution mechanisms (RTP group communication and IP = multicast).

-        =   Low complexity mixing of many using tricks like = VAD, encoding at lowest rate to support many receivers having different = paths, you name it...

 

Then, we need not to compare apples with oranges all the = time.

 

Christian

 

-------------= --------------------------------------------------

Dr.-Ing. = Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen =

Sand 13, = 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen.de/=

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of stephen = botzko
Sent: Wednesday, April = 21, 2010 4:34 PM
To: Colin Perkins
Cc: trac@tools.ietf.org; codec@ietf.org
Subject: Re: [codec] #16: Multicast?

 

in-line

Stephen Botzko

On = Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins <csp@csperkins.org> = wrote:

On 21 = Apr 2010, at 12:20, Marshall Eubanks wrote:

On = Apr 21, 2010, at 6:48 AM, Colin Perkins wrote:

On 21 = Apr 2010, at 10:42, codec issue tracker wrote:

#16: = Multicast?
------------------------------------+---------------------------------- Reporter:  hoene@…             =     |       Owner:
 Type:  enhancement             = |      Status:  new
Priority:  trivial               =   |   Milestone:
Component:  requirements            | =     Version:
Severity:  Active WG Document      |   =  Keywords:
------------------------------------+---------------------------------- The question arrose whether the interactive CODEC MUST support multicast = in addition to teleconferencing.

On 04/13/2010 11:35 AM, Christian Hoene = wrote:

P.S. = On the same note, does anybody here cares about using this CODEC with multicast? Is = there a single commercial multicast voice deployment? From what I've seen all = multicast does is making IETF voice standards harder to understand or = implement.


I think that would be a mistake to ignore multicast - not because of = multicast itself, but because of Xcast (RFC 5058) which is a promising technology = to replace centralized conference bridges.


Regarding multicast:

I think we shall start at user requirements and scenarios. = Teleconference (including mono or spatial audio) might be good starting point. Virtual environments like second live would require multicast communication, = too. If the requirements of these scenarios are well understand, we can start to = talk about potential solutions like IP multicast, Xcast or conference = bridges.



RTP is inherently a group communication protocol, and any codec designed = for use with RTP should consider operation in various different types of = group communication scenario (not just multicast). RFC 5117 is a good place to = start when considering the different types of topology in which RTP is used, = and the possible placement of mixing and switching functions which the codec = will need to work with.


It is not clear to me what supporting multicast would entail here. If = this is a codec over RTP, then what is to stop it from being multicast = ?

 

Nothing. However group conferences implemented using multicast require end system mixing = of potentially large numbers of active audio streams, whereas those = implemented using conference bridges do the mixing in a single central location, and generally suppress all but one speaker. The differences in mixing and = the number of simultaneous active streams that might be received potentially = affect the design of the codec.


Conference bridges with central mixing almost always mix multiple speakers.  As you add more streams into the mix, you reduce the = chance of missing onset speech and interruptions, but raise the noise floor. So = even if complexity is not a consideration, there is value in gating the mixer = (instead of always doing a full mix-minus).

More on point, compressed domain mixing and easy detection of VAD have = both been advocated on these lists, and both simplify the large-scale mixing problem.


--
Colin Perkins
http://csperkins.org/



_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec

 

 

------=_NextPart_000_0012_01CAE188.AC333780-- From stephen.botzko@gmail.com Wed Apr 21 11:26:49 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 673B13A67FE for ; Wed, 21 Apr 2010 11:26:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.504 X-Spam-Level: X-Spam-Status: No, score=-2.504 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aQ2Y2nrxVXyj for ; Wed, 21 Apr 2010 11:26:47 -0700 (PDT) Received: from mail-iw0-f194.google.com (mail-iw0-f194.google.com [209.85.223.194]) by core3.amsl.com (Postfix) with ESMTP id 82A973A691F for ; Wed, 21 Apr 2010 11:19:46 -0700 (PDT) Received: by iwn32 with SMTP id 32so4798021iwn.18 for ; Wed, 21 Apr 2010 11:19:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type; bh=2AceX8KziOAhFrhvAdKXAm047eIX/+eZSTO254/FtcA=; b=g0E5aCVDA0Upsxluk+aZ6X/9p+ArV9Fzc3vgZF0hHkr8w9sIxmclQkmUATVmbgFURf qubD18D6J+OyNctMs/iwKzFGxOHAV/B700VMVyBOgpTjRnLTp+WgypTrNRtbY63kkvko 9vnBGyw7cBLMFO3XUwkssmvslrVGbecA+A0mY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Osks2ohbhdZbEfHEnbwdyZyIli5+eJx9+Rap+1wZN0DRx71wyZhUHr9VWPAWI9ve3o CiRO/oWNrvHaLoN/5z+lbXJhmBfr9SLpxyvPk/aXDljYaBiZfaxy922uatzY90R4sdEG 1TscP0pZJCc4/DoPczLr0jpTQXh3UESIM9DDc= MIME-Version: 1.0 Received: by 10.231.79.213 with HTTP; Wed, 21 Apr 2010 11:19:27 -0700 (PDT) In-Reply-To: <001101cae177$e8aa6780$b9ff3680$@de> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> Date: Wed, 21 Apr 2010 14:19:27 -0400 Received: by 10.231.151.211 with SMTP id d19mr288923ibw.53.1271873973579; Wed, 21 Apr 2010 11:19:33 -0700 (PDT) Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=0016e68ac24664ef440484c33c31 Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 18:26:50 -0000 --0016e68ac24664ef440484c33c31 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Inline On Wed, Apr 21, 2010 at 1:27 PM, Christian Hoene wr= ote: > Hi Stephen, > > > > not too bad. You answered faster than the mailing list distributes=85 > Not sure how that happened! > > > Comments inline: > > > > > > *From:* stephen botzko [mailto:stephen.botzko@gmail.com] > *Sent:* Wednesday, April 21, 2010 7:10 PM > *To:* Christian Hoene > *Cc:* codec@ietf.org > > *Subject:* Re: [codec] #16: Multicast? > > > > I agree there are lots of use cases. > > > Though I don't see why high quality has to be given up in order to be > scalable. > > CH: These are just experiences from our lab. A spatial audio conference > server including the acoustic 3D sound rendering needs a LOT of processin= g > power. In the end, we have to remain realistic. Processing power is alway= s > limited thus if we need a lot then we cannot serve many clients. > > Also, I am not sure why you think central mixing is more scalable than > multicast (or why you think it is lower quality either). > > CH: With multicast, you need N times 1:N multicast distribution trees > (somewhat small tan O(n)=3Dn=B2). With central mixing you need N times 2 > transmission paths (O(n)=3Dn). Also, this distributed mixing you need N t= imes > the mixing at each client. With centralized, you can live with one mixing > for all (and some tricks for serving the talkers). > I agree you need more distribution trees for multicast if you allow every site to talk. There is a corresponding benefit, since there is no central choke point and also less bandwidth on shared WAN links. In the distributed case, you don't need an N-way mixer at each client, and you also don't need to continuously receive payload on all N streams at eac= h client either. In practice you can cap N at a relatively small number (in the 3-8 range) no matter how large the conference gets. In a large conference, you can even choose to drop your comfort noise if you are receiving two or more streams, and just send enough to keep your firewall pinhole open. This is all assuming a suitable voice activity measure in th= e RTP packet. Of course in the worst case, you will receive all N streams. > Cheers, > > Christian > > > Stephen Botzko > > On Wed, Apr 21, 2010 at 12:58 PM, Christian Hoene > wrote: > > Hi, > > > > the teleconferencing issue gets complex. I am trying to compile the > different requirements that have been mentioned on this list. > > - low complexity (with just one active speaker) vs. multiple > speaker mixing vs. spatial audio/stereo mixing > > - centralized vs. distributed > > - few participants vs. hundreds of listeners and talkers > > - individual distribution of audio streams vs. IP multicast or > RTP group communication > > - efficient encoding of multiple streams having the same content > (but different quality). > > - I bet I missed some. > > > > To make things easier, why not to split the teleconferencing scenario in > two: High quality and Scalable? > > > > The high quality scenario, intended for a low number of users, could have > features like > > - Distributed processing and mixing > > - High computational resources to support spatial audio mixing > (at the receiver) and multiple encodings of the same audio stream at > different qualities (at the sender) > > - Enough bandwidth to allow direct N to N transmissions of audio > streams (no multicast or group communication). This would be good for the > latency, too. > > > > The scalable scenario is the opposite: > > - Central processing and mixing for many participants . > > - N to 1 and 1 to N communication using efficient distribution > mechanisms (RTP group communication and IP multicast). > > - Low complexity mixing of many using tricks like VAD, encoding > at lowest rate to support many receivers having different paths, you name > it... > > > > Then, we need not to compare apples with oranges all the time. > > > > Christian > > > > --------------------------------------------------------------- > > Dr.-Ing. Christian Hoene > > Interactive Communication Systems (ICS), University of T=FCbingen > > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > > > *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf > Of *stephen botzko > *Sent:* Wednesday, April 21, 2010 4:34 PM > *To:* Colin Perkins > *Cc:* trac@tools.ietf.org; codec@ietf.org > *Subject:* Re: [codec] #16: Multicast? > > > > in-line > > Stephen Botzko > > On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins wrote: > > On 21 Apr 2010, at 12:20, Marshall Eubanks wrote: > > On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote: > > On 21 Apr 2010, at 10:42, codec issue tracker wrote: > > #16: Multicast? > ------------------------------------+---------------------------------- > Reporter: hoene@=85 | Owner: > Type: enhancement | Status: new > Priority: trivial | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Keywords: > ------------------------------------+---------------------------------- > The question arrose whether the interactive CODEC MUST support multicast = in > addition to teleconferencing. > > On 04/13/2010 11:35 AM, Christian Hoene wrote: > > P.S. On the same note, does anybody here cares about using this CODEC > with multicast? Is there a single commercial multicast voice deployment? > From what I've seen all multicast does is making IETF voice standards har= der > to understand or implement. > > > I think that would be a mistake to ignore multicast - not because of > multicast itself, but because of Xcast (RFC 5058) which is a promising > technology to replace centralized conference bridges. > > > Regarding multicast: > > I think we shall start at user requirements and scenarios. Teleconference > (including mono or spatial audio) might be good starting point. Virtual > environments like second live would require multicast communication, too.= If > the requirements of these scenarios are well understand, we can start to > talk about potential solutions like IP multicast, Xcast or conference > bridges. > > > > RTP is inherently a group communication protocol, and any codec designed > for use with RTP should consider operation in various different types of > group communication scenario (not just multicast). RFC 5117 is a good pla= ce > to start when considering the different types of topology in which RTP is > used, and the possible placement of mixing and switching functions which = the > codec will need to work with. > > > It is not clear to me what supporting multicast would entail here. If thi= s > is a codec over RTP, then what is to stop it from being multicast ? > > > > Nothing. However group conferences implemented using multicast require en= d > system mixing of potentially large numbers of active audio streams, where= as > those implemented using conference bridges do the mixing in a single cent= ral > location, and generally suppress all but one speaker. The differences in > mixing and the number of simultaneous active streams that might be receiv= ed > potentially affect the design of the codec. > > > Conference bridges with central mixing almost always mix multiple > speakers. As you add more streams into the mix, you reduce the chance of > missing onset speech and interruptions, but raise the noise floor. So eve= n > if complexity is not a consideration, there is value in gating the mixer > (instead of always doing a full mix-minus). > > More on point, compressed domain mixing and easy detection of VAD have bo= th > been advocated on these lists, and both simplify the large-scale mixing > problem. > > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > > > --0016e68ac24664ef440484c33c31 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Inline

On Wed, Apr 21, 2010 at 1:27 PM, C= hristian Hoene <hoene@uni-tuebingen.de> wrote:

= Hi Stephen,

= =A0=

= no= t too bad. You answered faster than the mailing list distributes=85

Not sure how that happened!

= = =A0

= Co= mments inline:

= = =A0

= = =A0

From:<= font size=3D"2" face=3D"Tahoma"> stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Wednesday, April 21,= 2010 7:10 PM
To: Christian Hoene
Cc: codec@ietf.org


Subject: Re: [codec] #16: Multicast?

=A0

I agree there are lots of use cases.



Though I don't see why high quality has to be given up in order to be scalable.=A0

CH: These are just experiences from our lab. A spatial audio conference server = including the acoustic 3D sound rendering needs a LOT of processing power. In the end= , we have to remain realistic. Processing power is always limited thus if we nee= d a lot then we cannot serve many clients.

Also, = I am not sure why you think central mixing is more scalable than multicast (or why you think it is lower quality either).<= /p>

CH: With multicast, you need N times 1:N multicast distribution trees (somewhat small tan O(n)=3Dn=B2). =A0With central mixing you need N times 2 transmission paths (O(n)=3Dn). Also, this distributed mi= xing you need N times the mixing at each client. With centralized, you can live = with one mixing for all (and some tricks for serving the talkers).=

I agree you need more distribution = trees for multicast if you allow every site to talk. There is a correspondi= ng benefit, since there is no central choke point and also less bandwidth o= n shared WAN links.

In the distributed case,=A0 you don't need an N-way mixer at each c= lient, and you also don't need to continuously receive payload on all N= streams at each client either.=A0 In practice you can cap N at a relativel= y small number (in the 3-8 range) no matter how large the conference gets.= =A0 In a large conference, you can even choose to drop your comfort noise i= f you are receiving two or more streams, and just send enough to keep your = firewall pinhole open.=A0 This is all assuming a suitable voice activity me= asure in the RTP packet.=A0 Of course in the worst case, you will receive a= ll N streams.
=A0

Cheers,

=A0Christian


Stephen Botzko

On Wed, Apr 21, 2010 at 12:58 PM, Christian Hoene <hoene@uni-tuebingen.de> wrote:

= Hi= ,

= = =A0

= th= e teleconferencing issue gets complex. I am trying to compile the different requirements that have been mentioned on this list.

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 low complex= ity (with just one active speaker) vs. multiple speaker mixing vs. spatial audio/stereo mixing

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 centralized= vs. distributed

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 few partici= pants vs. hundreds of listeners and talkers

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 individual = distribution of audio streams vs. IP multicast or RTP group communication

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 efficient e= ncoding of multiple streams having the same content (but different quality).

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0I bet I = missed some.

= = =A0

= To make things easier, why not to split the teleconferencing scenario in two: = High quality and Scalable?

= = =A0

= Th= e high quality scenario, intended for a low number of users, could have featu= res like

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Distributed= processing and mixing

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 High comput= ational resources to support spatial audio mixing (at the receiver) and multiple encodings of the same audio stream at different qualities (at the sender)

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Enough band= width to allow direct N to N transmissions of audio streams (no multicast or group communication). This would be good = for the latency, too.

= = =A0

= Th= e scalable scenario is the opposite:

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Central pro= cessing and mixing for many participants .

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 N to 1 and = 1 to N communication using efficient distribution mechanisms (RTP group communication and IP multicast).<= /font>

-=A0=A0=A0=A0=A0=A0=A0=A0=A0 Low complex= ity mixing of many using tricks like VAD, encoding at lowest rate to support many receivers having different paths, y= ou name it...

= = =A0

= Th= en, we need not to compare apples with oranges all the time.

= = =A0

= Ch= ristian

= = =A0

---------------------------------------------------= ------------

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
= http://www.net.uni-tuebingen.de/

= = =A0

From: codec-bounces@ietf.org [mailto:codec-b= ounces@ietf.org] On Behalf Of stephen botzk= o
Sent: Wednesday, April 21,= 2010 4:34 PM
To: Colin Perkins
Cc: trac@tools.ietf.org; codec@ietf.org
Subject: Re: [codec] #16: Multicast?

=A0

in-line

Stephen Botzko

On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins <csp@csperkins.org> wrote:

On 21 Apr 2010, at 12:20, Marshall Eubanks wrote:

On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote:

On 21 Apr 2010, at 10:42, codec issue tracker wrote:

#16: Multicast?
------------------------------------+----------------------------------
Reporter: =A0hoene@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Owner:
=A0Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Status: =A0new
Priority: =A0trivial =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone:
Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version:
Severity: =A0Active WG Document =A0 =A0 =A0| =A0 =A0Keywords:
------------------------------------+----------------------------------
The question arrose whether the interactive CODEC MUST support multicast in addition to teleconferencing.

On 04/13/2010 11:35 AM, Christian Hoene wrote:

P.S. On the same note, does anybody here cares about using this CODEC with multicast? Is the= re a single commercial multicast voice deployment? From what I've seen all m= ulticast does is making IETF voice standards harder to understand or implement.


I think that would be a mistake to ignore multicast - not because of multic= ast itself, but because of Xcast (RFC 5058) which is a promising technology to replace centralized conference bridges.


Regarding multicast:

I think we shall start at user requirements and scenarios. Teleconference (including mono or spatial audio) might be good starting point. Virtual environments like second live would require multicast communication, too. I= f the requirements of these scenarios are well understand, we can start to ta= lk about potential solutions like IP multicast, Xcast or conference bridges.



RTP is inherently a group communication protocol, and any codec designed fo= r use with RTP should consider operation in various different types of group communication scenario (not just multicast). RFC 5117 is a good place to st= art when considering the different types of topology in which RTP is used, and = the possible placement of mixing and switching functions which the codec will n= eed to work with.


It is not clear to me what supporting multicast would entail here. If this = is a codec over RTP, then what is to stop it from being multicast ?

=A0

Nothing. However group conferences implemented using multicast require end system mixing of potentially large numbers of active audio streams, whereas those implemente= d using conference bridges do the mixing in a single central location, and generally suppress all but one speaker. The differences in mixing and the number of simultaneous active streams that might be received potentially af= fect the design of the codec.


Conference bridges with central mixing almost always mix multiple speakers.=A0 As you add more streams into the mix, you reduce the chance of missing onset speech and interruptions, but raise the noise floor. So even = if complexity is not a consideration, there is value in gating the mixer (inst= ead of always doing a full mix-minus).

More on point, compressed domain mixing and easy detection of VAD have both been advocated on these lists, and both simplify the large-scale mixing problem.

=A0

=A0


--0016e68ac24664ef440484c33c31-- From hoene@uni-tuebingen.de Wed Apr 21 12:29:15 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD1D3A6B9B for ; Wed, 21 Apr 2010 12:29:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.196 X-Spam-Level: X-Spam-Status: No, score=-5.196 tagged_above=-999 required=5 tests=[AWL=1.053, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrUEAOshJxG9 for ; Wed, 21 Apr 2010 12:29:05 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id AC9683A6AB3 for ; Wed, 21 Apr 2010 12:27:28 -0700 (PDT) Received: from hoeneT60 ([178.2.215.255]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o3LJR6vu032235 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 21 Apr 2010 21:27:12 +0200 From: "Christian Hoene" To: "'stephen botzko'" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> In-Reply-To: Date: Wed, 21 Apr 2010 21:27:03 +0200 Message-ID: <002d01cae188$a330b2c0$e9921840$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002E_01CAE199.66B982C0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrhfziX4JGoQYrXTDa3JX/8e0fOvAABOaOg Content-Language: de X-AntiVirus-Spam-Check: clean (checked by Avira MailGate: version: 3.0.0-4; spam filter version: 3.0.0/2.0; host: mx05) X-AntiVirus: checked by Avira MailGate (version: 3.0.0-4; AVE: 8.2.1.220; VDF: 7.10.6.169; host: mx05); id=20827-yPTMMn Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 19:29:15 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002E_01CAE199.66B982C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, =20 if we take those two scenarios (high quality and scalable = teleconferencing), what are then the CODEC requirements? =20 High quality: - Quite the same requirement as an end-to-end audio = transmission: high quality and low latency. - Maybe additionally: variable bit rate encoding to achieve a = multiplexing gain at the receiver - and thus, a fast control loop to cope with variable bitrates = on transmission paths. - Maybe stereo/multichannel support to send the spatial audio = to the headphone or loudspeakers. =20 Scalable: - Efficient encoding/transcoding for multiple different = qualities (at the conference bridge) - The control loop must not react (fast) because (multicast) = group communication requires to encode at low quality anyhow. - Receiver side activity detection for music and voice having = low complexity (for the conference bridge) - Efficient mixing of two to four(?) active flows (is this = achievable without the complete process of decoding and encoding again?) =20 Are any teleconferencing requirements missing? =20 Christian =20 =20 =20 =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 From: stephen botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Wednesday, April 21, 2010 8:19 PM To: Christian Hoene Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? =20 Inline On Wed, Apr 21, 2010 at 1:27 PM, Christian Hoene = wrote: Hi Stephen, =20 not too bad. You answered faster than the mailing list distributes=85 Not sure how that happened!=20 =20 Comments inline: =20 =20 From: stephen botzko [mailto:stephen.botzko@gmail.com]=20 Sent: Wednesday, April 21, 2010 7:10 PM To: Christian Hoene Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? =20 I agree there are lots of use cases. Though I don't see why high quality has to be given up in order to be = scalable. =20 CH: These are just experiences from our lab. A spatial audio conference = server including the acoustic 3D sound rendering needs a LOT of processing power. In the end, we have to remain realistic. Processing = power is always limited thus if we need a lot then we cannot serve many clients. Also, I am not sure why you think central mixing is more scalable than = multicast (or why you think it is lower quality either). CH: With multicast, you need N times 1:N multicast distribution trees = (somewhat small tan O(n)=3Dn=B2). With central mixing you need N times 2 transmission paths (O(n)=3Dn). Also, this distributed mixing you = need N times the mixing at each client. With centralized, you can live with one mixing for all (and some tricks for serving the = talkers). I agree you need more distribution trees for multicast if you allow = every site to talk. There is a corresponding benefit, since there is no central choke point and also less bandwidth on shared WAN = links. In the distributed case, you don't need an N-way mixer at each client, = and you also don't need to continuously receive payload on all N streams at each client either. In practice you can cap N at a = relatively small number (in the 3-8 range) no matter how large the conference gets. In a large conference, you can even choose to drop = your comfort noise if you are receiving two or more streams, and just send enough to keep your firewall pinhole open. This = is all assuming a suitable voice activity measure in the RTP packet. Of course in the worst case, you will receive all N streams. =20 Cheers, Christian Stephen Botzko=20 On Wed, Apr 21, 2010 at 12:58 PM, Christian Hoene < = hoene@uni-tuebingen.de> wrote: Hi,=20 =20 the teleconferencing issue gets complex. I am trying to compile the = different requirements that have been mentioned on this list. - low complexity (with just one active speaker) vs. multiple = speaker mixing vs. spatial audio/stereo mixing - centralized vs. distributed - few participants vs. hundreds of listeners and talkers - individual distribution of audio streams vs. IP multicast or = RTP group communication - efficient encoding of multiple streams having the same = content (but different quality). - I bet I missed some. =20 To make things easier, why not to split the teleconferencing scenario in = two: High quality and Scalable? =20 The high quality scenario, intended for a low number of users, could = have features like - Distributed processing and mixing - High computational resources to support spatial audio mixing = (at the receiver) and multiple encodings of the same audio stream at different qualities (at the sender) - Enough bandwidth to allow direct N to N transmissions of = audio streams (no multicast or group communication). This would be good for the latency, too. =20 The scalable scenario is the opposite: - Central processing and mixing for many participants . - N to 1 and 1 to N communication using efficient distribution = mechanisms (RTP group communication and IP multicast). - Low complexity mixing of many using tricks like VAD, encoding = at lowest rate to support many receivers having different paths, you name it... =20 Then, we need not to compare apples with oranges all the time. =20 Christian =20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of stephen botzko Sent: Wednesday, April 21, 2010 4:34 PM To: Colin Perkins Cc: trac@tools.ietf.org; codec@ietf.org Subject: Re: [codec] #16: Multicast? =20 in-line Stephen Botzko On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins = wrote: On 21 Apr 2010, at 12:20, Marshall Eubanks wrote: On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote: On 21 Apr 2010, at 10:42, codec issue tracker wrote: #16: Multicast? ------------------------------------+---------------------------------- Reporter: hoene@=85 | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+---------------------------------- The question arrose whether the interactive CODEC MUST support multicast = in addition to teleconferencing. On 04/13/2010 11:35 AM, Christian Hoene wrote: P.S. On the same note, does anybody here cares about using this CODEC = with multicast? Is there a single commercial multicast voice deployment? From what I've seen all multicast does is making IETF voice = standards harder to understand or implement. I think that would be a mistake to ignore multicast - not because of = multicast itself, but because of Xcast (RFC 5058) which is a promising technology to replace centralized conference bridges. Regarding multicast: I think we shall start at user requirements and scenarios. = Teleconference (including mono or spatial audio) might be good starting point. Virtual environments like second live would require multicast = communication, too. If the requirements of these scenarios are well understand, we can start to talk about potential solutions like IP = multicast, Xcast or conference bridges. RTP is inherently a group communication protocol, and any codec designed = for use with RTP should consider operation in various different types of group communication scenario (not just multicast). = RFC 5117 is a good place to start when considering the different types of topology in which RTP is used, and the possible = placement of mixing and switching functions which the codec will need to work with. It is not clear to me what supporting multicast would entail here. If = this is a codec over RTP, then what is to stop it from being multicast ? =20 Nothing. However group conferences implemented using multicast require = end system mixing of potentially large numbers of active audio streams, whereas those implemented using conference bridges do the = mixing in a single central location, and generally suppress all but one speaker. The differences in mixing and the number of = simultaneous active streams that might be received potentially affect the design of the codec. Conference bridges with central mixing almost always mix multiple = speakers. As you add more streams into the mix, you reduce the chance of missing onset speech and interruptions, but raise the noise = floor. So even if complexity is not a consideration, there is value in gating the mixer (instead of always doing a full mix-minus). More on point, compressed domain mixing and easy detection of VAD have = both been advocated on these lists, and both simplify the large-scale mixing problem. --=20 Colin Perkins http://csperkins.org/ _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =20 =20 =20 ------=_NextPart_000_002E_01CAE199.66B982C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

if we take = those two scenarios (high quality and scalable teleconferencing), what are then the CODEC = requirements?

 

High = quality:

-          Quite the same requirement as an end-to-end audio transmission: high quality = and low latency.

-          Maybe additionally: variable bit rate encoding to achieve a multiplexing gain = at the receiver

-          and thus, a fast control loop to cope with variable bitrates on transmission = paths.

-          Maybe stereo/multichannel support to send the spatial audio to the headphone = or loudspeakers.

 

Scalable:=

-          Efficient encoding/transcoding for multiple different qualities (at the conference bridge)

-          The control loop must not react (fast) because (multicast) group = communication requires to encode at low quality anyhow.

-          Receiver side activity detection for music and voice having low complexity (for = the conference bridge)

-          Efficient mixing of two to four(?) active flows (is this achievable without the = complete process of decoding and encoding again?)

 

Are any = teleconferencing requirements missing?

 

=A0Christian

 

 

 

 

---------------------------------------------------------------=

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen =

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen= .de/

 

From: stephen botzko = [mailto:stephen.botzko@gmail.com]
Sent: Wednesday, April = 21, 2010 8:19 PM
To: Christian Hoene
Cc: codec@ietf.org
Subject: Re: [codec] #16: Multicast?

 

Inline

On Wed, Apr 21, 2010 at 1:27 PM, Christian Hoene <hoene@uni-tuebingen.de> = wrote:

Hi = Stephen,

 

=

not too bad. You answered faster than the mailing list = distributes…

Not sure how that happened!

 

Comments inline:

 

 

From: stephen botzko [mailto:stephen.botzko@gmail.com]
Sent: Wednesday, April = 21, 2010 7:10 PM
To: Christian Hoene
Cc: codec@ietf.org


Subject: Re: [codec] #16: Multicast?

 

I = agree there are lots of use cases.



Though I don't see why high quality has to be given up in order to be scalable. 

CH: These are just experiences from our lab. A spatial audio conference = server including the acoustic 3D sound rendering needs a LOT of processing = power. In the end, we have to remain realistic. Processing power is always limited = thus if we need a lot then we cannot serve many = clients.

Also, I am not sure why you think central = mixing is more scalable than multicast (or why you think it is lower quality = either).

CH: With multicast, you need N times 1:N multicast distribution trees = (somewhat small tan O(n)=3Dn=B2).  With central mixing you need N times 2 = transmission paths (O(n)=3Dn). Also, this distributed mixing you need N times the = mixing at each client. With centralized, you can live with one mixing for all (and = some tricks for serving the talkers).

I agree you need more distribution trees for multicast if you = allow every site to talk. There is a corresponding benefit, since there is no = central choke point and also less bandwidth on shared WAN links.

In the distributed case,  you don't need an N-way mixer at each = client, and you also don't need to continuously receive payload on all N streams = at each client either.  In practice you can cap N at a relatively = small number (in the 3-8 range) no matter how large the conference gets.  = In a large conference, you can even choose to drop your comfort noise if you = are receiving two or more streams, and just send enough to keep your = firewall pinhole open.  This is all assuming a suitable voice activity = measure in the RTP packet.  Of course in the worst case, you will receive all = N streams.
 

Cheers,<= /span>

 Ch= ristian


Stephen Botzko

On Wed, Apr 21, 2010 at 12:58 PM, Christian = Hoene <hoene@uni-tuebingen.de> = wrote:

Hi,

 

the teleconferencing issue gets complex. I am trying to compile the = different requirements that have been mentioned on this = list.

-        =   low complexity (with just one active speaker) = vs. multiple speaker mixing vs. spatial audio/stereo = mixing

-        =   centralized vs. = distributed

-        =   few participants vs. hundreds of listeners and = talkers

-        =   individual distribution of audio streams vs. IP multicast or RTP group communication

-        =   efficient encoding of multiple streams having = the same content (but different quality).

-        =    I bet I missed = some.

 

To make things easier, why not to split the teleconferencing scenario in = two: High quality and Scalable?

 

The high quality scenario, intended for a low number of users, could have = features like

-        =   Distributed processing and = mixing

-        =   High computational resources to support spatial = audio mixing (at the receiver) and multiple encodings of the same audio stream at = different qualities (at the sender)

-        =   Enough bandwidth to allow direct N to N = transmissions of audio streams (no multicast or group communication). This would be = good for the latency, too.

 

The scalable scenario is the opposite:

-        =   Central processing and mixing for many = participants .

-        =   N to 1 and 1 to N communication using efficient distribution mechanisms (RTP group communication and IP = multicast).

-        =   Low complexity mixing of many using tricks like = VAD, encoding at lowest rate to support many receivers having different = paths, you name it...

 

Then, we need not to compare apples with oranges all the = time.

 

Christian

 

-------------= --------------------------------------------------

Dr.-Ing. = Christian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen =

Sand 13, = 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen.de/=

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of stephen = botzko
Sent: Wednesday, April = 21, 2010 4:34 PM
To: Colin Perkins
Cc: trac@tools.ietf.org; codec@ietf.org
Subject: Re: [codec] #16: Multicast?

 

in-line

Stephen Botzko

On = Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins <csp@csperkins.org> = wrote:

On 21 = Apr 2010, at 12:20, Marshall Eubanks wrote:

On = Apr 21, 2010, at 6:48 AM, Colin Perkins wrote:

On 21 = Apr 2010, at 10:42, codec issue tracker wrote:

#16: = Multicast?
------------------------------------+---------------------------------- Reporter:  hoene@…             =     |       Owner:
 Type:  enhancement             = |      Status:  new
Priority:  trivial               =   |   Milestone:
Component:  requirements            | =     Version:
Severity:  Active WG Document      |   =  Keywords:
------------------------------------+---------------------------------- The question arrose whether the interactive CODEC MUST support multicast = in addition to teleconferencing.

On 04/13/2010 11:35 AM, Christian Hoene = wrote:

P.S. = On the same note, does anybody here cares about using this CODEC with multicast? Is = there a single commercial multicast voice deployment? From what I've seen all = multicast does is making IETF voice standards harder to understand or = implement.


I think that would be a mistake to ignore multicast - not because of = multicast itself, but because of Xcast (RFC 5058) which is a promising technology = to replace centralized conference bridges.


Regarding multicast:

I think we shall start at user requirements and scenarios. = Teleconference (including mono or spatial audio) might be good starting point. Virtual environments like second live would require multicast communication, = too. If the requirements of these scenarios are well understand, we can start to = talk about potential solutions like IP multicast, Xcast or conference = bridges.



RTP is inherently a group communication protocol, and any codec designed = for use with RTP should consider operation in various different types of = group communication scenario (not just multicast). RFC 5117 is a good place to = start when considering the different types of topology in which RTP is used, = and the possible placement of mixing and switching functions which the codec = will need to work with.


It is not clear to me what supporting multicast would entail here. If = this is a codec over RTP, then what is to stop it from being multicast = ?

 

Nothing. However group conferences implemented using multicast require end system mixing = of potentially large numbers of active audio streams, whereas those = implemented using conference bridges do the mixing in a single central location, and generally suppress all but one speaker. The differences in mixing and = the number of simultaneous active streams that might be received potentially = affect the design of the codec.


Conference bridges with central mixing almost always mix multiple speakers.  As you add more streams into the mix, you reduce the = chance of missing onset speech and interruptions, but raise the noise floor. So = even if complexity is not a consideration, there is value in gating the mixer = (instead of always doing a full mix-minus).

More on point, compressed domain mixing and easy detection of VAD have = both been advocated on these lists, and both simplify the large-scale mixing problem.


--
Colin Perkins
http://csperkins.org/



_______________________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/mailman/listinfo/codec

 

 

 

------=_NextPart_000_002E_01CAE199.66B982C0-- From rchen@broadcom.com Thu Apr 22 18:04:40 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70AEF3A67F7 for ; Thu, 22 Apr 2010 18:04:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=-0.650, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UnVW9tNcRW3H for ; Thu, 22 Apr 2010 18:04:22 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id F0F593A67F3 for ; Thu, 22 Apr 2010 18:04:21 -0700 (PDT) Received: from [10.9.200.131] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 22 Apr 2010 18:03:47 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Thu, 22 Apr 2010 18:03:47 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Christian Hoene" , "'stephen botzko'" Date: Thu, 22 Apr 2010 18:03:37 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrhfziX4JGoQYrXTDa3JX/8e0fOvAABOaOgADB221A= Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> In-Reply-To: <002d01cae188$a330b2c0$e9921840$@de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: CPE3 DCAO IeZT K//M O3Ww Pq5i RS6i RtlL TICS V/yK WcvW YVRv enaH eruJ f7LT hvQM; 3; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAaABvAGUAbgBlAEAAdQBuAGkALQB0AHUAZQBiAGkAbgBnAGUAbgAuAGQAZQA7AHMAdABlAHAAaABlAG4ALgBiAG8AdAB6AGsAbwBAAGcAbQBhAGkAbAAuAGMAbwBtAA==; Sosha1_v1; 7; {07308C3E-C940-4EE4-83D5-86951B3FEEF3}; cgBjAGgAZQBuAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0A; Fri, 23 Apr 2010 01:03:37 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAIwAxADYAOgAgAE0AdQBsAHQAaQBjAGEAcwB0AD8A x-cr-puzzleid: {07308C3E-C940-4EE4-83D5-86951B3FEEF3} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67CE2E7931G100486658-01-01 Content-Type: multipart/alternative; boundary=_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A017IRVEXCHCCR01c_ Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 01:04:40 -0000 --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A017IRVEXCHCCR01c_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hi Christian, My comments about your question of CODEC requirements are in-line. Raymond From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of C= hristian Hoene Sent: Wednesday, April 21, 2010 12:27 PM To: 'stephen botzko' Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? Hi, if we take those two scenarios (high quality and scalable teleconferencing)= , what are then the CODEC requirements? High quality: - Quite the same requirement as an end-to-end audio transmission: = high quality and low latency. [Raymond]: High quality is a given, but I would like to emphasize the impor= tance of low latency. (1) It is well-known that the longer the latency, the lower the perceived q= uality of the communication link. The E-model in the ITU-T Recommendation = G.107 models such communication quality in MOS_cqe, which among other thing= s depends on the so-called "delay impairment factor" Id. Basically, MOS_cq= e is a monotonically decreasing function of increasing latency, and beyond = about 150 ms one-way delay, the perceived quality of the communication link= drops rapidly with further delay increase. (2) The lower the latency, the less audible the echo, and thus the lower th= e required echo return loss. Hence, lower latency means easier echo contro= l and simpler echo canceller, and as people already mentioned previously, b= elow a certain delay, an echo is simply perceived as a harmless side-tone a= nd no echo canceller is needed. It seems to me that echo control in confere= nce calls is more difficult than in point-to-point calls. While I hardly e= ver heard echoes in domestic point-to-point calls, in my experience with co= nference calls at work, even with the G.711 codec (which has almost no dela= y), sometimes I still hear echoes (I just heard another one this afternoon)= . If a relatively long-delay IETF codec is used, the echo control will be = even more problematic. (3) In normal phone calls or conference calls, people routinely have a need= to interrupt each other, but beyond a certain point, long latency makes it= very difficult for people to interrupt each other on the call. This is be= cause when you try to interrupt another person, that person doesn't hear yo= ur interruption until a certain time later, so he keeps talking, but when y= ou hear that he did not stop talking when you interrupted, you stop; then, = he hears your interruption, so he stops. When you hear he stops, you start = talking again, but then he also hears you stopped (due to the long delay), = so he also starts talking again. The net result is that with a long latenc= y, when you try to interrupt him, you and he end up stopping and starting a= t roughly the same time for a few cycles, making it difficult to interrupt = each other. (4) We need to keep in mind that the IETF codec may not be the only codec i= nvolved in a phone call or a conference call. We cannot assume that all co= nference call participants will be using a computer to conduct the call. No= t only do people use cell phones for point-to-point phone calls, they also = often use cell phones to call in to conference calls. The one-way delay fo= r a cell phone call through one carriers network is typically around 80 to = 110 ms. A call from a cell phone in a carrier network to another cell phon= e in a different type of carrier network can easily double this delay to 16= 0 ~ 220 ms and makes the total one-way delay already far exceeding the 150 = ms mentioned in (1) above. Any coding delay added by the IETF codec will b= e on top of that long delay, and such coding delay will be applied twice wh= en both cell phones call through the IETF codec to a conference bridge. Ev= en without the IETF codec delay, when I previously called from a Verizon ce= ll phone to an AT&T cell phone, I already experienced the problem mentioned= in (3) sometimes. If the IETF codec has a relatively long delay, adding t= wo times the IETF codec one-way delay to the already long delay of 160 ~ 22= 0 ms will make the situation much worse. Even if just one cell phone is in= volved in a conference call, adding twice the one-way delay of a relatively= long-delay IETF codec can still easily push the total one-way delay beyond= 150 ms. To summarize, my point is that to help reduce potential echo problems and t= o ensure a high-quality experience in such a conference call, the IETF code= c should have a delay as low as possible while maintaining good enough spee= ch quality and a reasonable bit-rate. - Maybe additionally: variable bit rate encoding to achieve a mult= iplexing gain at the receiver - and thus, a fast control loop to cope with variable bitrates on = transmission paths. - Maybe stereo/multichannel support to send the spatial audio to t= he headphone or loudspeakers. Scalable: - Efficient encoding/transcoding for multiple different qualities = (at the conference bridge) [Raymond]: I am not sure whether by "efficient", you meant coding efficienc= y or computational efficiency. In any case, I would like to take this oppo= rtunity to express my view that although codec complexity isn't much of an = issue for PC-to-PC calls where there are GHz of processing power available,= the codec complexity is an important issue in certain application scenario= s. The following are just some examples. 1) If a conference bridge has to decode a large number of voice channels, m= ix, and re-encode, and if compressed-domain mixing cannot be done (which is= usually the case), then it is important to keep the decoder complexity low= . 2) In topology b) of your other email (IPend-to-transcoding_gateway-to-PSTN= end), the transcoding gateway, or VoIP gateway, often has to encode and dec= ode thousands of voice channels in a single box, so not only the computatio= nal complexity, but also the per-instance RAM size requirement of the codec= become very important for achieving high channel density in the gateway. 3) Many telephone terminal devices at the edge of the Internet use embedded= processors with limited processing power, and the processors also have to = handle many tasks other than speech coding. If the IETF codec complexity i= s too high, some of such devices may not have sufficient processing power t= o run it. Even if the codec can fit, some battery-powered mobile devices m= ay prefer to run a lower-complexity codec to reduce power consumption and b= attery drain. For example, even if you make a Internet phone call from a c= omputer, you may like the convenience of using a Bluetooth headset that all= ows you to walk around a bit and have hands-free operation. Currently most= Bluetooth headsets have small form factors with a tiny battery. This puts= a severe constraint on power consumption. Bluetooth headset chips typical= ly have very limited processing capability, and it has to handle many other= tasks such as echo cancellation and noise reduction. There is just not en= ough processing power to handle a relatively high-complexity codec. Most B= T headsets today relies on the extremely low-complexity, hardware-based CVS= D codec at 64 kb/s to transmit narrowband voice, but CVSD has audible codin= g noise, so it degrades the overall audio quality. If the IETF codec has l= ow enough complexity, it would be possible to directly encode and decode th= e IETF codec bit-stream at the BT headset, thus avoiding the quality degrad= ation of CVSD transcoding. In summary, my point is that the IETF codec should attempt to achieve a cod= ec complexity as low as possible in both MHz consumption and RAM size requi= rement while maintaining good enough speech quality. - The control loop must not react (fast) because (multicast) group= communication requires to encode at low quality anyhow. - Receiver side activity detection for music and voice having low = complexity (for the conference bridge) - Efficient mixing of two to four(?) active flows (is this achieva= ble without the complete process of decoding and encoding again?) Are any teleconferencing requirements missing? Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ From: stephen botzko [mailto:stephen.botzko@gmail.com] Sent: Wednesday, April 21, 2010 8:19 PM To: Christian Hoene Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? Inline On Wed, Apr 21, 2010 at 1:27 PM, Christian Hoene > wrote: Hi Stephen, not too bad. You answered faster than the mailing list distributes... Not sure how that happened! Comments inline: From: stephen botzko [mailto:stephen.botzko@gmail.com] Sent: Wednesday, April 21, 2010 7:10 PM To: Christian Hoene Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? I agree there are lots of use cases. Though I don't see why high quality has to be given up in order to be scala= ble. CH: These are just experiences from our lab. A spatial audio conference ser= ver including the acoustic 3D sound rendering needs a LOT of processing pow= er. In the end, we have to remain realistic. Processing power is always lim= ited thus if we need a lot then we cannot serve many clients. Also, I am not sure why you think central mixing is more scalable than mult= icast (or why you think it is lower quality either). CH: With multicast, you need N times 1:N multicast distribution trees (some= what small tan O(n)=3Dn=B2). With central mixing you need N times 2 transm= ission paths (O(n)=3Dn). Also, this distributed mixing you need N times the= mixing at each client. With centralized, you can live with one mixing for = all (and some tricks for serving the talkers). I agree you need more distribution trees for multicast if you allow every s= ite to talk. There is a corresponding benefit, since there is no central ch= oke point and also less bandwidth on shared WAN links. In the distributed case, you don't need an N-way mixer at each client, and= you also don't need to continuously receive payload on all N streams at ea= ch client either. In practice you can cap N at a relatively small number (= in the 3-8 range) no matter how large the conference gets. In a large conf= erence, you can even choose to drop your comfort noise if you are receiving= two or more streams, and just send enough to keep your firewall pinhole op= en. This is all assuming a suitable voice activity measure in the RTP pack= et. Of course in the worst case, you will receive all N streams. Cheers, Christian Stephen Botzko On Wed, Apr 21, 2010 at 12:58 PM, Christian Hoene > wrote: Hi, the teleconferencing issue gets complex. I am trying to compile the differe= nt requirements that have been mentioned on this list. - low complexity (with just one active speaker) vs. multiple speak= er mixing vs. spatial audio/stereo mixing - centralized vs. distributed - few participants vs. hundreds of listeners and talkers - individual distribution of audio streams vs. IP multicast or RTP= group communication - efficient encoding of multiple streams having the same content (= but different quality). - I bet I missed some. To make things easier, why not to split the teleconferencing scenario in tw= o: High quality and Scalable? The high quality scenario, intended for a low number of users, could have f= eatures like - Distributed processing and mixing - High computational resources to support spatial audio mixing (at= the receiver) and multiple encodings of the same audio stream at different= qualities (at the sender) - Enough bandwidth to allow direct N to N transmissions of audio s= treams (no multicast or group communication). This would be good for the la= tency, too. The scalable scenario is the opposite: - Central processing and mixing for many participants . - N to 1 and 1 to N communication using efficient distribution mec= hanisms (RTP group communication and IP multicast). - Low complexity mixing of many using tricks like VAD, encoding at= lowest rate to support many receivers having different paths, you name it.= .. Then, we need not to compare apples with oranges all the time. Christian --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ From: codec-bounces@ietf.org [mailto:codec-b= ounces@ietf.org] On Behalf Of stephen botzko Sent: Wednesday, April 21, 2010 4:34 PM To: Colin Perkins Cc: trac@tools.ietf.org; codec@ietf.org Subject: Re: [codec] #16: Multicast? in-line Stephen Botzko On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins > wrote: On 21 Apr 2010, at 12:20, Marshall Eubanks wrote: On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote: On 21 Apr 2010, at 10:42, codec issue tracker wrote: #16: Multicast? ------------------------------------+---------------------------------- Reporter: hoene@... | Owner: Type: enhancement | Status: new Priority: trivial | Milestone: Component: requirements | Version: Severity: Active WG Document | Keywords: ------------------------------------+---------------------------------- The question arrose whether the interactive CODEC MUST support multicast in= addition to teleconferencing. On 04/13/2010 11:35 AM, Christian Hoene wrote: P.S. On the same note, does anybody here cares about using this CODEC with = multicast? Is there a single commercial multicast voice deployment? From wh= at I've seen all multicast does is making IETF voice standards harder to un= derstand or implement. I think that would be a mistake to ignore multicast - not because of multic= ast itself, but because of Xcast (RFC 5058) which is a promising technology= to replace centralized conference bridges. Regarding multicast: I think we shall start at user requirements and scenarios. Teleconference (= including mono or spatial audio) might be good starting point. Virtual envi= ronments like second live would require multicast communication, too. If th= e requirements of these scenarios are well understand, we can start to talk= about potential solutions like IP multicast, Xcast or conference bridges. RTP is inherently a group communication protocol, and any codec designed fo= r use with RTP should consider operation in various different types of grou= p communication scenario (not just multicast). RFC 5117 is a good place to = start when considering the different types of topology in which RTP is used= , and the possible placement of mixing and switching functions which the co= dec will need to work with. It is not clear to me what supporting multicast would entail here. If this = is a codec over RTP, then what is to stop it from being multicast ? Nothing. However group conferences implemented using multicast require end = system mixing of potentially large numbers of active audio streams, whereas= those implemented using conference bridges do the mixing in a single centr= al location, and generally suppress all but one speaker. The differences in= mixing and the number of simultaneous active streams that might be receive= d potentially affect the design of the codec. Conference bridges with central mixing almost always mix multiple speakers.= As you add more streams into the mix, you reduce the chance of missing on= set speech and interruptions, but raise the noise floor. So even if complex= ity is not a consideration, there is value in gating the mixer (instead of = always doing a full mix-minus). More on point, compressed domain mixing and easy detection of VAD have both= been advocated on these lists, and both simplify the large-scale mixing pr= oblem. -- Colin Perkins http://csperkins.org/ _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A017IRVEXCHCCR01c_ Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Christian,

 

My comments about your question of CODEC requirements are in-li= ne.

 

Raymond

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Christian Hoene
Sent: Wednesday, April 21, 2010 12:27 PM
To: 'stephen botzko'
Cc: codec@ietf.org
Subject: Re: [codec] #16: Multicast?

 

Hi,

 

if we take those two scenarios (high quality and scalable teleconferencing), what are then the CODEC requirements?<= /p>

 

High quality:

-&nb= sp;         Quite the same requirement as an end-to-end audio transmissi= on: high quality and low latency.

[Raymond]: High quality is a given, but I would like to emphasi= ze the importance of low latency.

(1) It is well-known that the longer the latency, the lower the perceived quality of the communication link.=A0 The E-model in the ITU-T Recommendation G.107 models such communication quality in MOS_cqe, which am= ong other things depends on the so-called “delay impairment factor”= Id.=A0 Basically, MOS_cqe is a monotonically decreasing function of increasing lat= ency, and beyond about 150 ms one-way delay, the perceived quality of the communication link drops rapidly with further delay increase.

(2) The lower the latency, the less audible the echo, and thus = the lower the required echo return loss.=A0 Hence, lower latency means easier e= cho control and simpler echo canceller, and as people already mentioned previou= sly, below a certain delay, an echo is simply perceived as a harmless side-tone = and no echo canceller is needed. It seems to me that echo control in conference calls is more difficult than in point-to-point calls.=A0 While I hardly eve= r heard echoes in domestic point-to-point calls, in my experience with conference c= alls at work, even with the G.711 codec (which has almost no delay), sometimes I still hear echoes (I just heard another one this afternoon).=A0 If a relati= vely long-delay IETF codec is used, the echo control will be even more problemat= ic.

(3) In normal phone calls or conference calls, people routinely have a need to interrupt each other, but beyond a certain point, long laten= cy makes it very difficult for people to interrupt each other on the call.=A0 = This is because when you try to interrupt another person, that person doesn̵= 7;t hear your interruption until a certain time later, so he keeps talking, but when you hear that he did not stop talking when you interrupted, you stop; then, he hears your interruption, so he stops. When you hear he stops, you start talking again, but then he also hears you stopped (due to the long delay), so he also starts talking again.=A0 The net result is that with a l= ong latency, when you try to interrupt him, you and he end up stopping and star= ting at roughly the same time for a few cycles, making it difficult to interrupt each other.

(4) We need to keep in mind that the IETF codec may not be the = only codec involved in a phone call or a conference call. =A0We cannot assume th= at all conference call participants will be using a computer to conduct the call. = Not only do people use cell phones for point-to-point phone calls, they also of= ten use cell phones to call in to conference calls. =A0The one-way delay for a cell= phone call through one carriers network is typically around 80 to 110 ms. =A0A ca= ll from a cell phone in a carrier network to another cell phone in a different= type of carrier network can easily double this delay to 160 ~ 220 ms and makes t= he total one-way delay already far exceeding the 150 ms mentioned in (1) above= . =A0Any coding delay added by the IETF codec will be on top of that long delay, and= such coding delay will be applied twice when both cell phones call through the I= ETF codec to a conference bridge.=A0 Even without the IETF codec delay, when I previously called from a Verizon cell phone to an AT&T cell phone, I already experienced the problem mentioned in (3) sometimes.=A0 If the IETF = codec has a relatively long delay, adding two times the IETF codec one-way delay = to the already long delay of 160 ~ 220 ms will make the situation much worse.= =A0 Even if just one cell phone is involved in a conference call, adding twice = the one-way delay of a relatively long-delay IETF codec can still easily push t= he total one-way delay beyond 150 ms.

To summarize, my point is that to help reduce potential echo problems and to ensure a high-quality experience in such a conference call,= the IETF codec should have a delay as low as possible while maintaining good en= ough speech quality and a reasonable bit-rate.

-&nb= sp;         Maybe additionally: variable bit rate encoding to achieve a multiplexing gain at the receiver

-&nb= sp;         and thus, a fast control loop to cope with variable bitrates= on transmission paths.

-&nb= sp;         Maybe stereo/multichannel support to send the spatial audio = to the headphone or loudspeakers.

 

Scalable:

-&nb= sp;         Efficient encoding/transcoding for multiple different qualit= ies (at the conference bridge)

[Raymond]: I am not sure whether by “efficient”, yo= u meant coding efficiency or computational efficiency.=A0 In any case, I woul= d like to take this opportunity to express my view that although codec complexity = isn’t much of an issue for PC-to-PC calls where there are GHz of processing power available, the codec complexity is an important issue in certain applicatio= n scenarios.=A0 The following are just some examples.

1) If a conference bridge has to decode a large number of voice channels, mix, and re-encode, and if compressed-domain mixing cannot be don= e (which is usually the case), then it is important to keep the decoder complexity low.

2) In topology b) of your other email (IPend-to-transcoding_gat= eway-to-PSTNend), the transcoding gateway, or VoIP gateway, often has to encode and decode thousands of voice channels in a single box, so not only the computational complexity, but also the per-instance RAM size requirement of the codec bec= ome very important for achieving high channel density in the gateway.

3) Many telephone terminal devices at the edge of the Internet = use embedded processors with limited processing power, and the processors also = have to handle many tasks other than speech coding.=A0 If the IETF codec complex= ity is too high, some of such devices may not have sufficient processing power to = run it.=A0 Even if the codec can fit, some battery-powered mobile devices may prefer t= o run a lower-complexity codec to reduce power consumption and battery drain.= =A0 For example, even if you make a Internet phone call from a computer, you ma= y like the convenience of using a Bluetooth headset that allows you to walk around a bit and have hands-free operation.=A0 Currently most Bluetooth hea= dsets have small form factors with a tiny battery.=A0 This puts a severe constrai= nt on power consumption.=A0 Bluetooth headset chips typically have very limited processing capability, and it has to handle many other tasks such as echo cancellation and noise reduction.=A0 There is just not enough processing po= wer to handle a relatively high-complexity codec.=A0 Most BT headsets today relies= on the extremely low-complexity, hardware-based CVSD codec at 64 kb/s to transmit narrowband voice, but CVSD has audible coding noise, so it degrades the ove= rall audio quality.=A0 If the IETF codec has low enough complexity, it would be possible to directly encode and decode the IETF codec bit-stream at the BT headset, thus avoiding the quality degradation of CVSD transcoding.

In summary, my point is that the IETF codec should attempt to achieve a codec complexity as low as possible in both MHz consumption and R= AM size requirement while maintaining good enough speech quality.

-&nb= sp;         The control loop must not react (fast) because (multicast) g= roup communication requires to encode at low quality anyhow.

-&nb= sp;         Receiver side activity detection for music and voice having = low complexity (for the conference bridge)

-&nb= sp;         Efficient mixing of two to four(?) active flows (is this achievable without the complete process of decoding and encoding again?)

 

Are any teleconferencing requirements missing?

 

=A0Christian

 

 

 

 

------------------------------------------------------------= ---

Dr.-Ing. Christian Hoene

Interactive Communication Systems (ICS), University of T=FCb= ingen

Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 <= br> http://www.net= .uni-tuebingen.de/

 

From: ste= phen botzko [mailto:stephen.botzko@gmail.com]
Sent: Wednesday, April 21, 2010 8:19 PM
To: Christian Hoene
Cc: codec@ietf.org
Subject: Re: [codec] #16: Multicast?

 

Inline<= o:p>

On Wed, Apr 21, 2010 at 1:27 PM, Chris= tian Hoene <hoene@uni-tuebingen.de<= /a>> wrote:

Hi Stephen,

 

not too bad. You answered faster than the mailing list distributes…

Not sure how that happened!

 

Comments inline:

 

 

From: stephen botzk= o [mailto:steph= en.botzko@gmail.com]
Sent: Wednesday, April 21, 2010 7:10 PM
To: Christian Hoene
Cc: codec@ietf.o= rg


Subject: Re: [codec] #16: Multicast?

 

I agree there are lots of use cases.



Though I don't see why high quality has to be given up in order to be scalable. 

CH: These are just experiences from our lab. A spatial audio conference server including the acoustic 3D sound rendering needs a LOT of processing power. = In the end, we have to remain realistic. Processing power is always limited th= us if we need a lot then we cannot serve many clients.<= o:p>

Also, I am not sure why you think central mixing is more scalable than multicast (o= r why you think it is lower quality either).

CH: With multicast, you need N times 1:N multicast distribution trees (somewhat small tan O(n)=3Dn=B2).  With central mixing you need N times 2 transm= ission paths (O(n)=3Dn). Also, this distributed mixing you need N times the mixing= at each client. With centralized, you can live with one mixing for all (and so= me tricks for serving the talkers).

I agree you need more distribution tre= es for multicast if you allow every site to talk. There is a corresponding benefit= , since there is no central choke point and also less bandwidth on shared WAN links.

In the distributed case,  you don't need an N-way mixer at each client= , and you also don't need to continuously receive payload on all N streams at each client either.  In practice you can cap N at a relatively small number (in the 3-8 range) no matter how large the conference gets.  In= a large conference, you can even choose to drop your comfort noise if you are receiving two or more streams, and just send enough to keep your firewall pinhole open.  This is all assuming a suitable voice activity measure = in the RTP packet.  Of course in the worst case, you will receive all N streams.
 

Cheers,

 Christian


Stephen Botzko

On Wed, Apr 21, 2010 at 12:58 PM, Christian Hoene <hoene@uni-tuebingen.de> wrote:

Hi,

 

the teleconferencing issue gets complex. I am trying to compile the different requirements that have been mentioned on this list.<= o:p>

-      = ;    low complexity (with just one active speaker) vs. multiple speaker mixing vs. spatial audio/stereo mixing<= /o:p>

-      = ;    centralized vs. distributed

-      = ;    few participants vs. hundreds of listeners and talkers

-      = ;    individual distribution of audio streams vs. IP multicast or= RTP group communication

-      = ;    efficient encoding of multiple streams having the same conte= nt (but different quality).

-      = ;     I bet I missed some.=

 

To make things easier, why not to split the teleconferencing scenario in two: = High quality and Scalable?

 

The high quality scenario, intended for a low number of users, could have features l= ike

-      = ;    Distributed processing and mixing

-      = ;    High computational resources to support spatial audio mixing= (at the receiver) and multiple encodings of the same audio stream at different qualities (at the sender)

-      = ;    Enough bandwidth to allow direct N to N transmissions of aud= io streams (no multicast or group communication). This would be good for the latency, too.

 

The scalable scenario is the opposite:=

-      = ;    Central processing and mixing for many participants .=

-      = ;    N to 1 and 1 to N communication using efficient distribution mechanisms (RTP group communication and IP multicast).

-      = ;    Low complexity mixing of many using tricks like VAD, encodin= g at lowest rate to support many receivers having different paths, you name it..= .

 

Then, we need not to compare apples with oranges all the time.

 

Christian

 

-------------= --------------------------------------------------

Dr.-Ing. Chri= stian Hoene

Interactive Communication Systems (ICS), University of T=FCbingen

Sand 13, 7207= 6 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.net.uni-tuebingen.de/

 

From= : codec-bounces@ietf= .org [mailto:codec-b= ounces@ietf.org] On Behalf Of stephen botzko
Sent: Wednesday, April 21, 2010 4:34 PM
To: Colin Perkins
Cc: trac@to= ols.ietf.org; codec@ietf.org
Subject: Re: [codec] #16: Multicast?

 

in-line

Stephen Botzko

On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins <csp@csperkins.org&g= t; wrote:

On 21 Apr 2010, at 12:20, Marshall Eubanks wrote:

On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote:

On 21 Apr 2010, at 10:42, codec issue tracker wrote:

#16: Multicast?
------------------------------------+----------------------------------
Reporter:  hoene@…             &nb= sp;   |       Owner:
 Type:  enhancement             |      Status:  new
Priority:  trivial               &n= bsp; |   Milestone:
Component:  requirements            | &n= bsp;   Version:
Severity:  Active WG Document      |    Keywo= rds:
------------------------------------+----------------------------------
The question arrose whether the interactive CODEC MUST support multicast in addition to teleconferencing.

On 04/13/2010 11:35 AM, Christian Hoene wrote:

P.S. On the same note, does anybody here cares about using this C= ODEC with multicast? Is there a single commercial multicast voice deployment? Fr= om what I've seen all multicast does is making IETF voice standards harder to understand or implement.


I think that would be a mistake to ignore multicast - not because of multic= ast itself, but because of Xcast (RFC 5058) which is a promising technology to replace centralized conference bridges.


Regarding multicast:

I think we shall start at user requirements and scenarios. Teleconference (including mono or spatial audio) might be good starting point. Virtual environments like second live would require multicast communication, too. I= f the requirements of these scenarios are well understand, we can start to ta= lk about potential solutions like IP multicast, Xcast or conference bridges.



RTP is inherently a group communication protocol, and any codec designed fo= r use with RTP should consider operation in various different types of group communication scenario (not just multicast). RFC 5117 is a good place to st= art when considering the different types of topology in which RTP is used, and = the possible placement of mixing and switching functions which the codec will n= eed to work with.


It is not clear to me what supporting multicast would entail here. If this = is a codec over RTP, then what is to stop it from being multicast ?

 

Nothing. However group conferences implemented using multicast re= quire end system mixing of potentially large numbers of active audio streams, whe= reas those implemented using conference bridges do the mixing in a single centra= l location, and generally suppress all but one speaker. The differences in mi= xing and the number of simultaneous active streams that might be received potentially affect the design of the codec.


Conference bridges with central mixing almost always mix multiple speakers.  As you add more streams into the mix, you reduce the chance= of missing onset speech and interruptions, but raise the noise floor. So even = if complexity is not a consideration, there is value in gating the mixer (inst= ead of always doing a full mix-minus).

More on point, compressed domain mixing and easy detection of VAD have both been advocated on these lists, and both simplify the large-scale mixing problem.

 

 

 

--_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A017IRVEXCHCCR01c_-- From jean-marc.valin@usherbrooke.ca Thu Apr 22 21:04:45 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 45E1C3A68F0 for ; Thu, 22 Apr 2010 21:04:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcRh-jTHhCJj for ; Thu, 22 Apr 2010 21:04:44 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 42CF03A68D8 for ; Thu, 22 Apr 2010 21:04:44 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=windows-1252; format=flowed Received: from [192.168.1.10] ([70.81.109.112]) by VL-MO-MR003.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0L1B00G3K9ZK74F0@VL-MO-MR003.ip.videotron.ca> for codec@ietf.org; Fri, 23 Apr 2010 00:04:33 -0400 (EDT) Message-id: <4BD11C50.2020206@usherbrooke.ca> Date: Fri, 23 Apr 2010 00:04:32 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 To: "Raymond (Juin-Hwey) Chen" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> In-reply-to: Cc: "codec@ietf.org" , 'stephen botzko' Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 04:04:45 -0000 Hi, See me comments below. > [Raymond]: High quality is a given, but I would like to emphasize the > importance of low latency. > > (1) It is well-known that the longer the latency, the lower the > perceived quality of the communication link. The E-model in the ITU-T > Recommendation G.107 models such communication quality in MOS_cqe, > which among other things depends on the so-called “delay impairment > factor” /Id/. Basically, MOS_cqe is a monotonically decreasing > function of increasing latency, and beyond about 150 ms one-way delay, > the perceived quality of the communication link drops rapidly with > further delay increase. > As the author of CELT, I obviously agree that latency is an important aspect for this codec :-) That being said, I tend to say that 20 ms is still the most widely used frame size, so we might as well optimise for that. This is not really a problem because as the frame size goes down, the overhead of the IP/UDP/RTP headers go up, so the codec bit-rate becomes a bit less of an issue. For example, with 5 ms frames, we would already be sending 64 kb/s worth of headers (excluding the link layer), so we might as well spend about as many bits on the actual payload as we spend on the headers. And with 64 kb/s of payload, we can actually have high-quality full-band audio. > 1) If a conference bridge has to decode a large number of voice > channels, mix, and re-encode, and if compressed-domain mixing cannot > be done (which is usually the case), then it is important to keep the > decoder complexity low. Definitely agree here. The decoder complexity is very important. Not only because of mixing issue, but also because the decoder is generally not allowed to take shortcuts to save on complexity (unlike the encoder). As for compressed-domain mixing, as you say it is not always available, but *if* we can do it (even if only partially), then that can result in a "free" reduction in decoder complexity for mixing. > 2) In topology b) of your other email > (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, or > VoIP gateway, often has to encode and decode thousands of voice > channels in a single box, so not only the computational complexity, > but also the per-instance RAM size requirement of the codec become > very important for achieving high channel density in the gateway. > Agreed here, although I would say that per-instance RAM -- as long as it's reasonable -- is probably a bit less important than complexity. > 3) Many telephone terminal devices at the edge of the Internet use > embedded processors with limited processing power, and the processors > also have to handle many tasks other than speech coding. If the IETF > codec complexity is too high, some of such devices may not have > sufficient processing power to run it. Even if the codec can fit, some > battery-powered mobile devices may prefer to run a lower-complexity > codec to reduce power consumption and battery drain. For example, even > if you make a Internet phone call from a computer, you may like the > convenience of using a Bluetooth headset that allows you to walk > around a bit and have hands-free operation. Currently most Bluetooth > headsets have small form factors with a tiny battery. This puts a > severe constraint on power consumption. Bluetooth headset chips > typically have very limited processing capability, and it has to > handle many other tasks such as echo cancellation and noise reduction. > There is just not enough processing power to handle a relatively > high-complexity codec. Most BT headsets today relies on the extremely > low-complexity, hardware-based CVSD codec at 64 kb/s to transmit > narrowband voice, but CVSD has audible coding noise, so it degrades > the overall audio quality. If the IETF codec has low enough > complexity, it would be possible to directly encode and decode the > IETF codec bit-stream at the BT headset, thus avoiding the quality > degradation of CVSD transcoding. > Any idea what the complexity requirements would be for this use-case to be possible? Cheers, Jean-Marc From koen.vos@skype.net Fri Apr 23 01:16:16 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39A123A6943 for ; Fri, 23 Apr 2010 01:16:16 -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.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2RHNBHpX7-Ne for ; Fri, 23 Apr 2010 01:16:13 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id F21CB3A6992 for ; Fri, 23 Apr 2010 01:16:12 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 75BBE6012CE22 for ; Fri, 23 Apr 2010 09:16:01 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=fF9svSDjex49 uTsaLh95tAbSadw=; b=ZSwCG3lt9uCChvc9A6gtMcNJurYRzr37fEE7V0DRzd5h riKqk7VSHv4LzmM4PUIz4htzZMdHneRpmeOcy7VJXRHX+I5YAbu1xobcfbH3quq9 IhGE0qtZ4pBxdqhV1PEsv4pJoeMXpEVg33fyl97GoIMpm5T/gV4viYNS/qeeI0U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=pv14GDU2IEwN4SGyicis 4uks36VfGg4T0To5VEysL5b4kC930xVCZs+0KyuLIBslGeMK5uF6knjDVuN25Dah eovREUouSCrwD7ldlzf8B7vEBYkk+zwsvQXVnN9pkFujgcosARotzyhpxLrl+3E2 z34RrR/gCMbvxdRa4rnlFZ4= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 73CF56012CE21 for ; Fri, 23 Apr 2010 09:16:01 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vtFEaXv-odRm for ; Fri, 23 Apr 2010 09:15:59 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id D71826012CE20; Fri, 23 Apr 2010 09:15:59 +0100 (IST) Received: from 12.68.40.34 ([12.68.40.34]) by mail.skype.net (Horde Framework) with HTTP; Fri, 23 Apr 2010 01:15:59 -0700 Message-ID: <20100423011559.20246ayxdicd9vzz@mail.skype.net> Date: Fri, 23 Apr 2010 01:15:59 -0700 From: Koen Vos To: codec@ietf.org References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Apr 2010 08:16:16 -0000 By the time the BlueTooth Special Interest Group will have adopted a =20 future IETF codec standard, Moore's law will surely have multiplied =20 CPU resources in the BT device by one order of magnitude..? Not sure =20 it makes sense to apply today's BT constraints to tomorrow's codec. I'm not even convinced BlueTooth is a relevant use case for an =20 Internet codec. BT devices are audio devices more than VoIP end =20 points: BT always connects to the Internet through another device. =20 You could simply first decode incoming packets and send PCM data to =20 the BT device, or use a high-quality/high-bitrate codec like G.722. =20 The requirements for BT devices and the Internet are just too =20 different. Similarly, GSM phones use AMR on the network side and a =20 different codec towards the BT device. The required transcoding =20 causes no quality problems because BT supports high bitrates. best, koen. Quoting Raymond (Juin-Hwey) Chen: > Hi Christian, > > My comments about your question of CODEC requirements are in-line. > > Raymond > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 > Behalf Of Christian Hoene > Sent: Wednesday, April 21, 2010 12:27 PM > To: 'stephen botzko' > Cc: codec@ietf.org > Subject: Re: [codec] #16: Multicast? > > Hi, > > if we take those two scenarios (high quality and scalable =20 > teleconferencing), what are then the CODEC requirements? > > High quality: > > - Quite the same requirement as an end-to-end audio =20 > transmission: high quality and low latency. > [Raymond]: High quality is a given, but I would like to emphasize =20 > the importance of low latency. > (1) It is well-known that the longer the latency, the lower the =20 > perceived quality of the communication link. The E-model in the =20 > ITU-T Recommendation G.107 models such communication quality in =20 > MOS_cqe, which among other things depends on the so-called "delay =20 > impairment factor" Id. Basically, MOS_cqe is a monotonically =20 > decreasing function of increasing latency, and beyond about 150 ms =20 > one-way delay, the perceived quality of the communication link drops =20 > rapidly with further delay increase. > (2) The lower the latency, the less audible the echo, and thus the =20 > lower the required echo return loss. Hence, lower latency means =20 > easier echo control and simpler echo canceller, and as people =20 > already mentioned previously, below a certain delay, an echo is =20 > simply perceived as a harmless side-tone and no echo canceller is =20 > needed. It seems to me that echo control in conference calls is more =20 > difficult than in point-to-point calls. While I hardly ever heard =20 > echoes in domestic point-to-point calls, in my experience with =20 > conference calls at work, even with the G.711 codec (which has =20 > almost no delay), sometimes I still hear echoes (I just heard =20 > another one this afternoon). If a relatively long-delay IETF codec =20 > is used, the echo control will be even more problematic. > (3) In normal phone calls or conference calls, people routinely have =20 > a need to interrupt each other, but beyond a certain point, long =20 > latency makes it very difficult for people to interrupt each other =20 > on the call. This is because when you try to interrupt another =20 > person, that person doesn't hear your interruption until a certain =20 > time later, so he keeps talking, but when you hear that he did not =20 > stop talking when you interrupted, you stop; then, he hears your =20 > interruption, so he stops. When you hear he stops, you start talking =20 > again, but then he also hears you stopped (due to the long delay), =20 > so he also starts talking again. The net result is that with a long =20 > latency, when you try to interrupt him, you and he end up stopping =20 > and starting at roughly the same time for a few cycles, making it =20 > difficult to interrupt each other. > (4) We need to keep in mind that the IETF codec may not be the only =20 > codec involved in a phone call or a conference call. We cannot =20 > assume that all conference call participants will be using a =20 > computer to conduct the call. Not only do people use cell phones for =20 > point-to-point phone calls, they also often use cell phones to call =20 > in to conference calls. The one-way delay for a cell phone call =20 > through one carriers network is typically around 80 to 110 ms. A =20 > call from a cell phone in a carrier network to another cell phone in =20 > a different type of carrier network can easily double this delay to =20 > 160 ~ 220 ms and makes the total one-way delay already far exceeding =20 > the 150 ms mentioned in (1) above. Any coding delay added by the =20 > IETF codec will be on top of that long delay, and such coding delay =20 > will be applied twice when both cell phones call through the IETF =20 > codec to a conference bridge. Even without the IETF codec delay, =20 > when I previously called from a Verizon cell phone to an AT&T cell =20 > phone, I already experienced the problem mentioned in (3) sometimes. =20 > If the IETF codec has a relatively long delay, adding two times the =20 > IETF codec one-way delay to the already long delay of 160 ~ 220 ms =20 > will make the situation much worse. Even if just one cell phone is =20 > involved in a conference call, adding twice the one-way delay of a =20 > relatively long-delay IETF codec can still easily push the total =20 > one-way delay beyond 150 ms. > To summarize, my point is that to help reduce potential echo =20 > problems and to ensure a high-quality experience in such a =20 > conference call, the IETF codec should have a delay as low as =20 > possible while maintaining good enough speech quality and a =20 > reasonable bit-rate. > > - Maybe additionally: variable bit rate encoding to achieve =20 > a multiplexing gain at the receiver > > - and thus, a fast control loop to cope with variable =20 > bitrates on transmission paths. > > - Maybe stereo/multichannel support to send the spatial =20 > audio to the headphone or loudspeakers. > > Scalable: > > - Efficient encoding/transcoding for multiple different =20 > qualities (at the conference bridge) > [Raymond]: I am not sure whether by "efficient", you meant coding =20 > efficiency or computational efficiency. In any case, I would like =20 > to take this opportunity to express my view that although codec =20 > complexity isn't much of an issue for PC-to-PC calls where there are =20 > GHz of processing power available, the codec complexity is an =20 > important issue in certain application scenarios. The following are =20 > just some examples. > 1) If a conference bridge has to decode a large number of voice =20 > channels, mix, and re-encode, and if compressed-domain mixing cannot =20 > be done (which is usually the case), then it is important to keep =20 > the decoder complexity low. > 2) In topology b) of your other email =20 > (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, =20 > or VoIP gateway, often has to encode and decode thousands of voice =20 > channels in a single box, so not only the computational complexity, =20 > but also the per-instance RAM size requirement of the codec become =20 > very important for achieving high channel density in the gateway. > 3) Many telephone terminal devices at the edge of the Internet use =20 > embedded processors with limited processing power, and the =20 > processors also have to handle many tasks other than speech coding. =20 > If the IETF codec complexity is too high, some of such devices may =20 > not have sufficient processing power to run it. Even if the codec =20 > can fit, some battery-powered mobile devices may prefer to run a =20 > lower-complexity codec to reduce power consumption and battery =20 > drain. For example, even if you make a Internet phone call from a =20 > computer, you may like the convenience of using a Bluetooth headset =20 > that allows you to walk around a bit and have hands-free operation. =20 > Currently most Bluetooth headsets have small form factors with a =20 > tiny battery. This puts a severe constraint on power consumption. =20 > Bluetooth headset chips typically have very limited processing =20 > capability, and it has to handle many other tasks such as echo =20 > cancellation and noise reduction. There is just not enough =20 > processing power to handle a relatively high-complexity codec. Most =20 > BT headsets today relies on the extremely low-complexity, =20 > hardware-based CVSD codec at 64 kb/s to transmit narrowband voice, =20 > but CVSD has audible coding noise, so it degrades the overall audio =20 > quality. If the IETF codec has low enough complexity, it would be =20 > possible to directly encode and decode the IETF codec bit-stream at =20 > the BT headset, thus avoiding the quality degradation of CVSD =20 > transcoding. > In summary, my point is that the IETF codec should attempt to =20 > achieve a codec complexity as low as possible in both MHz =20 > consumption and RAM size requirement while maintaining good enough =20 > speech quality. > > - The control loop must not react (fast) because =20 > (multicast) group communication requires to encode at low quality =20 > anyhow. > > - Receiver side activity detection for music and voice =20 > having low complexity (for the conference bridge) > > - Efficient mixing of two to four(?) active flows (is this =20 > achievable without the complete process of decoding and encoding =20 > again?) > > Are any teleconferencing requirements missing? > > Christian > > > > > --------------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of T=FCbingen > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > From: stephen botzko [mailto:stephen.botzko@gmail.com] > Sent: Wednesday, April 21, 2010 8:19 PM > To: Christian Hoene > Cc: codec@ietf.org > Subject: Re: [codec] #16: Multicast? > > Inline > On Wed, Apr 21, 2010 at 1:27 PM, Christian Hoene =20 > > wrote: > Hi Stephen, > > not too bad. You answered faster than the mailing list distributes... > Not sure how that happened! > > Comments inline: > > > From: stephen botzko =20 > [mailto:stephen.botzko@gmail.com] > Sent: Wednesday, April 21, 2010 7:10 PM > To: Christian Hoene > Cc: codec@ietf.org > > Subject: Re: [codec] #16: Multicast? > > I agree there are lots of use cases. > > > Though I don't see why high quality has to be given up in order to =20 > be scalable. > CH: These are just experiences from our lab. A spatial audio =20 > conference server including the acoustic 3D sound rendering needs a =20 > LOT of processing power. In the end, we have to remain realistic. =20 > Processing power is always limited thus if we need a lot then we =20 > cannot serve many clients. > Also, I am not sure why you think central mixing is more scalable =20 > than multicast (or why you think it is lower quality either). > CH: With multicast, you need N times 1:N multicast distribution =20 > trees (somewhat small tan O(n)=3Dn=B2). With central mixing you need N = =20 > times 2 transmission paths (O(n)=3Dn). Also, this distributed mixing =20 > you need N times the mixing at each client. With centralized, you =20 > can live with one mixing for all (and some tricks for serving the =20 > talkers). > I agree you need more distribution trees for multicast if you allow =20 > every site to talk. There is a corresponding benefit, since there is =20 > no central choke point and also less bandwidth on shared WAN links. > > In the distributed case, you don't need an N-way mixer at each =20 > client, and you also don't need to continuously receive payload on =20 > all N streams at each client either. In practice you can cap N at a =20 > relatively small number (in the 3-8 range) no matter how large the =20 > conference gets. In a large conference, you can even choose to drop =20 > your comfort noise if you are receiving two or more streams, and =20 > just send enough to keep your firewall pinhole open. This is all =20 > assuming a suitable voice activity measure in the RTP packet. Of =20 > course in the worst case, you will receive all N streams. > > Cheers, > Christian > > Stephen Botzko > On Wed, Apr 21, 2010 at 12:58 PM, Christian Hoene =20 > > wrote: > Hi, > > the teleconferencing issue gets complex. I am trying to compile the =20 > different requirements that have been mentioned on this list. > > - low complexity (with just one active speaker) vs. =20 > multiple speaker mixing vs. spatial audio/stereo mixing > > - centralized vs. distributed > > - few participants vs. hundreds of listeners and talkers > > - individual distribution of audio streams vs. IP multicast =20 > or RTP group communication > > - efficient encoding of multiple streams having the same =20 > content (but different quality). > > - I bet I missed some. > > To make things easier, why not to split the teleconferencing =20 > scenario in two: High quality and Scalable? > > The high quality scenario, intended for a low number of users, could =20 > have features like > > - Distributed processing and mixing > > - High computational resources to support spatial audio =20 > mixing (at the receiver) and multiple encodings of the same audio =20 > stream at different qualities (at the sender) > > - Enough bandwidth to allow direct N to N transmissions of =20 > audio streams (no multicast or group communication). This would be =20 > good for the latency, too. > > The scalable scenario is the opposite: > > - Central processing and mixing for many participants . > > - N to 1 and 1 to N communication using efficient =20 > distribution mechanisms (RTP group communication and IP multicast). > > - Low complexity mixing of many using tricks like VAD, =20 > encoding at lowest rate to support many receivers having different =20 > paths, you name it... > > Then, we need not to compare apples with oranges all the time. > > Christian > > --------------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of T=FCbingen > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > From: codec-bounces@ietf.org =20 > [mailto:codec-bounces@ietf.org] On =20 > Behalf Of stephen botzko > Sent: Wednesday, April 21, 2010 4:34 PM > To: Colin Perkins > Cc: trac@tools.ietf.org; =20 > codec@ietf.org > Subject: Re: [codec] #16: Multicast? > > in-line > > Stephen Botzko > On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins =20 > > wrote: > On 21 Apr 2010, at 12:20, Marshall Eubanks wrote: > On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote: > On 21 Apr 2010, at 10:42, codec issue tracker wrote: > #16: Multicast? > ------------------------------------+---------------------------------- > Reporter: hoene@... | Owner: > Type: enhancement | Status: new > Priority: trivial | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Keywords: > ------------------------------------+---------------------------------- > The question arrose whether the interactive CODEC MUST support =20 > multicast in addition to teleconferencing. > > On 04/13/2010 11:35 AM, Christian Hoene wrote: > P.S. On the same note, does anybody here cares about using this =20 > CODEC with multicast? Is there a single commercial multicast voice =20 > deployment? From what I've seen all multicast does is making IETF =20 > voice standards harder to understand or implement. > > I think that would be a mistake to ignore multicast - not because of =20 > multicast itself, but because of Xcast (RFC 5058) which is a =20 > promising technology to replace centralized conference bridges. > > Regarding multicast: > > I think we shall start at user requirements and scenarios. =20 > Teleconference (including mono or spatial audio) might be good =20 > starting point. Virtual environments like second live would require =20 > multicast communication, too. If the requirements of these scenarios =20 > are well understand, we can start to talk about potential solutions =20 > like IP multicast, Xcast or conference bridges. > > > RTP is inherently a group communication protocol, and any codec =20 > designed for use with RTP should consider operation in various =20 > different types of group communication scenario (not just =20 > multicast). RFC 5117 is a good place to start when considering the =20 > different types of topology in which RTP is used, and the possible =20 > placement of mixing and switching functions which the codec will =20 > need to work with. > > It is not clear to me what supporting multicast would entail here. =20 > If this is a codec over RTP, then what is to stop it from being =20 > multicast ? > > Nothing. However group conferences implemented using multicast =20 > require end system mixing of potentially large numbers of active =20 > audio streams, whereas those implemented using conference bridges do =20 > the mixing in a single central location, and generally suppress all =20 > but one speaker. The differences in mixing and the number of =20 > simultaneous active streams that might be received potentially =20 > affect the design of the codec. > > Conference bridges with central mixing almost always mix multiple =20 > speakers. As you add more streams into the mix, you reduce the =20 > chance of missing onset speech and interruptions, but raise the =20 > noise floor. So even if complexity is not a consideration, there is =20 > value in gating the mixer (instead of always doing a full mix-minus). > > More on point, compressed domain mixing and easy detection of VAD =20 > have both been advocated on these lists, and both simplify the =20 > large-scale mixing problem. > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > > From rchen@broadcom.com Fri Apr 23 18:44:20 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C21363A681C for ; Fri, 23 Apr 2010 18:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.432 X-Spam-Level: X-Spam-Status: No, score=-0.432 tagged_above=-999 required=5 tests=[AWL=-0.433, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q3gTjfsFqqLe for ; Fri, 23 Apr 2010 18:44:18 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 290D93A67A6 for ; Fri, 23 Apr 2010 18:44:18 -0700 (PDT) Received: from [10.9.200.133] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 23 Apr 2010 18:43:56 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Fri, 23 Apr 2010 18:45:19 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Jean-Marc Valin" Date: Fri, 23 Apr 2010 18:43:45 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrimhyNUh3NLsf5RvSfcmuOhmvRfwAo3/xA Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> In-Reply-To: <4BD11C50.2020206@usherbrooke.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Ae0m KVt0 LLW7 NFWs RRuU RgtH R5jw YBI3 Yr9F Zy7W flna i20Q j1fs mhMQ q+i4 t71k; 4; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAaABvAGUAbgBlAEAAdQBuAGkALQB0AHUAZQBiAGkAbgBnAGUAbgAuAGQAZQA7AGoAZQBhAG4ALQBtAGEAcgBjAC4AdgBhAGwAaQBuAEAAdQBzAGgAZQByAGIAcgBvAG8AawBlAC4AYwBhADsAcwB0AGUAcABoAGUAbgAuAGIAbwB0AHoAawBvAEAAZwBtAGEAaQBsAC4AYwBvAG0A; Sosha1_v1; 7; {2C1AE9B2-5797-4739-8F73-2E93DAD8954B}; cgBjAGgAZQBuAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0A; Sat, 24 Apr 2010 01:43:45 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAIwAxADYAOgAgAE0AdQBsAHQAaQBjAGEAcwB0AD8A x-cr-puzzleid: {2C1AE9B2-5797-4739-8F73-2E93DAD8954B} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67CC935631G101627727-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" , 'stephen botzko' Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 01:44:20 -0000 Hi Jean-Marc, I agree that the 20 ms frame size or packet size is more efficient in bit-r= ate. However, this comment doesn't address my original point on the need t= o have a low-delay IETF codec for the conferencing bridge scenario, where t= he voice signal will travel through the codec twice (2 tandems), thus doubl= ing the one-way codec delay. As you are well aware of, codec design involves many trade-offs between the= four major attributes of a codec: delay, complexity, bit-rate, and quality= . For a given codec architecture, improving one attribute normally means s= acrificing at least one other attribute. Nothing comes for free. Therefor= e, yes, to get low delay, you need to pay the price of lower bit-rate effic= iency, but you can also view it another way: to get higher bit-rate efficie= ncy by using a 20 ms frame size, you pay the price of a higher codec delay.= The question to ask then, is not which frame size is more bit-rate effici= ent, but whether there are application scenarios where a 20 ms frame size w= ill simply make the one-way delay way too long and greatly degrade the user= s' communication experience. I believe the answer to the latter question is= a definite "yes". Let's do some math to see why that is so. Essentially all cellular codecs = use a frame size of 20 ms, yet the one-way delay of a cell-to-landline call= is typically 80 to 110 ms, or 4 to 5.5 times the codec frame size. This i= s because you have not only the codec buffering delay, but also processing = delay, transmission delay, and delay due to processor sharing using real-ti= me OS, etc. An IP phone guru told me that for a typical IP phone applicati= on, it is also quite common to see a one-way delay of 5 times the codec fra= me size. Let's just take 5X codec frame size as the one-way delay of a typ= ical implementation. Then, even if all conference participants use their c= omputers to call the conference bridge, if the IETF codec has a frame size = of 20 ms, then after the voice signal of a talker goes through the IETF cod= ec to the bridge, it already takes 100 ms one-way delay. After the bridge = decodes all channels, mixes, and re-encodes with the IETF codec and send to= every participant, the one-way delay is now already up to 200 ms, way more= than the 150 ms limit I mentioned in my last email. Now if a talker call = into the conference bridge through a cell phone call that has 100 ms one-wa= y delay to the edge of the Internet, by the time everyone else hears his vo= ice, it is already 300 ms later. Anyone trying to interrupt that cell phon= e caller will experience the talk-stop-talk-stop problem I mentioned before= . Now if another cell phone caller call into the conference bridge, then t= he one-way delay of his voice to the first cell phone caller will be a whop= ping 400 ms! That would probably turn it into half-duplex effectively. When we talk about "high-quality" conference call, it is much more than jus= t the quality or distortion level of the voice signal; the one-way delay is= also an important and integral part of the perceived quality of the commun= ication link. This is clearly documented and well-modeled in the E-model o= f the ITU-T G.107, and the 150 ms limit, beyond which the perceived quality= sort of "falls off the cliff", was also obtained after careful study by te= lephony experts at the ITU-T. It would be wise for the IETF codec WG to he= ed the warning of the ITU-T experts and keep the one-way delay less than 15= 0 ms. In contrast, if the IETF codec has a codec frame size and packet size of 5 = ms, then the on-the-net one-way conferencing delay is only 50 ms. Even if y= ou use a longer jitter buffer, the one-way delay is still unlikely to go ab= ove 100 ms, which is still well within the ITU-T's 150 ms guideline. True, sending 5 ms packets means the packet header overhead would be higher= , but that's a small price to pay to enable the conference participants to = have a high-quality experience by avoiding the problems associated with a l= ong one-way delay. The bit-rate penalty is not 64 kb/s as you said, but 3/= 4 of that, or 48 kb/s, because you don't get zero packet header overhead fo= r a 20 ms frame size, but 16 kb/s, so 64 - 16 =3D 48. =20 Now, with the exception of a small percentage of Internet users who still u= se dial-up modems, the vast majority of the Internet users today connect to= the Internet at a speed of at least several hundred kb/s, and most are in = the Mbps range. A 48 kb/s penalty is really a fairly small price to pay fo= r the majority of Internet users when it can give them a much better high-q= uality experience with an much lower delay. Furthermore, it is possible to use header compression technology to shrink = that 48 kb/s penalty to almost nothing. Also, even if a 5 ms packet size is an overkill in some situations, a codec= with a 5 ms frame size can easily packs two frames of compressed bit-strea= m into a 10 ms packet. Then the packet header overhead bit-rate would be 3= 2 kb/s, so the penalty shrinks by a factor of 3 from 48 kb/s to 32 - 16 =3D= 16 kb/s. With 10 ms packets, the one-way conferencing delay would be 100 m= s, still well within the 150 ms guideline. (Actually, since the internal "t= hread rate" of real-time OS can still run at 5 ms intervals, the one-way de= lay can be made less than 100 ms, but that's too much detail to go into.) I= n contrast, a codec with a 20 ms frame size cannot send its bit-stream with= 10 ms packets, unless it spreads each frame into two packets, which is wha= t IETF AVT advises against, because it will effectively double the packet l= oss rate. The way I see it, for conference bridge applications at least, I think it w= ould be a big mistake for IETF to recommend a codec with a frame size of 20= ms or higher. From my analysis above, by doing that we will be stuck with= too long a delay and the associated problems. =20 Best Regards, Raymond -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca]=20 Sent: Thursday, April 22, 2010 9:05 PM To: Raymond (Juin-Hwey) Chen Cc: Christian Hoene; 'stephen botzko'; codec@ietf.org Subject: Re: [codec] #16: Multicast? Hi, See me comments below. > [Raymond]: High quality is a given, but I would like to emphasize the=20 > importance of low latency. > > (1) It is well-known that the longer the latency, the lower the=20 > perceived quality of the communication link. The E-model in the ITU-T=20 > Recommendation G.107 models such communication quality in MOS_cqe,=20 > which among other things depends on the so-called "delay impairment=20 > factor" /Id/. Basically, MOS_cqe is a monotonically decreasing=20 > function of increasing latency, and beyond about 150 ms one-way delay,=20 > the perceived quality of the communication link drops rapidly with=20 > further delay increase. > As the author of CELT, I obviously agree that latency is an important=20 aspect for this codec :-) That being said, I tend to say that 20 ms is=20 still the most widely used frame size, so we might as well optimise for=20 that. This is not really a problem because as the frame size goes down,=20 the overhead of the IP/UDP/RTP headers go up, so the codec bit-rate=20 becomes a bit less of an issue. For example, with 5 ms frames, we would=20 already be sending 64 kb/s worth of headers (excluding the link layer),=20 so we might as well spend about as many bits on the actual payload as we=20 spend on the headers. And with 64 kb/s of payload, we can actually have=20 high-quality full-band audio. > 1) If a conference bridge has to decode a large number of voice=20 > channels, mix, and re-encode, and if compressed-domain mixing cannot=20 > be done (which is usually the case), then it is important to keep the=20 > decoder complexity low. Definitely agree here. The decoder complexity is very important. Not=20 only because of mixing issue, but also because the decoder is generally=20 not allowed to take shortcuts to save on complexity (unlike the=20 encoder). As for compressed-domain mixing, as you say it is not always=20 available, but *if* we can do it (even if only partially), then that can=20 result in a "free" reduction in decoder complexity for mixing. > 2) In topology b) of your other email=20 > (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, or=20 > VoIP gateway, often has to encode and decode thousands of voice=20 > channels in a single box, so not only the computational complexity,=20 > but also the per-instance RAM size requirement of the codec become=20 > very important for achieving high channel density in the gateway. > Agreed here, although I would say that per-instance RAM -- as long as=20 it's reasonable -- is probably a bit less important than complexity. > 3) Many telephone terminal devices at the edge of the Internet use=20 > embedded processors with limited processing power, and the processors=20 > also have to handle many tasks other than speech coding. If the IETF=20 > codec complexity is too high, some of such devices may not have=20 > sufficient processing power to run it. Even if the codec can fit, some=20 > battery-powered mobile devices may prefer to run a lower-complexity=20 > codec to reduce power consumption and battery drain. For example, even=20 > if you make a Internet phone call from a computer, you may like the=20 > convenience of using a Bluetooth headset that allows you to walk=20 > around a bit and have hands-free operation. Currently most Bluetooth=20 > headsets have small form factors with a tiny battery. This puts a=20 > severe constraint on power consumption. Bluetooth headset chips=20 > typically have very limited processing capability, and it has to=20 > handle many other tasks such as echo cancellation and noise reduction.=20 > There is just not enough processing power to handle a relatively=20 > high-complexity codec. Most BT headsets today relies on the extremely=20 > low-complexity, hardware-based CVSD codec at 64 kb/s to transmit=20 > narrowband voice, but CVSD has audible coding noise, so it degrades=20 > the overall audio quality. If the IETF codec has low enough=20 > complexity, it would be possible to directly encode and decode the=20 > IETF codec bit-stream at the BT headset, thus avoiding the quality=20 > degradation of CVSD transcoding. > Any idea what the complexity requirements would be for this use-case to=20 be possible? Cheers, Jean-Marc From swmike@swm.pp.se Fri Apr 23 19:05:27 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 475683A67CF for ; Fri, 23 Apr 2010 19:05:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.738 X-Spam-Level: X-Spam-Status: No, score=-5.738 tagged_above=-999 required=5 tests=[AWL=0.511, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEPNMsyusxX3 for ; Fri, 23 Apr 2010 19:05:26 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id 05AE73A67C0 for ; Fri, 23 Apr 2010 19:05:25 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id D4DCA9F; Sat, 24 Apr 2010 04:05:10 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id D16BD9E; Sat, 24 Apr 2010 04:05:10 +0200 (CEST) Date: Sat, 24 Apr 2010 04:05:10 +0200 (CEST) From: Mikael Abrahamsson To: "Raymond (Juin-Hwey) Chen" In-Reply-To: Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "codec@ietf.org" , 'stephen botzko' , Jean-Marc Valin Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 02:05:27 -0000 On Fri, 23 Apr 2010, Raymond (Juin-Hwey) Chen wrote: > The way I see it, for conference bridge applications at least, I think > it would be a big mistake for IETF to recommend a codec with a frame > size of 20 ms or higher. From my analysis above, by doing that we will > be stuck with too long a delay and the associated problems. >From my point of view as a network engineer, it would be a mistake to recommend *fixed* frame size at all. The codec needs to be able to handle everything from 5ms to 250ms frame size depending on network conditions (please see my emails from a few months back regarding the reality of the Internet today). From jean-marc.valin@usherbrooke.ca Fri Apr 23 19:52:59 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 653493A67E2 for ; Fri, 23 Apr 2010 19:52:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.369 X-Spam-Level: X-Spam-Status: No, score=-0.369 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r29qE+nZCa5C for ; Fri, 23 Apr 2010 19:52:57 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 3331E3A67F3 for ; Fri, 23 Apr 2010 19:52:57 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1; format=flowed Received: from [192.168.1.10] ([70.81.109.112]) by VL-MR-MR001.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-8.01 (built Dec 16 2008; 32bit)) with ESMTP id <0L1D00II41BXBTE0@VL-MR-MR001.ip.videotron.ca> for codec@ietf.org; Fri, 23 Apr 2010 22:52:46 -0400 (EDT) Message-id: <4BD25CFD.2020808@usherbrooke.ca> Date: Fri, 23 Apr 2010 22:52:45 -0400 From: Jean-Marc Valin User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 To: "Raymond (Juin-Hwey) Chen" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> In-reply-to: Cc: "codec@ietf.org" , 'stephen botzko' Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 02:52:59 -0000 Hi Raymond, I think I may have been a bit ambiguous in my previous email. I am totally in favor of supporting 5 ms frames. TO me, it is becoming clear that we want to support both 5 ms *and* 20 ms frames. I don't think it would be too hard to support both. About my comment about the overheard, my point was not to say that 64 kb/s overhead is necessarily unacceptable. My main point is that the codec's "sweet spot" should probably be such that the payload bit-rate be in the same order as the header overhead at the selected frame size. So when operating with 5 ms frames, since you're already paying 64 kb/s in headers, it's probably worth also having 64 kb/s of payload so that you can transmit full-band audio. On the other hand, when operating with 20 ms frames where the overhead is 16 kb/s, then a 16 kb/s payload is probably the sweet spot. That way you scale audio quality at the same time as you reduce latency. I hope this clears up the mis-understanding. Cheers, Jean-Marc On 2010-04-23 21:43, Raymond (Juin-Hwey) Chen wrote: > Hi Jean-Marc, > > I agree that the 20 ms frame size or packet size is more efficient in > bit-rate. However, this comment doesn't address my original point on > the need to have a low-delay IETF codec for the conferencing bridge > scenario, where the voice signal will travel through the codec twice > (2 tandems), thus doubling the one-way codec delay. > > As you are well aware of, codec design involves many trade-offs > between the four major attributes of a codec: delay, complexity, > bit-rate, and quality. For a given codec architecture, improving one > attribute normally means sacrificing at least one other attribute. > Nothing comes for free. Therefore, yes, to get low delay, you need > to pay the price of lower bit-rate efficiency, but you can also view > it another way: to get higher bit-rate efficiency by using a 20 ms > frame size, you pay the price of a higher codec delay. The question > to ask then, is not which frame size is more bit-rate efficient, but > whether there are application scenarios where a 20 ms frame size will > simply make the one-way delay way too long and greatly degrade the > users' communication experience. I believe the answer to the latter > question is a definite "yes". > > Let's do some math to see why that is so. Essentially all cellular > codecs use a frame size of 20 ms, yet the one-way delay of a > cell-to-landline call is typically 80 to 110 ms, or 4 to 5.5 times > the codec frame size. This is because you have not only the codec > buffering delay, but also processing delay, transmission delay, and > delay due to processor sharing using real-time OS, etc. An IP phone > guru told me that for a typical IP phone application, it is also > quite common to see a one-way delay of 5 times the codec frame size. > Let's just take 5X codec frame size as the one-way delay of a typical > implementation. Then, even if all conference participants use their > computers to call the conference bridge, if the IETF codec has a > frame size of 20 ms, then after the voice signal of a talker goes > through the IETF codec to the bridge, it already takes 100 ms one-way > delay. After the bridge decodes all channels, mixes, and re-encodes > with the IETF codec and send to every participant, the one-way delay > is now already up to 200 ms, way more than the 150 ms limit I > mentioned in my last email. Now if a talker call into the conference > bridge through a cell phone call that has 100 ms one-way delay to the > edge of the Internet, by the time everyone else hears his voice, it > is already 300 ms later. Anyone trying to interrupt that cell phone > caller will experience the talk-stop-talk-stop problem I mentioned > before. Now if another cell phone caller call into the conference > bridge, then the one-way delay of his voice to the first cell phone > caller will be a whopping 400 ms! That would probably turn it into > half-duplex effectively. > > When we talk about "high-quality" conference call, it is much more > than just the quality or distortion level of the voice signal; the > one-way delay is also an important and integral part of the perceived > quality of the communication link. This is clearly documented and > well-modeled in the E-model of the ITU-T G.107, and the 150 ms limit, > beyond which the perceived quality sort of "falls off the cliff", was > also obtained after careful study by telephony experts at the ITU-T. > It would be wise for the IETF codec WG to heed the warning of the > ITU-T experts and keep the one-way delay less than 150 ms. > > In contrast, if the IETF codec has a codec frame size and packet size > of 5 ms, then the on-the-net one-way conferencing delay is only 50 > ms. Even if you use a longer jitter buffer, the one-way delay is > still unlikely to go above 100 ms, which is still well within the > ITU-T's 150 ms guideline. > > True, sending 5 ms packets means the packet header overhead would be > higher, but that's a small price to pay to enable the conference > participants to have a high-quality experience by avoiding the > problems associated with a long one-way delay. The bit-rate penalty > is not 64 kb/s as you said, but 3/4 of that, or 48 kb/s, because you > don't get zero packet header overhead for a 20 ms frame size, but 16 > kb/s, so 64 - 16 = 48. > > Now, with the exception of a small percentage of Internet users who > still use dial-up modems, the vast majority of the Internet users > today connect to the Internet at a speed of at least several hundred > kb/s, and most are in the Mbps range. A 48 kb/s penalty is really a > fairly small price to pay for the majority of Internet users when it > can give them a much better high-quality experience with an much > lower delay. > > Furthermore, it is possible to use header compression technology to > shrink that 48 kb/s penalty to almost nothing. > > Also, even if a 5 ms packet size is an overkill in some situations, a > codec with a 5 ms frame size can easily packs two frames of > compressed bit-stream into a 10 ms packet. Then the packet header > overhead bit-rate would be 32 kb/s, so the penalty shrinks by a > factor of 3 from 48 kb/s to 32 - 16 = 16 kb/s. With 10 ms packets, > the one-way conferencing delay would be 100 ms, still well within the > 150 ms guideline. (Actually, since the internal "thread rate" of > real-time OS can still run at 5 ms intervals, the one-way delay can > be made less than 100 ms, but that's too much detail to go into.) In > contrast, a codec with a 20 ms frame size cannot send its bit-stream > with 10 ms packets, unless it spreads each frame into two packets, > which is what IETF AVT advises against, because it will effectively > double the packet loss rate. > > The way I see it, for conference bridge applications at least, I > think it would be a big mistake for IETF to recommend a codec with a > frame size of 20 ms or higher. From my analysis above, by doing that > we will be stuck with too long a delay and the associated problems. > > Best Regards, > > Raymond > > -----Original Message----- From: Jean-Marc Valin > [mailto:jean-marc.valin@usherbrooke.ca] Sent: Thursday, April 22, > 2010 9:05 PM To: Raymond (Juin-Hwey) Chen Cc: Christian Hoene; > 'stephen botzko'; codec@ietf.org Subject: Re: [codec] #16: > Multicast? > > Hi, > > See me comments below. > >> [Raymond]: High quality is a given, but I would like to emphasize >> the importance of low latency. >> >> (1) It is well-known that the longer the latency, the lower the >> perceived quality of the communication link. The E-model in the >> ITU-T Recommendation G.107 models such communication quality in >> MOS_cqe, which among other things depends on the so-called "delay >> impairment factor" /Id/. Basically, MOS_cqe is a monotonically >> decreasing function of increasing latency, and beyond about 150 ms >> one-way delay, the perceived quality of the communication link >> drops rapidly with further delay increase. >> > > As the author of CELT, I obviously agree that latency is an > important aspect for this codec :-) That being said, I tend to say > that 20 ms is still the most widely used frame size, so we might as > well optimise for that. This is not really a problem because as the > frame size goes down, the overhead of the IP/UDP/RTP headers go up, > so the codec bit-rate becomes a bit less of an issue. For example, > with 5 ms frames, we would already be sending 64 kb/s worth of > headers (excluding the link layer), so we might as well spend about > as many bits on the actual payload as we spend on the headers. And > with 64 kb/s of payload, we can actually have high-quality full-band > audio. > >> 1) If a conference bridge has to decode a large number of voice >> channels, mix, and re-encode, and if compressed-domain mixing >> cannot be done (which is usually the case), then it is important to >> keep the decoder complexity low. > > Definitely agree here. The decoder complexity is very important. Not > only because of mixing issue, but also because the decoder is > generally not allowed to take shortcuts to save on complexity (unlike > the encoder). As for compressed-domain mixing, as you say it is not > always available, but *if* we can do it (even if only partially), > then that can result in a "free" reduction in decoder complexity for > mixing. > >> 2) In topology b) of your other email >> (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, >> or VoIP gateway, often has to encode and decode thousands of voice >> channels in a single box, so not only the computational >> complexity, but also the per-instance RAM size requirement of the >> codec become very important for achieving high channel density in >> the gateway. >> > > Agreed here, although I would say that per-instance RAM -- as long > as it's reasonable -- is probably a bit less important than > complexity. > >> 3) Many telephone terminal devices at the edge of the Internet use >> embedded processors with limited processing power, and the >> processors also have to handle many tasks other than speech coding. >> If the IETF codec complexity is too high, some of such devices may >> not have sufficient processing power to run it. Even if the codec >> can fit, some battery-powered mobile devices may prefer to run a >> lower-complexity codec to reduce power consumption and battery >> drain. For example, even if you make a Internet phone call from a >> computer, you may like the convenience of using a Bluetooth headset >> that allows you to walk around a bit and have hands-free operation. >> Currently most Bluetooth headsets have small form factors with a >> tiny battery. This puts a severe constraint on power consumption. >> Bluetooth headset chips typically have very limited processing >> capability, and it has to handle many other tasks such as echo >> cancellation and noise reduction. There is just not enough >> processing power to handle a relatively high-complexity codec. Most >> BT headsets today relies on the extremely low-complexity, >> hardware-based CVSD codec at 64 kb/s to transmit narrowband voice, >> but CVSD has audible coding noise, so it degrades the overall audio >> quality. If the IETF codec has low enough complexity, it would be >> possible to directly encode and decode the IETF codec bit-stream at >> the BT headset, thus avoiding the quality degradation of CVSD >> transcoding. >> > > Any idea what the complexity requirements would be for this use-case > to be possible? > > Cheers, > > Jean-Marc > > > > > From rchen@broadcom.com Sat Apr 24 13:31:42 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A523D3A67F5 for ; Sat, 24 Apr 2010 13:31:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.324 X-Spam-Level: X-Spam-Status: No, score=-0.324 tagged_above=-999 required=5 tests=[AWL=-0.325, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mTcXE5A2xvh8 for ; Sat, 24 Apr 2010 13:31:40 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id CAB873A67D2 for ; Sat, 24 Apr 2010 13:31:40 -0700 (PDT) Received: from [10.9.200.133] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Sat, 24 Apr 2010 13:31:18 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Sat, 24 Apr 2010 13:32:41 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Jean-Marc Valin" Importance: low X-Priority: 5 Date: Sat, 24 Apr 2010 13:31:06 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrjWT5Pm2qJGfbjQROPLhhyRy4JIwAiDtVw Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <4BD25CFD.2020808@usherbrooke.ca> In-Reply-To: <4BD25CFD.2020808@usherbrooke.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: AzVP EUTD GXcL G2B2 HofK JCqd NCow Xx3m csrs fKR5 fPlK gZrw lp5k nCth pUZg skCP; 4; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAaABvAGUAbgBlAEAAdQBuAGkALQB0AHUAZQBiAGkAbgBnAGUAbgAuAGQAZQA7AGoAZQBhAG4ALQBtAGEAcgBjAC4AdgBhAGwAaQBuAEAAdQBzAGgAZQByAGIAcgBvAG8AawBlAC4AYwBhADsAcwB0AGUAcABoAGUAbgAuAGIAbwB0AHoAawBvAEAAZwBtAGEAaQBsAC4AYwBvAG0A; Sosha1_v1; 7; {628EF28F-14BB-4A55-99F4-AE9876C6F9B4}; cgBjAGgAZQBuAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0A; Sat, 24 Apr 2010 20:31:06 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAIwAxADYAOgAgAE0AdQBsAHQAaQBjAGEAcwB0AD8A x-cr-puzzleid: {628EF28F-14BB-4A55-99F4-AE9876C6F9B4} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67CD8A9C31G102472339-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" , 'stephen botzko' Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 20:31:42 -0000 Hi Jean-Marc, Thanks for your helpful clarification. I totally agree with you and Mikael Abrahamsson that it is unlikely for a s= ingle codec frame size to be optimal for all applications. Different appli= cations can have very different requirements in delay, complexity, bit-rate= , and quality, and thus will require different codec trade-offs to get the = most optimal solution. One size just doesn't fit all. I believe that's wh= y there are so many different speech and audio codecs out there, because no= single codec at any single operating point of delay, complexity, bit-rate,= and quality can meet the requirements of all possible codec applications. Given the broad range of different applications that the IETF codec is tryi= ng to cover, it is clear to me that the IETF codec needs to have multiple c= odec "modes" (or "profiles" as some other standard bodies often call them) = to cover not only different bit-rates and sampling rates, but also differen= t levels of delay and complexity. Thus, the IETF codec might need to have = a low-bit-rate mode (or high bit-rate efficiency mode), a low-delay mode, a= low-complexity mode, etc. For example, for dial-up modem users, the low-bit-rate mode will be suitabl= e. For delay-sensitive applications such as the conference bridge applicat= ions or any Internet phone call to a cell phone through a cellular network = (even point-to-point as oppose to conferencing), the low-delay mode will be= suitable. For devices with very limited processing capabilities such as m= ono Bluetooth telephone headsets, the low-complexity mode will be suitable.= A conference bridge can even use different IETF codec modes to communicat= e with different devices in the same conference call at the same time. Of course, sometimes it may be possible or desirable to combine different m= odes. For example, we could have a low-delay-high-quality mode for full-ba= nd interactive music performance over the Internet, and we could have a low= -delay-low-complexity mode when a Bluetooth headset is used to call a confe= rence bridge. Regarding your comment that the payload bit-rate should be the same order a= s the header bit-rate, although it seems to make sense intuitively, I think= in reality there are situations where it may not make sense. For instance= , in your example of a 5 ms frame/packet size with a 64 kb/s header bit-rat= e and 64 kb/s full-band audio bit-rate, what if an IP phone with a 8 kHz sa= mpling rate is used to make a call? Then all the extra bit-rate spent on au= dio bandwidth above 3.4 kHz (or 4 kHz maximum) is wasted. Or what if the r= esulting 128 kb/s is too high for the link because the link still needs to = support other data streams? Similarly, for the 20 ms frame size case, what= if you want to transmit full-band audio and 16 kb/s just won't give you th= e high fidelity level you are looking for? I understand that you are only = talking about a "sweet spot" and are not saying the payload bit-rate and th= e header bit-rate must be the same, but I am just saying that in certain si= tuations the sweet spot may actually be somewhere else. Also, I think ideally we should do header compression to minimize the heade= r bit-rate and increase the overall bit-rate efficiency of the system, then= there is no "sweet spot" issue as discussed above. I understand that this= may not be possible unless the networking gears support it at both ends, b= ut just from a system perspective, it would seem to me that it doesn't make= sense for speech/audio codec developers to try so hard to squeeze the spee= ch/audio signal to as few bits as possible, only to see the packet header h= aving very redundant and repetitive bits sent packet after packet. There a= re probably reasons why header compression is not more widely used (which I= don't know since it's outside my expertise area), but from a system perspe= ctive, it just seems to me to be extremely unbalanced and inefficient to se= nd so many unchanged bits in the header packet after packet, especially in = light of the high degree of speech/audio compression done in the payload. Best Regards, Raymond -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] Sent: Friday, April 23, 2010 7:53 PM To: Raymond (Juin-Hwey) Chen Cc: Christian Hoene; 'stephen botzko'; codec@ietf.org Subject: Re: [codec] #16: Multicast? Hi Raymond, I think I may have been a bit ambiguous in my previous email. I am totally in favor of supporting 5 ms frames. TO me, it is becoming clear that we want to support both 5 ms *and* 20 ms frames. I don't think it would be too hard to support both. About my comment about the overheard, my point was not to say that 64 kb/s overhead is necessarily unacceptable. My main point is that the codec's "sweet spot" should probably be such that the payload bit-rate be in the same order as the header overhead at the selected frame size. So when operating with 5 ms frames, since you're already paying 64 kb/s in headers, it's probably worth also having 64 kb/s of payload so that you can transmit full-band audio. On the other hand, when operating with 20 ms frames where the overhead is 16 kb/s, then a 16 kb/s payload is probably the sweet spot. That way you scale audio quality at the same time as you reduce latency. I hope this clears up the mis-understanding. Cheers, Jean-Marc On 2010-04-23 21:43, Raymond (Juin-Hwey) Chen wrote: > Hi Jean-Marc, > > I agree that the 20 ms frame size or packet size is more efficient in > bit-rate. However, this comment doesn't address my original point on > the need to have a low-delay IETF codec for the conferencing bridge > scenario, where the voice signal will travel through the codec twice > (2 tandems), thus doubling the one-way codec delay. > > As you are well aware of, codec design involves many trade-offs > between the four major attributes of a codec: delay, complexity, > bit-rate, and quality. For a given codec architecture, improving one > attribute normally means sacrificing at least one other attribute. > Nothing comes for free. Therefore, yes, to get low delay, you need > to pay the price of lower bit-rate efficiency, but you can also view > it another way: to get higher bit-rate efficiency by using a 20 ms > frame size, you pay the price of a higher codec delay. The question > to ask then, is not which frame size is more bit-rate efficient, but > whether there are application scenarios where a 20 ms frame size will > simply make the one-way delay way too long and greatly degrade the > users' communication experience. I believe the answer to the latter > question is a definite "yes". > > Let's do some math to see why that is so. Essentially all cellular > codecs use a frame size of 20 ms, yet the one-way delay of a > cell-to-landline call is typically 80 to 110 ms, or 4 to 5.5 times > the codec frame size. This is because you have not only the codec > buffering delay, but also processing delay, transmission delay, and > delay due to processor sharing using real-time OS, etc. An IP phone > guru told me that for a typical IP phone application, it is also > quite common to see a one-way delay of 5 times the codec frame size. > Let's just take 5X codec frame size as the one-way delay of a typical > implementation. Then, even if all conference participants use their > computers to call the conference bridge, if the IETF codec has a > frame size of 20 ms, then after the voice signal of a talker goes > through the IETF codec to the bridge, it already takes 100 ms one-way > delay. After the bridge decodes all channels, mixes, and re-encodes > with the IETF codec and send to every participant, the one-way delay > is now already up to 200 ms, way more than the 150 ms limit I > mentioned in my last email. Now if a talker call into the conference > bridge through a cell phone call that has 100 ms one-way delay to the > edge of the Internet, by the time everyone else hears his voice, it > is already 300 ms later. Anyone trying to interrupt that cell phone > caller will experience the talk-stop-talk-stop problem I mentioned > before. Now if another cell phone caller call into the conference > bridge, then the one-way delay of his voice to the first cell phone > caller will be a whopping 400 ms! That would probably turn it into > half-duplex effectively. > > When we talk about "high-quality" conference call, it is much more > than just the quality or distortion level of the voice signal; the > one-way delay is also an important and integral part of the perceived > quality of the communication link. This is clearly documented and > well-modeled in the E-model of the ITU-T G.107, and the 150 ms limit, > beyond which the perceived quality sort of "falls off the cliff", was > also obtained after careful study by telephony experts at the ITU-T. > It would be wise for the IETF codec WG to heed the warning of the > ITU-T experts and keep the one-way delay less than 150 ms. > > In contrast, if the IETF codec has a codec frame size and packet size > of 5 ms, then the on-the-net one-way conferencing delay is only 50 > ms. Even if you use a longer jitter buffer, the one-way delay is > still unlikely to go above 100 ms, which is still well within the > ITU-T's 150 ms guideline. > > True, sending 5 ms packets means the packet header overhead would be > higher, but that's a small price to pay to enable the conference > participants to have a high-quality experience by avoiding the > problems associated with a long one-way delay. The bit-rate penalty > is not 64 kb/s as you said, but 3/4 of that, or 48 kb/s, because you > don't get zero packet header overhead for a 20 ms frame size, but 16 > kb/s, so 64 - 16 =3D 48. > > Now, with the exception of a small percentage of Internet users who > still use dial-up modems, the vast majority of the Internet users > today connect to the Internet at a speed of at least several hundred > kb/s, and most are in the Mbps range. A 48 kb/s penalty is really a > fairly small price to pay for the majority of Internet users when it > can give them a much better high-quality experience with an much > lower delay. > > Furthermore, it is possible to use header compression technology to > shrink that 48 kb/s penalty to almost nothing. > > Also, even if a 5 ms packet size is an overkill in some situations, a > codec with a 5 ms frame size can easily packs two frames of > compressed bit-stream into a 10 ms packet. Then the packet header > overhead bit-rate would be 32 kb/s, so the penalty shrinks by a > factor of 3 from 48 kb/s to 32 - 16 =3D 16 kb/s. With 10 ms packets, > the one-way conferencing delay would be 100 ms, still well within the > 150 ms guideline. (Actually, since the internal "thread rate" of > real-time OS can still run at 5 ms intervals, the one-way delay can > be made less than 100 ms, but that's too much detail to go into.) In > contrast, a codec with a 20 ms frame size cannot send its bit-stream > with 10 ms packets, unless it spreads each frame into two packets, > which is what IETF AVT advises against, because it will effectively > double the packet loss rate. > > The way I see it, for conference bridge applications at least, I > think it would be a big mistake for IETF to recommend a codec with a > frame size of 20 ms or higher. From my analysis above, by doing that > we will be stuck with too long a delay and the associated problems. > > Best Regards, > > Raymond > > -----Original Message----- From: Jean-Marc Valin > [mailto:jean-marc.valin@usherbrooke.ca] Sent: Thursday, April 22, > 2010 9:05 PM To: Raymond (Juin-Hwey) Chen Cc: Christian Hoene; > 'stephen botzko'; codec@ietf.org Subject: Re: [codec] #16: > Multicast? > > Hi, > > See me comments below. > >> [Raymond]: High quality is a given, but I would like to emphasize >> the importance of low latency. >> >> (1) It is well-known that the longer the latency, the lower the >> perceived quality of the communication link. The E-model in the >> ITU-T Recommendation G.107 models such communication quality in >> MOS_cqe, which among other things depends on the so-called "delay >> impairment factor" /Id/. Basically, MOS_cqe is a monotonically >> decreasing function of increasing latency, and beyond about 150 ms >> one-way delay, the perceived quality of the communication link >> drops rapidly with further delay increase. >> > > As the author of CELT, I obviously agree that latency is an > important aspect for this codec :-) That being said, I tend to say > that 20 ms is still the most widely used frame size, so we might as > well optimise for that. This is not really a problem because as the > frame size goes down, the overhead of the IP/UDP/RTP headers go up, > so the codec bit-rate becomes a bit less of an issue. For example, > with 5 ms frames, we would already be sending 64 kb/s worth of > headers (excluding the link layer), so we might as well spend about > as many bits on the actual payload as we spend on the headers. And > with 64 kb/s of payload, we can actually have high-quality full-band > audio. > >> 1) If a conference bridge has to decode a large number of voice >> channels, mix, and re-encode, and if compressed-domain mixing >> cannot be done (which is usually the case), then it is important to >> keep the decoder complexity low. > > Definitely agree here. The decoder complexity is very important. Not > only because of mixing issue, but also because the decoder is > generally not allowed to take shortcuts to save on complexity (unlike > the encoder). As for compressed-domain mixing, as you say it is not > always available, but *if* we can do it (even if only partially), > then that can result in a "free" reduction in decoder complexity for > mixing. > >> 2) In topology b) of your other email >> (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, >> or VoIP gateway, often has to encode and decode thousands of voice >> channels in a single box, so not only the computational >> complexity, but also the per-instance RAM size requirement of the >> codec become very important for achieving high channel density in >> the gateway. >> > > Agreed here, although I would say that per-instance RAM -- as long > as it's reasonable -- is probably a bit less important than > complexity. > >> 3) Many telephone terminal devices at the edge of the Internet use >> embedded processors with limited processing power, and the >> processors also have to handle many tasks other than speech coding. >> If the IETF codec complexity is too high, some of such devices may >> not have sufficient processing power to run it. Even if the codec >> can fit, some battery-powered mobile devices may prefer to run a >> lower-complexity codec to reduce power consumption and battery >> drain. For example, even if you make a Internet phone call from a >> computer, you may like the convenience of using a Bluetooth headset >> that allows you to walk around a bit and have hands-free operation. >> Currently most Bluetooth headsets have small form factors with a >> tiny battery. This puts a severe constraint on power consumption. >> Bluetooth headset chips typically have very limited processing >> capability, and it has to handle many other tasks such as echo >> cancellation and noise reduction. There is just not enough >> processing power to handle a relatively high-complexity codec. Most >> BT headsets today relies on the extremely low-complexity, >> hardware-based CVSD codec at 64 kb/s to transmit narrowband voice, >> but CVSD has audible coding noise, so it degrades the overall audio >> quality. If the IETF codec has low enough complexity, it would be >> possible to directly encode and decode the IETF codec bit-stream at >> the BT headset, thus avoiding the quality degradation of CVSD >> transcoding. >> > > Any idea what the complexity requirements would be for this use-case > to be possible? > > Cheers, > > Jean-Marc > > > > > From koen.vos@skype.net Sat Apr 24 13:56:22 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D78973A68C5 for ; Sat, 24 Apr 2010 13:56:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.899 X-Spam-Level: X-Spam-Status: No, score=-4.899 tagged_above=-999 required=5 tests=[AWL=-0.159, BAYES_20=-0.74, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tm43T6uMHdLa for ; Sat, 24 Apr 2010 13:56:21 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 8B6433A6826 for ; Sat, 24 Apr 2010 13:56:20 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id E2031601322E8 for ; Sat, 24 Apr 2010 21:56:08 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=knDgnL2gbyjj oXe/FYlVL6P+p6I=; b=bA5qiNfaF1gRE2yjw+PQfUmHq6pfIhfXL80g4oQBj5Jl SMzkcVpFwk/gnIzhJjRELt0lajIb8t2MaPnAwKjgqWuFiXQ2+cJ5CZwTMfXTNtL9 M4OF9nuducjIoFnVkRI8rvChs/rz2E2tmBvSS1zOv8g2r9h4NbwbEekLaGX8Vto= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=CFg8UBtoXuQor8m5Umt8 rfZiKwItLTGdJ0Mxvy9BQSaZUleCiU88j0TspYBH6yi/Jx0lAMosYO7OpoNzuhae 6WaKbYLYhcfha+ym6/3/tQYDzUxGRB3UnX7lQebvNCsvpu2bVCGuRw0880+n++YV bk5GW0Jz8D2WToqslqOF50Y= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id E02AB60132130 for ; Sat, 24 Apr 2010 21:56:08 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6pIzAC6gKzI for ; Sat, 24 Apr 2010 21:56:07 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 7689F601322E6; Sat, 24 Apr 2010 21:56:07 +0100 (IST) Received: from adsl-71-141-115-202.dsl.snfc21.pacbell.net (adsl-71-141-115-202.dsl.snfc21.pacbell.net [71.141.115.202]) by mail.skype.net (Horde Framework) with HTTP; Sat, 24 Apr 2010 13:56:07 -0700 Message-ID: <20100424135607.84293hkaa13j1zvr@mail.skype.net> Date: Sat, 24 Apr 2010 13:56:07 -0700 From: Koen Vos To: codec@ietf.org References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 20:56:23 -0000 Quoting "Raymond (Juin-Hwey) Chen" > An IP phone guru told me that for a typical IP phone application, > it is also quite common to see a one-way delay of 5 times the codec > frame size. Sure - for certain frame sizes. But 1 ms frames won't give you 5 ms one-way delay. For a well-designed system and a typical Internet connection: - most delay comes from the network and is not codec related, and - one-way delay grows almost linearly with frame size. > Furthermore, it is possible to use header compression technology to > shrink that 48 kb/s penalty to almost nothing. Afaik, only RTP headers can be compressed between arbitrary Internet end points. You're still stuck with IP and UDP headers. best, koen. Quoting "Raymond (Juin-Hwey) Chen" : > Hi Jean-Marc, > > I agree that the 20 ms frame size or packet size is more efficient > in bit-rate. However, this comment doesn't address my original > point on the need to have a low-delay IETF codec for the > conferencing bridge scenario, where the voice signal will travel > through the codec twice (2 tandems), thus doubling the one-way codec > delay. > > As you are well aware of, codec design involves many trade-offs > between the four major attributes of a codec: delay, complexity, > bit-rate, and quality. For a given codec architecture, improving > one attribute normally means sacrificing at least one other > attribute. Nothing comes for free. Therefore, yes, to get low > delay, you need to pay the price of lower bit-rate efficiency, but > you can also view it another way: to get higher bit-rate efficiency > by using a 20 ms frame size, you pay the price of a higher codec > delay. The question to ask then, is not which frame size is more > bit-rate efficient, but whether there are application scenarios > where a 20 ms frame size will simply make the one-way delay way too > long and greatly degrade the users' communication experience. I > believe the answer to the latter question is a definite "yes". > > Let's do some math to see why that is so. Essentially all cellular > codecs use a frame size of 20 ms, yet the one-way delay of a > cell-to-landline call is typically 80 to 110 ms, or 4 to 5.5 times > the codec frame size. This is because you have not only the codec > buffering delay, but also processing delay, transmission delay, and > delay due to processor sharing using real-time OS, etc. An IP phone > guru told me that for a typical IP phone application, it is also > quite common to see a one-way delay of 5 times the codec frame size. > Let's just take 5X codec frame size as the one-way delay of a > typical implementation. Then, even if all conference participants > use their computers to call the conference bridge, if the IETF codec > has a frame size of 20 ms, then after the voice signal of a talker > goes through the IETF codec to the bridge, it already takes 100 ms > one-way delay. After the bridge decodes all channels, mixes, and > re-encodes with the IETF codec and send to every particip > ant, the one-way delay is now already up to 200 ms, way more than > the 150 ms limit I mentioned in my last email. Now if a talker call > into the conference bridge through a cell phone call that has 100 ms > one-way delay to the edge of the Internet, by the time everyone else > hears his voice, it is already 300 ms later. Anyone trying to > interrupt that cell phone caller will experience the > talk-stop-talk-stop problem I mentioned before. Now if another cell > phone caller call into the conference bridge, then the one-way delay > of his voice to the first cell phone caller will be a whopping 400 > ms! That would probably turn it into half-duplex effectively. > > When we talk about "high-quality" conference call, it is much more > than just the quality or distortion level of the voice signal; the > one-way delay is also an important and integral part of the > perceived quality of the communication link. This is clearly > documented and well-modeled in the E-model of the ITU-T G.107, and > the 150 ms limit, beyond which the perceived quality sort of "falls > off the cliff", was also obtained after careful study by telephony > experts at the ITU-T. It would be wise for the IETF codec WG to > heed the warning of the ITU-T experts and keep the one-way delay > less than 150 ms. > > In contrast, if the IETF codec has a codec frame size and packet > size of 5 ms, then the on-the-net one-way conferencing delay is only > 50 ms. Even if you use a longer jitter buffer, the one-way delay is > still unlikely to go above 100 ms, which is still well within the > ITU-T's 150 ms guideline. > > True, sending 5 ms packets means the packet header overhead would be > higher, but that's a small price to pay to enable the conference > participants to have a high-quality experience by avoiding the > problems associated with a long one-way delay. The bit-rate penalty > is not 64 kb/s as you said, but 3/4 of that, or 48 kb/s, because you > don't get zero packet header overhead for a 20 ms frame size, but 16 > kb/s, so 64 - 16 = 48. > > Now, with the exception of a small percentage of Internet users who > still use dial-up modems, the vast majority of the Internet users > today connect to the Internet at a speed of at least several hundred > kb/s, and most are in the Mbps range. A 48 kb/s penalty is really a > fairly small price to pay for the majority of Internet users when it > can give them a much better high-quality experience with an much > lower delay. > > Furthermore, it is possible to use header compression technology to > shrink that 48 kb/s penalty to almost nothing. > > Also, even if a 5 ms packet size is an overkill in some situations, > a codec with a 5 ms frame size can easily packs two frames of > compressed bit-stream into a 10 ms packet. Then the packet header > overhead bit-rate would be 32 kb/s, so the penalty shrinks by a > factor of 3 from 48 kb/s to 32 - 16 = 16 kb/s. With 10 ms packets, > the one-way conferencing delay would be 100 ms, still well within > the 150 ms guideline. (Actually, since the internal "thread rate" of > real-time OS can still run at 5 ms intervals, the one-way delay can > be made less than 100 ms, but that's too much detail to go into.) In > contrast, a codec with a 20 ms frame size cannot send its bit-stream > with 10 ms packets, unless it spreads each frame into two packets, > which is what IETF AVT advises against, because it will effectively > double the packet loss rate. > > The way I see it, for conference bridge applications at least, I > think it would be a big mistake for IETF to recommend a codec with a > frame size of 20 ms or higher. From my analysis above, by doing > that we will be stuck with too long a delay and the associated > problems. > > Best Regards, > > Raymond > > -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] > Sent: Thursday, April 22, 2010 9:05 PM > To: Raymond (Juin-Hwey) Chen > Cc: Christian Hoene; 'stephen botzko'; codec@ietf.org > Subject: Re: [codec] #16: Multicast? > > Hi, > > See me comments below. > >> [Raymond]: High quality is a given, but I would like to emphasize the >> importance of low latency. >> >> (1) It is well-known that the longer the latency, the lower the >> perceived quality of the communication link. The E-model in the ITU-T >> Recommendation G.107 models such communication quality in MOS_cqe, >> which among other things depends on the so-called "delay impairment >> factor" /Id/. Basically, MOS_cqe is a monotonically decreasing >> function of increasing latency, and beyond about 150 ms one-way delay, >> the perceived quality of the communication link drops rapidly with >> further delay increase. >> > > As the author of CELT, I obviously agree that latency is an important > aspect for this codec :-) That being said, I tend to say that 20 ms is > still the most widely used frame size, so we might as well optimise for > that. This is not really a problem because as the frame size goes down, > the overhead of the IP/UDP/RTP headers go up, so the codec bit-rate > becomes a bit less of an issue. For example, with 5 ms frames, we would > already be sending 64 kb/s worth of headers (excluding the link layer), > so we might as well spend about as many bits on the actual payload as we > spend on the headers. And with 64 kb/s of payload, we can actually have > high-quality full-band audio. > >> 1) If a conference bridge has to decode a large number of voice >> channels, mix, and re-encode, and if compressed-domain mixing cannot >> be done (which is usually the case), then it is important to keep the >> decoder complexity low. > > Definitely agree here. The decoder complexity is very important. Not > only because of mixing issue, but also because the decoder is generally > not allowed to take shortcuts to save on complexity (unlike the > encoder). As for compressed-domain mixing, as you say it is not always > available, but *if* we can do it (even if only partially), then that can > result in a "free" reduction in decoder complexity for mixing. > >> 2) In topology b) of your other email >> (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, or >> VoIP gateway, often has to encode and decode thousands of voice >> channels in a single box, so not only the computational complexity, >> but also the per-instance RAM size requirement of the codec become >> very important for achieving high channel density in the gateway. >> > > Agreed here, although I would say that per-instance RAM -- as long as > it's reasonable -- is probably a bit less important than complexity. > >> 3) Many telephone terminal devices at the edge of the Internet use >> embedded processors with limited processing power, and the processors >> also have to handle many tasks other than speech coding. If the IETF >> codec complexity is too high, some of such devices may not have >> sufficient processing power to run it. Even if the codec can fit, some >> battery-powered mobile devices may prefer to run a lower-complexity >> codec to reduce power consumption and battery drain. For example, even >> if you make a Internet phone call from a computer, you may like the >> convenience of using a Bluetooth headset that allows you to walk >> around a bit and have hands-free operation. Currently most Bluetooth >> headsets have small form factors with a tiny battery. This puts a >> severe constraint on power consumption. Bluetooth headset chips >> typically have very limited processing capability, and it has to >> handle many other tasks such as echo cancellation and noise reduction. >> There is just not enough processing power to handle a relatively >> high-complexity codec. Most BT headsets today relies on the extremely >> low-complexity, hardware-based CVSD codec at 64 kb/s to transmit >> narrowband voice, but CVSD has audible coding noise, so it degrades >> the overall audio quality. If the IETF codec has low enough >> complexity, it would be possible to directly encode and decode the >> IETF codec bit-stream at the BT headset, thus avoiding the quality >> degradation of CVSD transcoding. >> > > Any idea what the complexity requirements would be for this use-case to > be possible? > > Cheers, > > Jean-Marc > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From rchen@broadcom.com Sat Apr 24 14:41:15 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 710AB3A6800 for ; Sat, 24 Apr 2010 14:41:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.629 X-Spam-Level: X-Spam-Status: No, score=-0.629 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXiTuba81Six for ; Sat, 24 Apr 2010 14:41:14 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 457F93A694A for ; Sat, 24 Apr 2010 14:41:14 -0700 (PDT) Received: from [10.9.200.133] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Sat, 24 Apr 2010 14:40:53 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Sat, 24 Apr 2010 14:42:17 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Jean-Marc Valin" Importance: low X-Priority: 5 Date: Sat, 24 Apr 2010 14:40:51 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrimhyNUh3NLsf5RvSfcmuOhmvRfwBUwYUA Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> In-Reply-To: <4BD11C50.2020206@usherbrooke.ca> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67CDBAEF31G102528969-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" , 'stephen botzko' Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 21:41:15 -0000 Hi Jean-Marc, I would like to respond to a comment and a question in your original email = below. (1) Regarding your comment that "per-instance RAM -- as long as=20 it's reasonable -- is probably a bit less important than complexity", I thi= nk this may or may not be true depending on what is defined as "reasonable"= , and it also depends on the VoIP gateway under consideration. However, I t= hink one thing is clear, though: per-instance RAM is definitely not unimpor= tant. I have worked in a team that designed high-density VoIP gateways, an= d I know people did all kinds of tricks to reduce the RAM usage as much as = possible because of the high cost of the external high-speed SRAM used by h= igh-speed DSPs in such gateways. =20 Currently, high-density VoIP gateways can have several tens of thousands of= voice channels per box or per equipment rack. If codec A uses X kbytes mo= re per-instance RAM than codec B, than implementing codec A rather than cod= ec B in all channels will require X * (number of channels) more kbytes of h= igh-speed SRAM, which can be a substantial additional cost. Similarly, if = codec A requires a substantially higher DSP MHz than codec B, then implemen= ting codec A in all channels will mean that more high-speed DSP chips need = to be used to maintain the same number of channels. That's additional cost= . Actually, the more likely scenario is that the number of DSP chips has a= lready maxed out due to board space or heat dissipation constraint, then th= e gateway can only support a substantially smaller number of voice channels= when compared with using codec B. Consequently, the channel density per b= ox or per rack goes down substantially, and the per-channel deployment cost= goes up substantially. Thus, even if implementing codec A or codec B make= s no practical difference in a PC, it can make a very real and substantial = cost difference in VoIP gateways. An important application for the IETF codec is identified as "IPend-to-tran= scoding_gateway-to-PSTNend". If the deployment cost of the IETF codec in t= he VoIP gateway is too high, that will limit the degree of such deployment,= thus reducing the availability of such IP-to-PSTN calls and the usefulness= of the IETF codec in this application scenario.=20 (2) Regarding your question about the complexity requirement for the Blueto= oth headset use case to be possible, for the current generation of low-end = to mid-end Bluetooth mono headsets where most of the volume is, the 64 kb/s= narrowband CVSD codec is universally used but is implemented in chip hardw= are and consumes no DSP or host processor cycles. (Many of them don't even = have a DSP on chip and just have a host processor such as ARM7.) All the p= rocessor cycles are being used by other tasks such as Bluetooth stack, echo= control, noise suppression, packet loss concealment, etc. Therefore, ther= e actually aren't meaningful available processor cycles for a non-hardware-= based codec unless we remove some other DSP functions or reduce their MHz c= onsumption to make room for a firmware-implemented codec. For the low- to mid-end Bluetooth headsets currently under development, the= situation is not that much better. Again we have to remove other function= s or reduce their MHz usage to make room for a firmware-based codec. Given= such tight resources constraints, I would say ideally the full-duplex comp= lexity of such a firmware-based codec should be no more than about 5 MHz on= a typical 16-bit fixed-point DSP. In a few years time, the acceptable MHz= number may go up to 10 MHz, or at most 15 MHz. Best Regards, Raymond -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca]=20 Sent: Thursday, April 22, 2010 9:05 PM To: Raymond (Juin-Hwey) Chen Cc: Christian Hoene; 'stephen botzko'; codec@ietf.org Subject: Re: [codec] #16: Multicast? Hi, See me comments below. > [Raymond]: High quality is a given, but I would like to emphasize the=20 > importance of low latency. > > (1) It is well-known that the longer the latency, the lower the=20 > perceived quality of the communication link. The E-model in the ITU-T=20 > Recommendation G.107 models such communication quality in MOS_cqe,=20 > which among other things depends on the so-called "delay impairment=20 > factor" /Id/. Basically, MOS_cqe is a monotonically decreasing=20 > function of increasing latency, and beyond about 150 ms one-way delay,=20 > the perceived quality of the communication link drops rapidly with=20 > further delay increase. > As the author of CELT, I obviously agree that latency is an important=20 aspect for this codec :-) That being said, I tend to say that 20 ms is=20 still the most widely used frame size, so we might as well optimise for=20 that. This is not really a problem because as the frame size goes down,=20 the overhead of the IP/UDP/RTP headers go up, so the codec bit-rate=20 becomes a bit less of an issue. For example, with 5 ms frames, we would=20 already be sending 64 kb/s worth of headers (excluding the link layer),=20 so we might as well spend about as many bits on the actual payload as we=20 spend on the headers. And with 64 kb/s of payload, we can actually have=20 high-quality full-band audio. > 1) If a conference bridge has to decode a large number of voice=20 > channels, mix, and re-encode, and if compressed-domain mixing cannot=20 > be done (which is usually the case), then it is important to keep the=20 > decoder complexity low. Definitely agree here. The decoder complexity is very important. Not=20 only because of mixing issue, but also because the decoder is generally=20 not allowed to take shortcuts to save on complexity (unlike the=20 encoder). As for compressed-domain mixing, as you say it is not always=20 available, but *if* we can do it (even if only partially), then that can=20 result in a "free" reduction in decoder complexity for mixing. > 2) In topology b) of your other email=20 > (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, or=20 > VoIP gateway, often has to encode and decode thousands of voice=20 > channels in a single box, so not only the computational complexity,=20 > but also the per-instance RAM size requirement of the codec become=20 > very important for achieving high channel density in the gateway. > Agreed here, although I would say that per-instance RAM -- as long as=20 it's reasonable -- is probably a bit less important than complexity. > 3) Many telephone terminal devices at the edge of the Internet use=20 > embedded processors with limited processing power, and the processors=20 > also have to handle many tasks other than speech coding. If the IETF=20 > codec complexity is too high, some of such devices may not have=20 > sufficient processing power to run it. Even if the codec can fit, some=20 > battery-powered mobile devices may prefer to run a lower-complexity=20 > codec to reduce power consumption and battery drain. For example, even=20 > if you make a Internet phone call from a computer, you may like the=20 > convenience of using a Bluetooth headset that allows you to walk=20 > around a bit and have hands-free operation. Currently most Bluetooth=20 > headsets have small form factors with a tiny battery. This puts a=20 > severe constraint on power consumption. Bluetooth headset chips=20 > typically have very limited processing capability, and it has to=20 > handle many other tasks such as echo cancellation and noise reduction.=20 > There is just not enough processing power to handle a relatively=20 > high-complexity codec. Most BT headsets today relies on the extremely=20 > low-complexity, hardware-based CVSD codec at 64 kb/s to transmit=20 > narrowband voice, but CVSD has audible coding noise, so it degrades=20 > the overall audio quality. If the IETF codec has low enough=20 > complexity, it would be possible to directly encode and decode the=20 > IETF codec bit-stream at the BT headset, thus avoiding the quality=20 > degradation of CVSD transcoding. > Any idea what the complexity requirements would be for this use-case to=20 be possible? Cheers, Jean-Marc From stephen.botzko@gmail.com Sat Apr 24 16:37:08 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1CEE3A67FD for ; Sat, 24 Apr 2010 16:37:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.764 X-Spam-Level: X-Spam-Status: No, score=-1.764 tagged_above=-999 required=5 tests=[AWL=-0.655, BAYES_05=-1.11, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K10te-iUB71F for ; Sat, 24 Apr 2010 16:37:06 -0700 (PDT) Received: from mail-iw0-f194.google.com (mail-iw0-f194.google.com [209.85.223.194]) by core3.amsl.com (Postfix) with ESMTP id 393F33A6782 for ; Sat, 24 Apr 2010 16:37:05 -0700 (PDT) Received: by iwn32 with SMTP id 32so7228479iwn.18 for ; Sat, 24 Apr 2010 16:36:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=JhzUziPFY/Yglq2Y+Cq6jYGYSjlbBTzpmBnmTv0eV+U=; b=xGpfmguTNOD19OcIfCs8AGlqExZj0tC6gg2J+5+Xis4dUtd4sE293ZaKX08fXYTQg8 2vzNlSaUJs1Mft3OFl8BJWzayeb27EDPXc42K0owdCA1ty9I1Kvg7vzUU6y9rODXMvBo 9MdjyWtHlSQbC/ro36RSBRFxrwMvOnsw+oF2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=Ym3BqF1zNn0Vc0e/1DQIWHmeeYBMfkFfcIx5gxzZNEz/ISaY3xCNTIFzukKSrbmTbM g6eEU7+5w9wVRgmZkmQ3FnV55Zs0oVGDt64c630wGzFCoHmLxliEi8bluQsMOef2hBRO 8dPNBWJx8tMl7COK7vDOI3uoGnfWsipaPVb3g= MIME-Version: 1.0 Received: by 10.231.190.197 with SMTP id dj5mr651484ibb.58.1272152212076; Sat, 24 Apr 2010 16:36:52 -0700 (PDT) Received: by 10.231.79.213 with HTTP; Sat, 24 Apr 2010 16:36:51 -0700 (PDT) In-Reply-To: <20100424135607.84293hkaa13j1zvr@mail.skype.net> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <20100424135607.84293hkaa13j1zvr@mail.skype.net> Date: Sat, 24 Apr 2010 19:36:51 -0400 Message-ID: From: stephen botzko To: Koen Vos Content-Type: multipart/alternative; boundary=0016367b6332b3798c048504048d Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Apr 2010 23:37:08 -0000 --0016367b6332b3798c048504048d Content-Type: text/plain; charset=ISO-8859-1 >>> Sure - for certain frame sizes. But 1 ms frames won't give you 5 ms one-way delay. >>> Agreed, this delay model is too simplisti to be useful. There's algorithmic delay (including framing) + flight time + dejittering. Flight time depends on the network path, not on the frame size. And the amount of jitter is due principally to cross-congestion. Stephen Botzko On Sat, Apr 24, 2010 at 4:56 PM, Koen Vos wrote: > Quoting "Raymond (Juin-Hwey) Chen" > > An IP phone guru told me that for a typical IP phone application, it is >> also quite common to see a one-way delay of 5 times the codec frame size. >> > > Sure - for certain frame sizes. But 1 ms frames won't give you 5 ms > one-way delay. > > For a well-designed system and a typical Internet connection: > - most delay comes from the network and is not codec related, and > - one-way delay grows almost linearly with frame size. > > > > Furthermore, it is possible to use header compression technology to shrink >> that 48 kb/s penalty to almost nothing. >> > > Afaik, only RTP headers can be compressed between arbitrary Internet end > points. You're still stuck with IP and UDP headers. > > best, > koen. > > > > > Quoting "Raymond (Juin-Hwey) Chen" : > >> Hi Jean-Marc, >> >> I agree that the 20 ms frame size or packet size is more efficient in >> bit-rate. However, this comment doesn't address my original point on the >> need to have a low-delay IETF codec for the conferencing bridge scenario, >> where the voice signal will travel through the codec twice (2 tandems), thus >> doubling the one-way codec delay. >> >> As you are well aware of, codec design involves many trade-offs between >> the four major attributes of a codec: delay, complexity, bit-rate, and >> quality. For a given codec architecture, improving one attribute normally >> means sacrificing at least one other attribute. Nothing comes for free. >> Therefore, yes, to get low delay, you need to pay the price of lower >> bit-rate efficiency, but you can also view it another way: to get higher >> bit-rate efficiency by using a 20 ms frame size, you pay the price of a >> higher codec delay. The question to ask then, is not which frame size is >> more bit-rate efficient, but whether there are application scenarios where a >> 20 ms frame size will simply make the one-way delay way too long and greatly >> degrade the users' communication experience. I believe the answer to the >> latter question is a definite "yes". >> >> Let's do some math to see why that is so. Essentially all cellular codecs >> use a frame size of 20 ms, yet the one-way delay of a cell-to-landline call >> is typically 80 to 110 ms, or 4 to 5.5 times the codec frame size. This is >> because you have not only the codec buffering delay, but also processing >> delay, transmission delay, and delay due to processor sharing using >> real-time OS, etc. An IP phone guru told me that for a typical IP phone >> application, it is also quite common to see a one-way delay of 5 times the >> codec frame size. Let's just take 5X codec frame size as the one-way delay >> of a typical implementation. Then, even if all conference participants use >> their computers to call the conference bridge, if the IETF codec has a frame >> size of 20 ms, then after the voice signal of a talker goes through the IETF >> codec to the bridge, it already takes 100 ms one-way delay. After the >> bridge decodes all channels, mixes, and re-encodes with the IETF codec and >> send to every particip >> ant, the one-way delay is now already up to 200 ms, way more than the 150 >> ms limit I mentioned in my last email. Now if a talker call into the >> conference bridge through a cell phone call that has 100 ms one-way delay to >> the edge of the Internet, by the time everyone else hears his voice, it is >> already 300 ms later. Anyone trying to interrupt that cell phone caller >> will experience the talk-stop-talk-stop problem I mentioned before. Now if >> another cell phone caller call into the conference bridge, then the one-way >> delay of his voice to the first cell phone caller will be a whopping 400 ms! >> That would probably turn it into half-duplex effectively. >> >> When we talk about "high-quality" conference call, it is much more than >> just the quality or distortion level of the voice signal; the one-way delay >> is also an important and integral part of the perceived quality of the >> communication link. This is clearly documented and well-modeled in the >> E-model of the ITU-T G.107, and the 150 ms limit, beyond which the perceived >> quality sort of "falls off the cliff", was also obtained after careful study >> by telephony experts at the ITU-T. It would be wise for the IETF codec WG >> to heed the warning of the ITU-T experts and keep the one-way delay less >> than 150 ms. >> >> In contrast, if the IETF codec has a codec frame size and packet size of 5 >> ms, then the on-the-net one-way conferencing delay is only 50 ms. Even if >> you use a longer jitter buffer, the one-way delay is still unlikely to go >> above 100 ms, which is still well within the ITU-T's 150 ms guideline. >> >> True, sending 5 ms packets means the packet header overhead would be >> higher, but that's a small price to pay to enable the conference >> participants to have a high-quality experience by avoiding the problems >> associated with a long one-way delay. The bit-rate penalty is not 64 kb/s >> as you said, but 3/4 of that, or 48 kb/s, because you don't get zero packet >> header overhead for a 20 ms frame size, but 16 kb/s, so 64 - 16 = 48. >> >> Now, with the exception of a small percentage of Internet users who still >> use dial-up modems, the vast majority of the Internet users today connect to >> the Internet at a speed of at least several hundred kb/s, and most are in >> the Mbps range. A 48 kb/s penalty is really a fairly small price to pay for >> the majority of Internet users when it can give them a much better >> high-quality experience with an much lower delay. >> >> Furthermore, it is possible to use header compression technology to shrink >> that 48 kb/s penalty to almost nothing. >> >> Also, even if a 5 ms packet size is an overkill in some situations, a >> codec with a 5 ms frame size can easily packs two frames of compressed >> bit-stream into a 10 ms packet. Then the packet header overhead bit-rate >> would be 32 kb/s, so the penalty shrinks by a factor of 3 from 48 kb/s to 32 >> - 16 = 16 kb/s. With 10 ms packets, the one-way conferencing delay would be >> 100 ms, still well within the 150 ms guideline. (Actually, since the >> internal "thread rate" of real-time OS can still run at 5 ms intervals, the >> one-way delay can be made less than 100 ms, but that's too much detail to go >> into.) In contrast, a codec with a 20 ms frame size cannot send its >> bit-stream with 10 ms packets, unless it spreads each frame into two >> packets, which is what IETF AVT advises against, because it will effectively >> double the packet loss rate. >> >> The way I see it, for conference bridge applications at least, I think it >> would be a big mistake for IETF to recommend a codec with a frame size of 20 >> ms or higher. From my analysis above, by doing that we will be stuck with >> too long a delay and the associated problems. >> >> Best Regards, >> >> Raymond >> >> -----Original Message----- >> From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] >> Sent: Thursday, April 22, 2010 9:05 PM >> To: Raymond (Juin-Hwey) Chen >> Cc: Christian Hoene; 'stephen botzko'; codec@ietf.org >> Subject: Re: [codec] #16: Multicast? >> >> Hi, >> >> See me comments below. >> >> [Raymond]: High quality is a given, but I would like to emphasize the >>> importance of low latency. >>> >>> (1) It is well-known that the longer the latency, the lower the >>> perceived quality of the communication link. The E-model in the ITU-T >>> Recommendation G.107 models such communication quality in MOS_cqe, >>> which among other things depends on the so-called "delay impairment >>> factor" /Id/. Basically, MOS_cqe is a monotonically decreasing >>> function of increasing latency, and beyond about 150 ms one-way delay, >>> the perceived quality of the communication link drops rapidly with >>> further delay increase. >>> >>> >> As the author of CELT, I obviously agree that latency is an important >> aspect for this codec :-) That being said, I tend to say that 20 ms is >> still the most widely used frame size, so we might as well optimise for >> that. This is not really a problem because as the frame size goes down, >> the overhead of the IP/UDP/RTP headers go up, so the codec bit-rate >> becomes a bit less of an issue. For example, with 5 ms frames, we would >> already be sending 64 kb/s worth of headers (excluding the link layer), >> so we might as well spend about as many bits on the actual payload as we >> spend on the headers. And with 64 kb/s of payload, we can actually have >> high-quality full-band audio. >> >> 1) If a conference bridge has to decode a large number of voice >>> channels, mix, and re-encode, and if compressed-domain mixing cannot >>> be done (which is usually the case), then it is important to keep the >>> decoder complexity low. >>> >> >> Definitely agree here. The decoder complexity is very important. Not >> only because of mixing issue, but also because the decoder is generally >> not allowed to take shortcuts to save on complexity (unlike the >> encoder). As for compressed-domain mixing, as you say it is not always >> available, but *if* we can do it (even if only partially), then that can >> result in a "free" reduction in decoder complexity for mixing. >> >> 2) In topology b) of your other email >>> (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, or >>> VoIP gateway, often has to encode and decode thousands of voice >>> channels in a single box, so not only the computational complexity, >>> but also the per-instance RAM size requirement of the codec become >>> very important for achieving high channel density in the gateway. >>> >>> >> Agreed here, although I would say that per-instance RAM -- as long as >> it's reasonable -- is probably a bit less important than complexity. >> >> 3) Many telephone terminal devices at the edge of the Internet use >>> embedded processors with limited processing power, and the processors >>> also have to handle many tasks other than speech coding. If the IETF >>> codec complexity is too high, some of such devices may not have >>> sufficient processing power to run it. Even if the codec can fit, some >>> battery-powered mobile devices may prefer to run a lower-complexity >>> codec to reduce power consumption and battery drain. For example, even >>> if you make a Internet phone call from a computer, you may like the >>> convenience of using a Bluetooth headset that allows you to walk >>> around a bit and have hands-free operation. Currently most Bluetooth >>> headsets have small form factors with a tiny battery. This puts a >>> severe constraint on power consumption. Bluetooth headset chips >>> typically have very limited processing capability, and it has to >>> handle many other tasks such as echo cancellation and noise reduction. >>> There is just not enough processing power to handle a relatively >>> high-complexity codec. Most BT headsets today relies on the extremely >>> low-complexity, hardware-based CVSD codec at 64 kb/s to transmit >>> narrowband voice, but CVSD has audible coding noise, so it degrades >>> the overall audio quality. If the IETF codec has low enough >>> complexity, it would be possible to directly encode and decode the >>> IETF codec bit-stream at the BT headset, thus avoiding the quality >>> degradation of CVSD transcoding. >>> >>> >> Any idea what the complexity requirements would be for this use-case to >> be possible? >> >> Cheers, >> >> Jean-Marc >> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016367b6332b3798c048504048d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
=A0=A0 Sure - for certain frame sizes. =A0But 1 ms frames w= on't give you 5 ms=20 one-way delay.
>>>
Agreed, this delay model is too simplisti= to be useful.=A0

There's algorithmic delay (including framing)= + flight time + dejittering.=A0 Flight time depends on the network path, n= ot on the frame size.=A0 And the amount of jitter is due principally to cro= ss-congestion.

Stephen Botzko

On Sat, Apr 24, 2010 a= t 4:56 PM, Koen Vos <koen.vos@skype.net> wrote:
Quoting "Raymond (Juin-Hwey) Chen"

An IP phone =A0guru told me that for a typical IP phone application, it is = also quite common to see a one-way delay of 5 times the codec frame size.

Sure - for certain frame sizes. =A0But 1 ms frames won't give you 5 ms = one-way delay.

For a well-designed system and a typical Internet connection:
- most delay comes from the network and is not codec related, and
- one-way delay grows almost linearly with frame size.


Furthermore, it is possible to use header compression technology to shrink = that 48 kb/s penalty to almost nothing.

Afaik, only RTP headers can be compressed between arbitrary Internet end po= ints. =A0You're still stuck with IP and UDP headers.

best,
koen.




Quoting "Raymond (Juin-Hwey) Chen" <rchen@broadcom.com>:
=
Hi Jean-Marc,

I agree that the 20 ms frame size or packet size is more efficient in bit-r= ate. =A0However, this comment doesn't address my original point on the = need to have a low-delay IETF codec for the conferencing bridge scenario, w= here the voice signal will travel through the codec twice (2 tandems), thus= doubling the one-way codec delay.

As you are well aware of, codec design involves many trade-offs between the= four major attributes of a codec: delay, complexity, bit-rate, and quality= . =A0For a given codec architecture, improving one attribute normally means= sacrificing at least one other attribute. =A0Nothing comes for free. =A0Th= erefore, yes, to get low delay, you need to pay the price of lower bit-rate= efficiency, but you can also view it another way: to get higher bit-rate e= fficiency by using a 20 ms frame size, you pay the price of a higher codec = delay. =A0The question to ask then, is not which frame size is more bit-rat= e efficient, but whether there are application scenarios where a 20 ms fram= e size will simply make the one-way delay way too long and greatly degrade = the users' communication experience. I believe the answer to the latter= question is a definite "yes".

Let's do some math to see why that is so. =A0Essentially all cellular c= odecs use a frame size of 20 ms, yet the one-way delay of a cell-to-landlin= e call is typically 80 to 110 ms, or 4 to 5.5 times the codec frame size. = =A0This is because you have not only the codec buffering delay, but also pr= ocessing delay, transmission delay, and delay due to processor sharing usin= g real-time OS, etc. =A0An IP phone guru told me that for a typical IP phon= e application, it is also quite common to see a one-way delay of 5 times th= e codec frame size. =A0Let's just take 5X codec frame size as the one-w= ay delay of a typical implementation. =A0Then, even if all conference parti= cipants use their computers to call the conference bridge, if the IETF code= c has a frame size of 20 ms, then after the voice signal of a talker goes t= hrough the IETF codec to the bridge, it already takes 100 ms one-way delay.= =A0After the bridge decodes all channels, mixes, and re-encodes with the I= ETF codec and send to every particip
=A0ant, the one-way delay is now already up to 200 ms, way more than the 15= 0 ms limit I mentioned in my last email. =A0Now if a talker call into the c= onference bridge through a cell phone call that has 100 ms one-way delay to= the edge of the Internet, by the time everyone else hears his voice, it is= already 300 ms later. =A0Anyone trying to interrupt that cell phone caller= will experience the talk-stop-talk-stop problem I mentioned before. =A0Now= if another cell phone caller call into the conference bridge, then the one= -way delay of his voice to the first cell phone caller will be a whopping 4= 00 ms! That would probably turn it into half-duplex effectively.

When we talk about "high-quality" conference call, it is much mor= e than just the quality or distortion level of the voice signal; the one-wa= y delay is also an important and integral part of the perceived quality of = the communication link. =A0This is clearly documented and well-modeled in t= he E-model of the ITU-T G.107, and the 150 ms limit, beyond which the perce= ived quality sort of "falls off the cliff", was also obtained aft= er careful study by telephony experts at the ITU-T. =A0It would be wise for= the IETF codec WG to heed the warning of the ITU-T experts and keep the on= e-way delay less than 150 ms.

In contrast, if the IETF codec has a codec frame size and packet size of 5 = ms, then the on-the-net one-way conferencing delay is only 50 ms. Even if y= ou use a longer jitter buffer, the one-way delay is still unlikely to go ab= ove 100 ms, which is still well within the ITU-T's 150 ms guideline.
True, sending 5 ms packets means the packet header overhead would be higher= , but that's a small price to pay to enable the conference participants= to have a high-quality experience by avoiding the problems associated with= a long one-way delay. =A0The bit-rate penalty is not 64 kb/s as you said, = but 3/4 of that, or 48 kb/s, because you don't get zero packet header o= verhead for a 20 ms frame size, but 16 kb/s, so 64 - 16 =3D 48.

Now, with the exception of a small percentage of Internet users who still u= se dial-up modems, the vast majority of the Internet users today connect to= the Internet at a speed of at least several hundred kb/s, and most are in = the Mbps range. =A0A 48 kb/s penalty is really a fairly small price to pay = for the majority of Internet users when it can give them a much better high= -quality experience with an much lower delay.

Furthermore, it is possible to use header compression technology to shrink = that 48 kb/s penalty to almost nothing.

Also, even if a 5 ms packet size is an overkill in some situations, a codec= with a 5 ms frame size can easily packs two frames of compressed bit-strea= m into a 10 ms packet. =A0Then the packet header overhead bit-rate would be= 32 kb/s, so the penalty shrinks by a factor of 3 from 48 kb/s to 32 - 16 = =3D 16 kb/s. With 10 ms packets, the one-way conferencing delay would be 10= 0 ms, still well within the 150 ms guideline. (Actually, since the internal= "thread rate" of real-time OS can still run at 5 ms intervals, t= he one-way delay can be made less than 100 ms, but that's too much deta= il to go into.) In contrast, a codec with a 20 ms frame size cannot send it= s bit-stream with 10 ms packets, unless it spreads each frame into two pack= ets, which is what IETF AVT advises against, because it will effectively do= uble the packet loss rate.

The way I see it, for conference bridge applications at least, I think it w= ould be a big mistake for IETF to recommend a codec with a frame size of 20= ms or higher. =A0From my analysis above, by doing that we will be stuck wi= th too long a delay and the associated problems.

Best Regards,

Raymond

-----Original Message-----
From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca]
Sent: Thursday, April 22, 2010 9:05 PM
To: Raymond (Juin-Hwey) Chen
Cc: Christian Hoene; 'stephen botzko'; codec@ietf.org
Subject: Re: [codec] #16: Multicast?

Hi,

See me comments below.

[Raymond]: High quality is a given, but I would like to emphasize the
importance of low latency.

(1) It is well-known that the longer the latency, the lower the
perceived quality of the communication link. The E-model in the ITU-T
Recommendation G.107 models such communication quality in MOS_cqe,
which among other things depends on the so-called "delay impairment factor" /Id/. Basically, MOS_cqe is a monotonically decreasing
function of increasing latency, and beyond about 150 ms one-way delay,
the perceived quality of the communication link drops rapidly with
further delay increase.


As the author of CELT, I obviously agree that latency is an important
aspect for this codec :-) That being said, I tend to say that 20 ms is
still the most widely used frame size, so we might as well optimise for
that. This is not really a problem because as the frame size goes down,
the overhead of the IP/UDP/RTP headers go up, so the codec bit-rate
becomes a bit less of an issue. For example, with 5 ms frames, we would
already be sending 64 kb/s worth of headers (excluding the link layer),
so we might as well spend about as many bits on the actual payload as we spend on the headers. And with 64 kb/s of payload, we can actually have
high-quality full-band audio.

1) If a conference bridge has to decode a large number of voice
channels, mix, and re-encode, and if compressed-domain mixing cannot
be done (which is usually the case), then it is important to keep the
decoder complexity low.

Definitely agree here. The decoder complexity is very important. Not
only because of mixing issue, but also because the decoder is generally
not allowed to take shortcuts to save on complexity (unlike the
encoder). As for compressed-domain mixing, as you say it is not always
available, but *if* we can do it (even if only partially), then that can result in a "free" reduction in decoder complexity for mixing.
2) In topology b) of your other email
(IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, or
VoIP gateway, often has to encode and decode thousands of voice
channels in a single box, so not only the computational complexity,
but also the per-instance RAM size requirement of the codec become
very important for achieving high channel density in the gateway.


Agreed here, although I would say that per-instance RAM -- as long as
it's reasonable -- is probably a bit less important than complexity.
3) Many telephone terminal devices at the edge of the Internet use
embedded processors with limited processing power, and the processors
also have to handle many tasks other than speech coding. If the IETF
codec complexity is too high, some of such devices may not have
sufficient processing power to run it. Even if the codec can fit, some
battery-powered mobile devices may prefer to run a lower-complexity
codec to reduce power consumption and battery drain. For example, even
if you make a Internet phone call from a computer, you may like the
convenience of using a Bluetooth headset that allows you to walk
around a bit and have hands-free operation. Currently most Bluetooth
headsets have small form factors with a tiny battery. This puts a
severe constraint on power consumption. Bluetooth headset chips
typically have very limited processing capability, and it has to
handle many other tasks such as echo cancellation and noise reduction.
There is just not enough processing power to handle a relatively
high-complexity codec. Most BT headsets today relies on the extremely
low-complexity, hardware-based CVSD codec at 64 kb/s to transmit
narrowband voice, but CVSD has audible coding noise, so it degrades
the overall audio quality. If the IETF codec has low enough
complexity, it would be possible to directly encode and decode the
IETF codec bit-stream at the BT headset, thus avoiding the quality
degradation of CVSD transcoding.


Any idea what the complexity requirements would be for this use-case to
be possible?

Cheers,

Jean-Marc



_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec



_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016367b6332b3798c048504048d-- From rchen@broadcom.com Sat Apr 24 17:37:10 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F0593A6765 for ; Sat, 24 Apr 2010 17:37:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.648 X-Spam-Level: X-Spam-Status: No, score=-0.648 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVc4vaKgdzv2 for ; Sat, 24 Apr 2010 17:37:09 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 2603A3A67A2 for ; Sat, 24 Apr 2010 17:37:09 -0700 (PDT) Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Sat, 24 Apr 2010 17:36:49 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Sat, 24 Apr 2010 17:38:13 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Koen Vos" , "codec@ietf.org" Importance: low X-Priority: 5 Date: Sat, 24 Apr 2010 17:36:47 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: Acrj8JqSPOBguoP2TMe6kAceml5SdAAHBe3A Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <20100424135607.84293hkaa13j1zvr@mail.skype.net> In-Reply-To: <20100424135607.84293hkaa13j1zvr@mail.skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67CD512B20S101874338-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 00:37:10 -0000 On Saturday, April 24, 2010 at 1:56 PM, Koen Vos Wrote: > Sure - for certain frame sizes. But 1 ms frames won't give you 5 ms =20 > one-way delay. Of course not. That's why I added the sentence: "Even if you use a longer = jitter buffer, the one-way delay is still unlikely to go above 100 ms, ..."= in that email you quoted. I knew that below a certain threshold of the cod= ec frame size, you most likely want to use more frames of jitter buffer del= ay, thus my added sentence above. My main point, though, is not in the exa= ct one-way delay value for a codec with a 5 ms frame size, but rather that = with a 5 ms frame size you can get a much lower one-way delay than with a 2= 0 ms frame size. I don't think anyone can credibly argue that this stateme= nt is untrue. > For a well-designed system and a typical Internet connection: > - most delay comes from the network and is not codec related, and > - one-way delay grows almost linearly with frame size. Doesn't your last line above contradicts with the second last line? I am a = bit confused about what you are trying to say. =20 > Afaik, only RTP headers can be compressed between arbitrary Internet =20 > end points. You're still stuck with IP and UDP headers. I am aware of a header compression technology for VoIP over Cable applicati= ons that can compress the header size to a very small fraction of the origi= nal size, but it is probably not widely used. Raymond From koen.vos@skype.net Sat Apr 24 18:16:36 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D9823A677C for ; Sat, 24 Apr 2010 18:16:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.061 X-Spam-Level: X-Spam-Status: No, score=-5.061 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6h666fuPbXc for ; Sat, 24 Apr 2010 18:16:32 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 694BA3A67FA for ; Sat, 24 Apr 2010 18:16:32 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 31BC260132588; Sun, 25 Apr 2010 02:16:21 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=62J4YMju5cWF /XeOgHUOZROvjFI=; b=VtMUfaxXFqBIdcGPZN2nUs1UXAph78ZztL//JPIMWFwP Glq03SXbBc5hCGgCd1gVMObQz5RlsvRvhh90z3FBNmCndyfTPtNjpWLwmbRMPcrh Y18MmKB5tZBMa3gCLDOcpG88ISg7XjYOXWNGVoDC9t+0nn3eVAxkcx98mtCYpKc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=DvXxip2/gfrlSNfkeJw7 8qYA3JgyZ1u0nSRex0SYfAxlKU4BkRDUqN88Xw+Bx0i4EGwlTv+mL5D9aegPCjbq 5i4ak5G2SAFVdmc5iXiUK+FfJs2WwuSePI9E+T1ms70t80YAm4sXpHe1b6jMuOrO 0aFMxXXpJH0mWus/lbeV9pg= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 2FCC660132462; Sun, 25 Apr 2010 02:16:21 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggQcuMpgo3ii; Sun, 25 Apr 2010 02:16:20 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 761066013254D; Sun, 25 Apr 2010 02:16:20 +0100 (IST) Received: from adsl-71-141-115-202.dsl.snfc21.pacbell.net (adsl-71-141-115-202.dsl.snfc21.pacbell.net [71.141.115.202]) by mail.skype.net (Horde Framework) with HTTP; Sat, 24 Apr 2010 18:16:20 -0700 Message-ID: <20100424181620.352034g28cnjr010@mail.skype.net> Date: Sat, 24 Apr 2010 18:16:20 -0700 From: Koen Vos To: "Raymond (Juin-Hwey) Chen" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <20100424135607.84293hkaa13j1zvr@mail.skype.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 01:16:36 -0000 Quoting "Raymond (Juin-Hwey) Chen": > My main point, though, is not in the exact one-way delay value for a > codec with a 5 ms frame size, but rather that with a 5 ms frame size > you can get a much lower one-way delay than with a 20 ms frame size. It would be about 15 ms lower - don't know if that counts as "much" :) Also, note that for a given probability of packets arriving too late to be played out, the jitter buffer delay is independent of the frame size. >> - most delay comes from the network and is not codec related, and >> - one-way delay grows almost linearly with frame size. > > Doesn't your last line above contradicts with the second last line? I meant that approximately: one-way delay = codec-independent delay + frame size ("codec algorithmic delay" would be more accurate than "frame size") >> Afaik, only RTP headers can be compressed between arbitrary Internet >> end points. You're still stuck with IP and UDP headers. > > I am aware of a header compression technology for VoIP over Cable > applications that can compress the header size to a very small > fraction of the original size, but it is probably not widely used. Yes, header compression works between end-points on a cable. That's different from "between arbitrary Internet end points". best, koen. From rchen@broadcom.com Sat Apr 24 18:30:07 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A91CD3A6855 for ; Sat, 24 Apr 2010 18:30:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.29 X-Spam-Level: X-Spam-Status: No, score=-0.29 tagged_above=-999 required=5 tests=[AWL=-0.292, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bgdumt0jFpcY for ; Sat, 24 Apr 2010 18:30:05 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 10FE93A67A2 for ; Sat, 24 Apr 2010 18:30:05 -0700 (PDT) Received: from [10.9.200.133] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Sat, 24 Apr 2010 18:29:44 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Sat, 24 Apr 2010 18:31:08 -0700 From: "Raymond (Juin-Hwey) Chen" To: "stephen botzko" , "Koen Vos" Importance: low X-Priority: 5 Date: Sat, 24 Apr 2010 18:29:42 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrkBw4pMpf+gEl3QYWZ3Yo0uUVTXAACCHlw Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <20100424135607.84293hkaa13j1zvr@mail.skype.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67CD448231G102660943-01-01 Content-Type: multipart/alternative; boundary=_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A28BIRVEXCHCCR01c_ Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 01:30:07 -0000 --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A28BIRVEXCHCCR01c_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable On Saturday, April 24, 2010 at 4:37 PM, Stephen Botzko wrote: >>> Sure - for certain frame sizes. But 1 ms frames won't give you 5 ms one= -way delay. >>> > Agreed, this delay model is too simplisti to be useful. > There's algorithmic delay (including framing) + flight time + dejittering= . Flight time depends on the > network path, not on the frame size. And t= he amount of jitter is due principally to cross-congestion. I also agree. See my last email. My main point was not the absolute one-= way delay value for the 5 ms frame size but the relative delay between 5 ms= and 20 ms frame sizes. I agree that the 5X delay might be too simplistic.= I tried to use a simple formula to make it is easier for people to follow= , but I did realize its limitation especially at a small frame size, so I a= dded that "Even if you use a longer jitter buffer, ..." sentence. Regardless of whether 5X frame size is overly simplistic, the fact remains = that cellular codecs have a 20 ms frame size and have a typical one-way del= ay around 80 to 110 ms or so, and the cellular networks probably don't have= the kind of jitter that the Internet has. What would make us believe that= an IETF codec with a 20 ms frame size will get a one-way delay much below = 80 ms? Chances are an Internet call using an IETF codec with a 20 ms frame= size will likely have a one-way delay at least as long as the one-way dela= y of a cell phone call, and more likely to be longer, because PC audio driv= er software tends to add quite a bit of delay, and an Internet call incurs = additional jitter buffer delay when compared with cell phone calls. Therefore, regardless of the accuracy of the 5X frame size formula, the con= clusion remains the same: for the conference bridge application, a 20 ms co= dec frame size will result in the total one-way delay far exceeding the ITU= -T's 150 ms guideline, thus substantially degrading the perceived quality o= f the communication links, and with one or even two cell phone callers join= ing the conference, the long latency and the associated problems will just = get much worse. Therefore, it is necessary for the IETF codec to have a lo= w-delay mode using a small codec frame size such as 5 ms to address delay-s= ensitive applications such as bridge-based conference calls. Raymond --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A28BIRVEXCHCCR01c_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

On Saturday, April 24, 2010 at 4:37 PM, Stephen Botzko wrote:

>>>
   Sure - for certain frame sizes.  But 1 ms frames won't gi= ve you 5 ms one-way delay.
>>>
> Agreed, this delay model is too simplisti to be useful.

> There's algorithmic delay (including framing) + flight time + dejittering.  Flight time depends on the > network path, not on the frame size.  And the amount of jitter is due principa= lly to cross-congestion.

I also agree.  See my last email.   My main point was not the absolute one-way delay value for the 5 ms frame size but the relative delay= between 5 ms and 20 ms frame sizes.  I agree that the 5X delay might be too simplistic.  I tried to use a simple formula to make it is easier for people to follow, but I did realize its limitation especially at a small fr= ame size, so I added that “Even if you use a longer jitter buffer, …= ;” sentence. 

Regardless of whether 5X frame size is overly simplistic, the fact remains that cellul= ar codecs have a 20 ms frame size and have a typical one-way delay around 80 t= o 110 ms or so, and the cellular networks probably don’t have the kind = of jitter that the Internet has.  What would make us believe that an IETF codec with a 20 ms frame size will get a one-way delay much below 80 ms?&nb= sp; Chances are an Internet call using an IETF codec with a 20 ms frame size will likel= y have a one-way delay at least as long as the one-way delay of a cell phone call,= and more likely to be longer, because PC audio driver software tends to add qui= te a bit of delay, and an Internet call incurs additional jitter buffer delay wh= en compared with cell phone calls.

Therefore, regardless of the accuracy of the 5X frame size formula, the conclusion rem= ains the same: for the conference bridge application, a 20 ms codec frame size w= ill result in the total one-way delay far exceeding the ITU-T’s 150 ms guideline= , thus substantially degrading the perceived quality of the communication lin= ks, and with one or even two cell phone callers joining the conference, the lon= g latency and the associated problems will just get much worse.  Therefore, it i= s necessary for the IETF codec to have a low-delay mode using a small codec f= rame size such as 5 ms to address delay-sensitive applications such as bridge-ba= sed conference calls.

Raymond

--_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A28BIRVEXCHCCR01c_-- From swmike@swm.pp.se Sat Apr 24 19:45:40 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7E5B3A6B3E for ; Sat, 24 Apr 2010 19:45:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.54 X-Spam-Level: X-Spam-Status: No, score=-4.54 tagged_above=-999 required=5 tests=[AWL=-0.891, BAYES_50=0.001, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNZd8y+0sF22 for ; Sat, 24 Apr 2010 19:45:40 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id B34273A6B3C for ; Sat, 24 Apr 2010 19:45:36 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 4C3509F; Sun, 25 Apr 2010 04:45:20 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 493839E; Sun, 25 Apr 2010 04:45:20 +0200 (CEST) Date: Sun, 25 Apr 2010 04:45:20 +0200 (CEST) From: Mikael Abrahamsson To: "Raymond (Juin-Hwey) Chen" In-Reply-To: Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <20100424135607.84293hkaa13j1zvr@mail.skype.net> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 02:45:41 -0000 On Sat, 24 Apr 2010, Raymond (Juin-Hwey) Chen wrote: > Of course not. That's why I added the sentence: "Even if you use a > longer jitter buffer, the one-way delay is still unlikely to go above > 100 ms, ..." in that email you quoted. I knew that below a certain The light-speed-in-fiber delay RTT is 1ms per 100km. Europe - US West coast is ~150ms RTT. I'm in Thailand at the momen. I have 350ms RTT to Sweden currently (because the path goes sweden->us->singapore>thailand), just to give some datapoints. Add then ADSL2+ 25ms RTT just over the access layer, and I'd say that 200ms network RTT (100ms one-way) might be a low percentage of the calls, but it's still definitely going to happen. Considering the prices of internationall calls out of a place like this, a lot of people are going to want to use it to get around it. I talked to my mother over skype yesterday, because international calls are like 0.5USD/minute. To get around the huge jitter and packet loss I have on the access, it cranked up the jitter buffers to 2-3seconds. I still prefer this to paying 0.5USD/minute. So these are the diverse network conditions that the solution (where the codec is a part) needs to handle, it needs to be able to do interactive voice etc over a local network in cd (at least) quality, plus it needs to give intelligeble speech communication (walkie talkie quality if needed) over very adverse network conditions. GPRS-EDGE here works fairly well, better than the Wifi I'm on, it might very well be that using GPRS-EDGE with 4pps (250ms per packet so as to get vey low packet header overhead)) and a very low-bw codec would be better than the Wifi. I absolutely agree that we need quite a few different modes, and these need to be decoupled from each other because different conditions need different responses from the solution. Low pps for some, low quality but high pps for others, and of course all the other combinations of the factors involved. -- Mikael Abrahamsson email: swmike@swm.pp.se From rchen@broadcom.com Sat Apr 24 21:11:02 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 073FF3A6B41 for ; Sat, 24 Apr 2010 21:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.253 X-Spam-Level: X-Spam-Status: No, score=-0.253 tagged_above=-999 required=5 tests=[AWL=-0.255, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id umege5ywlkVy for ; Sat, 24 Apr 2010 21:10:53 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 3805B3A6981 for ; Sat, 24 Apr 2010 21:10:53 -0700 (PDT) Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Sat, 24 Apr 2010 21:10:30 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Sat, 24 Apr 2010 21:11:54 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Koen Vos" Importance: low X-Priority: 5 Date: Sat, 24 Apr 2010 21:10:29 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrkFPDDYsfSXcjBTAiPU6HWdiXEbgAA3a4w Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <20100424135607.84293hkaa13j1zvr@mail.skype.net> <20100424181620.352034g28cnjr010@mail.skype.net> In-Reply-To: <20100424181620.352034g28cnjr010@mail.skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67CD1F3C20S101990892-01-01 Content-Type: multipart/alternative; boundary=_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A290IRVEXCHCCR01c_ Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 04:11:02 -0000 --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A290IRVEXCHCCR01c_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Koen, My comments in-line below. Best Regards, Raymond -----Original Message----- From: Koen Vos [mailto:koen.vos@skype.net] Sent: Saturday, April 24, 2010 6:16 PM To: Raymond (Juin-Hwey) Chen Cc: codec@ietf.org Subject: RE: [codec] #16: Multicast? Quoting "Raymond (Juin-Hwey) Chen": > My main point, though, is not in the exact one-way delay value for a > codec with a 5 ms frame size, but rather that with a 5 ms frame size > you can get a much lower one-way delay than with a 20 ms frame size. It would be about 15 ms lower - don't know if that counts as "much" :) [Raymond]: I don't agree that it will be only 20 - 5 =3D 15 ms lower. That= will be true only if your one-way delay formula below is true, but theoret= ically it cannot be. See my comment below your formula. Also, note that for a given probability of packets arriving too late to be played out, the jitter buffer delay is independent of the frame size. [Raymond]: That may be true theoretically, but in practical implementations= , selecting a jitter buffer delay that is not divisible by the packet size = would make the adaptive jitter buffer pretty messy to implement. If we mak= e the it divisible by the packet size, then a smaller packet size gives you= more granularity to work with and can result in lower average delay as the= codec frames go through the adaptive jitter buffer. >> - most delay comes from the network and is not codec related, and >> - one-way delay grows almost linearly with frame size. > > Doesn't your last line above contradicts with the second last line? I meant that approximately: one-way delay =3D codec-independent delay + frame size ("codec algorithmic delay" would be more accurate than "frame size") [Raymond]: First, I agree that codec algorithmic buffering delay is more ac= curate than frame size since it can also include the "look-ahead" delay and= filtering delay if sub-band analysis/synthesis is used. However, your for= mula implies that for the codec-related delay, the "multiplier" to be used = for the codec frame size is only 1. That's unrealistic and theoretically i= mpossible. For that to happen, after you wait one frame of time for the cu= rrent frame of input audio samples to arrive at your input signal buffer (t= hat's one frame of codec-related delay already), you need an infinitely fas= t processor to finish the encoding operation instantly, then you need an in= finitely fast communication link to ship all the bits in the compressed fra= me to the decoder instantly, and then you need an infinitely fast processor= to finish decoding the frame instantly and start playing back the current = frame of audio without any delay. That's just impossible. In reality, if the processor is just barely fast enough to implement the co= dec in real time, then you need nearly a full frame of time to finish the e= ncoding and decoding operations. That makes the multiplier to be 2 already.= If your communication link is just barely fast enough to transmit your pa= ckets at the same speed they are generated without piling up unsent packets= , then it takes another frame of time to finish transmitting the compressed= bits in a frame to the decoder. That makes the multiplier to be 3 already= . Granted, in practice the processor and the communication link are usually f= aster than just barely enough, so the processing delay and the transmission= delay can be less than 1 frame each. However, there are other miscellaneo= us uncounted delays that tends to depend on the codec size in various ways.= Thus, a typical IP phone implementation would have One-way delay =3D codec-independent delay + 3*(codec frame size) + (codec= look-ahead) + (codec filtering delay if any). Hence, the one-way delay difference between a 20 ms and a 5 ms codec frame = size would be 45 ms + (codec look-ahead difference) + (codec filtering dela= y difference). Consequently, for the conference bridge application, the total difference i= n one-way delay can easily be in the 90 to 100 ms range. When adding this d= elay difference to all the other codec-independent delay components, it is = still a huge difference that the users can easily notice, especially since = it will most likely push the total one-way delay significantly beyond the 1= 50 ms limit. > I am aware of a header compression technology for VoIP over Cable > applications that can compress the header size to a very small > fraction of the original size, but it is probably not widely used. Yes, header compression works between end-points on a cable. That's different from "between arbitrary Internet end points". [Raymond]: The cable operators' networks are still IP networks. If the tec= hnology can work there, I don't see why it cannot work elsewhere in the Int= ernet. I know it is currently not available between arbitrary Internet end= points. I am just saying that technologies exist that can potentially be = deployed in the Internet to compress the packet headers to a very small fra= ction of the uncompressed headers. best, koen. --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A290IRVEXCHCCR01c_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi Koen,

 

My comments in-line below.

 

Best Regards,

 

Raymond

 

-----Original Message-----
From: Koen Vos [mailto:koen.vos@skype.net]
Sent: Saturday, April 24, 2010 6:16 PM
To: Raymond (Juin-Hwey) Chen
Cc: codec@ietf.org
Subject: RE: [codec] #16: Multicast?

 

Quoting "Raymond (Juin-Hwey) Chen":<= /o:p>

> My main point, though, is not in the exact one= -way delay value for a 

> codec with a 5 ms frame size, but rather that = with a 5 ms frame size 

> you can get a much lower one-way delay than wi= th a 20 ms frame size.

 

It would be about 15 ms lower - don't know if that = counts as "much" :)

 

[Raymond]: I don't agree= that it will be only 20 - 5 =3D 15 ms lower.  That will be true only if your o= ne-way delay formula below is true, but theoretically it cannot be.  See my comment below your formula.

 

Also, note that for a given probability of packets arriving too late 

to be played out, the jitter buffer delay is indepe= ndent of the frame 

size.

[Raymond]: That may be t= rue theoretically, but in practical implementations, selecting a jitter buffer = delay that is not divisible by the packet size would make the adaptive jitter buf= fer pretty messy to implement.  If we make the it divisible by the packet size, then a smaller packet size gives you more granularity to work with an= d can result in lower average delay as the codec frames go through the adapti= ve jitter buffer.

 

>> - most delay comes from the network and is= not codec related, and

>> - one-way delay grows almost linearly with= frame size.

> 

> Doesn't your last line above contradicts with = the second last line?

 

I meant that approximately:

    one-way delay =3D codec-independ= ent delay + frame size

 

("codec algorithmic delay" would be more accurate than "frame size")

 

[Raymond]: First, I agre= e that codec algorithmic buffering delay is more accurate than frame size since it= can also include the “look-ahead” delay and filtering delay if sub-= band analysis/synthesis is used.  However, your formula implies that for th= e codec-related delay, the “multiplier” to be used for the codec frame size is only 1.  That’s unrealistic and theoretically impossible.  For that to happen, after you wait one frame of time for = the current frame of input audio samples to arrive at your input signal buffer = (that’s one frame of codec-related delay already), you need an infinitely fast processor to finish the encoding operation instantly, then you need an infinitely fast communication link to ship all the bits in the compressed f= rame to the decoder instantly, and then you need an infinitely fast processor to finish decoding the frame instantly and start playing back the current fram= e of audio without any delay.  That’s just impossible. 

In reality, if the proce= ssor is just barely fast enough to implement the codec in real time, then you need nearly a full frame of time to finish the encoding and decoding operations. That makes the multiplier to be 2 already.  If your communication link= is just barely fast enough to transmit your packets at the same speed they are generated without piling up unsent packets, then it takes another frame of = time to finish transmitting the compressed bits in a frame to the decoder.  That makes the multiplier to be 3 already. 

Granted, in practice the= processor and the communication link are usually faster than just barely enough, so t= he processing delay and the transmission delay can be less than 1 frame each.  However, there are other miscellaneous uncounted delays that te= nds to depend on the codec size in various ways.  Thus, a typical IP phone implementation would have

  One-way delay =3D codec-independent delay + 3*(codec frame size) + (codec look-ahead) + (code= c filtering delay if any).

Hence, the one-way delay difference between a 20 ms and a 5 ms codec frame size would be 45 ms + (co= dec look-ahead difference) + (codec filtering delay difference).

Consequently, for the co= nference bridge application, the total difference in one-way delay can easily be in = the 90 to 100 ms range. When adding this delay difference to all the other codec-independent delay components, it is still a huge difference that the users can easily notice, especially since it will most likely push the tota= l one-way delay significantly beyond the 150 ms limit.

 

> I am aware of a header compression technology = for VoIP over Cable 

> applications that can compress the header size= to a very small 

> fraction of the original size, but it is proba= bly not widely used.

 

Yes, header compression works between end-points on= a cable.  That's 

different from "between arbitrary Internet end points".

 

[Raymond]: The cable ope= rators’ networks are still IP networks.  If the technology can work there, I d= on’t see why it cannot work elsewhere in the Internet.  I know it is curren= tly not available between arbitrary Internet end points.  I am just saying that technologies exist that can potentially be deployed in the Internet to compress the packet headers to a very small fraction of the uncompressed he= aders.

 

best,

koen.

 

--_000_CB68DF4CFBEF4942881AD37AE1A7E8C74AB3F4A290IRVEXCHCCR01c_-- From rchen@broadcom.com Sat Apr 24 23:01:01 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1F5F3A689C for ; Sat, 24 Apr 2010 23:01:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.225 X-Spam-Level: X-Spam-Status: No, score=-0.225 tagged_above=-999 required=5 tests=[AWL=-0.226, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ugnw4Kf0jG9K for ; Sat, 24 Apr 2010 23:00:57 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 44D633A6839 for ; Sat, 24 Apr 2010 23:00:56 -0700 (PDT) Received: from [10.9.200.133] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Sat, 24 Apr 2010 23:00:37 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.30]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Sat, 24 Apr 2010 23:02:01 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Koen Vos" , "codec@ietf.org" Importance: low X-Priority: 5 Date: Sat, 24 Apr 2010 23:00:31 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrivT8HaFXlNtdwTXChwtL+5TkS1wBcGQyg Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <20100423011559.20246ayxdicd9vzz@mail.skype.net> In-Reply-To: <20100423011559.20246ayxdicd9vzz@mail.skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: y98= DCwa EZlv GChK GWk6 HAS9 HERR JO1r KMW/ MnXc M7Wm NKQk O/zx RECk RQkd STbt; 2; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAawBvAGUAbgAuAHYAbwBzAEAAcwBrAHkAcABlAC4AbgBlAHQA; Sosha1_v1; 7; {ECDFC4A2-986E-450A-B039-0ED0F770AC77}; cgBjAGgAZQBuAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0A; Sun, 25 Apr 2010 06:00:31 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAIwAxADYAOgAgAE0AdQBsAHQAaQBjAGEAcwB0AD8A x-cr-puzzleid: {ECDFC4A2-986E-450A-B039-0ED0F770AC77} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67CD050F20S102049180-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 06:01:02 -0000 Hi Koen, Responding to your earlier email about Bluetooth headset application: (1) Although BT SIG standardization is a preferred route, it is technically= feasible to negotiate and use a non-Bluetooth-SIG codec. (2) Someone familiar with BT SIG told me that it would probably take only 6= months to add an optional codec to the BT SIG spec and 12 to 18 months to = add a mandatory codec. (3) The IETF codec is scheduled to be finalized in 14 months and submitted = to IESG in 18 months. Even if we take the BT SIG route and take 6 to 18 mo= nths there. The total time of 2 to 3 years from now means the Moore's Law = would only increase the CPU resources 2X to 3X, and definitely no more than= 4X max, not 10X. (4) Most importantly, guess what, in the last several years the Bluetooth h= eadset chips have been growing its processing power at a MUCH, MUCH slower = rate than what the Moore's Law says it should. Sometimes they did not incre= ase the speed at all for years. The reasons? The ASP (average sale price) = of Bluetooth chips plummeted very badly, making it unattractive to invest s= ignificant resources to make them significantly faster. Also, for low-end = and mid-end BT headsets, the BT chips were often considered "good enough" a= nd there wasn't a strong drive to increase the computing resources. In add= ition, the BT headsets got smaller over the last few years; the correspondi= ng reduction in battery size required a reduction in power consumption, whi= ch also limited how fast the processor speed could grow. In the next sever= al years, it is highly likely that the computing capabilities of Bluetooth = headset chips will continue to grow at a rate substantially below what's pr= edicted by the Moore's Law. (5) Although Bluetooth supports G.711 as an optional codec, basically no on= e uses it because it is too sensitive to bit errors. Essentially all the B= T mono headsets on the market today are narrowband (8 kHz sampling) headset= s using CVSD. There isn't any real wideband support yet, so your comment a= bout G.722 doesn't apply. Even after wideband-capable BT headsets come out= , for many years to come the majority of the BT headsets (especially mid- t= o low-end) will still be narrowband only, running only CVSD. Hence, the qua= lity degradation of the CVSD transcoding is real and will be with us for qu= ite a while, so it is desirable for the IETF codec to have a low-complexity= mode that can directly run on the BT headsets to avoid the quality degrada= tion of CVSD when using BT headsets to make Internet phone calls. (6) Even if you could use G.711 or G.722 in the BT headsets, they both oper= ate at 64 kb/s. A low-complexity mode of the IETF codec can operate at hal= f or one quarter of that bit-rate. This will help conserve BT headsets' ra= dio power because of the lower transmit duty cycle. It will also help the = Bluetooth + WiFi co-existence technologies. (7) Already a lot of people are used to using Bluetooth headsets to make ph= one calls today. If they have a choice, many of these people will also wan= t to use Bluetooth headsets to make Internet phone calls, not only through = computers, but also through smart phones connected to WiFi or cellular netw= orks. As more and more states and countries pass laws to ban the use of ce= ll phones that are not in hands-free mode while driving, the number of Blue= tooth headset users will only increase with time, and many of them will wan= t to make Internet-based phone calls. Given all the above, I would argue that Bluetooth headset is a very relevan= t application that the IETF codec should address with a low-complexity mode= . Best Regards, Raymond -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of K= oen Vos Sent: Friday, April 23, 2010 1:16 AM To: codec@ietf.org Subject: Re: [codec] #16: Multicast? By the time the BlueTooth Special Interest Group will have adopted a future IETF codec standard, Moore's law will surely have multiplied CPU resources in the BT device by one order of magnitude..? Not sure it makes sense to apply today's BT constraints to tomorrow's codec. I'm not even convinced BlueTooth is a relevant use case for an Internet codec. BT devices are audio devices more than VoIP end points: BT always connects to the Internet through another device. You could simply first decode incoming packets and send PCM data to the BT device, or use a high-quality/high-bitrate codec like G.722. The requirements for BT devices and the Internet are just too different. Similarly, GSM phones use AMR on the network side and a different codec towards the BT device. The required transcoding causes no quality problems because BT supports high bitrates. best, koen. Quoting Raymond (Juin-Hwey) Chen: > Hi Christian, > > My comments about your question of CODEC requirements are in-line. > > Raymond > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > Behalf Of Christian Hoene > Sent: Wednesday, April 21, 2010 12:27 PM > To: 'stephen botzko' > Cc: codec@ietf.org > Subject: Re: [codec] #16: Multicast? > > Hi, > > if we take those two scenarios (high quality and scalable > teleconferencing), what are then the CODEC requirements? > > High quality: > > - Quite the same requirement as an end-to-end audio > transmission: high quality and low latency. > [Raymond]: High quality is a given, but I would like to emphasize > the importance of low latency. > (1) It is well-known that the longer the latency, the lower the > perceived quality of the communication link. The E-model in the > ITU-T Recommendation G.107 models such communication quality in > MOS_cqe, which among other things depends on the so-called "delay > impairment factor" Id. Basically, MOS_cqe is a monotonically > decreasing function of increasing latency, and beyond about 150 ms > one-way delay, the perceived quality of the communication link drops > rapidly with further delay increase. > (2) The lower the latency, the less audible the echo, and thus the > lower the required echo return loss. Hence, lower latency means > easier echo control and simpler echo canceller, and as people > already mentioned previously, below a certain delay, an echo is > simply perceived as a harmless side-tone and no echo canceller is > needed. It seems to me that echo control in conference calls is more > difficult than in point-to-point calls. While I hardly ever heard > echoes in domestic point-to-point calls, in my experience with > conference calls at work, even with the G.711 codec (which has > almost no delay), sometimes I still hear echoes (I just heard > another one this afternoon). If a relatively long-delay IETF codec > is used, the echo control will be even more problematic. > (3) In normal phone calls or conference calls, people routinely have > a need to interrupt each other, but beyond a certain point, long > latency makes it very difficult for people to interrupt each other > on the call. This is because when you try to interrupt another > person, that person doesn't hear your interruption until a certain > time later, so he keeps talking, but when you hear that he did not > stop talking when you interrupted, you stop; then, he hears your > interruption, so he stops. When you hear he stops, you start talking > again, but then he also hears you stopped (due to the long delay), > so he also starts talking again. The net result is that with a long > latency, when you try to interrupt him, you and he end up stopping > and starting at roughly the same time for a few cycles, making it > difficult to interrupt each other. > (4) We need to keep in mind that the IETF codec may not be the only > codec involved in a phone call or a conference call. We cannot > assume that all conference call participants will be using a > computer to conduct the call. Not only do people use cell phones for > point-to-point phone calls, they also often use cell phones to call > in to conference calls. The one-way delay for a cell phone call > through one carriers network is typically around 80 to 110 ms. A > call from a cell phone in a carrier network to another cell phone in > a different type of carrier network can easily double this delay to > 160 ~ 220 ms and makes the total one-way delay already far exceeding > the 150 ms mentioned in (1) above. Any coding delay added by the > IETF codec will be on top of that long delay, and such coding delay > will be applied twice when both cell phones call through the IETF > codec to a conference bridge. Even without the IETF codec delay, > when I previously called from a Verizon cell phone to an AT&T cell > phone, I already experienced the problem mentioned in (3) sometimes. > If the IETF codec has a relatively long delay, adding two times the > IETF codec one-way delay to the already long delay of 160 ~ 220 ms > will make the situation much worse. Even if just one cell phone is > involved in a conference call, adding twice the one-way delay of a > relatively long-delay IETF codec can still easily push the total > one-way delay beyond 150 ms. > To summarize, my point is that to help reduce potential echo > problems and to ensure a high-quality experience in such a > conference call, the IETF codec should have a delay as low as > possible while maintaining good enough speech quality and a > reasonable bit-rate. > > - Maybe additionally: variable bit rate encoding to achieve > a multiplexing gain at the receiver > > - and thus, a fast control loop to cope with variable > bitrates on transmission paths. > > - Maybe stereo/multichannel support to send the spatial > audio to the headphone or loudspeakers. > > Scalable: > > - Efficient encoding/transcoding for multiple different > qualities (at the conference bridge) > [Raymond]: I am not sure whether by "efficient", you meant coding > efficiency or computational efficiency. In any case, I would like > to take this opportunity to express my view that although codec > complexity isn't much of an issue for PC-to-PC calls where there are > GHz of processing power available, the codec complexity is an > important issue in certain application scenarios. The following are > just some examples. > 1) If a conference bridge has to decode a large number of voice > channels, mix, and re-encode, and if compressed-domain mixing cannot > be done (which is usually the case), then it is important to keep > the decoder complexity low. > 2) In topology b) of your other email > (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, > or VoIP gateway, often has to encode and decode thousands of voice > channels in a single box, so not only the computational complexity, > but also the per-instance RAM size requirement of the codec become > very important for achieving high channel density in the gateway. > 3) Many telephone terminal devices at the edge of the Internet use > embedded processors with limited processing power, and the > processors also have to handle many tasks other than speech coding. > If the IETF codec complexity is too high, some of such devices may > not have sufficient processing power to run it. Even if the codec > can fit, some battery-powered mobile devices may prefer to run a > lower-complexity codec to reduce power consumption and battery > drain. For example, even if you make a Internet phone call from a > computer, you may like the convenience of using a Bluetooth headset > that allows you to walk around a bit and have hands-free operation. > Currently most Bluetooth headsets have small form factors with a > tiny battery. This puts a severe constraint on power consumption. > Bluetooth headset chips typically have very limited processing > capability, and it has to handle many other tasks such as echo > cancellation and noise reduction. There is just not enough > processing power to handle a relatively high-complexity codec. Most > BT headsets today relies on the extremely low-complexity, > hardware-based CVSD codec at 64 kb/s to transmit narrowband voice, > but CVSD has audible coding noise, so it degrades the overall audio > quality. If the IETF codec has low enough complexity, it would be > possible to directly encode and decode the IETF codec bit-stream at > the BT headset, thus avoiding the quality degradation of CVSD > transcoding. > In summary, my point is that the IETF codec should attempt to > achieve a codec complexity as low as possible in both MHz > consumption and RAM size requirement while maintaining good enough > speech quality. > > - The control loop must not react (fast) because > (multicast) group communication requires to encode at low quality > anyhow. > > - Receiver side activity detection for music and voice > having low complexity (for the conference bridge) > > - Efficient mixing of two to four(?) active flows (is this > achievable without the complete process of decoding and encoding > again?) > > Are any teleconferencing requirements missing? > > Christian > > > > > --------------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of T=FCbingen > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > From: stephen botzko [mailto:stephen.botzko@gmail.com] > Sent: Wednesday, April 21, 2010 8:19 PM > To: Christian Hoene > Cc: codec@ietf.org > Subject: Re: [codec] #16: Multicast? > > Inline > On Wed, Apr 21, 2010 at 1:27 PM, Christian Hoene > > wrote: > Hi Stephen, > > not too bad. You answered faster than the mailing list distributes... > Not sure how that happened! > > Comments inline: > > > From: stephen botzko > [mailto:stephen.botzko@gmail.com] > Sent: Wednesday, April 21, 2010 7:10 PM > To: Christian Hoene > Cc: codec@ietf.org > > Subject: Re: [codec] #16: Multicast? > > I agree there are lots of use cases. > > > Though I don't see why high quality has to be given up in order to > be scalable. > CH: These are just experiences from our lab. A spatial audio > conference server including the acoustic 3D sound rendering needs a > LOT of processing power. In the end, we have to remain realistic. > Processing power is always limited thus if we need a lot then we > cannot serve many clients. > Also, I am not sure why you think central mixing is more scalable > than multicast (or why you think it is lower quality either). > CH: With multicast, you need N times 1:N multicast distribution > trees (somewhat small tan O(n)=3Dn=B2). With central mixing you need N > times 2 transmission paths (O(n)=3Dn). Also, this distributed mixing > you need N times the mixing at each client. With centralized, you > can live with one mixing for all (and some tricks for serving the > talkers). > I agree you need more distribution trees for multicast if you allow > every site to talk. There is a corresponding benefit, since there is > no central choke point and also less bandwidth on shared WAN links. > > In the distributed case, you don't need an N-way mixer at each > client, and you also don't need to continuously receive payload on > all N streams at each client either. In practice you can cap N at a > relatively small number (in the 3-8 range) no matter how large the > conference gets. In a large conference, you can even choose to drop > your comfort noise if you are receiving two or more streams, and > just send enough to keep your firewall pinhole open. This is all > assuming a suitable voice activity measure in the RTP packet. Of > course in the worst case, you will receive all N streams. > > Cheers, > Christian > > Stephen Botzko > On Wed, Apr 21, 2010 at 12:58 PM, Christian Hoene > > wrote: > Hi, > > the teleconferencing issue gets complex. I am trying to compile the > different requirements that have been mentioned on this list. > > - low complexity (with just one active speaker) vs. > multiple speaker mixing vs. spatial audio/stereo mixing > > - centralized vs. distributed > > - few participants vs. hundreds of listeners and talkers > > - individual distribution of audio streams vs. IP multicast > or RTP group communication > > - efficient encoding of multiple streams having the same > content (but different quality). > > - I bet I missed some. > > To make things easier, why not to split the teleconferencing > scenario in two: High quality and Scalable? > > The high quality scenario, intended for a low number of users, could > have features like > > - Distributed processing and mixing > > - High computational resources to support spatial audio > mixing (at the receiver) and multiple encodings of the same audio > stream at different qualities (at the sender) > > - Enough bandwidth to allow direct N to N transmissions of > audio streams (no multicast or group communication). This would be > good for the latency, too. > > The scalable scenario is the opposite: > > - Central processing and mixing for many participants . > > - N to 1 and 1 to N communication using efficient > distribution mechanisms (RTP group communication and IP multicast). > > - Low complexity mixing of many using tricks like VAD, > encoding at lowest rate to support many receivers having different > paths, you name it... > > Then, we need not to compare apples with oranges all the time. > > Christian > > --------------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of T=FCbingen > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > From: codec-bounces@ietf.org > [mailto:codec-bounces@ietf.org] On > Behalf Of stephen botzko > Sent: Wednesday, April 21, 2010 4:34 PM > To: Colin Perkins > Cc: trac@tools.ietf.org; > codec@ietf.org > Subject: Re: [codec] #16: Multicast? > > in-line > > Stephen Botzko > On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins > > wrote: > On 21 Apr 2010, at 12:20, Marshall Eubanks wrote: > On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote: > On 21 Apr 2010, at 10:42, codec issue tracker wrote: > #16: Multicast? > ------------------------------------+---------------------------------- > Reporter: hoene@... | Owner: > Type: enhancement | Status: new > Priority: trivial | Milestone: > Component: requirements | Version: > Severity: Active WG Document | Keywords: > ------------------------------------+---------------------------------- > The question arrose whether the interactive CODEC MUST support > multicast in addition to teleconferencing. > > On 04/13/2010 11:35 AM, Christian Hoene wrote: > P.S. On the same note, does anybody here cares about using this > CODEC with multicast? Is there a single commercial multicast voice > deployment? From what I've seen all multicast does is making IETF > voice standards harder to understand or implement. > > I think that would be a mistake to ignore multicast - not because of > multicast itself, but because of Xcast (RFC 5058) which is a > promising technology to replace centralized conference bridges. > > Regarding multicast: > > I think we shall start at user requirements and scenarios. > Teleconference (including mono or spatial audio) might be good > starting point. Virtual environments like second live would require > multicast communication, too. If the requirements of these scenarios > are well understand, we can start to talk about potential solutions > like IP multicast, Xcast or conference bridges. > > > RTP is inherently a group communication protocol, and any codec > designed for use with RTP should consider operation in various > different types of group communication scenario (not just > multicast). RFC 5117 is a good place to start when considering the > different types of topology in which RTP is used, and the possible > placement of mixing and switching functions which the codec will > need to work with. > > It is not clear to me what supporting multicast would entail here. > If this is a codec over RTP, then what is to stop it from being > multicast ? > > Nothing. However group conferences implemented using multicast > require end system mixing of potentially large numbers of active > audio streams, whereas those implemented using conference bridges do > the mixing in a single central location, and generally suppress all > but one speaker. The differences in mixing and the number of > simultaneous active streams that might be received potentially > affect the design of the codec. > > Conference bridges with central mixing almost always mix multiple > speakers. As you add more streams into the mix, you reduce the > chance of missing onset speech and interruptions, but raise the > noise floor. So even if complexity is not a consideration, there is > value in gating the mixer (instead of always doing a full mix-minus). > > More on point, compressed domain mixing and easy detection of VAD > have both been advocated on these lists, and both simplify the > large-scale mixing problem. > > -- > Colin Perkins > http://csperkins.org/ > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > > _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From swmike@swm.pp.se Sun Apr 25 01:06:20 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2CAFE3A657C for ; Sun, 25 Apr 2010 01:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.692 X-Spam-Level: X-Spam-Status: No, score=-5.692 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oQcFmLOhmPif for ; Sun, 25 Apr 2010 01:06:19 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id 4AE0D3A682E for ; Sun, 25 Apr 2010 01:06:19 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 713519F; Sun, 25 Apr 2010 10:06:03 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 6E4AC9E; Sun, 25 Apr 2010 10:06:03 +0200 (CEST) Date: Sun, 25 Apr 2010 10:06:03 +0200 (CEST) From: Mikael Abrahamsson To: "Raymond (Juin-Hwey) Chen" In-Reply-To: Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <20100423011559.20246ayxdicd9vzz@mail.skype.net> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 08:06:20 -0000 On Sat, 24 Apr 2010, Raymond (Juin-Hwey) Chen wrote: > (7) Already a lot of people are used to using Bluetooth headsets to make > phone calls today. If they have a choice, many of these people will > also want to use Bluetooth headsets to make Internet phone calls, not > only through computers, but also through smart phones connected to WiFi > or cellular networks. As more and more states and countries pass laws > to ban the use of cell phones that are not in hands-free mode while > driving, the number of Bluetooth headset users will only increase with > time, and many of them will want to make Internet-based phone calls. I purchased a BT headset with the anticipation of using it with my computer to make Skype calls. I tried it, but the sound quality when doing bidirectional audio (whatever that mode is called) is not good enough, it worsens the "skype IP" call quality. I agree that the use case is interesting, but as long as BT sound quality is what it is, it's really only the "low end" type sound quality we're talking about. But yes, I make skype IP calls with my Nokia N900 using BT sometimes, so the use case example is definitely valid. -- Mikael Abrahamsson email: swmike@swm.pp.se From koen.vos@skype.net Sun Apr 25 04:01:22 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9688F3A6991 for ; Sun, 25 Apr 2010 04:01:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.812 X-Spam-Level: X-Spam-Status: No, score=-5.812 tagged_above=-999 required=5 tests=[AWL=0.787, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3IjufhPVN55I for ; Sun, 25 Apr 2010 04:01:20 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 928EF3A6993 for ; Sun, 25 Apr 2010 04:01:03 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id A451E60132DE7; Sun, 25 Apr 2010 12:00:51 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=rfMXUrNDNBEE 9CO/tQvpA8h4Y7Y=; b=IseiniYgXK4tT8H/e0jt2QdEiDfwi0C0ajImRzYDiixX y8s/K5Cnis6+aowmxFkFfIhkMyLxzQvoNrqe59EpENQqcRMsVkWOQoa2ouQvEnrg bAwp3lc/gzL95+WnqFvTMzzLyZpr9XPfeaat2e0avB0/Yh1B2TVwqozVeTIdNxg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=qv81towzzXN1bYSF9BiR qZM0YW5XL7Vq783NOvuuTig3GBQd2M3NP43Yz6+bfToge7DBx/8fhKrCUnDN68GN pHLKlGKgF+TilBOrXp4NUpuIhWJEGK3L0sR1CRAtDFFNqQ+vYKLAm9StrKNrA23o 1nCuIhYN6WloGc6lAIOKsPU= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id A1F2D60132DE3; Sun, 25 Apr 2010 12:00:51 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jtj30wRz7PyT; Sun, 25 Apr 2010 12:00:49 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id CD82660132DE5; Sun, 25 Apr 2010 12:00:49 +0100 (IST) Received: from adsl-71-141-115-202.dsl.snfc21.pacbell.net (adsl-71-141-115-202.dsl.snfc21.pacbell.net [71.141.115.202]) by mail.skype.net (Horde Framework) with HTTP; Sun, 25 Apr 2010 04:00:49 -0700 Message-ID: <20100425040049.69785q4ih4vowtep@mail.skype.net> Date: Sun, 25 Apr 2010 04:00:49 -0700 From: Koen Vos To: "Raymond (Juin-Hwey) Chen" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <20100423011559.20246ayxdicd9vzz@mail.skype.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? (Bluetooth) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 11:01:22 -0000 Hi Raymond, You seem to suggest that the IETF Internet codec should fit Bluetooth =20 requirements in order to enable transcoding-free operation all the way =20 from the Internet, through the Internet-connected device, to the BT =20 wireless audio device. A similar argument would hold for ITU-T cellular codecs: AMR-WB and =20 G.718 could have been designed with BT as an application. In reality, =20 these codecs have very little in common with BT codecs, because of the =20 vastly different requirements in terms of - complexity - memory footprint - bitrate - scalability - bit error robustness - packet loss robustness. Do you think it's realistic for us to come up with a design that =20 fulfills the needs of both worlds? The alternative is to separately design codecs for Internet =20 applications and BT devices, and continue the practice of transcoding =20 on the Internet-connected device. That would have a better chance of =20 maximizing quality in all scenarios. best, koen. Quoting "Raymond (Juin-Hwey) Chen": > Hi Koen, > > Responding to your earlier email about Bluetooth headset application: > > (1) Although BT SIG standardization is a preferred route, it is =20 > technically feasible to negotiate and use a non-Bluetooth-SIG codec. > > (2) Someone familiar with BT SIG told me that it would probably take =20 > only 6 months to add an optional codec to the BT SIG spec and 12 to =20 > 18 months to add a mandatory codec. > > (3) The IETF codec is scheduled to be finalized in 14 months and =20 > submitted to IESG in 18 months. Even if we take the BT SIG route =20 > and take 6 to 18 months there. The total time of 2 to 3 years from =20 > now means the Moore's Law would only increase the CPU resources 2X =20 > to 3X, and definitely no more than 4X max, not 10X. > > (4) Most importantly, guess what, in the last several years the =20 > Bluetooth headset chips have been growing its processing power at a =20 > MUCH, MUCH slower rate than what the Moore's Law says it should. =20 > Sometimes they did not increase the speed at all for years. The =20 > reasons? The ASP (average sale price) of Bluetooth chips plummeted =20 > very badly, making it unattractive to invest significant resources =20 > to make them significantly faster. Also, for low-end and mid-end BT =20 > headsets, the BT chips were often considered "good enough" and there =20 > wasn't a strong drive to increase the computing resources. In =20 > addition, the BT headsets got smaller over the last few years; the =20 > corresponding reduction in battery size required a reduction in =20 > power consumption, which also limited how fast the processor speed =20 > could grow. In the next several years, it is highly likely that the =20 > computing capabilities of Bluetooth headset chips will continue to =20 > grow at a rate substantially below what's predicted by the Moore's =20 > Law. > > (5) Although Bluetooth supports G.711 as an optional codec, =20 > basically no one uses it because it is too sensitive to bit errors. =20 > Essentially all the BT mono headsets on the market today are =20 > narrowband (8 kHz sampling) headsets using CVSD. There isn't any =20 > real wideband support yet, so your comment about G.722 doesn't =20 > apply. Even after wideband-capable BT headsets come out, for many =20 > years to come the majority of the BT headsets (especially mid- to =20 > low-end) will still be narrowband only, running only CVSD. Hence, =20 > the quality degradation of the CVSD transcoding is real and will be =20 > with us for quite a while, so it is desirable for the IETF codec to =20 > have a low-complexity mode that can directly run on the BT headsets =20 > to avoid the quality degradation of CVSD when using BT headsets to =20 > make Internet phone calls. > > (6) Even if you could use G.711 or G.722 in the BT headsets, they =20 > both operate at 64 kb/s. A low-complexity mode of the IETF codec =20 > can operate at half or one quarter of that bit-rate. This will help =20 > conserve BT headsets' radio power because of the lower transmit duty =20 > cycle. It will also help the Bluetooth + WiFi co-existence =20 > technologies. > > (7) Already a lot of people are used to using Bluetooth headsets to =20 > make phone calls today. If they have a choice, many of these people =20 > will also want to use Bluetooth headsets to make Internet phone =20 > calls, not only through computers, but also through smart phones =20 > connected to WiFi or cellular networks. As more and more states and =20 > countries pass laws to ban the use of cell phones that are not in =20 > hands-free mode while driving, the number of Bluetooth headset users =20 > will only increase with time, and many of them will want to make =20 > Internet-based phone calls. > > Given all the above, I would argue that Bluetooth headset is a very =20 > relevant application that the IETF codec should address with a =20 > low-complexity mode. > > Best Regards, > > Raymond > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 > Behalf Of Koen Vos > Sent: Friday, April 23, 2010 1:16 AM > To: codec@ietf.org > Subject: Re: [codec] #16: Multicast? > > By the time the BlueTooth Special Interest Group will have adopted a > future IETF codec standard, Moore's law will surely have multiplied > CPU resources in the BT device by one order of magnitude..? Not sure > it makes sense to apply today's BT constraints to tomorrow's codec. > > I'm not even convinced BlueTooth is a relevant use case for an > Internet codec. BT devices are audio devices more than VoIP end > points: BT always connects to the Internet through another device. > You could simply first decode incoming packets and send PCM data to > the BT device, or use a high-quality/high-bitrate codec like G.722. > The requirements for BT devices and the Internet are just too > different. Similarly, GSM phones use AMR on the network side and a > different codec towards the BT device. The required transcoding > causes no quality problems because BT supports high bitrates. > > best, > koen. > > > Quoting Raymond (Juin-Hwey) Chen: > >> Hi Christian, >> >> My comments about your question of CODEC requirements are in-line. >> >> Raymond >> >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >> Behalf Of Christian Hoene >> Sent: Wednesday, April 21, 2010 12:27 PM >> To: 'stephen botzko' >> Cc: codec@ietf.org >> Subject: Re: [codec] #16: Multicast? >> >> Hi, >> >> if we take those two scenarios (high quality and scalable >> teleconferencing), what are then the CODEC requirements? >> >> High quality: >> >> - Quite the same requirement as an end-to-end audio >> transmission: high quality and low latency. >> [Raymond]: High quality is a given, but I would like to emphasize >> the importance of low latency. >> (1) It is well-known that the longer the latency, the lower the >> perceived quality of the communication link. The E-model in the >> ITU-T Recommendation G.107 models such communication quality in >> MOS_cqe, which among other things depends on the so-called "delay >> impairment factor" Id. Basically, MOS_cqe is a monotonically >> decreasing function of increasing latency, and beyond about 150 ms >> one-way delay, the perceived quality of the communication link drops >> rapidly with further delay increase. >> (2) The lower the latency, the less audible the echo, and thus the >> lower the required echo return loss. Hence, lower latency means >> easier echo control and simpler echo canceller, and as people >> already mentioned previously, below a certain delay, an echo is >> simply perceived as a harmless side-tone and no echo canceller is >> needed. It seems to me that echo control in conference calls is more >> difficult than in point-to-point calls. While I hardly ever heard >> echoes in domestic point-to-point calls, in my experience with >> conference calls at work, even with the G.711 codec (which has >> almost no delay), sometimes I still hear echoes (I just heard >> another one this afternoon). If a relatively long-delay IETF codec >> is used, the echo control will be even more problematic. >> (3) In normal phone calls or conference calls, people routinely have >> a need to interrupt each other, but beyond a certain point, long >> latency makes it very difficult for people to interrupt each other >> on the call. This is because when you try to interrupt another >> person, that person doesn't hear your interruption until a certain >> time later, so he keeps talking, but when you hear that he did not >> stop talking when you interrupted, you stop; then, he hears your >> interruption, so he stops. When you hear he stops, you start talking >> again, but then he also hears you stopped (due to the long delay), >> so he also starts talking again. The net result is that with a long >> latency, when you try to interrupt him, you and he end up stopping >> and starting at roughly the same time for a few cycles, making it >> difficult to interrupt each other. >> (4) We need to keep in mind that the IETF codec may not be the only >> codec involved in a phone call or a conference call. We cannot >> assume that all conference call participants will be using a >> computer to conduct the call. Not only do people use cell phones for >> point-to-point phone calls, they also often use cell phones to call >> in to conference calls. The one-way delay for a cell phone call >> through one carriers network is typically around 80 to 110 ms. A >> call from a cell phone in a carrier network to another cell phone in >> a different type of carrier network can easily double this delay to >> 160 ~ 220 ms and makes the total one-way delay already far exceeding >> the 150 ms mentioned in (1) above. Any coding delay added by the >> IETF codec will be on top of that long delay, and such coding delay >> will be applied twice when both cell phones call through the IETF >> codec to a conference bridge. Even without the IETF codec delay, >> when I previously called from a Verizon cell phone to an AT&T cell >> phone, I already experienced the problem mentioned in (3) sometimes. >> If the IETF codec has a relatively long delay, adding two times the >> IETF codec one-way delay to the already long delay of 160 ~ 220 ms >> will make the situation much worse. Even if just one cell phone is >> involved in a conference call, adding twice the one-way delay of a >> relatively long-delay IETF codec can still easily push the total >> one-way delay beyond 150 ms. >> To summarize, my point is that to help reduce potential echo >> problems and to ensure a high-quality experience in such a >> conference call, the IETF codec should have a delay as low as >> possible while maintaining good enough speech quality and a >> reasonable bit-rate. >> >> - Maybe additionally: variable bit rate encoding to achieve >> a multiplexing gain at the receiver >> >> - and thus, a fast control loop to cope with variable >> bitrates on transmission paths. >> >> - Maybe stereo/multichannel support to send the spatial >> audio to the headphone or loudspeakers. >> >> Scalable: >> >> - Efficient encoding/transcoding for multiple different >> qualities (at the conference bridge) >> [Raymond]: I am not sure whether by "efficient", you meant coding >> efficiency or computational efficiency. In any case, I would like >> to take this opportunity to express my view that although codec >> complexity isn't much of an issue for PC-to-PC calls where there are >> GHz of processing power available, the codec complexity is an >> important issue in certain application scenarios. The following are >> just some examples. >> 1) If a conference bridge has to decode a large number of voice >> channels, mix, and re-encode, and if compressed-domain mixing cannot >> be done (which is usually the case), then it is important to keep >> the decoder complexity low. >> 2) In topology b) of your other email >> (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, >> or VoIP gateway, often has to encode and decode thousands of voice >> channels in a single box, so not only the computational complexity, >> but also the per-instance RAM size requirement of the codec become >> very important for achieving high channel density in the gateway. >> 3) Many telephone terminal devices at the edge of the Internet use >> embedded processors with limited processing power, and the >> processors also have to handle many tasks other than speech coding. >> If the IETF codec complexity is too high, some of such devices may >> not have sufficient processing power to run it. Even if the codec >> can fit, some battery-powered mobile devices may prefer to run a >> lower-complexity codec to reduce power consumption and battery >> drain. For example, even if you make a Internet phone call from a >> computer, you may like the convenience of using a Bluetooth headset >> that allows you to walk around a bit and have hands-free operation. >> Currently most Bluetooth headsets have small form factors with a >> tiny battery. This puts a severe constraint on power consumption. >> Bluetooth headset chips typically have very limited processing >> capability, and it has to handle many other tasks such as echo >> cancellation and noise reduction. There is just not enough >> processing power to handle a relatively high-complexity codec. Most >> BT headsets today relies on the extremely low-complexity, >> hardware-based CVSD codec at 64 kb/s to transmit narrowband voice, >> but CVSD has audible coding noise, so it degrades the overall audio >> quality. If the IETF codec has low enough complexity, it would be >> possible to directly encode and decode the IETF codec bit-stream at >> the BT headset, thus avoiding the quality degradation of CVSD >> transcoding. >> In summary, my point is that the IETF codec should attempt to >> achieve a codec complexity as low as possible in both MHz >> consumption and RAM size requirement while maintaining good enough >> speech quality. >> >> - The control loop must not react (fast) because >> (multicast) group communication requires to encode at low quality >> anyhow. >> >> - Receiver side activity detection for music and voice >> having low complexity (for the conference bridge) >> >> - Efficient mixing of two to four(?) active flows (is this >> achievable without the complete process of decoding and encoding >> again?) >> >> Are any teleconferencing requirements missing? >> >> Christian >> >> >> >> >> --------------------------------------------------------------- >> Dr.-Ing. Christian Hoene >> Interactive Communication Systems (ICS), University of T=FCbingen >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >> http://www.net.uni-tuebingen.de/ >> >> From: stephen botzko [mailto:stephen.botzko@gmail.com] >> Sent: Wednesday, April 21, 2010 8:19 PM >> To: Christian Hoene >> Cc: codec@ietf.org >> Subject: Re: [codec] #16: Multicast? >> >> Inline >> On Wed, Apr 21, 2010 at 1:27 PM, Christian Hoene >> > wrote: >> Hi Stephen, >> >> not too bad. You answered faster than the mailing list distributes... >> Not sure how that happened! >> >> Comments inline: >> >> >> From: stephen botzko >> [mailto:stephen.botzko@gmail.com] >> Sent: Wednesday, April 21, 2010 7:10 PM >> To: Christian Hoene >> Cc: codec@ietf.org >> >> Subject: Re: [codec] #16: Multicast? >> >> I agree there are lots of use cases. >> >> >> Though I don't see why high quality has to be given up in order to >> be scalable. >> CH: These are just experiences from our lab. A spatial audio >> conference server including the acoustic 3D sound rendering needs a >> LOT of processing power. In the end, we have to remain realistic. >> Processing power is always limited thus if we need a lot then we >> cannot serve many clients. >> Also, I am not sure why you think central mixing is more scalable >> than multicast (or why you think it is lower quality either). >> CH: With multicast, you need N times 1:N multicast distribution >> trees (somewhat small tan O(n)=3Dn=B2). With central mixing you need N >> times 2 transmission paths (O(n)=3Dn). Also, this distributed mixing >> you need N times the mixing at each client. With centralized, you >> can live with one mixing for all (and some tricks for serving the >> talkers). >> I agree you need more distribution trees for multicast if you allow >> every site to talk. There is a corresponding benefit, since there is >> no central choke point and also less bandwidth on shared WAN links. >> >> In the distributed case, you don't need an N-way mixer at each >> client, and you also don't need to continuously receive payload on >> all N streams at each client either. In practice you can cap N at a >> relatively small number (in the 3-8 range) no matter how large the >> conference gets. In a large conference, you can even choose to drop >> your comfort noise if you are receiving two or more streams, and >> just send enough to keep your firewall pinhole open. This is all >> assuming a suitable voice activity measure in the RTP packet. Of >> course in the worst case, you will receive all N streams. >> >> Cheers, >> Christian >> >> Stephen Botzko >> On Wed, Apr 21, 2010 at 12:58 PM, Christian Hoene >> > wrote: >> Hi, >> >> the teleconferencing issue gets complex. I am trying to compile the >> different requirements that have been mentioned on this list. >> >> - low complexity (with just one active speaker) vs. >> multiple speaker mixing vs. spatial audio/stereo mixing >> >> - centralized vs. distributed >> >> - few participants vs. hundreds of listeners and talkers >> >> - individual distribution of audio streams vs. IP multicast >> or RTP group communication >> >> - efficient encoding of multiple streams having the same >> content (but different quality). >> >> - I bet I missed some. >> >> To make things easier, why not to split the teleconferencing >> scenario in two: High quality and Scalable? >> >> The high quality scenario, intended for a low number of users, could >> have features like >> >> - Distributed processing and mixing >> >> - High computational resources to support spatial audio >> mixing (at the receiver) and multiple encodings of the same audio >> stream at different qualities (at the sender) >> >> - Enough bandwidth to allow direct N to N transmissions of >> audio streams (no multicast or group communication). This would be >> good for the latency, too. >> >> The scalable scenario is the opposite: >> >> - Central processing and mixing for many participants . >> >> - N to 1 and 1 to N communication using efficient >> distribution mechanisms (RTP group communication and IP multicast). >> >> - Low complexity mixing of many using tricks like VAD, >> encoding at lowest rate to support many receivers having different >> paths, you name it... >> >> Then, we need not to compare apples with oranges all the time. >> >> Christian >> >> --------------------------------------------------------------- >> Dr.-Ing. Christian Hoene >> Interactive Communication Systems (ICS), University of T=FCbingen >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >> http://www.net.uni-tuebingen.de/ >> >> From: codec-bounces@ietf.org >> [mailto:codec-bounces@ietf.org] On >> Behalf Of stephen botzko >> Sent: Wednesday, April 21, 2010 4:34 PM >> To: Colin Perkins >> Cc: trac@tools.ietf.org; >> codec@ietf.org >> Subject: Re: [codec] #16: Multicast? >> >> in-line >> >> Stephen Botzko >> On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins >> > wrote: >> On 21 Apr 2010, at 12:20, Marshall Eubanks wrote: >> On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote: >> On 21 Apr 2010, at 10:42, codec issue tracker wrote: >> #16: Multicast? >> ------------------------------------+---------------------------------- >> Reporter: hoene@... | Owner: >> Type: enhancement | Status: new >> Priority: trivial | Milestone: >> Component: requirements | Version: >> Severity: Active WG Document | Keywords: >> ------------------------------------+---------------------------------- >> The question arrose whether the interactive CODEC MUST support >> multicast in addition to teleconferencing. >> >> On 04/13/2010 11:35 AM, Christian Hoene wrote: >> P.S. On the same note, does anybody here cares about using this >> CODEC with multicast? Is there a single commercial multicast voice >> deployment? From what I've seen all multicast does is making IETF >> voice standards harder to understand or implement. >> >> I think that would be a mistake to ignore multicast - not because of >> multicast itself, but because of Xcast (RFC 5058) which is a >> promising technology to replace centralized conference bridges. >> >> Regarding multicast: >> >> I think we shall start at user requirements and scenarios. >> Teleconference (including mono or spatial audio) might be good >> starting point. Virtual environments like second live would require >> multicast communication, too. If the requirements of these scenarios >> are well understand, we can start to talk about potential solutions >> like IP multicast, Xcast or conference bridges. >> >> >> RTP is inherently a group communication protocol, and any codec >> designed for use with RTP should consider operation in various >> different types of group communication scenario (not just >> multicast). RFC 5117 is a good place to start when considering the >> different types of topology in which RTP is used, and the possible >> placement of mixing and switching functions which the codec will >> need to work with. >> >> It is not clear to me what supporting multicast would entail here. >> If this is a codec over RTP, then what is to stop it from being >> multicast ? >> >> Nothing. However group conferences implemented using multicast >> require end system mixing of potentially large numbers of active >> audio streams, whereas those implemented using conference bridges do >> the mixing in a single central location, and generally suppress all >> but one speaker. The differences in mixing and the number of >> simultaneous active streams that might be received potentially >> affect the design of the codec. >> >> Conference bridges with central mixing almost always mix multiple >> speakers. As you add more streams into the mix, you reduce the >> chance of missing onset speech and interruptions, but raise the >> noise floor. So even if complexity is not a consideration, there is >> value in gating the mixer (instead of always doing a full mix-minus). >> >> More on point, compressed domain mixing and easy detection of VAD >> have both been advocated on these lists, and both simplify the >> large-scale mixing problem. >> >> -- >> Colin Perkins >> http://csperkins.org/ >> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> >> > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > From koen.vos@skype.net Sun Apr 25 12:25:10 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A48C3A6942 for ; Sun, 25 Apr 2010 12:25:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKIAOc0RvZPx for ; Sun, 25 Apr 2010 12:25:08 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id C2CB33A6A88 for ; Sun, 25 Apr 2010 12:24:46 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 76C4C60133166; Sun, 25 Apr 2010 20:24:34 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=UofpYB1j8OyK NZNGbG80TjHgYP8=; b=O5hl8CiFgr3wWgJszNt74q1kYIeyrtW2U5ZxhDdsYqFE JpOADf4EbOemcZSVqaIDmVRihArhBjTE0Jz4+XKM6IBOQooi/TRU7T/p5uveKoTO yWCW+FQ7CNwiZ/R85aHhZRStStvKO/0OvUIGj4cpQMImutX27ywAoRE4IyvYQJE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=wD7231gFXCr4uy8kbOQr cvUZvFbkEeCUHQCDNdrRcsWjL0JAkuLbVbfh52I39BfGd5Sf8TtZbjY/jUjk8TFl wz75vg4h+xsjvbK/jKWxbH2oQFlYoj26bc7ZnQ7zBLEUAPMxSqr1pUqjoF7s3RH2 PDultUQiPJAmhg1JEoPwkPs= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 74C9D60133110; Sun, 25 Apr 2010 20:24:34 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GIezJ24JtgZf; Sun, 25 Apr 2010 20:24:29 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 0C65860133168; Sun, 25 Apr 2010 20:24:29 +0100 (IST) Received: from adsl-71-141-115-202.dsl.snfc21.pacbell.net (adsl-71-141-115-202.dsl.snfc21.pacbell.net [71.141.115.202]) by mail.skype.net (Horde Framework) with HTTP; Sun, 25 Apr 2010 12:24:29 -0700 Message-ID: <20100425122429.2136460zti0p5fjh@mail.skype.net> Date: Sun, 25 Apr 2010 12:24:29 -0700 From: Koen Vos To: "Raymond (Juin-Hwey) Chen" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <20100424135607.84293hkaa13j1zvr@mail.skype.net> <20100424181620.352034g28cnjr010@mail.skype.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 19:25:10 -0000 Hi Raymond, Jitter buffers have no problem implementing a non-integer-frame delay, because packets are queued and read non-synchronously. Processing time matters on low-end hardware - a small fraction of today's VoIP end points. Even then, the higher coding efficiency of longer frames can be translated into lower complexity. And transmission delay increases (perhaps) linearly with the *packet size*, not with the *frame size*. For a 32 kbps codec with 5 ms frames, packets are just 30% smaller than with a 16 kbps codecs with 20 ms frames. Let me ask you something: how often is G.729 used with 10 ms packets, or Broadvoice with 5 ms packets? best, koen. Quoting "Raymond (Juin-Hwey) Chen": > Hi Koen, > > > > My comments in-line below. > > > > Best Regards, > > > > Raymond > > > > -----Original Message----- > From: Koen Vos [mailto:koen.vos@skype.net] > Sent: Saturday, April 24, 2010 6:16 PM > To: Raymond (Juin-Hwey) Chen > Cc: codec@ietf.org > Subject: RE: [codec] #16: Multicast? > > > > Quoting "Raymond (Juin-Hwey) Chen": > >> My main point, though, is not in the exact one-way delay value for a > >> codec with a 5 ms frame size, but rather that with a 5 ms frame size > >> you can get a much lower one-way delay than with a 20 ms frame size. > > > > It would be about 15 ms lower - don't know if that counts as "much" :) > > > > [Raymond]: I don't agree that it will be only 20 - 5 = 15 ms lower. > That will be true only if your one-way delay formula below is true, > but theoretically it cannot be. See my comment below your formula. > > > > Also, note that for a given probability of packets arriving too late > > to be played out, the jitter buffer delay is independent of the frame > > size. > > [Raymond]: That may be true theoretically, but in practical > implementations, selecting a jitter buffer delay that is not > divisible by the packet size would make the adaptive jitter buffer > pretty messy to implement. If we make the it divisible by the > packet size, then a smaller packet size gives you more granularity > to work with and can result in lower average delay as the codec > frames go through the adaptive jitter buffer. > > > >>> - most delay comes from the network and is not codec related, and > >>> - one-way delay grows almost linearly with frame size. > >> > >> Doesn't your last line above contradicts with the second last line? > > > > I meant that approximately: > > one-way delay = codec-independent delay + frame size > > > > ("codec algorithmic delay" would be more accurate than "frame size") > > > > [Raymond]: First, I agree that codec algorithmic buffering delay is > more accurate than frame size since it can also include the > "look-ahead" delay and filtering delay if sub-band > analysis/synthesis is used. However, your formula implies that for > the codec-related delay, the "multiplier" to be used for the codec > frame size is only 1. That's unrealistic and theoretically > impossible. For that to happen, after you wait one frame of time > for the current frame of input audio samples to arrive at your input > signal buffer (that's one frame of codec-related delay already), you > need an infinitely fast processor to finish the encoding operation > instantly, then you need an infinitely fast communication link to > ship all the bits in the compressed frame to the decoder instantly, > and then you need an infinitely fast processor to finish decoding > the frame instantly and start playing back the current frame of > audio without any delay. That's just impossible. > > In reality, if the processor is just barely fast enough to implement > the codec in real time, then you need nearly a full frame of time to > finish the encoding and decoding operations. That makes the > multiplier to be 2 already. If your communication link is just > barely fast enough to transmit your packets at the same speed they > are generated without piling up unsent packets, then it takes > another frame of time to finish transmitting the compressed bits in > a frame to the decoder. That makes the multiplier to be 3 already. > > Granted, in practice the processor and the communication link are > usually faster than just barely enough, so the processing delay and > the transmission delay can be less than 1 frame each. However, > there are other miscellaneous uncounted delays that tends to depend > on the codec size in various ways. Thus, a typical IP phone > implementation would have > > One-way delay = codec-independent delay + 3*(codec frame size) + > (codec look-ahead) + (codec filtering delay if any). > > Hence, the one-way delay difference between a 20 ms and a 5 ms codec > frame size would be 45 ms + (codec look-ahead difference) + (codec > filtering delay difference). > > Consequently, for the conference bridge application, the total > difference in one-way delay can easily be in the 90 to 100 ms range. > When adding this delay difference to all the other codec-independent > delay components, it is still a huge difference that the users can > easily notice, especially since it will most likely push the total > one-way delay significantly beyond the 150 ms limit. > > > >> I am aware of a header compression technology for VoIP over Cable > >> applications that can compress the header size to a very small > >> fraction of the original size, but it is probably not widely used. > > > > Yes, header compression works between end-points on a cable. That's > > different from "between arbitrary Internet end points". > > > > [Raymond]: The cable operators' networks are still IP networks. If > the technology can work there, I don't see why it cannot work > elsewhere in the Internet. I know it is currently not available > between arbitrary Internet end points. I am just saying that > technologies exist that can potentially be deployed in the Internet > to compress the packet headers to a very small fraction of the > uncompressed headers. > > > > best, > > koen. > > > From stephen.botzko@gmail.com Sun Apr 25 13:38:31 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 134F93A6883 for ; Sun, 25 Apr 2010 13:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.066 X-Spam-Level: X-Spam-Status: No, score=-1.066 tagged_above=-999 required=5 tests=[AWL=-1.068, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2P76FtDQq6Hz for ; Sun, 25 Apr 2010 13:38:29 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 71CCA3A6894 for ; Sun, 25 Apr 2010 13:38:27 -0700 (PDT) Received: by wyb35 with SMTP id 35so2397200wyb.31 for ; Sun, 25 Apr 2010 13:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ebliW/PvPusbIgiUhwuHyc1E6jfrtT/c10ZUr4KJXXo=; b=GTlwfx68gbb8J/39yrb3a82rd6ZoBvdexZL5C1cyUubBoY1gPpHU6xU2XcV1tAgk3u bKti6NSSAPMJlUkbJZSs8iCy9fn/JaSzmBDLqXfBBIQqGLAzJX7jHmQ5ws2nM+EIeXVr QJRe53bepfMYTNnatQ+CGF5ZjvN4zu4iRyVOU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=qXgUBqzHiJGgS4MOKMSh6Nk2G6XKgZlAyGUK/PTFZWcvv8pM5F5SM1YyNIUrwfW3vp xHhYXqOK3fUvCgmwUo2/8N2tw4YMpJQzP1iDbKrtiLZfL2dttq88RI6hqGaY7KpubelB qrm2o0spHfplMlSXdB92zQtbk6HcGQnQ8EYqQ= MIME-Version: 1.0 Received: by 10.216.85.203 with SMTP id u53mr1380049wee.184.1272227893160; Sun, 25 Apr 2010 13:38:13 -0700 (PDT) Received: by 10.216.28.139 with HTTP; Sun, 25 Apr 2010 13:38:12 -0700 (PDT) In-Reply-To: <20100425122429.2136460zti0p5fjh@mail.skype.net> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <20100424135607.84293hkaa13j1zvr@mail.skype.net> <20100424181620.352034g28cnjr010@mail.skype.net> <20100425122429.2136460zti0p5fjh@mail.skype.net> Date: Sun, 25 Apr 2010 16:38:12 -0400 Message-ID: From: stephen botzko To: Koen Vos Content-Type: multipart/alternative; boundary=0016e6d62335a52cda048515a367 Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Apr 2010 20:38:31 -0000 --0016e6d62335a52cda048515a367 Content-Type: text/plain; charset=ISO-8859-1 >>> And transmission delay increases (perhaps) linearly with the *packet size*, not with the *frame size*. For a 32 kbps codec with 5 ms frames, packets are just 30% smaller than with a 16 kbps codecs with 20 ms frames. >>> "Packet size" here has to include layer 2 overhead, not just IP overhead, making your argument even stronger. In the case of Ethernet, Layer-2 overhead is 38-42 bytes per packet (depending on whether a vlan tag is present), so it is about the same as the IP/UDP/RTP overhead. And of course there's encryption pads, VPN encapsulation, etc. that apply in many cases. There is a floor transmission delay when you send the minimum size packets the network path allows. There is an incremental delay due to serialization when you send larger size packets than the minimum. (At each hop you wait until you receive last bit in the packet before you forward the first bit). I'd agree that a reasonable model for the incremental delay is that it scales linearly with the *increase* in packet size. But the floor delay is usually too large for this to matter dominate. And on top of that is the variable delay (jitter) due to congestion, layer 2 retransmission, and the like. That also will not scale linearly with frame size or packet size. So arguments that increasing the frame size by 10 ms will increase the overall delay by 50 ms make no sense to me at all. Stephen Botzko On Sun, Apr 25, 2010 at 3:24 PM, Koen Vos wrote: > Hi Raymond, > > Jitter buffers have no problem implementing a non-integer-frame delay, > because packets are queued and read non-synchronously. > > Processing time matters on low-end hardware - a small fraction of today's > VoIP end points. Even then, the higher coding efficiency of longer frames > can be translated into lower complexity. > > And transmission delay increases (perhaps) linearly with the *packet size*, > not with the *frame size*. For a 32 kbps codec with 5 ms frames, packets > are just 30% smaller than with a 16 kbps codecs with 20 ms frames. > > Let me ask you something: how often is G.729 used with 10 ms packets, or > Broadvoice with 5 ms packets? > > best, > koen. > > > > > Quoting "Raymond (Juin-Hwey) Chen": > > Hi Koen, >> >> >> >> My comments in-line below. >> >> >> >> Best Regards, >> >> >> >> Raymond >> >> >> >> -----Original Message----- >> From: Koen Vos [mailto:koen.vos@skype.net] >> Sent: Saturday, April 24, 2010 6:16 PM >> To: Raymond (Juin-Hwey) Chen >> Cc: codec@ietf.org >> Subject: RE: [codec] #16: Multicast? >> >> >> >> Quoting "Raymond (Juin-Hwey) Chen": >> >> My main point, though, is not in the exact one-way delay value for a >>> >> >> codec with a 5 ms frame size, but rather that with a 5 ms frame size >>> >> >> you can get a much lower one-way delay than with a 20 ms frame size. >>> >> >> >> >> It would be about 15 ms lower - don't know if that counts as "much" :) >> >> >> >> [Raymond]: I don't agree that it will be only 20 - 5 = 15 ms lower. That >> will be true only if your one-way delay formula below is true, but >> theoretically it cannot be. See my comment below your formula. >> >> >> >> Also, note that for a given probability of packets arriving too late >> >> to be played out, the jitter buffer delay is independent of the frame >> >> size. >> >> [Raymond]: That may be true theoretically, but in practical >> implementations, selecting a jitter buffer delay that is not divisible by >> the packet size would make the adaptive jitter buffer pretty messy to >> implement. If we make the it divisible by the packet size, then a smaller >> packet size gives you more granularity to work with and can result in lower >> average delay as the codec frames go through the adaptive jitter buffer. >> >> >> >> - most delay comes from the network and is not codec related, and >>>> >>> >> - one-way delay grows almost linearly with frame size. >>>> >>> >> >>> >> Doesn't your last line above contradicts with the second last line? >>> >> >> >> >> I meant that approximately: >> >> one-way delay = codec-independent delay + frame size >> >> >> >> ("codec algorithmic delay" would be more accurate than "frame size") >> >> >> >> [Raymond]: First, I agree that codec algorithmic buffering delay is more >> accurate than frame size since it can also include the "look-ahead" delay >> and filtering delay if sub-band analysis/synthesis is used. However, your >> formula implies that for the codec-related delay, the "multiplier" to be >> used for the codec frame size is only 1. That's unrealistic and >> theoretically impossible. For that to happen, after you wait one frame of >> time for the current frame of input audio samples to arrive at your input >> signal buffer (that's one frame of codec-related delay already), you need an >> infinitely fast processor to finish the encoding operation instantly, then >> you need an infinitely fast communication link to ship all the bits in the >> compressed frame to the decoder instantly, and then you need an infinitely >> fast processor to finish decoding the frame instantly and start playing back >> the current frame of audio without any delay. That's just impossible. >> >> In reality, if the processor is just barely fast enough to implement the >> codec in real time, then you need nearly a full frame of time to finish the >> encoding and decoding operations. That makes the multiplier to be 2 already. >> If your communication link is just barely fast enough to transmit your >> packets at the same speed they are generated without piling up unsent >> packets, then it takes another frame of time to finish transmitting the >> compressed bits in a frame to the decoder. That makes the multiplier to be >> 3 already. >> >> Granted, in practice the processor and the communication link are usually >> faster than just barely enough, so the processing delay and the transmission >> delay can be less than 1 frame each. However, there are other miscellaneous >> uncounted delays that tends to depend on the codec size in various ways. >> Thus, a typical IP phone implementation would have >> >> One-way delay = codec-independent delay + 3*(codec frame size) + (codec >> look-ahead) + (codec filtering delay if any). >> >> Hence, the one-way delay difference between a 20 ms and a 5 ms codec frame >> size would be 45 ms + (codec look-ahead difference) + (codec filtering delay >> difference). >> >> Consequently, for the conference bridge application, the total difference >> in one-way delay can easily be in the 90 to 100 ms range. When adding this >> delay difference to all the other codec-independent delay components, it is >> still a huge difference that the users can easily notice, especially since >> it will most likely push the total one-way delay significantly beyond the >> 150 ms limit. >> >> >> >> I am aware of a header compression technology for VoIP over Cable >>> >> >> applications that can compress the header size to a very small >>> >> >> fraction of the original size, but it is probably not widely used. >>> >> >> >> >> Yes, header compression works between end-points on a cable. That's >> >> different from "between arbitrary Internet end points". >> >> >> >> [Raymond]: The cable operators' networks are still IP networks. If the >> technology can work there, I don't see why it cannot work elsewhere in the >> Internet. I know it is currently not available between arbitrary Internet >> end points. I am just saying that technologies exist that can potentially >> be deployed in the Internet to compress the packet headers to a very small >> fraction of the uncompressed headers. >> >> >> >> best, >> >> koen. >> >> >> >> > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016e6d62335a52cda048515a367 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
And transmission delay increases (perhaps) linearly with th= e *packet=20 size*, not with the *frame size*. =A0For a 32 kbps codec with 5 ms frames, packets are just 30% smaller than with a 16 kbps codecs with 20 ms=20 frames.
>>>
=A0"Packet size" here has to include l= ayer 2 overhead, not just IP overhead, making your argument even stronger. = In the case of Ethernet, Layer-2 overhead is 38-42 bytes per packet (depend= ing on whether a vlan tag is present), so it is about the same as the IP/UD= P/RTP overhead.=A0 And of course there's encryption pads, VPN encapsula= tion, etc. that apply in many cases.

There is a floor transmission delay when you send the minimum size pack= ets the network path allows.

There is an incremental delay due to se= rialization when you send larger size packets than the minimum. (At each ho= p you wait until you receive last bit in the packet before you forward the = first bit). =A0 I'd agree that a reasonable model for the incremental d= elay is that it scales linearly with the increase in packet size.=A0= But the floor delay is usually too large for this to matter dominate.

And on top of that is the variable delay=A0 (jitter) due to congestion,= layer 2 retransmission, and the like.=A0 That also will not scale linearly= with frame size or packet size.

So arguments that increasing the f= rame size by 10 ms will increase the overall delay by 50 ms make no sense t= o me at all.

Stephen Botzko

On Sun, Apr 25, 2010 a= t 3:24 PM, Koen Vos <koen.vos@skype.net> wrote:
Hi Raymond,

Jitter buffers have no problem implementing a non-integer-frame delay, beca= use packets are queued and read non-synchronously.

Processing time matters on low-end hardware - a small fraction of today'= ;s VoIP end points. =A0Even then, the higher coding efficiency of longer fr= ames can be translated into lower complexity.

And transmission delay increases (perhaps) linearly with the *packet size*,= not with the *frame size*. =A0For a 32 kbps codec with 5 ms frames, packet= s are just 30% smaller than with a 16 kbps codecs with 20 ms frames.

Let me ask you something: how often is G.729 used with 10 ms packets, or Br= oadvoice with 5 ms packets?

best,
koen.




Quoting "Raymond (Juin-Hwey) Chen":

Hi Koen,



My comments in-line below.



Best Regards,



Raymond



-----Original Message-----
From: Koen Vos [mailto:koen.vos@skype.net]
Sent: Saturday, April 24, 2010 6:16 PM
To: Raymond (Juin-Hwey) Chen
Cc: codec@ietf.org<= br> Subject: RE: [codec] #16: Multicast?



Quoting "Raymond (Juin-Hwey) Chen":

My main point, though, is not in the exact one-way delay value for a

codec with a 5 ms frame size, but rather that with a 5 ms frame size

you can get a much lower one-way delay than with a 20 ms frame size.



It would be about 15 ms lower - don't know if that counts as "much= " :)



[Raymond]: I don't agree that it will be only 20 - 5 =3D 15 ms lower. = =A0That will be true only if your one-way delay formula below is true, but = theoretically it cannot be. =A0See my comment below your formula.



Also, note that for a given probability of packets arriving too late

to be played out, the jitter buffer delay is independent of the frame

size.

[Raymond]: That may be true theoretically, but in practical implementations= , selecting a jitter buffer delay that is not divisible by the packet size = would make the adaptive jitter buffer pretty messy to implement. =A0If we m= ake the it divisible by the packet size, then a smaller packet size gives y= ou more granularity to work with and can result in lower average delay as t= he codec frames go through the adaptive jitter buffer.



- most delay comes from the network and is not codec related, and

- one-way delay grows almost linearly with frame size.



Doesn't your last line above contradicts with the second last line?



I meant that approximately:

=A0 =A0one-way delay =3D codec-independent delay + frame size



("codec algorithmic delay" would be more accurate than "fram= e size")



[Raymond]: First, I agree that codec algorithmic buffering delay is more ac= curate than frame size since it can also include the "look-ahead"= delay and filtering delay if sub-band analysis/synthesis is used. =A0Howev= er, your formula implies that for the codec-related delay, the "multip= lier" to be used for the codec frame size is only 1. =A0That's unr= ealistic and theoretically impossible. =A0For that to happen, after you wai= t one frame of time for the current frame of input audio samples to arrive = at your input signal buffer (that's one frame of codec-related delay al= ready), you need an infinitely fast processor to finish the encoding operat= ion instantly, then you need an infinitely fast communication link to ship = all the bits in the compressed frame to the decoder instantly, and then you= need an infinitely fast processor to finish decoding the frame instantly a= nd start playing back the current frame of audio without any delay. =A0That= 's just impossible.

In reality, if the processor is just barely fast enough to implement the co= dec in real time, then you need nearly a full frame of time to finish the e= ncoding and decoding operations. That makes the multiplier to be 2 already.= =A0If your communication link is just barely fast enough to transmit your = packets at the same speed they are generated without piling up unsent packe= ts, then it takes another frame of time to finish transmitting the compress= ed bits in a frame to the decoder. =A0That makes the multiplier to be 3 alr= eady.

Granted, in practice the processor and the communication link are usually f= aster than just barely enough, so the processing delay and the transmission= delay can be less than 1 frame each. =A0However, there are other miscellan= eous uncounted delays that tends to depend on the codec size in various way= s. =A0Thus, a typical IP phone implementation would have

=A0One-way delay =3D codec-independent delay + 3*(codec frame size) + (cod= ec look-ahead) + (codec filtering delay if any).

Hence, the one-way delay difference between a 20 ms and a 5 ms codec frame = size would be 45 ms + (codec look-ahead difference) + (codec filtering dela= y difference).

Consequently, for the conference bridge application, the total difference i= n one-way delay can easily be in the 90 to 100 ms range. When adding this d= elay difference to all the other codec-independent delay components, it is = still a huge difference that the users can easily notice, especially since = it will most likely push the total one-way delay significantly beyond the 1= 50 ms limit.



I am aware of a header compression technology for VoIP over Cable

applications that can compress the header size to a very small

fraction of the original size, but it is probably not widely used.



Yes, header compression works between end-points on a cable. =A0That's<= br>
different from "between arbitrary Internet end points".



[Raymond]: The cable operators' networks are still IP networks. =A0If t= he technology can work there, I don't see why it cannot work elsewhere = in the Internet. =A0I know it is currently not available between arbitrary = Internet end points. =A0I am just saying that technologies exist that can p= otentially be deployed in the Internet to compress the packet headers to a = very small fraction of the uncompressed headers.



best,

koen.





_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016e6d62335a52cda048515a367-- From rchen@broadcom.com Sun Apr 25 23:50:09 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0CF373A67F0 for ; Sun, 25 Apr 2010 23:50:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.202 X-Spam-Level: X-Spam-Status: No, score=-0.202 tagged_above=-999 required=5 tests=[AWL=-0.204, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8R5VsNFDP6oq for ; Sun, 25 Apr 2010 23:49:56 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 6EEFE3A67EC for ; Sun, 25 Apr 2010 23:49:50 -0700 (PDT) Received: from [10.9.200.131] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Sun, 25 Apr 2010 23:49:29 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Sun, 25 Apr 2010 23:49:29 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Koen Vos" Importance: low X-Priority: 5 Date: Sun, 25 Apr 2010 23:49:27 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrkrPe8JLVEu3WHTT+0OV80CrqVRQAVc8Zw Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <20100424135607.84293hkaa13j1zvr@mail.skype.net> <20100424181620.352034g28cnjr010@mail.skype.net> <20100425122429.2136460zti0p5fjh@mail.skype.net> In-Reply-To: <20100425122429.2136460zti0p5fjh@mail.skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67CBE8F331G103842230-01-01 Content-Type: multipart/alternative; boundary=_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B901365EFIRVEXCHCCR01c_ Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 06:50:09 -0000 --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B901365EFIRVEXCHCCR01c_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable In-line... -----Original Message----- From: Koen Vos [mailto:koen.vos@skype.net] Sent: Sunday, April 25, 2010 12:24 PM To: Raymond (Juin-Hwey) Chen Cc: codec@ietf.org Subject: RE: [codec] #16: Multicast? Hi Raymond, Jitter buffers have no problem implementing a non-integer-frame delay, because packets are queued and read non-synchronously. [Raymond]: I am talking about adaptive jitter buffer that tries to minimize= the delay through the jitter buffer dynamically depending on the observed = network jitter. If the jitter is small, you decrease that delay, and if it= is large, you increase that delay. An engineer who actually implemented su= ch an adaptive jitter buffer in an IP phone told me that the non-integer-fr= ame delay made it pretty messy to implement (I didn't say it was not possib= le; it's just messy), so for implementation simplicity's sake, the jitter d= elay was often chosen to be an integer number of frames. He also said that = a smaller frame size gives you more frequent observations of the network ji= tter and thus makes the jitter estimate more responsive and accurate. Processing time matters on low-end hardware - a small fraction of today's VoIP end points. [Raymond]: Processing time certainly matters for IP phones, and there are a= lot of enterprise IP phones deployed today. I heard that it is actually si= gnificantly cheaper for enterprises to have their entire phone systems IP-p= hone-based than analog-phone-based. I won't be surprised that before too lo= ng the vast majority of enterprises will use only IP phones. Even consumer= phones and cell phones are moving toward IP-based. Eventually that would = be a very large percentage of VoIP end points. And transmission delay increases (perhaps) linearly with the *packet size*, not with the *frame size*. For a 32 kbps codec with 5 ms frames, packets are just 30% smaller than with a 16 kbps codecs with 20 ms frames. [Raymond]: Agreed. My previous comments on transmission delay was based on = the TDM rather than packet scenario, but I was just using that simplified T= DM example to make a point that transmission delay cannot be zero, as your = 1X frame size multiplier would imply. Even with your statement above, a la= rger codec frame size still makes a larger packet size, which then increase= s the transmission delay, so you can't say transmission delay is zero or is= independent of the codec size. In any case, these are really minor details. My key point is that your 1X = multiplier for the codec frame size is simply theoretically impossible. Th= e rule of thumb used by IP phone engineers is around 3X codec frame size. Let me ask you something: how often is G.729 used with 10 ms packets, or Broadvoice with 5 ms packets? [Raymond]: Not very often, but that's because previously network routers/sw= itches didn't like to handle too many packets per second, and the higher pa= cket header overhead associated with a smaller packet size means the overal= l bit-rate would be higher than desired or allowed, so the time of small pa= cket size for low-delay VoIP hasn't really come yet. However, with the hel= p of Moore's Law, network routers/switches are becoming much faster now, an= d I was told that they can handle a 5 ms packet size without problems; furt= hermore, the speed of backbone networks and access networks keep increasing= with time, so the bit-rate concern will also decrease with time. Unlike processing speed and communication speed that continuously get impro= ved with time for decades, delay is one thing that will NOT get improved wi= th time and Moore's Law cannot do anything about that! If the IETF codec has a minimum frame size of 20 ms, we will be stuck with = the longer overall delay associated with that, and Moore's Law will not hel= p us reduce that delay in the future. On the other hand, in addition to us= ing a 20 ms frame size for bit-rate-sensitive applications, if the IETF cod= ec also has a low-delay mode that uses a 5 ms frame size, then at least for= delay-sensitive applications, people have a choice to achieve a lower dela= y by paying the price of a higher overall bit-rate (i.e. with packet header= counted), and this higher bit-rate will be less and less of a concern as t= he network speed keep increasing with time. Therefore, recognizing that delay cannot be helped by Moore's Law but bit-r= ate can, it would be wise for the IETF codec WG to adopt a low-delay mode f= or the codec in order to be future-proof. best, koen. Quoting "Raymond (Juin-Hwey) Chen": > Hi Koen, > > > > My comments in-line below. > > > > Best Regards, > > > > Raymond > > > > -----Original Message----- > From: Koen Vos [mailto:koen.vos@skype.net] > Sent: Saturday, April 24, 2010 6:16 PM > To: Raymond (Juin-Hwey) Chen > Cc: codec@ietf.org > Subject: RE: [codec] #16: Multicast? > > > > Quoting "Raymond (Juin-Hwey) Chen": > >> My main point, though, is not in the exact one-way delay value for a > >> codec with a 5 ms frame size, but rather that with a 5 ms frame size > >> you can get a much lower one-way delay than with a 20 ms frame size. > > > > It would be about 15 ms lower - don't know if that counts as "much" :) > > > > [Raymond]: I don't agree that it will be only 20 - 5 =3D 15 ms lower. > That will be true only if your one-way delay formula below is true, > but theoretically it cannot be. See my comment below your formula. > > > > Also, note that for a given probability of packets arriving too late > > to be played out, the jitter buffer delay is independent of the frame > > size. > > [Raymond]: That may be true theoretically, but in practical > implementations, selecting a jitter buffer delay that is not > divisible by the packet size would make the adaptive jitter buffer > pretty messy to implement. If we make the it divisible by the > packet size, then a smaller packet size gives you more granularity > to work with and can result in lower average delay as the codec > frames go through the adaptive jitter buffer. > > > >>> - most delay comes from the network and is not codec related, and > >>> - one-way delay grows almost linearly with frame size. > >> > >> Doesn't your last line above contradicts with the second last line? > > > > I meant that approximately: > > one-way delay =3D codec-independent delay + frame size > > > > ("codec algorithmic delay" would be more accurate than "frame size") > > > > [Raymond]: First, I agree that codec algorithmic buffering delay is > more accurate than frame size since it can also include the > "look-ahead" delay and filtering delay if sub-band > analysis/synthesis is used. However, your formula implies that for > the codec-related delay, the "multiplier" to be used for the codec > frame size is only 1. That's unrealistic and theoretically > impossible. For that to happen, after you wait one frame of time > for the current frame of input audio samples to arrive at your input > signal buffer (that's one frame of codec-related delay already), you > need an infinitely fast processor to finish the encoding operation > instantly, then you need an infinitely fast communication link to > ship all the bits in the compressed frame to the decoder instantly, > and then you need an infinitely fast processor to finish decoding > the frame instantly and start playing back the current frame of > audio without any delay. That's just impossible. > > In reality, if the processor is just barely fast enough to implement > the codec in real time, then you need nearly a full frame of time to > finish the encoding and decoding operations. That makes the > multiplier to be 2 already. If your communication link is just > barely fast enough to transmit your packets at the same speed they > are generated without piling up unsent packets, then it takes > another frame of time to finish transmitting the compressed bits in > a frame to the decoder. That makes the multiplier to be 3 already. > > Granted, in practice the processor and the communication link are > usually faster than just barely enough, so the processing delay and > the transmission delay can be less than 1 frame each. However, > there are other miscellaneous uncounted delays that tends to depend > on the codec size in various ways. Thus, a typical IP phone > implementation would have > > One-way delay =3D codec-independent delay + 3*(codec frame size) + > (codec look-ahead) + (codec filtering delay if any). > > Hence, the one-way delay difference between a 20 ms and a 5 ms codec > frame size would be 45 ms + (codec look-ahead difference) + (codec > filtering delay difference). > > Consequently, for the conference bridge application, the total > difference in one-way delay can easily be in the 90 to 100 ms range. > When adding this delay difference to all the other codec-independent > delay components, it is still a huge difference that the users can > easily notice, especially since it will most likely push the total > one-way delay significantly beyond the 150 ms limit. > > > >> I am aware of a header compression technology for VoIP over Cable > >> applications that can compress the header size to a very small > >> fraction of the original size, but it is probably not widely used. > > > > Yes, header compression works between end-points on a cable. That's > > different from "between arbitrary Internet end points". > > > > [Raymond]: The cable operators' networks are still IP networks. If > the technology can work there, I don't see why it cannot work > elsewhere in the Internet. I know it is currently not available > between arbitrary Internet end points. I am just saying that > technologies exist that can potentially be deployed in the Internet > to compress the packet headers to a very small fraction of the > uncompressed headers. > > > > best, > > koen. > > > --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B901365EFIRVEXCHCCR01c_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

In-line...

 

-----Original Message-----
From: Koen Vos [mailto:koen.vos@skype.net]
Sent: Sunday, April 25, 2010 12:24 PM
To: Raymond (Juin-Hwey) Chen
Cc: codec@ietf.org
Subject: RE: [codec] #16: Multicast?

 

Hi Raymond,

 

Jitter buffers have no problem implementing a non-integer-frame delay, 

because packets are queued and read non-synchronous= ly.

[Raymond]: I am talking = about adaptive jitter buffer that tries to minimize the delay through the jitter buffer dynamically depending on the observed network jitter.  If the jitter is small, you decrease that delay, and if it is large, you increase = that delay. An engineer who actually implemented such an adaptive jitter buffer = in an IP phone told me that the non-integer-frame delay made it pretty messy t= o implement (I didn’t say it was not possible; it’s just messy), = so for implementation simplicity’s sake, the jitter delay was often chos= en to be an integer number of frames. He also said that a smaller frame size g= ives you more frequent observations of the network jitter and thus makes the jit= ter estimate more responsive and accurate.

 

Processing time matters on low-end hardware - a sma= ll fraction of 

today's VoIP end points. 

[Raymond]: Processing ti= me certainly matters for IP phones, and there are a lot of enterprise IP phone= s deployed today. I heard that it is actually significantly cheaper for enterprises to have their entire phone systems IP-phone-based than analog-phone-based. I won’t be surprised that before too long the vas= t majority of enterprises will use only IP phones.  Even consumer phones= and cell phones are moving toward IP-based.  Eventually that would be a ve= ry large percentage of VoIP end points.

 

And transmission delay increases (perhaps) linearly= with the *packet 

size*, not with the *frame size*.  For a 32 kb= ps codec with 5 ms 

frames, packets are just 30% smaller than with a 16= kbps codecs with 

20 ms frames.

[Raymond]: Agreed. My pr= evious comments on transmission delay was based on the TDM rather than packet scen= ario, but I was just using that simplified TDM example to make a point that trans= mission delay cannot be zero, as your 1X frame size multiplier would imply.  E= ven with your statement above, a larger codec frame size still makes a larger packet size, which then increases the transmission delay, so you can’= t say transmission delay is zero or is independent of the codec size.

In any case, these are r= eally minor details.  My key point is that your 1X multiplier for the codec frame size is simply theoretically impossible.  The rule of thumb used= by IP phone engineers is around 3X codec frame size.  <= /p>

 

Let me ask you something: how often is G.729 used w= ith 10 ms packets, 

or Broadvoice with 5 ms packets?

[Raymond]: Not very ofte= n, but that’s because previously network routers/switches didn’t like = to handle too many packets per second, and the higher packet header overhead associated with a smaller packet size means the overall bit-rate would be higher than desired or allowed, so the time of small packet size for low-de= lay VoIP hasn’t really come yet.  However, with the help of Moore= 217;s Law, network routers/switches are becoming much faster now, and I was told = that they can handle a 5 ms packet size without problems; furthermore, the speed= of backbone networks and access networks keep increasing with time, so the bit-rate con= cern will also decrease with time.

Unlike processing speed = and communication speed that continuously get improved with time for decades, d= elay is one thing that will NOT get improved with time and Moore’s Law can= not do anything about that! 

If the IETF codec has a = minimum frame size of 20 ms, we will be stuck with the longer overall delay associa= ted with that, and Moore’s Law will not help us reduce that delay in the future.  On the other hand, in addition to using a 20 ms frame size fo= r bit-rate-sensitive applications, if the IETF codec also has a low-delay mod= e that uses a 5 ms frame size, then at least for delay-sensitive applications= , people have a choice to achieve a lower delay by paying the price of a higher over= all bit-rate (i.e. with packet header counted), and this higher bit-rate will b= e less and less of a concern as the network speed keep increasing with time.<= o:p>

Therefore, recognizing t= hat delay cannot be helped by Moore’s Law but bit-rate can, it would be w= ise for the IETF codec WG to adopt a low-delay mode for the codec in order to b= e future-proof.

 =

 

best,

koen.

 

 

 

Quoting "Raymond (Juin-Hwey) Chen":<= /o:p>

 

> Hi Koen,

> 

> 

> 

> My comments in-line below.

> 

> 

> 

> Best Regards,

> 

> 

> 

> Raymond

> 

> 

> 

> -----Original Message-----

> From: Koen Vos [mailto:koen.vos@skype.net]

> Sent: Saturday, April 24, 2010 6:16 PM

> To: Raymond (Juin-Hwey) Chen

> Cc: codec@ietf.org

> Subject: RE: [codec] #16: Multicast?

> 

> 

> 

> Quoting "Raymond (Juin-Hwey) Chen":<= o:p>

> 

>> My main point, though, is not in the exact one-way delay value for a

> 

>> codec with a 5 ms frame size, but rather t= hat with a 5 ms frame size

> 

>> you can get a much lower one-way delay tha= n with a 20 ms frame size.

> 

> 

> 

> It would be about 15 ms lower - don't know if = that counts as "much" :)

> 

> 

> 

> [Raymond]: I don't agree that it will be only = 20 - 5 =3D 15 ms lower.  

> That will be true only if your one-way delay f= ormula below is true, 

> but theoretically it cannot be.  See my c= omment below your formula.

> 

> 

> 

> Also, note that for a given probability of pac= kets arriving too late

> 

> to be played out, the jitter buffer delay is independent of the frame

> 

> size.

> 

> [Raymond]: That may be true theoretically, but= in practical 

> implementations, selecting a jitter buffer del= ay that is not 

> divisible by the packet size would make the ad= aptive jitter buffer 

> pretty messy to implement.  If we make th= e it divisible by the 

> packet size, then a smaller packet size gives = you more granularity 

> to work with and can result in lower average d= elay as the codec 

> frames go through the adaptive jitter buffer.<= o:p>

> 

> 

> 

>>> - most delay comes from the network an= d is not codec related, and

> 

>>> - one-way delay grows almost linearly = with frame size.

> 

>> 

> 

>> Doesn't your last line above contradicts w= ith the second last line?

> 

> 

> 

> I meant that approximately:

> 

>     one-way delay =3D codec-independent delay + frame size

> 

> 

> 

> ("codec algorithmic delay" would be = more accurate than "frame size")

> 

> 

> 

> [Raymond]: First, I agree that codec algorithm= ic buffering delay is 

> more accurate than frame size since it can als= o include the 

> "look-ahead" delay and filtering del= ay if sub-band 

> analysis/synthesis is used.  However, you= r formula implies that for 

> the codec-related delay, the "multiplier&= quot; to be used for the codec 

> frame size is only 1.  That's unrealistic= and theoretically 

> impossible.  For that to happen, after yo= u wait one frame of time 

> for the current frame of input audio samples t= o arrive at your input 

> signal buffer (that's one frame of codec-relat= ed delay already), you 

> need an infinitely fast processor to finish th= e encoding operation 

> instantly, then you need an infinitely fast communication link to 

> ship all the bits in the compressed frame to t= he decoder instantly, 

> and then you need an infinitely fast processor= to finish decoding 

> the frame instantly and start playing back the current frame of 

> audio without any delay.  That's just impossible.

> 

> In reality, if the processor is just barely fa= st enough to implement 

> the codec in real time, then you need nearly a= full frame of time to 

> finish the encoding and decoding operations. T= hat makes the 

> multiplier to be 2 already.  If your communication link is just 

> barely fast enough to transmit your packets at= the same speed they 

> are generated without piling up unsent packets= , then it takes 

> another frame of time to finish transmitting t= he compressed bits in 

> a frame to the decoder.  That makes the multiplier to be 3 already.

> 

> Granted, in practice the processor and the communication link are 

> usually faster than just barely enough, so the processing delay and 

> the transmission delay can be less than 1 fram= e each.  However, 

> there are other miscellaneous uncounted delays= that tends to depend 

> on the codec size in various ways.  Thus,= a typical IP phone 

> implementation would have

> 

>   One-way delay =3D codec-independen= t delay + 3*(codec frame size) + 

> (codec look-ahead) + (codec filtering delay if= any).

> 

> Hence, the one-way delay difference between a = 20 ms and a 5 ms codec 

> frame size would be 45 ms + (codec look-ahead difference) + (codec 

> filtering delay difference).

> 

> Consequently, for the conference bridge applic= ation, the total 

> difference in one-way delay can easily be in t= he 90 to 100 ms range. 

> When adding this delay difference to all the o= ther codec-independent 

> delay components, it is still a huge differenc= e that the users can 

> easily notice, especially since it will most l= ikely push the total 

> one-way delay significantly beyond the 150 ms = limit.

> 

> 

> 

>> I am aware of a header compression technol= ogy for VoIP over Cable

> 

>> applications that can compress the header = size to a very small

> 

>> fraction of the original size, but it is probably not widely used.

> 

> 

> 

> Yes, header compression works between end-poin= ts on a cable.  That's

> 

> different from "between arbitrary Interne= t end points".

> 

> 

> 

> [Raymond]: The cable operators' networks are s= till IP networks.  If 

> the technology can work there, I don't see why= it cannot work 

> elsewhere in the Internet.  I know it is currently not available 

> between arbitrary Internet end points.  I= am just saying that 

> technologies exist that can potentially be dep= loyed in the Internet 

> to compress the packet headers to a very small fraction of the 

> uncompressed headers.

> 

> 

> 

> best,

> 

> koen.

> 

> 

> 

 

 

 

--_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B901365EFIRVEXCHCCR01c_-- From rchen@broadcom.com Mon Apr 26 00:46:48 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B7B93A68A5 for ; Mon, 26 Apr 2010 00:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.184 X-Spam-Level: X-Spam-Status: No, score=-0.184 tagged_above=-999 required=5 tests=[AWL=-0.186, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2lgIpNi+74x for ; Mon, 26 Apr 2010 00:46:34 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id A0A7D3A6869 for ; Mon, 26 Apr 2010 00:46:34 -0700 (PDT) Received: from [10.9.200.133] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 26 Apr 2010 00:45:37 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB02.corp.ad.broadcom.com ([10.9.200.133]) with mapi; Mon, 26 Apr 2010 00:47:00 -0700 From: "Raymond (Juin-Hwey) Chen" To: "stephen botzko" , "Koen Vos" Importance: low X-Priority: 5 Date: Mon, 26 Apr 2010 00:45:35 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: Acrkt0SypR00XQ02S5uZvCyzlKhIOwAVV+tw Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <20100424135607.84293hkaa13j1zvr@mail.skype.net> <20100424181620.352034g28cnjr010@mail.skype.net> <20100425122429.2136460zti0p5fjh@mail.skype.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67CB9B2B38O185910260-01-01 Content-Type: multipart/alternative; boundary=_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B901365F2IRVEXCHCCR01c_ Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 07:46:48 -0000 --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B901365F2IRVEXCHCCR01c_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Hi Stephen, Thanks for sharing your broad knowledge in this. You made some good points= , and I basically agree with them. I just have some comments in-line. Raymond From: stephen botzko [mailto:stephen.botzko@gmail.com] Sent: Sunday, April 25, 2010 1:38 PM To: Koen Vos Cc: Raymond (Juin-Hwey) Chen; codec@ietf.org Subject: Re: [codec] #16: Multicast? >>> And transmission delay increases (perhaps) linearly with the *packet size*,= not with the *frame size*. For a 32 kbps codec with 5 ms frames, packets = are just 30% smaller than with a 16 kbps codecs with 20 ms frames. >>> "Packet size" here has to include layer 2 overhead, not just IP overhead, = making your argument even stronger. In the case of Ethernet, Layer-2 overhe= ad is 38-42 bytes per packet (depending on whether a vlan tag is present), = so it is about the same as the IP/UDP/RTP overhead. And of course there's = encryption pads, VPN encapsulation, etc. that apply in many cases. There is a floor transmission delay when you send the minimum size packets = the network path allows. [Raymond]: Agreed. There is an incremental delay due to serialization when you send larger siz= e packets than the minimum. (At each hop you wait until you receive last bi= t in the packet before you forward the first bit). I'd agree that a reaso= nable model for the incremental delay is that it scales linearly with the i= ncrease in packet size. But the floor delay is usually too large for this = to matter dominate. [Raymond]: As I mentioned in my last response to Koen, I was just using a s= implified TDM example to make a point that the transmission delay cannot be= zero as the 1X frame size multiplier implies. I agree that for packet sys= tems the delay increase will be smaller than in TDM, but it will not be zer= o. This transmission delay component is indeed small compared with what yo= u called the floor delay. However, using the IP phone engineers' rule of t= humb of 3X codec frame size, the total codec-dependent component of the del= ay can be quite significant when compared with the floor delay, especially = for a 20 ms frame size. And on top of that is the variable delay (jitter) due to congestion, layer= 2 retransmission, and the like. That also will not scale linearly with fr= ame size or packet size. So arguments that increasing the frame size by 10 ms will increase the over= all delay by 50 ms make no sense to me at all. [Raymond]: I have abandoned that 5X frame size formula many emails ago. I = was trying to make it simple, but later I realized that this over-simplifie= d approach is not good, so several emails ago I already replaced it with on= e-way delay =3D codec-independent delay + 3*(codec frame size) + (codec loo= k-ahead) + (codec filtering delay if any). The main debate now is centered= on whether the multiplier of the codec frame size should be 1 as Koen said= or 3 as I was told by experienced IP phone engineers. I argue that 1X is = theoretically impossible. It is interesting to note that the ITU-T uses a = multiplier of 2X. I think 2X is probably achievable for the idealized situ= ation. In practice, however, many nitty-gritty details get in the way of g= etting that idealized situation, and little additional delays just keep get= ting added, resulting in a real-world realistic 3X multiplier. With a 3X m= ultiplier, the one-way delay difference between a 20 ms and a 5 ms codec fr= ame size would be 45 ms + (codec look-ahead difference) + (codec filtering = delay difference). For the conference bridge application, the total differ= ence in one-way delay will double to the 90 to 100 ms range. That's a VERY= significant difference that typical users will notice (it's like adding an= other cell phone call delay), especially if it pushes the total one-way del= ay significantly beyond the 150 ms guideline. Therefore, I argue that for= the best user experience in conference bridge calls, the IETF codec should= have a low-delay mode with a small codec frame size such as 5 ms, and let = the continually increasing speed of communication links make the header ove= rhead bit-rate become less and less of an issue in the future. (Even now, = for those people who have high speed connection to their computers, it is a= lready not an issue. It is better for them to get low delay than to worry = about bit-rate or packet header overhead.) Stephen Botzko On Sun, Apr 25, 2010 at 3:24 PM, Koen Vos > wrote: Hi Raymond, Jitter buffers have no problem implementing a non-integer-frame delay, beca= use packets are queued and read non-synchronously. Processing time matters on low-end hardware - a small fraction of today's V= oIP end points. Even then, the higher coding efficiency of longer frames c= an be translated into lower complexity. And transmission delay increases (perhaps) linearly with the *packet size*,= not with the *frame size*. For a 32 kbps codec with 5 ms frames, packets = are just 30% smaller than with a 16 kbps codecs with 20 ms frames. Let me ask you something: how often is G.729 used with 10 ms packets, or Br= oadvoice with 5 ms packets? best, koen. Quoting "Raymond (Juin-Hwey) Chen": Hi Koen, My comments in-line below. Best Regards, Raymond -----Original Message----- From: Koen Vos [mailto:koen.vos@skype.net] Sent: Saturday, April 24, 2010 6:16 PM To: Raymond (Juin-Hwey) Chen Cc: codec@ietf.org Subject: RE: [codec] #16: Multicast? Quoting "Raymond (Juin-Hwey) Chen": My main point, though, is not in the exact one-way delay value for a codec with a 5 ms frame size, but rather that with a 5 ms frame size you can get a much lower one-way delay than with a 20 ms frame size. It would be about 15 ms lower - don't know if that counts as "much" :) [Raymond]: I don't agree that it will be only 20 - 5 =3D 15 ms lower. That= will be true only if your one-way delay formula below is true, but theoret= ically it cannot be. See my comment below your formula. Also, note that for a given probability of packets arriving too late to be played out, the jitter buffer delay is independent of the frame size. [Raymond]: That may be true theoretically, but in practical implementations= , selecting a jitter buffer delay that is not divisible by the packet size = would make the adaptive jitter buffer pretty messy to implement. If we mak= e the it divisible by the packet size, then a smaller packet size gives you= more granularity to work with and can result in lower average delay as the= codec frames go through the adaptive jitter buffer. - most delay comes from the network and is not codec related, and - one-way delay grows almost linearly with frame size. Doesn't your last line above contradicts with the second last line? I meant that approximately: one-way delay =3D codec-independent delay + frame size ("codec algorithmic delay" would be more accurate than "frame size") [Raymond]: First, I agree that codec algorithmic buffering delay is more ac= curate than frame size since it can also include the "look-ahead" delay and= filtering delay if sub-band analysis/synthesis is used. However, your for= mula implies that for the codec-related delay, the "multiplier" to be used = for the codec frame size is only 1. That's unrealistic and theoretically i= mpossible. For that to happen, after you wait one frame of time for the cu= rrent frame of input audio samples to arrive at your input signal buffer (t= hat's one frame of codec-related delay already), you need an infinitely fas= t processor to finish the encoding operation instantly, then you need an in= finitely fast communication link to ship all the bits in the compressed fra= me to the decoder instantly, and then you need an infinitely fast processor= to finish decoding the frame instantly and start playing back the current = frame of audio without any delay. That's just impossible. In reality, if the processor is just barely fast enough to implement the co= dec in real time, then you need nearly a full frame of time to finish the e= ncoding and decoding operations. That makes the multiplier to be 2 already.= If your communication link is just barely fast enough to transmit your pa= ckets at the same speed they are generated without piling up unsent packets= , then it takes another frame of time to finish transmitting the compressed= bits in a frame to the decoder. That makes the multiplier to be 3 already= . Granted, in practice the processor and the communication link are usually f= aster than just barely enough, so the processing delay and the transmission= delay can be less than 1 frame each. However, there are other miscellaneo= us uncounted delays that tends to depend on the codec size in various ways.= Thus, a typical IP phone implementation would have One-way delay =3D codec-independent delay + 3*(codec frame size) + (codec = look-ahead) + (codec filtering delay if any). Hence, the one-way delay difference between a 20 ms and a 5 ms codec frame = size would be 45 ms + (codec look-ahead difference) + (codec filtering dela= y difference). Consequently, for the conference bridge application, the total difference i= n one-way delay can easily be in the 90 to 100 ms range. When adding this d= elay difference to all the other codec-independent delay components, it is = still a huge difference that the users can easily notice, especially since = it will most likely push the total one-way delay significantly beyond the 1= 50 ms limit. I am aware of a header compression technology for VoIP over Cable applications that can compress the header size to a very small fraction of the original size, but it is probably not widely used. Yes, header compression works between end-points on a cable. That's different from "between arbitrary Internet end points". [Raymond]: The cable operators' networks are still IP networks. If the tec= hnology can work there, I don't see why it cannot work elsewhere in the Int= ernet. I know it is currently not available between arbitrary Internet end= points. I am just saying that technologies exist that can potentially be = deployed in the Internet to compress the packet headers to a very small fra= ction of the uncompressed headers. best, koen. _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B901365F2IRVEXCHCCR01c_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable

Hi Stephen,

 

Thanks for sharing your broad knowledge in this.  You made some good points, and I basically agree with them.  I just have some comments in-line.

 

Raymond

From: stephen botzk= o [mailto:stephen.botzko@gmail.com]
Sent: Sunday, April 25, 2010 1:38 PM
To: Koen Vos
Cc: Raymond (Juin-Hwey) Chen; codec@ietf.org
Subject: Re: [codec] #16: Multicast?

 

>>>
And transmission delay increases (perhaps) linearly with the *packet size*,= not with the *frame size*.  For a 32 kbps codec with 5 ms frames, packets = are just 30% smaller than with a 16 kbps codecs with 20 ms frames.
>>>
 "Packet size" here has to include layer 2 overhead, not jus= t IP overhead, making your argument even stronger. In the case of Ethernet, Laye= r-2 overhead is 38-42 bytes per packet (depending on whether a vlan tag is present), so it is about the same as the IP/UDP/RTP overhead.  And of course there's encryption pads, VPN encapsulation, etc. that apply in many cases.

There is a floor transmission delay when you send the minimum size packets = the network path allows.

[Raymond]: Agreed.

There is an incremental delay due to serialization when you send larger siz= e packets than the minimum. (At each hop you wait until you receive last bit = in the packet before you forward the first bit).   I'd agree that a reasonable model for the incremental delay is that it scales linearly with = the increase in packet size.  But the floor delay is usually too large for this to matter dominate.

[Raymond]: As I mentioned in m= y last response to Koen, I was just using a simplified TDM example to make a point that the transmission delay cannot be zero as the 1X frame size multiplier implies.  I agree that for packet systems the delay increas= e will be smaller than in TDM, but it will not be zero.  This transmissi= on delay component is indeed small compared with what you called the floor delay.  However, using the IP phone engineers’ rule of thumb of = 3X codec frame size, the total codec-dependent component of the delay can be q= uite significant when compared with the floor delay, especially for a 20 ms fram= e size.

And on top of that is the variable delay  (jitter) due to congestion, layer 2 retransmission, and the like.  That also will not scale linear= ly with frame size or packet size.

So arguments that increasing the frame size by 10 ms will increase the over= all delay by 50 ms make no sense to me at all.

[Raymond]: I have abandoned th= at 5X frame size formula many emails ago.  I was trying to make it simple= , but later I realized that this over-simplified approach is not good, so sev= eral emails ago I already replaced it with one-way delay =3D codec-independent d= elay + 3*(codec frame size) + (codec look-ahead) + (codec filtering delay if any).=   The main debate now is centered on whether the multiplier of the codec fram= e size should be 1 as Koen said or 3 as I was told by experienced IP phone engineers.  I argue that 1X is theoretically impossible.  It is interesting to note that the ITU-T uses a multiplier of 2X.  I think 2= X is probably achievable for the idealized situation.  In practice, however= , many nitty-gritty details get in the way of getting that idealized situatio= n, and little additional delays just keep getting added, resulting in a real-w= orld realistic 3X multiplier.  With a 3X multiplier, the one-way delay difference between a 20 ms and a 5 ms codec frame size would be 45 ms + (co= dec look-ahead difference) + (codec filtering delay difference).  For the conference bridge application, the total difference in one-way delay will double to the 90 to 100 ms range.  That’s a VERY significant difference that typical users will notice (it’s like adding another c= ell phone call delay), especially if it pushes the total one-way delay significantly beyond the 150 ms guideline.   Therefore, I argue t= hat for the best user experience in conference bridge calls, the IETF codec sho= uld have a low-delay mode with a small codec frame size such as 5 ms, and let t= he continually increasing speed of communication links make the header overhead bit-rate b= ecome less and less of an issue in the future.  (Even now, for those people = who have high speed connection to their computers, it is already not an issue.&= nbsp; It is better for them to get low delay than to worry about bit-rate or pack= et header overhead.)

Stephen Botzko

On Sun, Apr 25, 2010 at 3:24 PM, Koen Vos <koen.vos@skype.net> wrote:

Hi Raymond,

Jitter buffers have no problem implementing a non-integer-frame delay, beca= use packets are queued and read non-synchronously.

Processing time matters on low-end hardware - a small fraction of today's V= oIP end points.  Even then, the higher coding efficiency of longer frames = can be translated into lower complexity.

And transmission delay increases (perhaps) linearly with the *packet size*,= not with the *frame size*.  For a 32 kbps codec with 5 ms frames, packets = are just 30% smaller than with a 16 kbps codecs with 20 ms frames.

Let me ask you something: how often is G.729 used with 10 ms packets, or Broadvoice with 5 ms packets?

best,
koen.





Quoting "Raymond (Juin-Hwey) Chen":

Hi Koen,



My comments in-line below.



Best Regards,



Raymond



-----Original Message-----
From: Koen Vos [mailto:koen.vos@skype.net]
Sent: Saturday, April 24, 2010 6:16 PM
To: Raymond (Juin-Hwey) Chen
Cc: codec@ietf.org<= br> Subject: RE: [codec] #16: Multicast?



Quoting "Raymond (Juin-Hwey) Chen":

My main point, though, is not in the exact one-way del= ay value for a

 

codec with a 5 ms frame size, but rather that with a 5= ms frame size

 

you can get a much lower one-way delay than with a 20 = ms frame size.




It would be about 15 ms lower - don't know if that counts as "much&quo= t; :)



[Raymond]: I don't agree that it will be only 20 - 5 =3D 15 ms lower.  = ;That will be true only if your one-way delay formula below is true, but theoretically it cannot be.  See my comment below your formula.



Also, note that for a given probability of packets arriving too late

to be played out, the jitter buffer delay is independent of the frame

size.

[Raymond]: That may be true theoretically, but in practical implementations= , selecting a jitter buffer delay that is not divisible by the packet size would make t= he adaptive jitter buffer pretty messy to implement.  If we make the it divisible by the packet size, then a smaller packet size gives you more granularity to work with and can result in lower average delay as the codec frames go through the adaptive jitter buffer.


- most delay comes from the network and is not codec related, and

 

- one-way delay grows almost linearly with frame size.=

 

 

 

Doesn't your last line above contradicts with the seco= nd last line?




I meant that approximately:

   one-way delay =3D codec-independent delay + frame size



("codec algorithmic delay" would be more accurate than "fram= e size")



[Raymond]: First, I agree that codec algorithmic buffering delay is more accurate than frame size since it can also include the "look-ahead&quo= t; delay and filtering delay if sub-band analysis/synthesis is used.  However, your formula implies that for the codec-related delay, the "multiplier" to be used for the codec frame size is only 1.  That's unrealistic and theoretically impossible.  For that to happen, after you wait one frame of time for the current frame of input aud= io samples to arrive at your input signal buffer (that's one frame of codec-re= lated delay already), you need an infinitely fast processor to finish the encodin= g operation instantly, then you need an infinitely fast communication link to ship all the bits in the compressed frame to the decoder instantly, and the= n you need an infinitely fast processor to finish decoding the frame instantl= y and start playing back the current frame of audio without any delay.  That's just impossible.

In reality, if the processor is just barely fast enough to implement the co= dec in real time, then you need nearly a full frame of time to finish the encod= ing and decoding operations. That makes the multiplier to be 2 already.  I= f your communication link is just barely fast enough to transmit your packets= at the same speed they are generated without piling up unsent packets, then it takes another frame of time to finish transmitting the compressed bits in a frame to the decoder.  That makes the multiplier to be 3 already.

Granted, in practice the processor and the communication link are usually faster than just barely enough, so the processing delay and the transmissio= n delay can be less than 1 frame each.  However, there are other miscellaneous uncounted delays that tends to depend on the codec size in various ways.  Thus, a typical IP phone implementation would have

 One-way delay =3D codec-independent delay + 3*(codec frame size) + (c= odec look-ahead) + (codec filtering delay if any).

Hence, the one-way delay difference between a 20 ms and a 5 ms codec frame = size would be 45 ms + (codec look-ahead difference) + (codec filtering delay difference).

Consequently, for the conference bridge application, the total difference i= n one-way delay can easily be in the 90 to 100 ms range. When adding this del= ay difference to all the other codec-independent delay components, it is still= a huge difference that the users can easily notice, especially since it will = most likely push the total one-way delay significantly beyond the 150 ms limit.<= br>

I am aware of a header compression technology for VoIP= over Cable

 

applications that can compress the header size to a ve= ry small

 

fraction of the original size, but it is probably not = widely used.




Yes, header compression works between end-points on a cable.  That's
different from "between arbitrary Internet end points".



[Raymond]: The cable operators' networks are still IP networks.  If th= e technology can work there, I don't see why it cannot work elsewhere in the Internet.  I know it is currently not available between arbitrary Inte= rnet end points.  I am just saying that technologies exist that can potenti= ally be deployed in the Internet to compress the packet headers to a very small fraction of the uncompressed headers.



best,

koen.


 

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

 

--_000_CB68DF4CFBEF4942881AD37AE1A7E8C74B901365F2IRVEXCHCCR01c_-- From rchen@broadcom.com Mon Apr 26 14:02:51 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 354673A6839 for ; Mon, 26 Apr 2010 14:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.169 X-Spam-Level: X-Spam-Status: No, score=-0.169 tagged_above=-999 required=5 tests=[AWL=-0.170, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-WbMfRfh2fm for ; Mon, 26 Apr 2010 14:02:50 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id 018CF3A6B6E for ; Mon, 26 Apr 2010 14:02:47 -0700 (PDT) Received: from [10.9.200.131] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Mon, 26 Apr 2010 14:02:20 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Mon, 26 Apr 2010 14:02:20 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Mikael Abrahamsson" Date: Mon, 26 Apr 2010 14:02:18 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrkTi/xlw0UOCUaT+WSfKLd+Krg0wBIzQdg Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <20100423011559.20246ayxdicd9vzz@mail.skype.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67CB20D620S103926853-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 21:02:51 -0000 Hi Mikael, Thanks for sharing your experience using a BT headset for Skype calls. I t= hink part of the quality degradation that you experienced was due to the re= duction of the audio bandwidth to narrowband (8 kHz sampling, 3.4 kHz bandw= idth), and another part of the degradation was due to the audible coding no= ise of the CVSD codec, a 40-year-old coding technology first proposed in 19= 70. =20 If a high-quality, low-complexity, wider bandwidth IETF codec mode can be i= mplemented in Skype and the Bluetooth headset to avoid the CVSD transcoding= (together with wideband upgrade of the transducers and audio path in the B= T headset, of course), then not only will you get much better speech qualit= y in your Skype calls than what you have experienced, but also you will get= a lower latency. This is because transcoding between the Skype codec and = CVSD not only accumulates the coding distortion of the two codecs, but also= accumulates the coding delays. Although CVSD is a sample-by-sample codec,= BT headsets still transmit the CVSD bit-stream in 3.75 ms or 7.5 ms packet= s, and they can potentially add a one-way delay up to 20 ~ 25 ms through th= e Bluetooth headset (the exact delay depends on the implementation). While we were discussing whether a 5 ms packet size can even be considered,= for many years Bluetooth headsets have been using an even smaller 3.75 ms = packet size. Best Regards, Raymond -----Original Message----- From: Mikael Abrahamsson [mailto:swmike@swm.pp.se]=20 Sent: Sunday, April 25, 2010 1:06 AM To: Raymond (Juin-Hwey) Chen Cc: Koen Vos; codec@ietf.org Subject: Re: [codec] #16: Multicast? On Sat, 24 Apr 2010, Raymond (Juin-Hwey) Chen wrote: > (7) Already a lot of people are used to using Bluetooth headsets to make= =20 > phone calls today. If they have a choice, many of these people will=20 > also want to use Bluetooth headsets to make Internet phone calls, not=20 > only through computers, but also through smart phones connected to WiFi=20 > or cellular networks. As more and more states and countries pass laws=20 > to ban the use of cell phones that are not in hands-free mode while=20 > driving, the number of Bluetooth headset users will only increase with=20 > time, and many of them will want to make Internet-based phone calls. I purchased a BT headset with the anticipation of using it with my=20 computer to make Skype calls. I tried it, but the sound quality when doing= =20 bidirectional audio (whatever that mode is called) is not good enough, it=20 worsens the "skype IP" call quality. I agree that the use case is=20 interesting, but as long as BT sound quality is what it is, it's really=20 only the "low end" type sound quality we're talking about. But yes, I make skype IP calls with my Nokia N900 using BT sometimes, so=20 the use case example is definitely valid. --=20 Mikael Abrahamsson email: swmike@swm.pp.se From rob.glidden@sbcglobal.net Mon Apr 26 14:59:49 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 908AB3A68DE for ; Mon, 26 Apr 2010 14:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.836 X-Spam-Level: *** X-Spam-Status: No, score=3.836 tagged_above=-999 required=5 tests=[BAYES_99=3.5, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7hEwQ9qZ6ka9 for ; Mon, 26 Apr 2010 14:59:41 -0700 (PDT) Received: from smtp126.sbc.mail.sp1.yahoo.com (smtp126.sbc.mail.sp1.yahoo.com [69.147.65.185]) by core3.amsl.com (Postfix) with SMTP id 1F6783A63D3 for ; Mon, 26 Apr 2010 14:59:40 -0700 (PDT) Received: (qmail 7238 invoked from network); 26 Apr 2010 21:59:27 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type; b=JGvfKuGthcd35griedMqj+j3Dr2sbTTxliUmKefBk+brjPAqm30hz6ejcY4cHRSETmBfIjV0K6q7w/VMkuHAEbeaOntxfTMDiG15nBQ8WaJRjSx3Ck2KjX7ufqOqLrGpHhT3Uib036YbHr+sv3yraqGw2JMOdMhxDCB0oCG6N7M= ; Received: from adsl-69-104-2-32.dsl.pltn13.pacbell.net (rob.glidden@69.104.2.32 with plain) by smtp126.sbc.mail.sp1.yahoo.com with SMTP; 26 Apr 2010 14:59:26 -0700 PDT X-Yahoo-SMTP: xflwSnaswBCuS46GvTyhPI4RUJpgPG5UXouB5Vxqo4t9fsHeH0I- X-YMail-OSG: .4H5PNEVM1n1Z04AISx213kmsVjP2M7Fp8hXRRt5QX9fYtuei5icW2cWjqpq16VMATuKMYAZb08KXwhb6wNm0eKoxDnnLxrgVXR5i5Rpm_98n5pPLi9sp5.EMzX597b9SwvfzMlhQRhNNVgbR.QhXAS7j.5oBvRPZJsQORvPyY7ah9uOPhIrgZa9CQ4kR7uj5hsjhtO9KIY16pjJ6Svyvbj1dHAcWSTP1eQImll7t6Nevief8Rm35h_DrzKyKuYUmZAp4Q3V7VtIkQ9jmlotVJDRa.ZH3cfuOXUU3MJmRTSQu3F1khgxJPXvqyIf6gjwRKJqt1.dWY7I1S77j4cAvOGC X-Yahoo-Newman-Property: ymail-3 Message-ID: <4BD60CB3.9050906@sbcglobal.net> Date: Mon, 26 Apr 2010 14:59:15 -0700 From: Rob Glidden User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: "codec@ietf.org" Content-Type: multipart/alternative; boundary="------------040006070001000209070603" Subject: [codec] MPEG Issues Resolution on Type-1 (Royalty-Free) Standardization X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Apr 2010 21:59:49 -0000 This is a multi-part message in MIME format. --------------040006070001000209070603 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit MPEG --- Working Group 11 of ISO/IEC JTC 1/SC 29 --- has issued a resolution seeking active participation in developing a Type-1 (royalty-free) video coding standard. Would seem opportune for the IETF codec working group to reach out, since charter says: "The working group will communicate a detailed description of the requirements and goals to other SDOs including the ITU-T, 3GPP, and MPEG to help determine if existing codecs meet the requirements and goals." Publicly-released information from recent MPEG meetings on royalty-free standardization is excerpted below. Rob ---------------- http://www.robglidden.com/2010/04/mpeg-resolution-on-royalty-free-standardization/ *Resolutions, the 92nd SC 29/WG 11 Meeting, 2010-04-19/23, Dresden, Germany* SC 29/WG 11 N 11241 http://www.itscj.ipsj.or.jp/sc29/open/29view/29n11185c.htm *Type-1 License Video Coding Standard* Given that there is a desire for using royalty free video coding technologies for some applications such as video distribution over the Internet, MPEG wishes to enquire of National Bodies about their willingness to commit to active participation (as defined by Section 6.2.1.4 of the JTC1 directives) in developing a Type-1 video coding standard. MPEG would appreciate if NBs provide the names of individual organisations that will commit resources. MPEG will use the information gathered from the NB responses, particularly including the number of countries willing to actively participate, in order to decide at the Geneva meeting whether to request approval of a new Work Item Proposal. MPEG does not intend to reopen the issue, unless strong support of at least five national bodies is presented in the future. ---------------- *ISO/IEC JTC 1 N8557, ISO/IEC JTC 1 Directives, 5th Edition, Version 3.0* http://www.itscj.ipsj.or.jp/sc29/directives.pdf 6.2.1.3 ... In order to be approved, the proposal shall be supported by a majority of all P-members of JTC 1 with at least five P-members of the SC to which the project will be assigned committed to active participation. ... 6.2.1.4 Active participation for NPs includes involvement by NBs in more than one of the following: . Attendance at meetings (see also 7.11); . Contributing to the development of the WD; . Performing substantial review on a CD and subsequent stages; . Submitting detailed comment with ballots. ---------------- *Meeting Report, the 91st SC 29/WG 11 Meeting, 2010-01-18/22, Kyoto, Japan* SC 29/WG 11 N 11077 http://www.itscj.ipsj.or.jp/sc29/open/29view/29n11151c.htm *Royalty-free Codecs* In order to help with the discussion on royalty-free codecs, several National Bodies provided input as requested in N11066/ Call for Comments on Possible Future activities on "Royalty-free" Standardization by MPEG/. MPEG thanks with N11222 /Responses to NB position statements on N1066/. No clear conclusions could be drawn from the diverse responses. Furthermore, neither MPEG nor ISO can guarantee that a standard developed with the goal of being RAND or royalty-free will actually be RAND or royalty-free since the analysis of patents is outside of the scope and competence of ISO and MPEG. MPEG issued document N11221 /Possible future actions on standardization with Type 1 licensing/ where the legal issues are summarized and discussed. Type 1 licensing refers to option 1 of the joint patent declaration form, where an intellectual property holder can indicate that he will not charge for his IP. Laymen refer to this type of licensing as royalty-free. However, MPEG believes that 20 years after its publication some technology will become royalty-free. Since parts of MPEG-1 and MPEG-2 were published in 2013 and 2014, candidates are a MPEG-2 Part 2 baseline profile carved out of MPEG-2 Part 2, MPEG-1 Part 3 Layer 2 baseline profile carved out of the MPEG-1 part 3 Layer 2, a MPEG-1 Part 3 Layer 3 baseline profile carved out of the MPEG-1 part 3 Layer 3, and a MPEG-2 Part 1 baseline profile carved out of the MPEG-2 part 1. These candidates would be compatible with existing equipment. Alternatively, MPEG may define a new set of standards which are believed to be RF provided such standards provide sufficient differentiation to be successful in the market place. ---------------- *Meeting Report, the 90th SC 29/WG 11 Meeting, 2009-10-26/30, Xian, China* SC 29/WG 11 N 10876 http://www.itscj.ipsj.or.jp/sc29/open/29view/29n10944c.htm *Royalty-free Codecs* The Chinese National Body encouraged MPEG to discuss the option of royalty-free codecs developed within MPEG (N11065 /Responses to CNNB position statement on more friendly IPR policy/). Especially small companies perceive licensing as cumbersome. Some royalty free standards have become successful in the market place. MPEG might consider royalty-free codecs only as a supplement to its current standards development process. The preliminary results of the discussion are summarized in N11067 /Summary of Issues and question from the 90th MPEG Meeting in connection with CNNB input document (M16903)/. In order to help with this discussion, MPEG requests National Bodies to provide input according to N11066/ Call for Comments on Possible Future activities on "Royalty-free" Standardization by MPEG/. ---------------- --------------040006070001000209070603 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit MPEG — Working Group 11 of  ISO/IEC JTC 1/SC 29 — has issued a resolution seeking active participation in developing a Type-1 (royalty-free) video coding standard.

Would seem opportune for the IETF codec working group to reach out, since charter says:

"The working group will communicate a detailed description of the requirements and goals to other SDOs including the ITU-T, 3GPP, and MPEG to help determine if existing codecs meet the requirements and goals."

Publicly-released information from recent MPEG meetings on royalty-free standardization is excerpted below.

Rob

—————-
http://www.robglidden.com/2010/04/mpeg-resolution-on-royalty-free-standardization/

Resolutions, the 92nd SC 29/WG 11 Meeting, 2010-04-19/23, Dresden, Germany

SC 29/WG 11 N 11241

http://www.itscj.ipsj.or.jp/sc29/open/29view/29n11185c.htm

Type-1 License Video Coding Standard

Given that there is a desire for using royalty free video coding technologies for some applications such as video distribution over the Internet, MPEG wishes to enquire of National Bodies about their willingness to commit to active participation (as defined by Section 6.2.1.4 of the JTC1 directives) in developing a Type-1 video coding standard. MPEG would appreciate if NBs provide the names of individual organisations that will commit resources. MPEG will use the information gathered from the NB responses, particularly including the number of countries willing to actively participate, in order to decide at the Geneva meeting whether to request approval of a new Work Item Proposal. MPEG does not intend to reopen the issue, unless strong support of at least five national bodies is presented in the future.

—————-
ISO/IEC JTC 1 N8557, ISO/IEC JTC 1 Directives, 5th Edition, Version 3.0

http://www.itscj.ipsj.or.jp/sc29/directives.pdf

6.2.1.3 … In order to be approved, the proposal shall be supported by a majority of all P-members of JTC 1 with at least five P-members of the SC to which the project will be assigned committed to active participation. …

6.2.1.4  Active participation for NPs includes involvement by NBs in more than one of the following:

• Attendance at meetings (see also 7.11);
• Contributing to the development of the WD;
• Performing substantial review on a CD and subsequent stages;
• Submitting detailed comment with ballots.

—————-

Meeting Report, the 91st SC 29/WG 11 Meeting, 2010-01-18/22, Kyoto, Japan

SC 29/WG 11 N 11077

http://www.itscj.ipsj.or.jp/sc29/open/29view/29n11151c.htm

Royalty-free Codecs

In order to help with the discussion on royalty-free codecs, several National Bodies provided input as requested in N11066 Call for Comments on Possible Future activities on “Royalty-free” Standardization by MPEG. MPEG thanks with N11222 Responses to NB position statements on N1066. No clear conclusions could be drawn from the diverse responses. Furthermore, neither MPEG nor ISO can guarantee that a standard developed with the goal of being RAND or royalty-free will actually be RAND or royalty-free since the analysis of patents is outside of the scope and competence of ISO and MPEG.

MPEG issued document N11221 Possible future actions on standardization with Type 1 licensing where the legal issues are summarized and discussed. Type 1 licensing refers to option 1 of the joint patent declaration form, where an intellectual property holder can indicate that he will not charge for his IP. Laymen refer to this type of licensing as royalty-free.

However, MPEG believes that 20 years after its publication some technology will become royalty-free. Since parts of MPEG-1 and MPEG-2 were published in 2013 and 2014, candidates are a MPEG-2 Part 2 baseline profile carved out of MPEG-2 Part 2, MPEG-1 Part 3 Layer 2 baseline profile carved out of the MPEG-1 part 3 Layer 2, a MPEG-1 Part 3 Layer 3 baseline profile carved out of the MPEG-1 part 3 Layer 3, and a MPEG-2 Part 1 baseline profile carved out of the MPEG-2 part 1. These candidates would be compatible with existing equipment. Alternatively, MPEG may define a new set of standards which are believed to be RF provided such standards provide sufficient differentiation to be successful in the market place.

—————-

Meeting Report, the 90th SC 29/WG 11 Meeting, 2009-10-26/30, Xian, China

SC 29/WG 11 N 10876

http://www.itscj.ipsj.or.jp/sc29/open/29view/29n10944c.htm

Royalty-free Codecs

The Chinese National Body encouraged MPEG to discuss the option of royalty-free codecs developed within MPEG (N11065 Responses to CNNB position statement on more friendly IPR policy). Especially small companies perceive licensing as cumbersome. Some royalty free standards have become successful in the market place.

MPEG might consider royalty-free codecs only as a supplement to its current standards development process. The preliminary results of the discussion are summarized in N11067 Summary of Issues and question from the 90th MPEG Meeting in connection with CNNB input document (M16903). In order to help with this discussion, MPEG requests National Bodies to provide input according to N11066 Call for Comments on Possible Future activities on “Royalty-free” Standardization by MPEG.

—————-



--------------040006070001000209070603-- From koen.vos@skype.net Tue Apr 27 00:16:19 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1326E3A6A27 for ; Tue, 27 Apr 2010 00:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.539 X-Spam-Level: X-Spam-Status: No, score=-4.539 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AstwOi2iHyGN for ; Tue, 27 Apr 2010 00:16:17 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 18C773A6C31 for ; Tue, 27 Apr 2010 00:16:16 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 21DB760135BE3; Tue, 27 Apr 2010 08:16:03 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=bnuXNvOFlh13 9o2ucGsKUz5REa8=; b=fJvNlU1VwhUgiO4B5P9BartcB9zKkkp+Ri1wLiTV0hVs ek4cGTBNnXW0+ZTLwyrkqAVr9P7N8+0w5YduHnRLMldz6ZSXW+gJN123EF9Lmoqd Xtc916lhghTKx7HLrW9pg8U6RHYaWgVKkbHUZTfSz6ESReQs4voqMZCyJ9VLMp8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:cc:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=fNntddv9y5H3vxYKQYXY PebJhK5b9S1EY3jInxeGpwcq6JCEIq63U/4GkSl0ODf0op7JpzJonVcn+MHPNaix sh56bvkfE5AU+F6UgtNXt75aXDaXzQ5ZXmkbzUIPH18LNNvkRrPxGnbGsD7j22Yi UBWHQGBcjF3KqZVfPeC6mo0= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 1F60660135BE1; Tue, 27 Apr 2010 08:16:03 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DDMUpkkGkywW; Tue, 27 Apr 2010 08:16:02 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 06EC860135BE2; Tue, 27 Apr 2010 08:16:02 +0100 (IST) Received: from adsl-71-141-115-202.dsl.snfc21.pacbell.net (adsl-71-141-115-202.dsl.snfc21.pacbell.net [71.141.115.202]) by mail.skype.net (Horde Framework) with HTTP; Tue, 27 Apr 2010 00:16:01 -0700 Message-ID: <20100427001601.28347kv06z915l4h@mail.skype.net> Date: Tue, 27 Apr 2010 00:16:01 -0700 From: Koen Vos To: "Raymond (Juin-Hwey) Chen" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <20100424135607.84293hkaa13j1zvr@mail.skype.net> <20100424181620.352034g28cnjr010@mail.skype.net> <20100425122429.2136460zti0p5fjh@mail.skype.net> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Apr 2010 07:16:19 -0000 Hi Raymond, Please don't get me wrong: I share your vision that, over time, Moore's law will drive adoption of the highest possible audio quality in IP end points. And the creation of the very low-delay, full-band, (near-)transparent and even multi-channel codec this requires falls indeed within the objectives of this WG, if you ask me. best, koen. Quoting "Raymond (Juin-Hwey) Chen": > In-line... > > > > -----Original Message----- > From: Koen Vos [mailto:koen.vos@skype.net] > Sent: Sunday, April 25, 2010 12:24 PM > To: Raymond (Juin-Hwey) Chen > Cc: codec@ietf.org > Subject: RE: [codec] #16: Multicast? > > > > Hi Raymond, > > > > Jitter buffers have no problem implementing a non-integer-frame delay, > > because packets are queued and read non-synchronously. > > [Raymond]: I am talking about adaptive jitter buffer that tries to > minimize the delay through the jitter buffer dynamically depending > on the observed network jitter. If the jitter is small, you > decrease that delay, and if it is large, you increase that delay. An > engineer who actually implemented such an adaptive jitter buffer in > an IP phone told me that the non-integer-frame delay made it pretty > messy to implement (I didn't say it was not possible; it's just > messy), so for implementation simplicity's sake, the jitter delay > was often chosen to be an integer number of frames. He also said > that a smaller frame size gives you more frequent observations of > the network jitter and thus makes the jitter estimate more > responsive and accurate. > > > > Processing time matters on low-end hardware - a small fraction of > > today's VoIP end points. > > [Raymond]: Processing time certainly matters for IP phones, and > there are a lot of enterprise IP phones deployed today. I heard that > it is actually significantly cheaper for enterprises to have their > entire phone systems IP-phone-based than analog-phone-based. I won't > be surprised that before too long the vast majority of enterprises > will use only IP phones. Even consumer phones and cell phones are > moving toward IP-based. Eventually that would be a very large > percentage of VoIP end points. > > > > And transmission delay increases (perhaps) linearly with the *packet > > size*, not with the *frame size*. For a 32 kbps codec with 5 ms > > frames, packets are just 30% smaller than with a 16 kbps codecs with > > 20 ms frames. > > [Raymond]: Agreed. My previous comments on transmission delay was > based on the TDM rather than packet scenario, but I was just using > that simplified TDM example to make a point that transmission delay > cannot be zero, as your 1X frame size multiplier would imply. Even > with your statement above, a larger codec frame size still makes a > larger packet size, which then increases the transmission delay, so > you can't say transmission delay is zero or is independent of the > codec size. > > In any case, these are really minor details. My key point is that > your 1X multiplier for the codec frame size is simply theoretically > impossible. The rule of thumb used by IP phone engineers is around > 3X codec frame size. > > > > Let me ask you something: how often is G.729 used with 10 ms packets, > > or Broadvoice with 5 ms packets? > > [Raymond]: Not very often, but that's because previously network > routers/switches didn't like to handle too many packets per second, > and the higher packet header overhead associated with a smaller > packet size means the overall bit-rate would be higher than desired > or allowed, so the time of small packet size for low-delay VoIP > hasn't really come yet. However, with the help of Moore's Law, > network routers/switches are becoming much faster now, and I was > told that they can handle a 5 ms packet size without problems; > furthermore, the speed of backbone networks and access networks keep > increasing with time, so the bit-rate concern will also decrease > with time. > > Unlike processing speed and communication speed that continuously > get improved with time for decades, delay is one thing that will NOT > get improved with time and Moore's Law cannot do anything about that! > > If the IETF codec has a minimum frame size of 20 ms, we will be > stuck with the longer overall delay associated with that, and > Moore's Law will not help us reduce that delay in the future. On > the other hand, in addition to using a 20 ms frame size for > bit-rate-sensitive applications, if the IETF codec also has a > low-delay mode that uses a 5 ms frame size, then at least for > delay-sensitive applications, people have a choice to achieve a > lower delay by paying the price of a higher overall bit-rate (i.e. > with packet header counted), and this higher bit-rate will be less > and less of a concern as the network speed keep increasing with time. > > Therefore, recognizing that delay cannot be helped by Moore's Law > but bit-rate can, it would be wise for the IETF codec WG to adopt a > low-delay mode for the codec in order to be future-proof. > > > > > > best, > > koen. > > > > > > > > Quoting "Raymond (Juin-Hwey) Chen": > > > >> Hi Koen, > >> > >> > >> > >> My comments in-line below. > >> > >> > >> > >> Best Regards, > >> > >> > >> > >> Raymond > >> > >> > >> > >> -----Original Message----- > >> From: Koen Vos [mailto:koen.vos@skype.net] > >> Sent: Saturday, April 24, 2010 6:16 PM > >> To: Raymond (Juin-Hwey) Chen > >> Cc: codec@ietf.org > >> Subject: RE: [codec] #16: Multicast? > >> > >> > >> > >> Quoting "Raymond (Juin-Hwey) Chen": > >> > >>> My main point, though, is not in the exact one-way delay value for a > >> > >>> codec with a 5 ms frame size, but rather that with a 5 ms frame size > >> > >>> you can get a much lower one-way delay than with a 20 ms frame size. > >> > >> > >> > >> It would be about 15 ms lower - don't know if that counts as "much" :) > >> > >> > >> > >> [Raymond]: I don't agree that it will be only 20 - 5 = 15 ms lower. > >> That will be true only if your one-way delay formula below is true, > >> but theoretically it cannot be. See my comment below your formula. > >> > >> > >> > >> Also, note that for a given probability of packets arriving too late > >> > >> to be played out, the jitter buffer delay is independent of the frame > >> > >> size. > >> > >> [Raymond]: That may be true theoretically, but in practical > >> implementations, selecting a jitter buffer delay that is not > >> divisible by the packet size would make the adaptive jitter buffer > >> pretty messy to implement. If we make the it divisible by the > >> packet size, then a smaller packet size gives you more granularity > >> to work with and can result in lower average delay as the codec > >> frames go through the adaptive jitter buffer. > >> > >> > >> > >>>> - most delay comes from the network and is not codec related, and > >> > >>>> - one-way delay grows almost linearly with frame size. > >> > >>> > >> > >>> Doesn't your last line above contradicts with the second last line? > >> > >> > >> > >> I meant that approximately: > >> > >> one-way delay = codec-independent delay + frame size > >> > >> > >> > >> ("codec algorithmic delay" would be more accurate than "frame size") > >> > >> > >> > >> [Raymond]: First, I agree that codec algorithmic buffering delay is > >> more accurate than frame size since it can also include the > >> "look-ahead" delay and filtering delay if sub-band > >> analysis/synthesis is used. However, your formula implies that for > >> the codec-related delay, the "multiplier" to be used for the codec > >> frame size is only 1. That's unrealistic and theoretically > >> impossible. For that to happen, after you wait one frame of time > >> for the current frame of input audio samples to arrive at your input > >> signal buffer (that's one frame of codec-related delay already), you > >> need an infinitely fast processor to finish the encoding operation > >> instantly, then you need an infinitely fast communication link to > >> ship all the bits in the compressed frame to the decoder instantly, > >> and then you need an infinitely fast processor to finish decoding > >> the frame instantly and start playing back the current frame of > >> audio without any delay. That's just impossible. > >> > >> In reality, if the processor is just barely fast enough to implement > >> the codec in real time, then you need nearly a full frame of time to > >> finish the encoding and decoding operations. That makes the > >> multiplier to be 2 already. If your communication link is just > >> barely fast enough to transmit your packets at the same speed they > >> are generated without piling up unsent packets, then it takes > >> another frame of time to finish transmitting the compressed bits in > >> a frame to the decoder. That makes the multiplier to be 3 already. > >> > >> Granted, in practice the processor and the communication link are > >> usually faster than just barely enough, so the processing delay and > >> the transmission delay can be less than 1 frame each. However, > >> there are other miscellaneous uncounted delays that tends to depend > >> on the codec size in various ways. Thus, a typical IP phone > >> implementation would have > >> > >> One-way delay = codec-independent delay + 3*(codec frame size) + > >> (codec look-ahead) + (codec filtering delay if any). > >> > >> Hence, the one-way delay difference between a 20 ms and a 5 ms codec > >> frame size would be 45 ms + (codec look-ahead difference) + (codec > >> filtering delay difference). > >> > >> Consequently, for the conference bridge application, the total > >> difference in one-way delay can easily be in the 90 to 100 ms range. > >> When adding this delay difference to all the other codec-independent > >> delay components, it is still a huge difference that the users can > >> easily notice, especially since it will most likely push the total > >> one-way delay significantly beyond the 150 ms limit. > >> > >> > >> > >>> I am aware of a header compression technology for VoIP over Cable > >> > >>> applications that can compress the header size to a very small > >> > >>> fraction of the original size, but it is probably not widely used. > >> > >> > >> > >> Yes, header compression works between end-points on a cable. That's > >> > >> different from "between arbitrary Internet end points". > >> > >> > >> > >> [Raymond]: The cable operators' networks are still IP networks. If > >> the technology can work there, I don't see why it cannot work > >> elsewhere in the Internet. I know it is currently not available > >> between arbitrary Internet end points. I am just saying that > >> technologies exist that can potentially be deployed in the Internet > >> to compress the packet headers to a very small fraction of the > >> uncompressed headers. > >> > >> > >> > >> best, > >> > >> koen. > >> > >> > >> > > > > > > > From rchen@broadcom.com Thu Apr 29 15:14:50 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B8A93A68CB for ; Thu, 29 Apr 2010 15:14:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.156 X-Spam-Level: X-Spam-Status: No, score=-0.156 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_50=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8j579V2I24dy for ; Thu, 29 Apr 2010 15:14:47 -0700 (PDT) Received: from mms2.broadcom.com (mms2.broadcom.com [216.31.210.18]) by core3.amsl.com (Postfix) with ESMTP id 282923A67EF for ; Thu, 29 Apr 2010 15:14:46 -0700 (PDT) Received: from [10.9.200.131] by mms2.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Thu, 29 Apr 2010 15:14:11 -0700 X-Server-Uuid: D3C04415-6FA8-4F2C-93C1-920E106A2031 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Thu, 29 Apr 2010 15:14:11 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Koen Vos" Date: Thu, 29 Apr 2010 15:14:06 -0700 Thread-Topic: [codec] #16: Multicast? (Bluetooth) Thread-Index: AcrkZp6r+FlhtPLJTqiyj0huCcvYcgC0NDlA Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <20100423011559.20246ayxdicd9vzz@mail.skype.net> <20100425040049.69785q4ih4vowtep@mail.skype.net> In-Reply-To: <20100425040049.69785q4ih4vowtep@mail.skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: CPIy DAfl F3PU GuPW K4gP MDJL ML43 Myxz O9Q7 RUUk RWDe RxV0 SZkT SqpW UffQ Vwlw; 2; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAawBvAGUAbgAuAHYAbwBzAEAAcwBrAHkAcABlAC4AbgBlAHQA; Sosha1_v1; 7; {E56D802B-2465-48FA-AED2-F265ADE00AD8}; cgBjAGgAZQBuAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0A; Thu, 29 Apr 2010 22:14:06 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAIwAxADYAOgAgAE0AdQBsAHQAaQBjAGEAcwB0AD8AIAAoAEIAbAB1AGUAdABvAG8AdABoACkA x-cr-puzzleid: {E56D802B-2465-48FA-AED2-F265ADE00AD8} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67C4DB3938O190698824-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? (Bluetooth) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Apr 2010 22:14:50 -0000 Hi Koen, For some reason the SPAM filter accidentally routed your email below (sent = last Sunday) to my junk email folder and I just saw it. Sorry about the del= ay of my response. I agree that there are some fundamental differences in the requirements for= cellular codecs and Bluetooth codecs which caused the codecs in these two = types of devices to each go their own way. However, these differences are = (or can be) substantially smaller between an Internet codec and Bluetooth c= odecs, so I think it is easier for Internet devices and Bluetooth devices t= o use the same codec to avoid the additional delay and coding distortion of= transcoding. (1) Royalty-free requirement: Cellular codecs are usually royalty-bearing, and that's acceptable in the c= ellular world. Not so with Bluetooth. Bluetooth devices are meant to be s= imple and low cost. As such, Bluetooth SIG basically only wants to standar= dize royalty-free technologies. That's an important reason why they picked= the CVSD codec, a royalty-free old technology of 1970. We are trying to m= ake the IETF codec royalty-free, so in this regard this goal is consistent = with the Bluetooth SIG's royalty-free requirement for codec. (2) Bit-rate requirement: Cellular radio spectrum is a limited, fixed resource that doesn't change wi= th time, and cellular operators spent billions of dollars in radio spectrum= auctions. Thus, it is extremely important for cellular codecs to have bit-= rates as low as possible, with an average bit-rate often going below 1 bit/= sample, to maximize the number of cellular subscribers a given amount of ra= dio spectrum can support. In contrast, the bit-rate is not nearly as big a= concern for Bluetooth. Initially Bluetooth SIG picked the relatively high-= bit-rate 64 kb/s CVSD narrowband codec (8 bits/sample) for its simplicity a= nd royalty-free nature among other things. Since the speeds of the Interne= t back bone and access networks keep growing with time, the bit-rate of an = Internet codec is also not nearly as big a concern as in cellular codecs, a= nd an Internet codec around 2 bits/sample can have better trade-offs (e.g. = higher quality, lower delay, and lower complexity) for Internet application= s than what cellular codecs can provide. Incidentally, Bluetooth SIG is mo= ving toward 4 bits/sample. As you can see, in terms of the bit-rate requir= ement, an Internet codec is much closer to Bluetooth codecs than cellular c= odecs are. (3) Complexity requirement: Bluetooth headsets have much lower processing power and much smaller batter= ies than cell phones. The complexity of cellular codecs, typically in the r= ange of 20 to 40 MHz on a DSP, is too high to fit most Bluetooth headsets. = However, unlike cell phones and Bluetooth headsets where each is a specific= type of device with a relatively narrow range of device complexity, Intern= et voice/audio applications can potentially encompass a large variety of di= fferent device types, from desktop computers at the high end with > 3 GHz m= ulti-core CPU to IP phones and possibly even Bluetooth headsets at the low = end with a processor of only a few tens of MHz. It is up to the IETF codec= WG how we want the complexity of the IETF codec to be. We can standardize= just one codec mode that works well for computer-to-computer calls but can= 't fit in low-end devices, or we can keep that mode but also have a low-com= plexity mode that can be implemented in low-end devices. Frankly, I think = the second approach makes much more sense since it allows many more devices= to benefit from the IETF codec and enables the large number of Bluetooth h= eadset users to avoid the additional distortion and delay associated with t= ranscoding when making Internet calls. (4) Delay requirement: Due to the need for cellular codecs to achieve bit-r= ates as low as possible, they sacrificed the coding delay and used a 20 ms = frame size, because using a 10 or 5 ms frame size would increase the bit-ra= te for a given level of speech quality. On the other hand, a Bluetooth hea= dset needs to have a low delay since its delay is added to the already long= cell phone delay. For the IETF codec, again it is up to the codec WG to d= ecide what kind of codec delay we want, and again I think it makes sense to= have a higher-delay, higher bit-rate efficiency mode for bit-rate-sensitiv= e applications and another low-delay mode for delay-sensitive applications,= since one size doesn't fit all. If the IETF codec delay is forced to be o= ne size, the resulting codec will be (potentially very) suboptimal for some= applications. You wrote: > Do you think it's realistic for us to come up with a design that > fulfills the needs of both worlds? With a one-size-fit-all approach, probably not, but with a multi-mode appro= ach, then I think so. Best Regards, Raymond -----Original Message----- From: Koen Vos [mailto:koen.vos@skype.net] Sent: Sunday, April 25, 2010 4:01 AM To: Raymond (Juin-Hwey) Chen Cc: codec@ietf.org Subject: RE: [codec] #16: Multicast? (Bluetooth) Hi Raymond, You seem to suggest that the IETF Internet codec should fit Bluetooth requirements in order to enable transcoding-free operation all the way from the Internet, through the Internet-connected device, to the BT wireless audio device. A similar argument would hold for ITU-T cellular codecs: AMR-WB and G.718 could have been designed with BT as an application. In reality, these codecs have very little in common with BT codecs, because of the vastly different requirements in terms of - complexity - memory footprint - bitrate - scalability - bit error robustness - packet loss robustness. Do you think it's realistic for us to come up with a design that fulfills the needs of both worlds? The alternative is to separately design codecs for Internet applications and BT devices, and continue the practice of transcoding on the Internet-connected device. That would have a better chance of maximizing quality in all scenarios. best, koen. Quoting "Raymond (Juin-Hwey) Chen": > Hi Koen, > > Responding to your earlier email about Bluetooth headset application: > > (1) Although BT SIG standardization is a preferred route, it is > technically feasible to negotiate and use a non-Bluetooth-SIG codec. > > (2) Someone familiar with BT SIG told me that it would probably take > only 6 months to add an optional codec to the BT SIG spec and 12 to > 18 months to add a mandatory codec. > > (3) The IETF codec is scheduled to be finalized in 14 months and > submitted to IESG in 18 months. Even if we take the BT SIG route > and take 6 to 18 months there. The total time of 2 to 3 years from > now means the Moore's Law would only increase the CPU resources 2X > to 3X, and definitely no more than 4X max, not 10X. > > (4) Most importantly, guess what, in the last several years the > Bluetooth headset chips have been growing its processing power at a > MUCH, MUCH slower rate than what the Moore's Law says it should. > Sometimes they did not increase the speed at all for years. The > reasons? The ASP (average sale price) of Bluetooth chips plummeted > very badly, making it unattractive to invest significant resources > to make them significantly faster. Also, for low-end and mid-end BT > headsets, the BT chips were often considered "good enough" and there > wasn't a strong drive to increase the computing resources. In > addition, the BT headsets got smaller over the last few years; the > corresponding reduction in battery size required a reduction in > power consumption, which also limited how fast the processor speed > could grow. In the next several years, it is highly likely that the > computing capabilities of Bluetooth headset chips will continue to > grow at a rate substantially below what's predicted by the Moore's > Law. > > (5) Although Bluetooth supports G.711 as an optional codec, > basically no one uses it because it is too sensitive to bit errors. > Essentially all the BT mono headsets on the market today are > narrowband (8 kHz sampling) headsets using CVSD. There isn't any > real wideband support yet, so your comment about G.722 doesn't > apply. Even after wideband-capable BT headsets come out, for many > years to come the majority of the BT headsets (especially mid- to > low-end) will still be narrowband only, running only CVSD. Hence, > the quality degradation of the CVSD transcoding is real and will be > with us for quite a while, so it is desirable for the IETF codec to > have a low-complexity mode that can directly run on the BT headsets > to avoid the quality degradation of CVSD when using BT headsets to > make Internet phone calls. > > (6) Even if you could use G.711 or G.722 in the BT headsets, they > both operate at 64 kb/s. A low-complexity mode of the IETF codec > can operate at half or one quarter of that bit-rate. This will help > conserve BT headsets' radio power because of the lower transmit duty > cycle. It will also help the Bluetooth + WiFi co-existence > technologies. > > (7) Already a lot of people are used to using Bluetooth headsets to > make phone calls today. If they have a choice, many of these people > will also want to use Bluetooth headsets to make Internet phone > calls, not only through computers, but also through smart phones > connected to WiFi or cellular networks. As more and more states and > countries pass laws to ban the use of cell phones that are not in > hands-free mode while driving, the number of Bluetooth headset users > will only increase with time, and many of them will want to make > Internet-based phone calls. > > Given all the above, I would argue that Bluetooth headset is a very > relevant application that the IETF codec should address with a > low-complexity mode. > > Best Regards, > > Raymond > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > Behalf Of Koen Vos > Sent: Friday, April 23, 2010 1:16 AM > To: codec@ietf.org > Subject: Re: [codec] #16: Multicast? > > By the time the BlueTooth Special Interest Group will have adopted a > future IETF codec standard, Moore's law will surely have multiplied > CPU resources in the BT device by one order of magnitude..? Not sure > it makes sense to apply today's BT constraints to tomorrow's codec. > > I'm not even convinced BlueTooth is a relevant use case for an > Internet codec. BT devices are audio devices more than VoIP end > points: BT always connects to the Internet through another device. > You could simply first decode incoming packets and send PCM data to > the BT device, or use a high-quality/high-bitrate codec like G.722. > The requirements for BT devices and the Internet are just too > different. Similarly, GSM phones use AMR on the network side and a > different codec towards the BT device. The required transcoding > causes no quality problems because BT supports high bitrates. > > best, > koen. > > > Quoting Raymond (Juin-Hwey) Chen: > >> Hi Christian, >> >> My comments about your question of CODEC requirements are in-line. >> >> Raymond >> >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >> Behalf Of Christian Hoene >> Sent: Wednesday, April 21, 2010 12:27 PM >> To: 'stephen botzko' >> Cc: codec@ietf.org >> Subject: Re: [codec] #16: Multicast? >> >> Hi, >> >> if we take those two scenarios (high quality and scalable >> teleconferencing), what are then the CODEC requirements? >> >> High quality: >> >> - Quite the same requirement as an end-to-end audio >> transmission: high quality and low latency. >> [Raymond]: High quality is a given, but I would like to emphasize >> the importance of low latency. >> (1) It is well-known that the longer the latency, the lower the >> perceived quality of the communication link. The E-model in the >> ITU-T Recommendation G.107 models such communication quality in >> MOS_cqe, which among other things depends on the so-called "delay >> impairment factor" Id. Basically, MOS_cqe is a monotonically >> decreasing function of increasing latency, and beyond about 150 ms >> one-way delay, the perceived quality of the communication link drops >> rapidly with further delay increase. >> (2) The lower the latency, the less audible the echo, and thus the >> lower the required echo return loss. Hence, lower latency means >> easier echo control and simpler echo canceller, and as people >> already mentioned previously, below a certain delay, an echo is >> simply perceived as a harmless side-tone and no echo canceller is >> needed. It seems to me that echo control in conference calls is more >> difficult than in point-to-point calls. While I hardly ever heard >> echoes in domestic point-to-point calls, in my experience with >> conference calls at work, even with the G.711 codec (which has >> almost no delay), sometimes I still hear echoes (I just heard >> another one this afternoon). If a relatively long-delay IETF codec >> is used, the echo control will be even more problematic. >> (3) In normal phone calls or conference calls, people routinely have >> a need to interrupt each other, but beyond a certain point, long >> latency makes it very difficult for people to interrupt each other >> on the call. This is because when you try to interrupt another >> person, that person doesn't hear your interruption until a certain >> time later, so he keeps talking, but when you hear that he did not >> stop talking when you interrupted, you stop; then, he hears your >> interruption, so he stops. When you hear he stops, you start talking >> again, but then he also hears you stopped (due to the long delay), >> so he also starts talking again. The net result is that with a long >> latency, when you try to interrupt him, you and he end up stopping >> and starting at roughly the same time for a few cycles, making it >> difficult to interrupt each other. >> (4) We need to keep in mind that the IETF codec may not be the only >> codec involved in a phone call or a conference call. We cannot >> assume that all conference call participants will be using a >> computer to conduct the call. Not only do people use cell phones for >> point-to-point phone calls, they also often use cell phones to call >> in to conference calls. The one-way delay for a cell phone call >> through one carriers network is typically around 80 to 110 ms. A >> call from a cell phone in a carrier network to another cell phone in >> a different type of carrier network can easily double this delay to >> 160 ~ 220 ms and makes the total one-way delay already far exceeding >> the 150 ms mentioned in (1) above. Any coding delay added by the >> IETF codec will be on top of that long delay, and such coding delay >> will be applied twice when both cell phones call through the IETF >> codec to a conference bridge. Even without the IETF codec delay, >> when I previously called from a Verizon cell phone to an AT&T cell >> phone, I already experienced the problem mentioned in (3) sometimes. >> If the IETF codec has a relatively long delay, adding two times the >> IETF codec one-way delay to the already long delay of 160 ~ 220 ms >> will make the situation much worse. Even if just one cell phone is >> involved in a conference call, adding twice the one-way delay of a >> relatively long-delay IETF codec can still easily push the total >> one-way delay beyond 150 ms. >> To summarize, my point is that to help reduce potential echo >> problems and to ensure a high-quality experience in such a >> conference call, the IETF codec should have a delay as low as >> possible while maintaining good enough speech quality and a >> reasonable bit-rate. >> >> - Maybe additionally: variable bit rate encoding to achieve >> a multiplexing gain at the receiver >> >> - and thus, a fast control loop to cope with variable >> bitrates on transmission paths. >> >> - Maybe stereo/multichannel support to send the spatial >> audio to the headphone or loudspeakers. >> >> Scalable: >> >> - Efficient encoding/transcoding for multiple different >> qualities (at the conference bridge) >> [Raymond]: I am not sure whether by "efficient", you meant coding >> efficiency or computational efficiency. In any case, I would like >> to take this opportunity to express my view that although codec >> complexity isn't much of an issue for PC-to-PC calls where there are >> GHz of processing power available, the codec complexity is an >> important issue in certain application scenarios. The following are >> just some examples. >> 1) If a conference bridge has to decode a large number of voice >> channels, mix, and re-encode, and if compressed-domain mixing cannot >> be done (which is usually the case), then it is important to keep >> the decoder complexity low. >> 2) In topology b) of your other email >> (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, >> or VoIP gateway, often has to encode and decode thousands of voice >> channels in a single box, so not only the computational complexity, >> but also the per-instance RAM size requirement of the codec become >> very important for achieving high channel density in the gateway. >> 3) Many telephone terminal devices at the edge of the Internet use >> embedded processors with limited processing power, and the >> processors also have to handle many tasks other than speech coding. >> If the IETF codec complexity is too high, some of such devices may >> not have sufficient processing power to run it. Even if the codec >> can fit, some battery-powered mobile devices may prefer to run a >> lower-complexity codec to reduce power consumption and battery >> drain. For example, even if you make a Internet phone call from a >> computer, you may like the convenience of using a Bluetooth headset >> that allows you to walk around a bit and have hands-free operation. >> Currently most Bluetooth headsets have small form factors with a >> tiny battery. This puts a severe constraint on power consumption. >> Bluetooth headset chips typically have very limited processing >> capability, and it has to handle many other tasks such as echo >> cancellation and noise reduction. There is just not enough >> processing power to handle a relatively high-complexity codec. Most >> BT headsets today relies on the extremely low-complexity, >> hardware-based CVSD codec at 64 kb/s to transmit narrowband voice, >> but CVSD has audible coding noise, so it degrades the overall audio >> quality. If the IETF codec has low enough complexity, it would be >> possible to directly encode and decode the IETF codec bit-stream at >> the BT headset, thus avoiding the quality degradation of CVSD >> transcoding. >> In summary, my point is that the IETF codec should attempt to >> achieve a codec complexity as low as possible in both MHz >> consumption and RAM size requirement while maintaining good enough >> speech quality. >> >> - The control loop must not react (fast) because >> (multicast) group communication requires to encode at low quality >> anyhow. >> >> - Receiver side activity detection for music and voice >> having low complexity (for the conference bridge) >> >> - Efficient mixing of two to four(?) active flows (is this >> achievable without the complete process of decoding and encoding >> again?) >> >> Are any teleconferencing requirements missing? >> >> Christian >> >> >> >> >> --------------------------------------------------------------- >> Dr.-Ing. Christian Hoene >> Interactive Communication Systems (ICS), University of T=FCbingen >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >> http://www.net.uni-tuebingen.de/ >> >> From: stephen botzko [mailto:stephen.botzko@gmail.com] >> Sent: Wednesday, April 21, 2010 8:19 PM >> To: Christian Hoene >> Cc: codec@ietf.org >> Subject: Re: [codec] #16: Multicast? >> >> Inline >> On Wed, Apr 21, 2010 at 1:27 PM, Christian Hoene >> > wrote: >> Hi Stephen, >> >> not too bad. You answered faster than the mailing list distributes... >> Not sure how that happened! >> >> Comments inline: >> >> >> From: stephen botzko >> [mailto:stephen.botzko@gmail.com] >> Sent: Wednesday, April 21, 2010 7:10 PM >> To: Christian Hoene >> Cc: codec@ietf.org >> >> Subject: Re: [codec] #16: Multicast? >> >> I agree there are lots of use cases. >> >> >> Though I don't see why high quality has to be given up in order to >> be scalable. >> CH: These are just experiences from our lab. A spatial audio >> conference server including the acoustic 3D sound rendering needs a >> LOT of processing power. In the end, we have to remain realistic. >> Processing power is always limited thus if we need a lot then we >> cannot serve many clients. >> Also, I am not sure why you think central mixing is more scalable >> than multicast (or why you think it is lower quality either). >> CH: With multicast, you need N times 1:N multicast distribution >> trees (somewhat small tan O(n)=3Dn=B2). With central mixing you need N >> times 2 transmission paths (O(n)=3Dn). Also, this distributed mixing >> you need N times the mixing at each client. With centralized, you >> can live with one mixing for all (and some tricks for serving the >> talkers). >> I agree you need more distribution trees for multicast if you allow >> every site to talk. There is a corresponding benefit, since there is >> no central choke point and also less bandwidth on shared WAN links. >> >> In the distributed case, you don't need an N-way mixer at each >> client, and you also don't need to continuously receive payload on >> all N streams at each client either. In practice you can cap N at a >> relatively small number (in the 3-8 range) no matter how large the >> conference gets. In a large conference, you can even choose to drop >> your comfort noise if you are receiving two or more streams, and >> just send enough to keep your firewall pinhole open. This is all >> assuming a suitable voice activity measure in the RTP packet. Of >> course in the worst case, you will receive all N streams. >> >> Cheers, >> Christian >> >> Stephen Botzko >> On Wed, Apr 21, 2010 at 12:58 PM, Christian Hoene >> > wrote: >> Hi, >> >> the teleconferencing issue gets complex. I am trying to compile the >> different requirements that have been mentioned on this list. >> >> - low complexity (with just one active speaker) vs. >> multiple speaker mixing vs. spatial audio/stereo mixing >> >> - centralized vs. distributed >> >> - few participants vs. hundreds of listeners and talkers >> >> - individual distribution of audio streams vs. IP multicast >> or RTP group communication >> >> - efficient encoding of multiple streams having the same >> content (but different quality). >> >> - I bet I missed some. >> >> To make things easier, why not to split the teleconferencing >> scenario in two: High quality and Scalable? >> >> The high quality scenario, intended for a low number of users, could >> have features like >> >> - Distributed processing and mixing >> >> - High computational resources to support spatial audio >> mixing (at the receiver) and multiple encodings of the same audio >> stream at different qualities (at the sender) >> >> - Enough bandwidth to allow direct N to N transmissions of >> audio streams (no multicast or group communication). This would be >> good for the latency, too. >> >> The scalable scenario is the opposite: >> >> - Central processing and mixing for many participants . >> >> - N to 1 and 1 to N communication using efficient >> distribution mechanisms (RTP group communication and IP multicast). >> >> - Low complexity mixing of many using tricks like VAD, >> encoding at lowest rate to support many receivers having different >> paths, you name it... >> >> Then, we need not to compare apples with oranges all the time. >> >> Christian >> >> --------------------------------------------------------------- >> Dr.-Ing. Christian Hoene >> Interactive Communication Systems (ICS), University of T=FCbingen >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 >> http://www.net.uni-tuebingen.de/ >> >> From: codec-bounces@ietf.org >> [mailto:codec-bounces@ietf.org] On >> Behalf Of stephen botzko >> Sent: Wednesday, April 21, 2010 4:34 PM >> To: Colin Perkins >> Cc: trac@tools.ietf.org; >> codec@ietf.org >> Subject: Re: [codec] #16: Multicast? >> >> in-line >> >> Stephen Botzko >> On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins >> > wrote: >> On 21 Apr 2010, at 12:20, Marshall Eubanks wrote: >> On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote: >> On 21 Apr 2010, at 10:42, codec issue tracker wrote: >> #16: Multicast? >> ------------------------------------+---------------------------------- >> Reporter: hoene@... | Owner: >> Type: enhancement | Status: new >> Priority: trivial | Milestone: >> Component: requirements | Version: >> Severity: Active WG Document | Keywords: >> ------------------------------------+---------------------------------- >> The question arrose whether the interactive CODEC MUST support >> multicast in addition to teleconferencing. >> >> On 04/13/2010 11:35 AM, Christian Hoene wrote: >> P.S. On the same note, does anybody here cares about using this >> CODEC with multicast? Is there a single commercial multicast voice >> deployment? From what I've seen all multicast does is making IETF >> voice standards harder to understand or implement. >> >> I think that would be a mistake to ignore multicast - not because of >> multicast itself, but because of Xcast (RFC 5058) which is a >> promising technology to replace centralized conference bridges. >> >> Regarding multicast: >> >> I think we shall start at user requirements and scenarios. >> Teleconference (including mono or spatial audio) might be good >> starting point. Virtual environments like second live would require >> multicast communication, too. If the requirements of these scenarios >> are well understand, we can start to talk about potential solutions >> like IP multicast, Xcast or conference bridges. >> >> >> RTP is inherently a group communication protocol, and any codec >> designed for use with RTP should consider operation in various >> different types of group communication scenario (not just >> multicast). RFC 5117 is a good place to start when considering the >> different types of topology in which RTP is used, and the possible >> placement of mixing and switching functions which the codec will >> need to work with. >> >> It is not clear to me what supporting multicast would entail here. >> If this is a codec over RTP, then what is to stop it from being >> multicast ? >> >> Nothing. However group conferences implemented using multicast >> require end system mixing of potentially large numbers of active >> audio streams, whereas those implemented using conference bridges do >> the mixing in a single central location, and generally suppress all >> but one speaker. The differences in mixing and the number of >> simultaneous active streams that might be received potentially >> affect the design of the codec. >> >> Conference bridges with central mixing almost always mix multiple >> speakers. As you add more streams into the mix, you reduce the >> chance of missing onset speech and interruptions, but raise the >> noise floor. So even if complexity is not a consideration, there is >> value in gating the mixer (instead of always doing a full mix-minus). >> >> More on point, compressed domain mixing and easy detection of VAD >> have both been advocated on these lists, and both simplify the >> large-scale mixing problem. >> >> -- >> Colin Perkins >> http://csperkins.org/ >> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> >> >> >> > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > From stephen.botzko@gmail.com Fri Apr 30 04:35:44 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C4EC28C228 for ; Fri, 30 Apr 2010 04:35:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.852 X-Spam-Level: X-Spam-Status: No, score=-0.852 tagged_above=-999 required=5 tests=[AWL=-0.854, BAYES_50=0.001, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nguRXAn4GGWl for ; Fri, 30 Apr 2010 04:35:39 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 1BB2528C214 for ; Fri, 30 Apr 2010 04:35:05 -0700 (PDT) Received: by wwb24 with SMTP id 24so75639wwb.31 for ; Fri, 30 Apr 2010 04:34:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=BWS+5UTS+RBQe2NihxIeaB5pdxCvAcfT7A0b3BzK2+A=; b=BwgG5gypGfdInVIXIlisqI7EUHGTOyOzF7nxaIa4yHT9pZw+NXiBVv82BP4sxyM9F0 jVYK23L4Fw+bV0gc3zd2bj0fmPzZKV6/73gUaptPPe7FHDaRO5bkaYmMXpXn6GIAn1Rg mKp+NtpHv/1qxKHH6CBQixfC0cPRxpWID3Pr0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CRgW4bg56x7HF6ZdGS/2+LQFzbhlmSzOm5v9yRYj+hO9vx+tEDWhahLD5pyXmFjHG2 8nLX0xpcnA8/QEd42zeukF4XI0f161Ko3va8FrJwiSfLb7qLbZ98Z6Avgn6lhb8LnXsh nQqVlQ/ogV+BWBGowu9lpNCauc7TfxXyQ5Fwk= MIME-Version: 1.0 Received: by 10.216.86.7 with SMTP id v7mr4078154wee.191.1272627288513; Fri, 30 Apr 2010 04:34:48 -0700 (PDT) Received: by 10.216.28.139 with HTTP; Fri, 30 Apr 2010 04:34:48 -0700 (PDT) In-Reply-To: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <20100423011559.20246ayxdicd9vzz@mail.skype.net> <20100425040049.69785q4ih4vowtep@mail.skype.net> Date: Fri, 30 Apr 2010 07:34:48 -0400 Message-ID: From: stephen botzko To: "Raymond (Juin-Hwey) Chen" Content-Type: multipart/alternative; boundary=0016e6d97670769f34048572a1c5 Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? (Bluetooth) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 11:35:44 -0000 --0016e6d97670769f34048572a1c5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Though the Bluetooth angle is interesting, it is clearly out-of-scope for this WG. Of course Bluetooth SIG could pick up CODEC later on if they think it meets their requirements. Stephen Botzko On Thu, Apr 29, 2010 at 6:14 PM, Raymond (Juin-Hwey) Chen < rchen@broadcom.com> wrote: > Hi Koen, > > For some reason the SPAM filter accidentally routed your email below (sen= t > last Sunday) to my junk email folder and I just saw it. Sorry about the > delay of my response. > > I agree that there are some fundamental differences in the requirements f= or > cellular codecs and Bluetooth codecs which caused the codecs in these two > types of devices to each go their own way. However, these differences ar= e > (or can be) substantially smaller between an Internet codec and Bluetooth > codecs, so I think it is easier for Internet devices and Bluetooth device= s > to use the same codec to avoid the additional delay and coding distortion= of > transcoding. > > (1) Royalty-free requirement: > Cellular codecs are usually royalty-bearing, and that's acceptable in the > cellular world. Not so with Bluetooth. Bluetooth devices are meant to b= e > simple and low cost. As such, Bluetooth SIG basically only wants to > standardize royalty-free technologies. That's an important reason why th= ey > picked the CVSD codec, a royalty-free old technology of 1970. We are try= ing > to make the IETF codec royalty-free, so in this regard this goal is > consistent with the Bluetooth SIG's royalty-free requirement for codec. > > (2) Bit-rate requirement: > Cellular radio spectrum is a limited, fixed resource that doesn't change > with time, and cellular operators spent billions of dollars in radio > spectrum auctions. Thus, it is extremely important for cellular codecs to > have bit-rates as low as possible, with an average bit-rate often going > below 1 bit/sample, to maximize the number of cellular subscribers a give= n > amount of radio spectrum can support. In contrast, the bit-rate is not > nearly as big a concern for Bluetooth. Initially Bluetooth SIG picked the > relatively high-bit-rate 64 kb/s CVSD narrowband codec (8 bits/sample) fo= r > its simplicity and royalty-free nature among other things. Since the spe= eds > of the Internet back bone and access networks keep growing with time, the > bit-rate of an Internet codec is also not nearly as big a concern as in > cellular codecs, and an Internet codec around 2 bits/sample can have bett= er > trade-offs (e.g. higher quality, lower delay, and lower complexity) for > Internet applications than what cellular codecs can provide. Incidentall= y, > Bluetooth SIG is moving toward 4 bits/sample. As you can see, in terms o= f > the bit-rate requirement, an Internet codec is much closer to Bluetooth > codecs than cellular codecs are. > > (3) Complexity requirement: > Bluetooth headsets have much lower processing power and much smaller > batteries than cell phones. The complexity of cellular codecs, typically = in > the range of 20 to 40 MHz on a DSP, is too high to fit most Bluetooth > headsets. However, unlike cell phones and Bluetooth headsets where each i= s a > specific type of device with a relatively narrow range of device complexi= ty, > Internet voice/audio applications can potentially encompass a large varie= ty > of different device types, from desktop computers at the high end with > = 3 > GHz multi-core CPU to IP phones and possibly even Bluetooth headsets at t= he > low end with a processor of only a few tens of MHz. It is up to the IETF > codec WG how we want the complexity of the IETF codec to be. We can > standardize just one codec mode that works well for computer-to-computer > calls but can't fit in low-end devices, or we can keep that mode but also > have a low-complexity mode that can be implemented in low-end devices. > Frankly, I think the second approach makes much more sense since it allo= ws > many more devices to benefit from the IETF codec and enables the large > number of Bluetooth headset users to avoid the additional distortion and > delay associated with transcoding when making Internet calls. > > (4) Delay requirement: Due to the need for cellular codecs to achieve > bit-rates as low as possible, they sacrificed the coding delay and used a= 20 > ms frame size, because using a 10 or 5 ms frame size would increase the > bit-rate for a given level of speech quality. On the other hand, a > Bluetooth headset needs to have a low delay since its delay is added to t= he > already long cell phone delay. For the IETF codec, again it is up to the > codec WG to decide what kind of codec delay we want, and again I think it > makes sense to have a higher-delay, higher bit-rate efficiency mode for > bit-rate-sensitive applications and another low-delay mode for > delay-sensitive applications, since one size doesn't fit all. If the IET= F > codec delay is forced to be one size, the resulting codec will be > (potentially very) suboptimal for some applications. > > You wrote: > > Do you think it's realistic for us to come up with a design that > > fulfills the needs of both worlds? > > With a one-size-fit-all approach, probably not, but with a multi-mode > approach, then I think so. > > Best Regards, > > Raymond > > -----Original Message----- > From: Koen Vos [mailto:koen.vos@skype.net] > Sent: Sunday, April 25, 2010 4:01 AM > To: Raymond (Juin-Hwey) Chen > Cc: codec@ietf.org > Subject: RE: [codec] #16: Multicast? (Bluetooth) > > Hi Raymond, > > You seem to suggest that the IETF Internet codec should fit Bluetooth > requirements in order to enable transcoding-free operation all the way > from the Internet, through the Internet-connected device, to the BT > wireless audio device. > > A similar argument would hold for ITU-T cellular codecs: AMR-WB and > G.718 could have been designed with BT as an application. In reality, > these codecs have very little in common with BT codecs, because of the > vastly different requirements in terms of > - complexity > - memory footprint > - bitrate > - scalability > - bit error robustness > - packet loss robustness. > > Do you think it's realistic for us to come up with a design that > fulfills the needs of both worlds? > > The alternative is to separately design codecs for Internet > applications and BT devices, and continue the practice of transcoding > on the Internet-connected device. That would have a better chance of > maximizing quality in all scenarios. > > best, > koen. > > > Quoting "Raymond (Juin-Hwey) Chen": > > > Hi Koen, > > > > Responding to your earlier email about Bluetooth headset application: > > > > (1) Although BT SIG standardization is a preferred route, it is > > technically feasible to negotiate and use a non-Bluetooth-SIG codec. > > > > (2) Someone familiar with BT SIG told me that it would probably take > > only 6 months to add an optional codec to the BT SIG spec and 12 to > > 18 months to add a mandatory codec. > > > > (3) The IETF codec is scheduled to be finalized in 14 months and > > submitted to IESG in 18 months. Even if we take the BT SIG route > > and take 6 to 18 months there. The total time of 2 to 3 years from > > now means the Moore's Law would only increase the CPU resources 2X > > to 3X, and definitely no more than 4X max, not 10X. > > > > (4) Most importantly, guess what, in the last several years the > > Bluetooth headset chips have been growing its processing power at a > > MUCH, MUCH slower rate than what the Moore's Law says it should. > > Sometimes they did not increase the speed at all for years. The > > reasons? The ASP (average sale price) of Bluetooth chips plummeted > > very badly, making it unattractive to invest significant resources > > to make them significantly faster. Also, for low-end and mid-end BT > > headsets, the BT chips were often considered "good enough" and there > > wasn't a strong drive to increase the computing resources. In > > addition, the BT headsets got smaller over the last few years; the > > corresponding reduction in battery size required a reduction in > > power consumption, which also limited how fast the processor speed > > could grow. In the next several years, it is highly likely that the > > computing capabilities of Bluetooth headset chips will continue to > > grow at a rate substantially below what's predicted by the Moore's > > Law. > > > > (5) Although Bluetooth supports G.711 as an optional codec, > > basically no one uses it because it is too sensitive to bit errors. > > Essentially all the BT mono headsets on the market today are > > narrowband (8 kHz sampling) headsets using CVSD. There isn't any > > real wideband support yet, so your comment about G.722 doesn't > > apply. Even after wideband-capable BT headsets come out, for many > > years to come the majority of the BT headsets (especially mid- to > > low-end) will still be narrowband only, running only CVSD. Hence, > > the quality degradation of the CVSD transcoding is real and will be > > with us for quite a while, so it is desirable for the IETF codec to > > have a low-complexity mode that can directly run on the BT headsets > > to avoid the quality degradation of CVSD when using BT headsets to > > make Internet phone calls. > > > > (6) Even if you could use G.711 or G.722 in the BT headsets, they > > both operate at 64 kb/s. A low-complexity mode of the IETF codec > > can operate at half or one quarter of that bit-rate. This will help > > conserve BT headsets' radio power because of the lower transmit duty > > cycle. It will also help the Bluetooth + WiFi co-existence > > technologies. > > > > (7) Already a lot of people are used to using Bluetooth headsets to > > make phone calls today. If they have a choice, many of these people > > will also want to use Bluetooth headsets to make Internet phone > > calls, not only through computers, but also through smart phones > > connected to WiFi or cellular networks. As more and more states and > > countries pass laws to ban the use of cell phones that are not in > > hands-free mode while driving, the number of Bluetooth headset users > > will only increase with time, and many of them will want to make > > Internet-based phone calls. > > > > Given all the above, I would argue that Bluetooth headset is a very > > relevant application that the IETF codec should address with a > > low-complexity mode. > > > > Best Regards, > > > > Raymond > > > > -----Original Message----- > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > > Behalf Of Koen Vos > > Sent: Friday, April 23, 2010 1:16 AM > > To: codec@ietf.org > > Subject: Re: [codec] #16: Multicast? > > > > By the time the BlueTooth Special Interest Group will have adopted a > > future IETF codec standard, Moore's law will surely have multiplied > > CPU resources in the BT device by one order of magnitude..? Not sure > > it makes sense to apply today's BT constraints to tomorrow's codec. > > > > I'm not even convinced BlueTooth is a relevant use case for an > > Internet codec. BT devices are audio devices more than VoIP end > > points: BT always connects to the Internet through another device. > > You could simply first decode incoming packets and send PCM data to > > the BT device, or use a high-quality/high-bitrate codec like G.722. > > The requirements for BT devices and the Internet are just too > > different. Similarly, GSM phones use AMR on the network side and a > > different codec towards the BT device. The required transcoding > > causes no quality problems because BT supports high bitrates. > > > > best, > > koen. > > > > > > Quoting Raymond (Juin-Hwey) Chen: > > > >> Hi Christian, > >> > >> My comments about your question of CODEC requirements are in-line. > >> > >> Raymond > >> > >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > >> Behalf Of Christian Hoene > >> Sent: Wednesday, April 21, 2010 12:27 PM > >> To: 'stephen botzko' > >> Cc: codec@ietf.org > >> Subject: Re: [codec] #16: Multicast? > >> > >> Hi, > >> > >> if we take those two scenarios (high quality and scalable > >> teleconferencing), what are then the CODEC requirements? > >> > >> High quality: > >> > >> - Quite the same requirement as an end-to-end audio > >> transmission: high quality and low latency. > >> [Raymond]: High quality is a given, but I would like to emphasize > >> the importance of low latency. > >> (1) It is well-known that the longer the latency, the lower the > >> perceived quality of the communication link. The E-model in the > >> ITU-T Recommendation G.107 models such communication quality in > >> MOS_cqe, which among other things depends on the so-called "delay > >> impairment factor" Id. Basically, MOS_cqe is a monotonically > >> decreasing function of increasing latency, and beyond about 150 ms > >> one-way delay, the perceived quality of the communication link drops > >> rapidly with further delay increase. > >> (2) The lower the latency, the less audible the echo, and thus the > >> lower the required echo return loss. Hence, lower latency means > >> easier echo control and simpler echo canceller, and as people > >> already mentioned previously, below a certain delay, an echo is > >> simply perceived as a harmless side-tone and no echo canceller is > >> needed. It seems to me that echo control in conference calls is more > >> difficult than in point-to-point calls. While I hardly ever heard > >> echoes in domestic point-to-point calls, in my experience with > >> conference calls at work, even with the G.711 codec (which has > >> almost no delay), sometimes I still hear echoes (I just heard > >> another one this afternoon). If a relatively long-delay IETF codec > >> is used, the echo control will be even more problematic. > >> (3) In normal phone calls or conference calls, people routinely have > >> a need to interrupt each other, but beyond a certain point, long > >> latency makes it very difficult for people to interrupt each other > >> on the call. This is because when you try to interrupt another > >> person, that person doesn't hear your interruption until a certain > >> time later, so he keeps talking, but when you hear that he did not > >> stop talking when you interrupted, you stop; then, he hears your > >> interruption, so he stops. When you hear he stops, you start talking > >> again, but then he also hears you stopped (due to the long delay), > >> so he also starts talking again. The net result is that with a long > >> latency, when you try to interrupt him, you and he end up stopping > >> and starting at roughly the same time for a few cycles, making it > >> difficult to interrupt each other. > >> (4) We need to keep in mind that the IETF codec may not be the only > >> codec involved in a phone call or a conference call. We cannot > >> assume that all conference call participants will be using a > >> computer to conduct the call. Not only do people use cell phones for > >> point-to-point phone calls, they also often use cell phones to call > >> in to conference calls. The one-way delay for a cell phone call > >> through one carriers network is typically around 80 to 110 ms. A > >> call from a cell phone in a carrier network to another cell phone in > >> a different type of carrier network can easily double this delay to > >> 160 ~ 220 ms and makes the total one-way delay already far exceeding > >> the 150 ms mentioned in (1) above. Any coding delay added by the > >> IETF codec will be on top of that long delay, and such coding delay > >> will be applied twice when both cell phones call through the IETF > >> codec to a conference bridge. Even without the IETF codec delay, > >> when I previously called from a Verizon cell phone to an AT&T cell > >> phone, I already experienced the problem mentioned in (3) sometimes. > >> If the IETF codec has a relatively long delay, adding two times the > >> IETF codec one-way delay to the already long delay of 160 ~ 220 ms > >> will make the situation much worse. Even if just one cell phone is > >> involved in a conference call, adding twice the one-way delay of a > >> relatively long-delay IETF codec can still easily push the total > >> one-way delay beyond 150 ms. > >> To summarize, my point is that to help reduce potential echo > >> problems and to ensure a high-quality experience in such a > >> conference call, the IETF codec should have a delay as low as > >> possible while maintaining good enough speech quality and a > >> reasonable bit-rate. > >> > >> - Maybe additionally: variable bit rate encoding to achieve > >> a multiplexing gain at the receiver > >> > >> - and thus, a fast control loop to cope with variable > >> bitrates on transmission paths. > >> > >> - Maybe stereo/multichannel support to send the spatial > >> audio to the headphone or loudspeakers. > >> > >> Scalable: > >> > >> - Efficient encoding/transcoding for multiple different > >> qualities (at the conference bridge) > >> [Raymond]: I am not sure whether by "efficient", you meant coding > >> efficiency or computational efficiency. In any case, I would like > >> to take this opportunity to express my view that although codec > >> complexity isn't much of an issue for PC-to-PC calls where there are > >> GHz of processing power available, the codec complexity is an > >> important issue in certain application scenarios. The following are > >> just some examples. > >> 1) If a conference bridge has to decode a large number of voice > >> channels, mix, and re-encode, and if compressed-domain mixing cannot > >> be done (which is usually the case), then it is important to keep > >> the decoder complexity low. > >> 2) In topology b) of your other email > >> (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, > >> or VoIP gateway, often has to encode and decode thousands of voice > >> channels in a single box, so not only the computational complexity, > >> but also the per-instance RAM size requirement of the codec become > >> very important for achieving high channel density in the gateway. > >> 3) Many telephone terminal devices at the edge of the Internet use > >> embedded processors with limited processing power, and the > >> processors also have to handle many tasks other than speech coding. > >> If the IETF codec complexity is too high, some of such devices may > >> not have sufficient processing power to run it. Even if the codec > >> can fit, some battery-powered mobile devices may prefer to run a > >> lower-complexity codec to reduce power consumption and battery > >> drain. For example, even if you make a Internet phone call from a > >> computer, you may like the convenience of using a Bluetooth headset > >> that allows you to walk around a bit and have hands-free operation. > >> Currently most Bluetooth headsets have small form factors with a > >> tiny battery. This puts a severe constraint on power consumption. > >> Bluetooth headset chips typically have very limited processing > >> capability, and it has to handle many other tasks such as echo > >> cancellation and noise reduction. There is just not enough > >> processing power to handle a relatively high-complexity codec. Most > >> BT headsets today relies on the extremely low-complexity, > >> hardware-based CVSD codec at 64 kb/s to transmit narrowband voice, > >> but CVSD has audible coding noise, so it degrades the overall audio > >> quality. If the IETF codec has low enough complexity, it would be > >> possible to directly encode and decode the IETF codec bit-stream at > >> the BT headset, thus avoiding the quality degradation of CVSD > >> transcoding. > >> In summary, my point is that the IETF codec should attempt to > >> achieve a codec complexity as low as possible in both MHz > >> consumption and RAM size requirement while maintaining good enough > >> speech quality. > >> > >> - The control loop must not react (fast) because > >> (multicast) group communication requires to encode at low quality > >> anyhow. > >> > >> - Receiver side activity detection for music and voice > >> having low complexity (for the conference bridge) > >> > >> - Efficient mixing of two to four(?) active flows (is this > >> achievable without the complete process of decoding and encoding > >> again?) > >> > >> Are any teleconferencing requirements missing? > >> > >> Christian > >> > >> > >> > >> > >> --------------------------------------------------------------- > >> Dr.-Ing. Christian Hoene > >> Interactive Communication Systems (ICS), University of T=FCbingen > >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > >> http://www.net.uni-tuebingen.de/ > >> > >> From: stephen botzko [mailto:stephen.botzko@gmail.com] > >> Sent: Wednesday, April 21, 2010 8:19 PM > >> To: Christian Hoene > >> Cc: codec@ietf.org > >> Subject: Re: [codec] #16: Multicast? > >> > >> Inline > >> On Wed, Apr 21, 2010 at 1:27 PM, Christian Hoene > >> > wrote: > >> Hi Stephen, > >> > >> not too bad. You answered faster than the mailing list distributes... > >> Not sure how that happened! > >> > >> Comments inline: > >> > >> > >> From: stephen botzko > >> [mailto:stephen.botzko@gmail.com] > >> Sent: Wednesday, April 21, 2010 7:10 PM > >> To: Christian Hoene > >> Cc: codec@ietf.org > >> > >> Subject: Re: [codec] #16: Multicast? > >> > >> I agree there are lots of use cases. > >> > >> > >> Though I don't see why high quality has to be given up in order to > >> be scalable. > >> CH: These are just experiences from our lab. A spatial audio > >> conference server including the acoustic 3D sound rendering needs a > >> LOT of processing power. In the end, we have to remain realistic. > >> Processing power is always limited thus if we need a lot then we > >> cannot serve many clients. > >> Also, I am not sure why you think central mixing is more scalable > >> than multicast (or why you think it is lower quality either). > >> CH: With multicast, you need N times 1:N multicast distribution > >> trees (somewhat small tan O(n)=3Dn=B2). With central mixing you need = N > >> times 2 transmission paths (O(n)=3Dn). Also, this distributed mixing > >> you need N times the mixing at each client. With centralized, you > >> can live with one mixing for all (and some tricks for serving the > >> talkers). > >> I agree you need more distribution trees for multicast if you allow > >> every site to talk. There is a corresponding benefit, since there is > >> no central choke point and also less bandwidth on shared WAN links. > >> > >> In the distributed case, you don't need an N-way mixer at each > >> client, and you also don't need to continuously receive payload on > >> all N streams at each client either. In practice you can cap N at a > >> relatively small number (in the 3-8 range) no matter how large the > >> conference gets. In a large conference, you can even choose to drop > >> your comfort noise if you are receiving two or more streams, and > >> just send enough to keep your firewall pinhole open. This is all > >> assuming a suitable voice activity measure in the RTP packet. Of > >> course in the worst case, you will receive all N streams. > >> > >> Cheers, > >> Christian > >> > >> Stephen Botzko > >> On Wed, Apr 21, 2010 at 12:58 PM, Christian Hoene > >> > wrote: > >> Hi, > >> > >> the teleconferencing issue gets complex. I am trying to compile the > >> different requirements that have been mentioned on this list. > >> > >> - low complexity (with just one active speaker) vs. > >> multiple speaker mixing vs. spatial audio/stereo mixing > >> > >> - centralized vs. distributed > >> > >> - few participants vs. hundreds of listeners and talkers > >> > >> - individual distribution of audio streams vs. IP multicast > >> or RTP group communication > >> > >> - efficient encoding of multiple streams having the same > >> content (but different quality). > >> > >> - I bet I missed some. > >> > >> To make things easier, why not to split the teleconferencing > >> scenario in two: High quality and Scalable? > >> > >> The high quality scenario, intended for a low number of users, could > >> have features like > >> > >> - Distributed processing and mixing > >> > >> - High computational resources to support spatial audio > >> mixing (at the receiver) and multiple encodings of the same audio > >> stream at different qualities (at the sender) > >> > >> - Enough bandwidth to allow direct N to N transmissions of > >> audio streams (no multicast or group communication). This would be > >> good for the latency, too. > >> > >> The scalable scenario is the opposite: > >> > >> - Central processing and mixing for many participants . > >> > >> - N to 1 and 1 to N communication using efficient > >> distribution mechanisms (RTP group communication and IP multicast). > >> > >> - Low complexity mixing of many using tricks like VAD, > >> encoding at lowest rate to support many receivers having different > >> paths, you name it... > >> > >> Then, we need not to compare apples with oranges all the time. > >> > >> Christian > >> > >> --------------------------------------------------------------- > >> Dr.-Ing. Christian Hoene > >> Interactive Communication Systems (ICS), University of T=FCbingen > >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > >> http://www.net.uni-tuebingen.de/ > >> > >> From: codec-bounces@ietf.org > >> [mailto:codec-bounces@ietf.org] On > >> Behalf Of stephen botzko > >> Sent: Wednesday, April 21, 2010 4:34 PM > >> To: Colin Perkins > >> Cc: trac@tools.ietf.org; > >> codec@ietf.org > >> Subject: Re: [codec] #16: Multicast? > >> > >> in-line > >> > >> Stephen Botzko > >> On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins > >> > wrote: > >> On 21 Apr 2010, at 12:20, Marshall Eubanks wrote: > >> On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote: > >> On 21 Apr 2010, at 10:42, codec issue tracker wrote: > >> #16: Multicast? > >> ------------------------------------+---------------------------------= - > >> Reporter: hoene@... | Owner: > >> Type: enhancement | Status: new > >> Priority: trivial | Milestone: > >> Component: requirements | Version: > >> Severity: Active WG Document | Keywords: > >> ------------------------------------+---------------------------------= - > >> The question arrose whether the interactive CODEC MUST support > >> multicast in addition to teleconferencing. > >> > >> On 04/13/2010 11:35 AM, Christian Hoene wrote: > >> P.S. On the same note, does anybody here cares about using this > >> CODEC with multicast? Is there a single commercial multicast voice > >> deployment? From what I've seen all multicast does is making IETF > >> voice standards harder to understand or implement. > >> > >> I think that would be a mistake to ignore multicast - not because of > >> multicast itself, but because of Xcast (RFC 5058) which is a > >> promising technology to replace centralized conference bridges. > >> > >> Regarding multicast: > >> > >> I think we shall start at user requirements and scenarios. > >> Teleconference (including mono or spatial audio) might be good > >> starting point. Virtual environments like second live would require > >> multicast communication, too. If the requirements of these scenarios > >> are well understand, we can start to talk about potential solutions > >> like IP multicast, Xcast or conference bridges. > >> > >> > >> RTP is inherently a group communication protocol, and any codec > >> designed for use with RTP should consider operation in various > >> different types of group communication scenario (not just > >> multicast). RFC 5117 is a good place to start when considering the > >> different types of topology in which RTP is used, and the possible > >> placement of mixing and switching functions which the codec will > >> need to work with. > >> > >> It is not clear to me what supporting multicast would entail here. > >> If this is a codec over RTP, then what is to stop it from being > >> multicast ? > >> > >> Nothing. However group conferences implemented using multicast > >> require end system mixing of potentially large numbers of active > >> audio streams, whereas those implemented using conference bridges do > >> the mixing in a single central location, and generally suppress all > >> but one speaker. The differences in mixing and the number of > >> simultaneous active streams that might be received potentially > >> affect the design of the codec. > >> > >> Conference bridges with central mixing almost always mix multiple > >> speakers. As you add more streams into the mix, you reduce the > >> chance of missing onset speech and interruptions, but raise the > >> noise floor. So even if complexity is not a consideration, there is > >> value in gating the mixer (instead of always doing a full mix-minus). > >> > >> More on point, compressed domain mixing and easy detection of VAD > >> have both been advocated on these lists, and both simplify the > >> large-scale mixing problem. > >> > >> -- > >> Colin Perkins > >> http://csperkins.org/ > >> > >> > >> > >> _______________________________________________ > >> codec mailing list > >> codec@ietf.org > >> https://www.ietf.org/mailman/listinfo/codec > >> > >> > >> > >> > > > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec > > > > > > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016e6d97670769f34048572a1c5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Though the Bluetooth angle is interesting, it is clearly out-of-scope for t= his WG.=A0

Of course Bluetooth SIG could pick up CODEC later on if = they think it meets their requirements.

Stephen Botzko

On Thu, Apr 29, 2010 at 6:14 PM, Raymond (Juin-Hwey) Chen <rchen@broadcom.com> wrote:
Hi Koen,

For some reason the SPAM filter accidentally routed your email below (sent = last Sunday) to my junk email folder and I just saw it. Sorry about the del= ay of my response.

I agree that there are some fundamental differences in the requirements for= cellular codecs and Bluetooth codecs which caused the codecs in these two = types of devices to each go their own way. =A0However, these differences ar= e (or can be) substantially smaller between an Internet codec and Bluetooth= codecs, so I think it is easier for Internet devices and Bluetooth devices= to use the same codec to avoid the additional delay and coding distortion = of transcoding.

(1) Royalty-free requirement:
Cellular codecs are usually royalty-bearing, and that's acceptable in t= he cellular world. =A0Not so with Bluetooth. =A0Bluetooth devices are meant= to be simple and low cost. =A0As such, Bluetooth SIG basically only wants = to standardize royalty-free technologies. =A0That's an important reason= why they picked the CVSD codec, a royalty-free old technology of 1970. =A0= We are trying to make the IETF codec royalty-free, so in this regard this g= oal is consistent with the Bluetooth SIG's royalty-free requirement for= codec.

(2) Bit-rate requirement:
Cellular radio spectrum is a limited, fixed resource that doesn't chang= e with time, and cellular operators spent billions of dollars in radio spec= trum auctions. Thus, it is extremely important for cellular codecs to have = bit-rates as low as possible, with an average bit-rate often going below 1 = bit/sample, to maximize the number of cellular subscribers a given amount o= f radio spectrum can support. =A0In contrast, the bit-rate is not nearly as= big a concern for Bluetooth. Initially Bluetooth SIG picked the relatively= high-bit-rate 64 kb/s CVSD narrowband codec (8 bits/sample) for its simpli= city and royalty-free nature among other things. =A0Since the speeds of the= Internet back bone and access networks keep growing with time, the bit-rat= e of an Internet codec is also not nearly as big a concern as in cellular c= odecs, and an Internet codec around 2 bits/sample can have better trade-off= s (e.g. higher quality, lower delay, and lower complexity) for Internet app= lications than what cellular codecs can provide. =A0Incidentally, Bluetooth= SIG is moving toward 4 bits/sample. =A0As you can see, in terms of the bit= -rate requirement, an Internet codec is much closer to Bluetooth codecs tha= n cellular codecs are.

(3) Complexity requirement:
Bluetooth headsets have much lower processing power and much smaller batter= ies than cell phones. The complexity of cellular codecs, typically in the r= ange of 20 to 40 MHz on a DSP, is too high to fit most Bluetooth headsets. = However, unlike cell phones and Bluetooth headsets where each is a specific= type of device with a relatively narrow range of device complexity, Intern= et voice/audio applications can potentially encompass a large variety of di= fferent device types, from desktop computers at the high end with > 3 GH= z multi-core CPU to IP phones and possibly even Bluetooth headsets at the l= ow end with a processor of only a few tens of MHz. =A0It is up to the IETF = codec WG how we want the complexity of the IETF codec to be. =A0We can stan= dardize just one codec mode that works well for computer-to-computer calls = but can't fit in low-end devices, or we can keep that mode but also hav= e a low-complexity mode that can be implemented in low-end devices. =A0Fran= kly, I think the second approach makes much more sense since it allows many= more devices to benefit from the IETF codec and enables the large number o= f Bluetooth headset users to avoid the additional distortion and delay asso= ciated with transcoding when making Internet calls.

(4) Delay requirement: Due to the need for cellular codecs to achieve bit-r= ates as low as possible, they sacrificed the coding delay and used a 20 ms = frame size, because using a 10 or 5 ms frame size would increase the bit-ra= te for a given level of speech quality. =A0On the other hand, a Bluetooth h= eadset needs to have a low delay since its delay is added to the already lo= ng cell phone delay. =A0For the IETF codec, again it is up to the codec WG = to decide what kind of codec delay we want, and again I think it makes sens= e to have a higher-delay, higher bit-rate efficiency mode for bit-rate-sens= itive applications and another low-delay mode for delay-sensitive applicati= ons, since one size doesn't fit all. =A0If the IETF codec delay is forc= ed to be one size, the resulting codec will be (potentially very) suboptima= l for some applications.

You wrote:
> Do you think it's realistic for us to come up with a design that > fulfills the needs of both worlds?

With a one-size-fit-all approach, probably not, but with a multi-mode= approach, then I think so.

Best Regards,

Raymond

-----Original Message-----
From: Koen Vos [mailto:koen.vos@skype.net]
Sent: Sunday, April 25, 2010 4:01 AM
To: Raymond (Juin-Hwey) Chen
Cc: codec@ietf.org
Subject: RE: [codec] #16: Multicast= ? (Bluetooth)

Hi Raymond,

You seem to suggest that the IETF Internet codec should fit Bluetooth
requirements in order to enable transcoding-free operation all the way
from the Internet, through the Internet-connected device, to the BT
wireless audio device.

A similar argument would hold for ITU-T cellular codecs: AMR-WB and
G.718 could have been designed with BT as an application. =A0In reality, these codecs have very little in common with BT codecs, because of the
vastly different requirements in terms of
- complexity
- memory footprint
- bitrate
- scalability
- bit error robustness
- packet loss robustness.

Do you think it's realistic for us to come up with a design that
fulfills the needs of both worlds?

The alternative is to separately design codecs for Internet
applications and BT devices, and continue the practice of transcoding
on the Internet-connected device. =A0That would have a better chance of
maximizing quality in all scenarios.

best,
koen.


Quoting "Raymond (Juin-Hwey) Chen":

> Hi Koen,
>
> Responding to your earlier email about Bluetooth headset application:<= br> >
> (1) Although BT SIG standardization is a preferred route, it is
> technically feasible to negotiate and use a non-Bluetooth-SIG codec. >
> (2) Someone familiar with BT SIG told me that it would probably take > only 6 months to add an optional codec to the BT SIG spec and 12 to > 18 months to add a mandatory codec.
>
> (3) The IETF codec is scheduled to be finalized in 14 months and
> submitted to IESG in 18 months. =A0Even if we take the BT SIG route > and take 6 to 18 months there. =A0The total time of 2 to 3 years from<= br> > now means the Moore's Law would only increase the CPU resources 2X=
> to 3X, and definitely no more than 4X max, not 10X.
>
> (4) Most importantly, guess what, in the last several years the
> Bluetooth headset chips have been growing its processing power at a > MUCH, MUCH slower rate than what the Moore's Law says it should. > Sometimes they did not increase the speed at all for years. =A0The
> reasons? The ASP (average sale price) of Bluetooth chips plummeted
> very badly, making it unattractive to invest significant resources
> to make them significantly faster. =A0Also, for low-end and mid-end BT=
> headsets, the BT chips were often considered "good enough" a= nd there
> wasn't a strong drive to increase the computing resources. =A0In > addition, the BT headsets got smaller over the last few years; the
> corresponding reduction in battery size required a reduction in
> power consumption, which also limited how fast the processor speed
> could grow. =A0In the next several years, it is highly likely that the=
> computing capabilities of Bluetooth headset chips will continue to
> grow at a rate substantially below what's predicted by the Moore&#= 39;s
> Law.
>
> (5) Although Bluetooth supports G.711 as an optional codec,
> basically no one uses it because it is too sensitive to bit errors. > Essentially all the BT mono headsets on the market today are
> narrowband (8 kHz sampling) headsets using CVSD. =A0There isn't an= y
> real wideband support yet, so your comment about G.722 doesn't
> apply. =A0Even after wideband-capable BT headsets come out, for many > years to come the majority of the BT headsets (especially mid- to
> low-end) will still be narrowband only, running only CVSD. Hence,
> the quality degradation of the CVSD transcoding is real and will be > with us for quite a while, so it is desirable for the IETF codec to > have a low-complexity mode that can directly run on the BT headsets > to avoid the quality degradation of CVSD when using BT headsets to
> make Internet phone calls.
>
> (6) Even if you could use G.711 or G.722 in the BT headsets, they
> both operate at 64 kb/s. =A0A low-complexity mode of the IETF codec > can operate at half or one quarter of that bit-rate. =A0This will help=
> conserve BT headsets' radio power because of the lower transmit du= ty
> cycle. =A0It will also help the Bluetooth + WiFi co-existence
> technologies.
>
> (7) Already a lot of people are used to using Bluetooth headsets to > make phone calls today. =A0If they have a choice, many of these people=
> will also want to use Bluetooth headsets to make Internet phone
> calls, not only through computers, but also through smart phones
> connected to WiFi or cellular networks. =A0As more and more states and=
> countries pass laws to ban the use of cell phones that are not in
> hands-free mode while driving, the number of Bluetooth headset users > will only increase with time, and many of them will want to make
> Internet-based phone calls.
>
> Given all the above, I would argue that Bluetooth headset is a very > relevant application that the IETF codec should address with a
> low-complexity mode.
>
> Best Regards,
>
> Raymond
>
> -----Original Message-----
> From: codec-bounces@ietf.org= [mailto:codec-bounces@ietf.o= rg] On
> Behalf Of Koen Vos
> Sent: Friday, April 23, 2010 1:16 AM
> To: codec@ietf.org
> Subject: Re: [codec] #16: Multicast?
>
> By the time the BlueTooth Special Interest Group will have adopted a > future IETF codec standard, Moore's law will surely have multiplie= d
> CPU resources in the BT device by one order of magnitude..? =A0Not sur= e
> it makes sense to apply today's BT constraints to tomorrow's c= odec.
>
> I'm not even convinced BlueTooth is a relevant use case for an
> Internet codec. =A0BT devices are audio devices more than VoIP end
> points: BT always connects to the Internet through another device.
> You could simply first decode incoming packets and send PCM data to > the BT device, or use a high-quality/high-bitrate codec like G.722. > The requirements for BT devices and the Internet are just too
> different. =A0Similarly, GSM phones use AMR on the network side and a<= br> > different codec towards the BT device. =A0The required transcoding
> causes no quality problems because BT supports high bitrates.
>
> best,
> koen.
>
>
> Quoting Raymond (Juin-Hwey) Chen:
>
>> Hi Christian,
>>
>> My comments about your question of CODEC requirements are in-line.=
>>
>> Raymond
>>
>> From: codec-bounces@ietf= .org [mailto:codec-bounces@ie= tf.org] On
>> Behalf Of Christian Hoene
>> Sent: Wednesday, April 21, 2010 12:27 PM
>> To: 'stephen botzko'
>> Cc: codec@ietf.org
>> Subject: Re: [codec] #16: Multicast?
>>
>> Hi,
>>
>> if we take those two scenarios (high quality and scalable
>> teleconferencing), what are then the CODEC requirements?
>>
>> High quality:
>>
>> - =A0 =A0 =A0 =A0 =A0Quite the same requirement as an end-to-end a= udio
>> transmission: high quality and low latency.
>> [Raymond]: High quality is a given, but I would like to emphasize<= br> >> the importance of low latency.
>> (1) It is well-known that the longer the latency, the lower the >> perceived quality of the communication link. =A0The E-model in the=
>> ITU-T Recommendation G.107 models such communication quality in >> MOS_cqe, which among other things depends on the so-called "d= elay
>> impairment factor" Id. =A0Basically, MOS_cqe is a monotonical= ly
>> decreasing function of increasing latency, and beyond about 150 ms=
>> one-way delay, the perceived quality of the communication link dro= ps
>> rapidly with further delay increase.
>> (2) The lower the latency, the less audible the echo, and thus the=
>> lower the required echo return loss. =A0Hence, lower latency means=
>> easier echo control and simpler echo canceller, and as people
>> already mentioned previously, below a certain delay, an echo is >> simply perceived as a harmless side-tone and no echo canceller is<= br> >> needed. It seems to me that echo control in conference calls is mo= re
>> difficult than in point-to-point calls. =A0While I hardly ever hea= rd
>> echoes in domestic point-to-point calls, in my experience with
>> conference calls at work, even with the G.711 codec (which has
>> almost no delay), sometimes I still hear echoes (I just heard
>> another one this afternoon). =A0If a relatively long-delay IETF co= dec
>> is used, the echo control will be even more problematic.
>> (3) In normal phone calls or conference calls, people routinely ha= ve
>> a need to interrupt each other, but beyond a certain point, long >> latency makes it very difficult for people to interrupt each other=
>> on the call. =A0This is because when you try to interrupt another<= br> >> person, that person doesn't hear your interruption until a cer= tain
>> time later, so he keeps talking, but when you hear that he did not=
>> stop talking when you interrupted, you stop; then, he hears your >> interruption, so he stops. When you hear he stops, you start talki= ng
>> again, but then he also hears you stopped (due to the long delay),=
>> so he also starts talking again. =A0The net result is that with a = long
>> latency, when you try to interrupt him, you and he end up stopping=
>> and starting at roughly the same time for a few cycles, making it<= br> >> difficult to interrupt each other.
>> (4) We need to keep in mind that the IETF codec may not be the onl= y
>> codec involved in a phone call or a conference call. =A0We cannot<= br> >> assume that all conference call participants will be using a
>> computer to conduct the call. Not only do people use cell phones f= or
>> point-to-point phone calls, they also often use cell phones to cal= l
>> in to conference calls. =A0The one-way delay for a cell phone call=
>> through one carriers network is typically around 80 to 110 ms. =A0= A
>> call from a cell phone in a carrier network to another cell phone = in
>> a different type of carrier network can easily double this delay t= o
>> 160 ~ 220 ms and makes the total one-way delay already far exceedi= ng
>> the 150 ms mentioned in (1) above. =A0Any coding delay added by th= e
>> IETF codec will be on top of that long delay, and such coding dela= y
>> will be applied twice when both cell phones call through the IETF<= br> >> codec to a conference bridge. =A0Even without the IETF codec delay= ,
>> when I previously called from a Verizon cell phone to an AT&T = cell
>> phone, I already experienced the problem mentioned in (3) sometime= s.
>> =A0If the IETF codec has a relatively long delay, adding two times= the
>> IETF codec one-way delay to the already long delay of 160 ~ 220 ms=
>> will make the situation much worse. =A0Even if just one cell phone= is
>> involved in a conference call, adding twice the one-way delay of a=
>> relatively long-delay IETF codec can still easily push the total >> one-way delay beyond 150 ms.
>> To summarize, my point is that to help reduce potential echo
>> problems and to ensure a high-quality experience in such a
>> conference call, the IETF codec should have a delay as low as
>> possible while maintaining good enough speech quality and a
>> reasonable bit-rate.
>>
>> - =A0 =A0 =A0 =A0 =A0Maybe additionally: variable bit rate encodin= g to achieve
>> a multiplexing gain at the receiver
>>
>> - =A0 =A0 =A0 =A0 =A0and thus, a fast control loop to cope with va= riable
>> bitrates on transmission paths.
>>
>> - =A0 =A0 =A0 =A0 =A0Maybe stereo/multichannel support to send the= spatial
>> audio to the headphone or loudspeakers.
>>
>> Scalable:
>>
>> - =A0 =A0 =A0 =A0 =A0Efficient encoding/transcoding for multiple d= ifferent
>> qualities (at the conference bridge)
>> [Raymond]: I am not sure whether by "efficient", you mea= nt coding
>> efficiency or computational efficiency. =A0In any case, I would li= ke
>> to take this opportunity to express my view that although codec >> complexity isn't much of an issue for PC-to-PC calls where the= re are
>> GHz of processing power available, the codec complexity is an
>> important issue in certain application scenarios. =A0The following= are
>> just some examples.
>> 1) If a conference bridge has to decode a large number of voice >> channels, mix, and re-encode, and if compressed-domain mixing cann= ot
>> be done (which is usually the case), then it is important to keep<= br> >> the decoder complexity low.
>> 2) In topology b) of your other email
>> (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway= ,
>> or VoIP gateway, often has to encode and decode thousands of voice=
>> channels in a single box, so not only the computational complexity= ,
>> but also the per-instance RAM size requirement of the codec become=
>> very important for achieving high channel density in the gateway.<= br> >> 3) Many telephone terminal devices at the edge of the Internet use=
>> embedded processors with limited processing power, and the
>> processors also have to handle many tasks other than speech coding= .
>> If the IETF codec complexity is too high, some of such devices may=
>> not have sufficient processing power to run it. =A0Even if the cod= ec
>> can fit, some battery-powered mobile devices may prefer to run a >> lower-complexity codec to reduce power consumption and battery
>> drain. =A0For example, even if you make a Internet phone call from= a
>> computer, you may like the convenience of using a Bluetooth headse= t
>> that allows you to walk around a bit and have hands-free operation= .
>> Currently most Bluetooth headsets have small form factors with a >> tiny battery. =A0This puts a severe constraint on power consumptio= n.
>> Bluetooth headset chips typically have very limited processing
>> capability, and it has to handle many other tasks such as echo
>> cancellation and noise reduction. =A0There is just not enough
>> processing power to handle a relatively high-complexity codec. =A0= Most
>> BT headsets today relies on the extremely low-complexity,
>> hardware-based CVSD codec at 64 kb/s to transmit narrowband voice,=
>> but CVSD has audible coding noise, so it degrades the overall audi= o
>> quality. =A0If the IETF codec has low enough complexity, it would = be
>> possible to directly encode and decode the IETF codec bit-stream a= t
>> the BT headset, thus avoiding the quality degradation of CVSD
>> transcoding.
>> In summary, my point is that the IETF codec should attempt to
>> achieve a codec complexity as low as possible in both MHz
>> consumption and RAM size requirement while maintaining good enough=
>> speech quality.
>>
>> - =A0 =A0 =A0 =A0 =A0The control loop must not react (fast) becaus= e
>> (multicast) group communication requires to encode at low quality<= br> >> anyhow.
>>
>> - =A0 =A0 =A0 =A0 =A0Receiver side activity detection for music an= d voice
>> having low complexity (for the conference bridge)
>>
>> - =A0 =A0 =A0 =A0 =A0Efficient mixing of two to four(?) active flo= ws (is this
>> achievable without the complete process of decoding and encoding >> again?)
>>
>> Are any teleconferencing requirements missing?
>>
>> =A0Christian
>>
>>
>>
>>
>> --------------------------------------------------------------- >> Dr.-Ing. Christian Hoene
>> Interactive Communication Systems (ICS), University of T=FCbingen<= br> >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
>> htt= p://www.net.uni-tuebingen.de/
>>
>> From: stephen botzko [mailto:stephen.botzko@gmail.com]
>> Sent: Wednesday, April 21, 2010 8:19 PM
>> To: Christian Hoene
>> Cc: codec@ietf.org
>> Subject: Re: [codec] #16: Multicast?
>>
>> Inline
>> On Wed, Apr 21, 2010 at 1:27 PM, Christian Hoene
>> <hoene@uni-tuebingen.= de<mailto:hoene@uni-tuebin= gen.de>> wrote:
>> Hi Stephen,
>>
>> not too bad. You answered faster than the mailing list distributes= ...
>> Not sure how that happened!
>>
>> Comments inline:
>>
>>
>> From: stephen botzko
>> [mailto:stephen.botzko= @gmail.com<mailto:stephe= n.botzko@gmail.com>]
>> Sent: Wednesday, April 21, 2010 7:10 PM
>> To: Christian Hoene
>> Cc: codec@ietf.org<mailto= :codec@ietf.org>
>>
>> Subject: Re: [codec] #16: Multicast?
>>
>> I agree there are lots of use cases.
>>
>>
>> Though I don't see why high quality has to be given up in orde= r to
>> be scalable.
>> CH: These are just experiences from our lab. A spatial audio
>> conference server including the acoustic 3D sound rendering needs = a
>> LOT of processing power. In the end, we have to remain realistic.<= br> >> Processing power is always limited thus if we need a lot then we >> cannot serve many clients.
>> Also, I am not sure why you think central mixing is more scalable<= br> >> than multicast (or why you think it is lower quality either).
>> CH: With multicast, you need N times 1:N multicast distribution >> trees (somewhat small tan O(n)=3Dn=B2). =A0With central mixing you= need N
>> times 2 transmission paths (O(n)=3Dn). Also, this distributed mixi= ng
>> you need N times the mixing at each client. With centralized, you<= br> >> can live with one mixing for all (and some tricks for serving the<= br> >> talkers).
>> I agree you need more distribution trees for multicast if you allo= w
>> every site to talk. There is a corresponding benefit, since there = is
>> no central choke point and also less bandwidth on shared WAN links= .
>>
>> In the distributed case, =A0you don't need an N-way mixer at e= ach
>> client, and you also don't need to continuously receive payloa= d on
>> all N streams at each client either. =A0In practice you can cap N = at a
>> relatively small number (in the 3-8 range) no matter how large the=
>> conference gets. =A0In a large conference, you can even choose to = drop
>> your comfort noise if you are receiving two or more streams, and >> just send enough to keep your firewall pinhole open. =A0This is al= l
>> assuming a suitable voice activity measure in the RTP packet. =A0O= f
>> course in the worst case, you will receive all N streams.
>>
>> Cheers,
>> =A0Christian
>>
>> Stephen Botzko
>> On Wed, Apr 21, 2010 at 12:58 PM, Christian Hoene
>> <hoene@uni-tuebingen.= de<mailto:hoene@uni-tuebin= gen.de>> wrote:
>> Hi,
>>
>> the teleconferencing issue gets complex. I am trying to compile th= e
>> different requirements that have been mentioned on this list.
>>
>> - =A0 =A0 =A0 =A0 =A0low complexity (with just one active speaker)= vs.
>> multiple speaker mixing vs. spatial audio/stereo mixing
>>
>> - =A0 =A0 =A0 =A0 =A0centralized vs. distributed
>>
>> - =A0 =A0 =A0 =A0 =A0few participants vs. hundreds of listeners an= d talkers
>>
>> - =A0 =A0 =A0 =A0 =A0individual distribution of audio streams vs. = IP multicast
>> or RTP group communication
>>
>> - =A0 =A0 =A0 =A0 =A0efficient encoding of multiple streams having= the same
>> content (but different quality).
>>
>> - =A0 =A0 =A0 =A0 =A0 I bet I missed some.
>>
>> To make things easier, why not to split the teleconferencing
>> scenario in two: High quality and Scalable?
>>
>> The high quality scenario, intended for a low number of users, cou= ld
>> have features like
>>
>> - =A0 =A0 =A0 =A0 =A0Distributed processing and mixing
>>
>> - =A0 =A0 =A0 =A0 =A0High computational resources to support spati= al audio
>> mixing (at the receiver) and multiple encodings of the same audio<= br> >> stream at different qualities (at the sender)
>>
>> - =A0 =A0 =A0 =A0 =A0Enough bandwidth to allow direct N to N trans= missions of
>> audio streams (no multicast or group communication). This would be=
>> good for the latency, too.
>>
>> The scalable scenario is the opposite:
>>
>> - =A0 =A0 =A0 =A0 =A0Central processing and mixing for many partic= ipants .
>>
>> - =A0 =A0 =A0 =A0 =A0N to 1 and 1 to N communication using efficie= nt
>> distribution mechanisms (RTP group communication and IP multicast)= .
>>
>> - =A0 =A0 =A0 =A0 =A0Low complexity mixing of many using tricks li= ke VAD,
>> encoding at lowest rate to support many receivers having different=
>> paths, you name it...
>>
>> Then, we need not to compare apples with oranges all the time.
>>
>> Christian
>>
>> --------------------------------------------------------------- >> Dr.-Ing. Christian Hoene
>> Interactive Communication Systems (ICS), University of T=FCbingen<= br> >> Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
>> htt= p://www.net.uni-tuebingen.de/
>>
>> From: codec-bounces@ietf= .org<mailto:codec-bounces@= ietf.org>
>> [mailto:codec-bounces@ie= tf.org<mailto:codec-bounce= s@ietf.org>] On
>> Behalf Of stephen botzko
>> Sent: Wednesday, April 21, 2010 4:34 PM
>> To: Colin Perkins
>> Cc: trac@tools.ietf.org= <mailto:trac@tools.ietf.org&g= t;;
>> codec@ietf.org<mailto:codec@ietf.org>
>> Subject: Re: [codec] #16: Multicast?
>>
>> in-line
>>
>> Stephen Botzko
>> On Wed, Apr 21, 2010 at 8:17 AM, Colin Perkins
>> <csp@csperkins.org<= mailto:csp@csperkins.org>> w= rote:
>> On 21 Apr 2010, at 12:20, Marshall Eubanks wrote:
>> On Apr 21, 2010, at 6:48 AM, Colin Perkins wrote:
>> On 21 Apr 2010, at 10:42, codec issue tracker wrote:
>> #16: Multicast?
>> ------------------------------------+-----------------------------= -----
>> Reporter: =A0hoene@... =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 = =A0 Owner:
>> =A0Type: =A0enhancement =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0Statu= s: =A0new
>> Priority: =A0trivial =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milesto= ne:
>> Component: =A0requirements =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Versio= n:
>> Severity: =A0Active WG Document =A0 =A0 =A0| =A0 =A0Keywords:
>> ------------------------------------+-----------------------------= -----
>> The question arrose whether the interactive CODEC MUST support
>> multicast in addition to teleconferencing.
>>
>> On 04/13/2010 11:35 AM, Christian Hoene wrote:
>> P.S. On the same note, does anybody here cares about using this >> CODEC with multicast? Is there a single commercial multicast voice=
>> deployment? From what I've seen all multicast does is making I= ETF
>> voice standards harder to understand or implement.
>>
>> I think that would be a mistake to ignore multicast - not because = of
>> multicast itself, but because of Xcast (RFC 5058) which is a
>> promising technology to replace centralized conference bridges. >>
>> Regarding multicast:
>>
>> I think we shall start at user requirements and scenarios.
>> Teleconference (including mono or spatial audio) might be good
>> starting point. Virtual environments like second live would requir= e
>> multicast communication, too. If the requirements of these scenari= os
>> are well understand, we can start to talk about potential solution= s
>> like IP multicast, Xcast or conference bridges.
>>
>>
>> RTP is inherently a group communication protocol, and any codec >> designed for use with RTP should consider operation in various
>> different types of group communication scenario (not just
>> multicast). RFC 5117 is a good place to start when considering the=
>> different types of topology in which RTP is used, and the possible=
>> placement of mixing and switching functions which the codec will >> need to work with.
>>
>> It is not clear to me what supporting multicast would entail here.=
>> If this is a codec over RTP, then what is to stop it from being >> multicast ?
>>
>> Nothing. However group conferences implemented using multicast
>> require end system mixing of potentially large numbers of active >> audio streams, whereas those implemented using conference bridges = do
>> the mixing in a single central location, and generally suppress al= l
>> but one speaker. The differences in mixing and the number of
>> simultaneous active streams that might be received potentially
>> affect the design of the codec.
>>
>> Conference bridges with central mixing almost always mix multiple<= br> >> speakers. =A0As you add more streams into the mix, you reduce the<= br> >> chance of missing onset speech and interruptions, but raise the >> noise floor. So even if complexity is not a consideration, there i= s
>> value in gating the mixer (instead of always doing a full mix-minu= s).
>>
>> More on point, compressed domain mixing and easy detection of VAD<= br> >> have both been advocated on these lists, and both simplify the
>> large-scale mixing problem.
>>
>> --
>> Colin Perkins
>> http://csperki= ns.org/
>>
>>
>>
>> _______________________________________________
>> codec mailing list
>> codec@ietf.org<mailto:codec@ietf.org>
>> https://www.ietf.org/mailman/listinfo/codec
>>
>>
>>
>>
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ietf.org/mailman/listinfo/codec
>
>
>



_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--0016e6d97670769f34048572a1c5-- From hoene@uni-tuebingen.de Fri Apr 30 05:24:30 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A387D3A6C42 for ; Fri, 30 Apr 2010 05:24:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.376 X-Spam-Level: X-Spam-Status: No, score=-4.376 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FF1RT6imef+d for ; Fri, 30 Apr 2010 05:24:29 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id A3EAC3A6C43 for ; Fri, 30 Apr 2010 05:23:25 -0700 (PDT) Received: from hoeneT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o3UCN6KT028093 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Apr 2010 14:23:06 +0200 From: "Christian Hoene" To: "'Raymond \(Juin-Hwey\) Chen'" , "'Mikael Abrahamsson'" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <20100423011559.20246ayxdicd9vzz@mail.skype.net> In-Reply-To: Date: Fri, 30 Apr 2010 14:23:07 +0200 Message-ID: <006c01cae85f$e45df360$ad19da20$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrkTi/xlw0UOCUaT+WSfKLd+Krg0wBIzQdgALXPAHA= Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 12:24:31 -0000 Hi, I just want to share some insights from the recent development of = Bluetooth's Hands-Free Profile (HFP) version 1.5, which supports wideband speech. One main requirement were on the frame size of 7.5 ms = because the Bluetooth MAC protocol support scheduling at this interval. Actually, to achieve this they modified SBC to work on 15 = blocks instead of 4,8,12 or 16 blocks and they decided against G.722. The lesson to learn is about the importance of MAC protocol. To get a = efficient, low power, and mobile device you have to consider the impact of packet scheduling. If packets are scheduled regular, the = MAC protocol can work more efficient. The more irregular packet arrive, the more expensive a packet transmission gets. Actually, you can translate the cost of packet scheduling to bits per = packet. Depending on the wireless technology, it might vary substantially. The worst case is 802.11b at 11 Mbps at long preamble - = then, you can add about 1300 bytes to every packet just for physical headers and MAC scheduling. However, more modern technologies = like LTE and IEEE 802.11n are much more efficient in terms of per packet overhead.=20 If you ask me, one important usage scenario is over wireless links = supporting low-power mobile devices. If we ignore this scenario it will be a judge mistake: a) Battery powered mobile devices must be energy efficient to reduce the = size of the batteries. Also, they should not demand to many computational resources, otherwise they would consume to much energy. b) Wireless IP access is also in scope because many devices get Internet = access LTE, WLAN, Wimax, UMTS, etc.=20 Bluetooth headsets are somewhat a special case. Actually, they are two = cases: 1) Headphones (A2DP): For me it is not clear whether supporting the = Internet CODEC on top of A2DP (which is - by the way - already possible according to Bluetooth spec A2DP V1.2) or using the Internet = CODEC till the Bluetooth AP and transcoding to SBC is more efficient, cost effect, or energy saving. 2) Mic (HFP): Here is the scheduling of 3.75 or 7.5ms might be an = important requirement that the Internet CODEC cannot fulfill always because it must adapt its parameters to the Internet transmission = path not just to the Bluetooth link. Thus, I would recommend to write a liaison statement to Bluetooth AVT = group and ask whether they would have interest to include the Internet CODEC into a future version of A2DP. Definitely, this must not = happen soon because the they can do is only if the Internet CODEC is finishing. Supporting HFP might be more difficult than A2DP = because of the very tough requirements on efficiency. With best regards, Christian=20 --------------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen=20 Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532=20 http://www.net.uni-tuebingen.de/ >-----Original Message----- >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Raymond (Juin-Hwey) Chen >Sent: Monday, April 26, 2010 11:02 PM >To: Mikael Abrahamsson >Cc: codec@ietf.org >Subject: Re: [codec] #16: Multicast? > >Hi Mikael, > >Thanks for sharing your experience using a BT headset for Skype calls. = I think part of the quality >degradation that you experienced was due to the reduction of the audio = bandwidth to narrowband (8 kHz >sampling, 3.4 kHz bandwidth), and another part of the degradation was = due to the audible coding noise >of the CVSD codec, a 40-year-old coding technology first proposed in = 1970. > >If a high-quality, low-complexity, wider bandwidth IETF codec mode can = be implemented in Skype and the >Bluetooth headset to avoid the CVSD transcoding (together with wideband = upgrade of the transducers and >audio path in the BT headset, of course), then not only will you get = much better speech quality in >your Skype calls than what you have experienced, but also you will get = a lower latency. This is >because transcoding between the Skype codec and CVSD not only = accumulates the coding distortion of the >two codecs, but also accumulates the coding delays. Although CVSD is a = sample-by-sample codec, BT >headsets still transmit the CVSD bit-stream in 3.75 ms or 7.5 ms = packets, and they can potentially add >a one-way delay up to 20 ~ 25 ms through the Bluetooth headset (the = exact delay depends on the >implementation). > >While we were discussing whether a 5 ms packet size can even be = considered, for many years Bluetooth >headsets have been using an even smaller 3.75 ms packet size. > >Best Regards, > >Raymond > >-----Original Message----- >From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] >Sent: Sunday, April 25, 2010 1:06 AM >To: Raymond (Juin-Hwey) Chen >Cc: Koen Vos; codec@ietf.org >Subject: Re: [codec] #16: Multicast? > >On Sat, 24 Apr 2010, Raymond (Juin-Hwey) Chen wrote: > >> (7) Already a lot of people are used to using Bluetooth headsets to = make >> phone calls today. If they have a choice, many of these people will >> also want to use Bluetooth headsets to make Internet phone calls, not >> only through computers, but also through smart phones connected to = WiFi >> or cellular networks. As more and more states and countries pass = laws >> to ban the use of cell phones that are not in hands-free mode while >> driving, the number of Bluetooth headset users will only increase = with >> time, and many of them will want to make Internet-based phone calls. > >I purchased a BT headset with the anticipation of using it with my >computer to make Skype calls. I tried it, but the sound quality when = doing >bidirectional audio (whatever that mode is called) is not good enough, = it >worsens the "skype IP" call quality. I agree that the use case is >interesting, but as long as BT sound quality is what it is, it's really >only the "low end" type sound quality we're talking about. > >But yes, I make skype IP calls with my Nokia N900 using BT sometimes, = so >the use case example is definitely valid. > >-- >Mikael Abrahamsson email: swmike@swm.pp.se > > >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From hoene@uni-tuebingen.de Fri Apr 30 05:42:33 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BC893A6B63 for ; Fri, 30 Apr 2010 05:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.572 X-Spam-Level: X-Spam-Status: No, score=-5.572 tagged_above=-999 required=5 tests=[AWL=0.677, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJOuep+s6XGZ for ; Fri, 30 Apr 2010 05:42:32 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 517853A6886 for ; Fri, 30 Apr 2010 05:42:22 -0700 (PDT) Received: from hoeneT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o3UCg22B030915 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Apr 2010 14:42:02 +0200 From: "Christian Hoene" To: "'Christian Hoene'" , "'Raymond \(Juin-Hwey\) Chen'" , "'Mikael Abrahamsson'" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <20100423011559.20246ayxdicd9vzz@mail.skype.net> <006c01cae85f$e45df360$ad19da20$@de> In-Reply-To: <006c01cae85f$e45df360$ad19da20$@de> Date: Fri, 30 Apr 2010 14:42:03 +0200 Message-ID: <007001cae862$899fc9f0$9cdf5dd0$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrkTi/xlw0UOCUaT+WSfKLd+Krg0wBIzQdgALXPAHAABmIcIA== Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 12:42:33 -0000 >I just want to share some insights from the recent development of Bluetooth's Hands-Free Profile (HFP) >version 1.5, which supports No, not version 1.5 but its not yet published successor. Sorry, Christian From hoene@uni-tuebingen.de Fri Apr 30 06:01:49 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F377F3A6A98 for ; Fri, 30 Apr 2010 06:01:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.657 X-Spam-Level: X-Spam-Status: No, score=-5.657 tagged_above=-999 required=5 tests=[AWL=0.592, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IBJLjl8VOeyK for ; Fri, 30 Apr 2010 06:01:48 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 8BC3E28C236 for ; Fri, 30 Apr 2010 06:01:47 -0700 (PDT) Received: from hoeneT60 (u-173-c044.cs.uni-tuebingen.de [134.2.173.44]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id o3UD1SnG001166 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 30 Apr 2010 15:01:28 +0200 From: "Christian Hoene" To: "'Koen Vos'" , "'Raymond \(Juin-Hwey\) Chen'" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <20100424135607.84293hkaa13j1zvr@mail.skype.net> <20100424181620.352034g28cnjr010@mail.skype.net> In-Reply-To: <20100424181620.352034g28cnjr010@mail.skype.net> Date: Fri, 30 Apr 2010 15:01:29 +0200 Message-ID: <007601cae865$408bdfd0$c1a39f70$@de> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrkFPe4j2bC4cCKQAGsf/8sz8f6+AET3RmA Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 13:01:49 -0000 >>> Afaik, only RTP headers can be compressed between arbitrary Internet >>> end points. You're still stuck with IP and UDP headers. >> >> I am aware of a header compression technology for VoIP over Cable >> applications that can compress the header size to a very small >> fraction of the original size, but it is probably not widely used. > >Yes, header compression works between end-points on a cable. That's >different from "between arbitrary Internet end points". BTW: IP header compression using ROHC is covered by patents ;-) https://datatracker.ietf.org/ipr/search/?option=title_search&title_search=rohc Cheers, Christian > >best, >koen. >_______________________________________________ >codec mailing list >codec@ietf.org >https://www.ietf.org/mailman/listinfo/codec From ron.even.tlv@gmail.com Fri Apr 30 06:13:55 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F8293A6AC0 for ; Fri, 30 Apr 2010 06:13:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.134 X-Spam-Level: X-Spam-Status: No, score=-2.134 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nQrs-Hgh+pxd for ; Fri, 30 Apr 2010 06:13:53 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 313F13A6B6E for ; Fri, 30 Apr 2010 06:13:52 -0700 (PDT) Received: by wyb35 with SMTP id 35so144977wyb.31 for ; Fri, 30 Apr 2010 06:13:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:cc:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:content-language:thread-index; bh=tcv83Jdivo0IH7fldttAmhi9B7QZCwPVmOd9SE/BGJg=; b=hZJyx9Faou+7vzhx1aFNZWu0I2YhGc+u2Q5QkWGN2mm8efsraLmUtLVC0vGlFNoA7z Y+ld4x5s3wxELT83dBZdwILubxUFmjTfe8TNNR+Vz+sct/vKlITGfwNedUfh1sH09MZr B/HDywxJHgaG5qLOspgsXlnvYGr1suLMpHKEg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; b=e8z/6oURzqjv9YmW5YbykM0DdbMZ/mVMDudsRfWTxZ2jvL766F+NTSSmDMhvGqmrPU kpQXy6eRJ0EbePdhSS68f2+cr9VxQrGDGy1zCzGRBYOUy8Zf7dDNPjz+NuH+0rXzOgw9 3gRIxVXdOC99+isVS6UrlqyaE4xQYaBXonh1g= Received: by 10.216.183.205 with SMTP id q55mr1961851wem.172.1272633213949; Fri, 30 Apr 2010 06:13:33 -0700 (PDT) Received: from windows8d787f9 ([109.65.33.169]) by mx.google.com with ESMTPS id x14sm15608745wbs.12.2010.04.30.06.13.31 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 30 Apr 2010 06:13:32 -0700 (PDT) From: "Roni Even" To: "'Christian Hoene'" , "'Raymond \(Juin-Hwey\) Chen'" , "'Mikael Abrahamsson'" References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <20100423011559.20246ayxdicd9vzz@mail.skype.net> <006c01cae85f$e45df360$ad19da20$@de> In-Reply-To: <006c01cae85f$e45df360$ad19da20$@de> Date: Fri, 30 Apr 2010 16:12:32 +0300 Message-ID: <4bdad77c.8e83e30a.4af1.ffff942d@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Content-language: en-us Thread-index: AcrkTi/xlw0UOCUaT+WSfKLd+Krg0wBIzQdgALXPAHAAB1WtcA== Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? (USB) X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 13:13:55 -0000 Hi, I think that this is going to a wrong direction. I already suggested = that since the group will do one codec we first need to decide on the applications. The initial request was for a wideband codec for the = Internet and this is the application that should dictate the requirements. We can look at the other applications in the requirements and charter and = continue with the requirements that are in-line with the original application.=20 Other applications are nice to have if they do not add more requirements = to the codec to be defined here. We are talking here on more requirements = which in my understanding are not in the scope of the WG Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Christian Hoene > Sent: Friday, April 30, 2010 3:23 PM > To: 'Raymond (Juin-Hwey) Chen'; 'Mikael Abrahamsson' > Cc: codec@ietf.org > Subject: Re: [codec] #16: Multicast? >=20 > Hi, >=20 > I just want to share some insights from the recent development of > Bluetooth's Hands-Free Profile (HFP) version 1.5, which supports > wideband speech. One main requirement were on the frame size of 7.5 = ms > because the Bluetooth MAC protocol support scheduling at > this interval. Actually, to achieve this they modified SBC to work on > 15 blocks instead of 4,8,12 or 16 blocks and they decided > against G.722. >=20 > The lesson to learn is about the importance of MAC protocol. To get a > efficient, low power, and mobile device you have to consider > the impact of packet scheduling. If packets are scheduled regular, the > MAC protocol can work more efficient. The more irregular > packet arrive, the more expensive a packet transmission gets. >=20 > Actually, you can translate the cost of packet scheduling to bits per > packet. Depending on the wireless technology, it might vary > substantially. The worst case is 802.11b at 11 Mbps at long preamble - > then, you can add about 1300 bytes to every packet just for > physical headers and MAC scheduling. However, more modern technologies > like LTE and IEEE 802.11n are much more efficient in terms of > per packet overhead. >=20 >=20 > If you ask me, one important usage scenario is over wireless links > supporting low-power mobile devices. If we ignore this scenario > it will be a judge mistake: > a) Battery powered mobile devices must be energy efficient to reduce > the size of the batteries. Also, they should not demand to many > computational resources, otherwise they would consume to much energy. > b) Wireless IP access is also in scope because many devices get > Internet access LTE, WLAN, Wimax, UMTS, etc. >=20 >=20 > Bluetooth headsets are somewhat a special case. Actually, they are two > cases: > 1) Headphones (A2DP): For me it is not clear whether supporting the > Internet CODEC on top of A2DP (which is - by the way - already > possible according to Bluetooth spec A2DP V1.2) or using the Internet > CODEC till the Bluetooth AP and transcoding to SBC is more > efficient, cost effect, or energy saving. > 2) Mic (HFP): Here is the scheduling of 3.75 or 7.5ms might be an > important requirement that the Internet CODEC cannot fulfill > always because it must adapt its parameters to the Internet > transmission path not just to the Bluetooth link. >=20 > Thus, I would recommend to write a liaison statement to Bluetooth AVT > group and ask whether they would have interest to include the > Internet CODEC into a future version of A2DP. Definitely, this must = not > happen soon because the they can do is only if the Internet > CODEC is finishing. Supporting HFP might be more difficult than A2DP > because of the very tough requirements on efficiency. >=20 > With best regards, >=20 > Christian >=20 > --------------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of T=FCbingen > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ >=20 >=20 > >-----Original Message----- > >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On = Behalf > Of Raymond (Juin-Hwey) Chen > >Sent: Monday, April 26, 2010 11:02 PM > >To: Mikael Abrahamsson > >Cc: codec@ietf.org > >Subject: Re: [codec] #16: Multicast? > > > >Hi Mikael, > > > >Thanks for sharing your experience using a BT headset for Skype = calls. > I think part of the quality > >degradation that you experienced was due to the reduction of the = audio > bandwidth to narrowband (8 kHz > >sampling, 3.4 kHz bandwidth), and another part of the degradation was > due to the audible coding noise > >of the CVSD codec, a 40-year-old coding technology first proposed in > 1970. > > > >If a high-quality, low-complexity, wider bandwidth IETF codec mode = can > be implemented in Skype and the > >Bluetooth headset to avoid the CVSD transcoding (together with > wideband upgrade of the transducers and > >audio path in the BT headset, of course), then not only will you get > much better speech quality in > >your Skype calls than what you have experienced, but also you will = get > a lower latency. This is > >because transcoding between the Skype codec and CVSD not only > accumulates the coding distortion of the > >two codecs, but also accumulates the coding delays. Although CVSD is > a sample-by-sample codec, BT > >headsets still transmit the CVSD bit-stream in 3.75 ms or 7.5 ms > packets, and they can potentially add > >a one-way delay up to 20 ~ 25 ms through the Bluetooth headset (the > exact delay depends on the > >implementation). > > > >While we were discussing whether a 5 ms packet size can even be > considered, for many years Bluetooth > >headsets have been using an even smaller 3.75 ms packet size. > > > >Best Regards, > > > >Raymond > > > >-----Original Message----- > >From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > >Sent: Sunday, April 25, 2010 1:06 AM > >To: Raymond (Juin-Hwey) Chen > >Cc: Koen Vos; codec@ietf.org > >Subject: Re: [codec] #16: Multicast? > > > >On Sat, 24 Apr 2010, Raymond (Juin-Hwey) Chen wrote: > > > >> (7) Already a lot of people are used to using Bluetooth headsets to > make > >> phone calls today. If they have a choice, many of these people = will > >> also want to use Bluetooth headsets to make Internet phone calls, > not > >> only through computers, but also through smart phones connected to > WiFi > >> or cellular networks. As more and more states and countries pass > laws > >> to ban the use of cell phones that are not in hands-free mode while > >> driving, the number of Bluetooth headset users will only increase > with > >> time, and many of them will want to make Internet-based phone = calls. > > > >I purchased a BT headset with the anticipation of using it with my > >computer to make Skype calls. I tried it, but the sound quality when > doing > >bidirectional audio (whatever that mode is called) is not good = enough, > it > >worsens the "skype IP" call quality. I agree that the use case is > >interesting, but as long as BT sound quality is what it is, it's > really > >only the "low end" type sound quality we're talking about. > > > >But yes, I make skype IP calls with my Nokia N900 using BT sometimes, > so > >the use case example is definitely valid. > > > >-- > >Mikael Abrahamsson email: swmike@swm.pp.se > > > > > >_______________________________________________ > >codec mailing list > >codec@ietf.org > >https://www.ietf.org/mailman/listinfo/codec >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From trac@tools.ietf.org Fri Apr 30 06:14:33 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 215833A6B9A for ; Fri, 30 Apr 2010 06:14:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.213 X-Spam-Level: X-Spam-Status: No, score=-101.213 tagged_above=-999 required=5 tests=[AWL=-1.213, BAYES_50=0.001, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uqfbKNFEICS for ; Fri, 30 Apr 2010 06:14:32 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 2ADE13A6B6E for ; Fri, 30 Apr 2010 06:14:32 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from ) id 1O7q2q-0000dM-RQ; Fri, 30 Apr 2010 06:14:17 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "codec issue tracker" X-Trac-Version: 0.11.6 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.6, by Edgewall Software To: hoene@uni-tuebingen.de X-Trac-Project: codec Date: Fri, 30 Apr 2010 13:14:16 -0000 X-URL: http://tools.ietf.org/codec/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/16#comment:1 Message-ID: <071.d62cf61071b00067f2340085ae1779b5@tools.ietf.org> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> X-Trac-Ticket-ID: 16 In-Reply-To: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Reply-To: codec@ietf.org List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 13:14:33 -0000 #16: Multicast? ------------------------------------+--------------------------------------- Reporter: hoene@… | Owner: Type: enhancement | Status: closed Priority: trivial | Milestone: Component: requirements | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by hoene@…): * status: new => closed * resolution: => fixed Comment: [Colin]: RTP is inherently a group communication protocol, and any codec designed for use with RTP should consider operation in various different types of group communication scenario (not just multicast). RFC 5117 is a good place to start when considering the different types of topology in which RTP is used, and the possible placement of mixing and switching functions which the codec will need to work with. [Christian]: I believe that multicast support NEEDS NOT to be particular optimized due to the following two reasons: a) RFC5117: 4.1.3. Per Domain Bit-Rate Adaptation Participants are most likely to be connected to each other with a heterogeneous set of paths. This makes congestion control in a Point to Multipoint set problematic. For the ASM and "relay" scenario, each individual sender has to adapt to the receiver with the least capable path. This is no longer necessary when Media Translators, Mixers, or MCUs are involved, as each participant only needs to adapt to the slowest path within its own domain. The Translator, Mixer, or MCU topologies all require their respective outgoing streams to adjust the bit-rate, packet-rate, etc., to adapt to the least capable path in each of the other domains. That way one can avoid lowering the quality to the least-capable participant in all the domains at the cost (complexity, delay, equipment) of the Mixer or Translator. Indeed, the CODEC SHOULD be adapted on each path to achieve best quality. b) Multicast is used (to my best knowledge) mainly locally and not throughout the Internet, thus if we want to support global interactive communication with a good CODEC support of MULTICAST cannot be considered as granted. [Marshall]: It is not clear to me what supporting multicast would entail here. If this is a codec over RTP, then what is to stop it from being multicast ? [Stephan]: Teleconferencing standards (both in the ITU-T and the IETF) support multicast.. It would be awkward if the codec decision was somehow coupled to the transport, and (IMHO) architecturally wrong. While it is probably true that multicast is more likely to be used on enterprise networks, I don't see that as terribly relevant. I see no technical reason to NEED NOT multicast. [Colin]: Nothing. However group conferences implemented using multicast require end system mixing of potentially large numbers of active audio streams, whereas those implemented using conference bridges do the mixing in a single central location, and generally suppress all but one speaker. The differences in mixing and the number of simultaneous active streams that might be received potentially affect the design of the codec. [Marshall]: At any rate, I would regard multicast support as a SHOULD. [Christian]: The scalable [teleconference] scenario is [...]: - Central processing and mixing for many participants . - N to 1 and 1 to N communication using efficient distribution mechanisms (RTP group communication and IP multicast). -- Ticket URL: codec From stephen.botzko@gmail.com Fri Apr 30 06:41:24 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29B623A6C0B for ; Fri, 30 Apr 2010 06:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3DYoBOTH-VZo for ; Fri, 30 Apr 2010 06:41:22 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 825F83A6BF7 for ; Fri, 30 Apr 2010 06:41:20 -0700 (PDT) Received: by wwb24 with SMTP id 24so163233wwb.31 for ; Fri, 30 Apr 2010 06:41:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=LB/pRf52XSrQuHo1LcwEA2ZX/dWZRnExYPOBMbmXTQQ=; b=Vb+nm+B186hGWGO4zT8H/Z/2ZyplpuX3WqyjQy6N3iTqC6hqncWJbwUioyi6R2d6pT wtXuBEzp3KuBo0LvVU+FUyEu17b12dRzqDb+8CFqmLxIZB7Foo0/DhH2/qsTJPMOkOo3 kUui8BSFeN+FWEaNHNbUEB1kx7QhD5zieU4tI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=QKJea0r8XIPbSnz7CIBYVSrujOFsX/pLBxHGs9nTHBJm7wV9jkdph/o3JSS2FxNAMw 0mHL7A2Eykdz74hgBf0B89LmL6CiCrXv/4hvk+h1wv/qVF4KOqrI6338nCPNqDzv5L72 DqZLqapUL2PxxPnNP8dfuJTNTRzLY2UBPbdBY= MIME-Version: 1.0 Received: by 10.216.174.76 with SMTP id w54mr693345wel.213.1272634861792; Fri, 30 Apr 2010 06:41:01 -0700 (PDT) Received: by 10.216.28.139 with HTTP; Fri, 30 Apr 2010 06:41:01 -0700 (PDT) In-Reply-To: <006c01cae85f$e45df360$ad19da20$@de> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <20100423011559.20246ayxdicd9vzz@mail.skype.net> <006c01cae85f$e45df360$ad19da20$@de> Date: Fri, 30 Apr 2010 09:41:01 -0400 Message-ID: From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=001485f1d92addee380485746480 Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 13:41:24 -0000 --001485f1d92addee380485746480 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Christian I agree that Wireless IP is in scope, one could also argue that LTE might b= e in scope, since it will be using IPv6. As we all know, the internet runs over multiple physical layers, and usuall= y an end-to-end connection uses more than one physical layer. So I am not sure how we can translate layer 2 constraints into requirements for CODEC itself. I can see how it might impact the RTP packetization - allowing frames to be split across packets would allow media-aware devices to adjust the packetization to optimize delivery. BTW, I am a bit puzzled by the G.722 statement, since it can run at a 7.5 m= s packet delivery schedule (using 60 payload bytes per packet). Stephen Botzko On Fri, Apr 30, 2010 at 8:23 AM, Christian Hoene wr= ote: > Hi, > > I just want to share some insights from the recent development of > Bluetooth's Hands-Free Profile (HFP) version 1.5, which supports > wideband speech. One main requirement were on the frame size of 7.5 ms > because the Bluetooth MAC protocol support scheduling at > this interval. Actually, to achieve this they modified SBC to work on 15 > blocks instead of 4,8,12 or 16 blocks and they decided > against G.722. > > The lesson to learn is about the importance of MAC protocol. To get a > efficient, low power, and mobile device you have to consider > the impact of packet scheduling. If packets are scheduled regular, the MA= C > protocol can work more efficient. The more irregular > packet arrive, the more expensive a packet transmission gets. > > Actually, you can translate the cost of packet scheduling to bits per > packet. Depending on the wireless technology, it might vary > substantially. The worst case is 802.11b at 11 Mbps at long preamble - > then, you can add about 1300 bytes to every packet just for > physical headers and MAC scheduling. However, more modern technologies li= ke > LTE and IEEE 802.11n are much more efficient in terms of > per packet overhead. > > > If you ask me, one important usage scenario is over wireless links > supporting low-power mobile devices. If we ignore this scenario > it will be a judge mistake: > a) Battery powered mobile devices must be energy efficient to reduce the > size of the batteries. Also, they should not demand to many > computational resources, otherwise they would consume to much energy. > b) Wireless IP access is also in scope because many devices get Internet > access LTE, WLAN, Wimax, UMTS, etc. > > > Bluetooth headsets are somewhat a special case. Actually, they are two > cases: > 1) Headphones (A2DP): For me it is not clear whether supporting the > Internet CODEC on top of A2DP (which is - by the way - already > possible according to Bluetooth spec A2DP V1.2) or using the Internet COD= EC > till the Bluetooth AP and transcoding to SBC is more > efficient, cost effect, or energy saving. > 2) Mic (HFP): Here is the scheduling of 3.75 or 7.5ms might be an importa= nt > requirement that the Internet CODEC cannot fulfill > always because it must adapt its parameters to the Internet transmission > path not just to the Bluetooth link. > > Thus, I would recommend to write a liaison statement to Bluetooth AVT gro= up > and ask whether they would have interest to include the > Internet CODEC into a future version of A2DP. Definitely, this must not > happen soon because the they can do is only if the Internet > CODEC is finishing. Supporting HFP might be more difficult than A2DP > because of the very tough requirements on efficiency. > > With best regards, > > Christian > > --------------------------------------------------------------- > Dr.-Ing. Christian Hoene > Interactive Communication Systems (ICS), University of T=FCbingen > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://www.net.uni-tuebingen.de/ > > > >-----Original Message----- > >From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf O= f > Raymond (Juin-Hwey) Chen > >Sent: Monday, April 26, 2010 11:02 PM > >To: Mikael Abrahamsson > >Cc: codec@ietf.org > >Subject: Re: [codec] #16: Multicast? > > > >Hi Mikael, > > > >Thanks for sharing your experience using a BT headset for Skype calls. = I > think part of the quality > >degradation that you experienced was due to the reduction of the audio > bandwidth to narrowband (8 kHz > >sampling, 3.4 kHz bandwidth), and another part of the degradation was du= e > to the audible coding noise > >of the CVSD codec, a 40-year-old coding technology first proposed in 197= 0. > > > >If a high-quality, low-complexity, wider bandwidth IETF codec mode can b= e > implemented in Skype and the > >Bluetooth headset to avoid the CVSD transcoding (together with wideband > upgrade of the transducers and > >audio path in the BT headset, of course), then not only will you get muc= h > better speech quality in > >your Skype calls than what you have experienced, but also you will get a > lower latency. This is > >because transcoding between the Skype codec and CVSD not only accumulate= s > the coding distortion of the > >two codecs, but also accumulates the coding delays. Although CVSD is a > sample-by-sample codec, BT > >headsets still transmit the CVSD bit-stream in 3.75 ms or 7.5 ms packets= , > and they can potentially add > >a one-way delay up to 20 ~ 25 ms through the Bluetooth headset (the exac= t > delay depends on the > >implementation). > > > >While we were discussing whether a 5 ms packet size can even be > considered, for many years Bluetooth > >headsets have been using an even smaller 3.75 ms packet size. > > > >Best Regards, > > > >Raymond > > > >-----Original Message----- > >From: Mikael Abrahamsson [mailto:swmike@swm.pp.se] > >Sent: Sunday, April 25, 2010 1:06 AM > >To: Raymond (Juin-Hwey) Chen > >Cc: Koen Vos; codec@ietf.org > >Subject: Re: [codec] #16: Multicast? > > > >On Sat, 24 Apr 2010, Raymond (Juin-Hwey) Chen wrote: > > > >> (7) Already a lot of people are used to using Bluetooth headsets to ma= ke > >> phone calls today. If they have a choice, many of these people will > >> also want to use Bluetooth headsets to make Internet phone calls, not > >> only through computers, but also through smart phones connected to WiF= i > >> or cellular networks. As more and more states and countries pass laws > >> to ban the use of cell phones that are not in hands-free mode while > >> driving, the number of Bluetooth headset users will only increase with > >> time, and many of them will want to make Internet-based phone calls. > > > >I purchased a BT headset with the anticipation of using it with my > >computer to make Skype calls. I tried it, but the sound quality when doi= ng > >bidirectional audio (whatever that mode is called) is not good enough, i= t > >worsens the "skype IP" call quality. I agree that the use case is > >interesting, but as long as BT sound quality is what it is, it's really > >only the "low end" type sound quality we're talking about. > > > >But yes, I make skype IP calls with my Nokia N900 using BT sometimes, so > >the use case example is definitely valid. > > > >-- > >Mikael Abrahamsson email: swmike@swm.pp.se > > > > > >_______________________________________________ > >codec mailing list > >codec@ietf.org > >https://www.ietf.org/mailman/listinfo/codec > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001485f1d92addee380485746480 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Christian

I agree that Wireless IP is in scope, one could also ar= gue that LTE=20 might be in scope, since it will be using IPv6.

As we all know, the = internet runs over multiple physical layers, and usually an end-to-end conn= ection uses more than one physical layer.=A0 So I am not sure how we can tr= anslate layer 2 constraints into requirements for CODEC itself.

I can see how it might impact the RTP packetization - allowing frames t= o be split across packets would allow media-aware devices to adjust the pac= ketization to optimize delivery.=A0

BTW, I am a bit puzzled by the = G.722 statement, since it can run at a 7.5 ms packet delivery schedule (usi= ng 60 payload bytes per packet).

Stephen Botzko





On Fri= , Apr 30, 2010 at 8:23 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote= :
Hi,

I just want to share some insights from the recent development of Bluetooth= 's Hands-Free Profile (HFP) version 1.5, which supports
wideband speech. =A0One main requirement were on the frame size of 7.5 ms b= ecause the Bluetooth MAC protocol support scheduling at
this interval. Actually, to achieve this they modified SBC to work on 15 bl= ocks instead of 4,8,12 or 16 blocks and they decided
against G.722.

The lesson to learn is about the importance of MAC protocol. To get a effic= ient, low power, and mobile device you have to consider
the impact of packet scheduling. If packets are scheduled regular, the MAC = protocol can work more efficient. The more irregular
packet arrive, the more expensive a packet transmission gets.

Actually, you can translate the cost of packet scheduling to bits per packe= t. Depending on the wireless technology, it might vary
substantially. The worst case is 802.11b at 11 Mbps at long preamble - then= , you can add about 1300 bytes to every packet just for
physical headers and MAC scheduling. However, more modern technologies like= LTE and IEEE 802.11n are much more efficient in terms of
per packet overhead.


If you ask me, one important usage scenario is over wireless links supporti= ng low-power mobile devices. If we ignore this scenario
it will be a judge mistake:
a) Battery powered mobile devices must be energy efficient to reduce the si= ze of the batteries. Also, they should not demand to many
computational resources, otherwise they would consume to much energy.
b) Wireless IP access is also in scope because many devices get Internet ac= cess LTE, WLAN, Wimax, UMTS, etc.


Bluetooth headsets are somewhat a special case. Actually, they are two case= s:
1) Headphones (A2DP): For me it is not clear whether supporting the Interne= t CODEC on top of A2DP (which is - by the way - already
possible according to Bluetooth spec A2DP V1.2) or using the Internet CODEC= till the Bluetooth AP and transcoding to SBC is more
efficient, cost effect, or energy saving.
2) Mic (HFP): Here is the scheduling of 3.75 or 7.5ms might be an important= requirement that the Internet CODEC cannot fulfill
always because it must adapt its parameters to the Internet transmission pa= th not just to the Bluetooth link.

Thus, I would recommend to write a liaison statement to Bluetooth AVT group= and ask whether they would have interest to include the
Internet CODEC into a future version of A2DP. Definitely, this must not hap= pen soon because the they can do is only if the Internet
CODEC is finishing. Supporting HFP might be more difficult than A2DP becaus= e of the very tough requirements on efficiency.

With best regards,

=A0Christian

---------------------------------------------------------------
Dr.-Ing. Christian Hoene
Interactive Communication Systems (ICS), University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://www.n= et.uni-tuebingen.de/


>-----Original Message-----
>From: codec-bounces@ietf.org<= /a> [mailto:codec-bounces@ietf.or= g] On Behalf Of Raymond (Juin-Hwey) Chen
>Sent: Monday, April 26, 2010 11:02 PM
>To: Mikael Abrahamsson
>Cc: codec@ietf.org
>Subject: Re: [codec] #16: Multicast?
>
>Hi Mikael,
>
>Thanks for sharing your experience using a BT headset for Skype calls. = =A0I think part of the quality
>degradation that you experienced was due to the reduction of the audio = bandwidth to narrowband (8 kHz
>sampling, 3.4 kHz bandwidth), and another part of the degradation was d= ue to the audible coding noise
>of the CVSD codec, a 40-year-old coding technology first proposed in 19= 70.
>
>If a high-quality, low-complexity, wider bandwidth IETF codec mode can = be implemented in Skype and the
>Bluetooth headset to avoid the CVSD transcoding (together with wideband= upgrade of the transducers and
>audio path in the BT headset, of course), then not only will you get mu= ch better speech quality in
>your Skype calls than what you have experienced, but also you will get = a lower latency. =A0This is
>because transcoding between the Skype codec and CVSD not only accumulat= es the coding distortion of the
>two codecs, but also accumulates the coding delays. =A0Although CVSD is= a sample-by-sample codec, BT
>headsets still transmit the CVSD bit-stream in 3.75 ms or 7.5 ms packet= s, and they can potentially add
>a one-way delay up to 20 ~ 25 ms through the Bluetooth headset (the exa= ct delay depends on the
>implementation).
>
>While we were discussing whether a 5 ms packet size can even be conside= red, for many years Bluetooth
>headsets have been using an even smaller 3.75 ms packet size.
>
>Best Regards,
>
>Raymond
>
>-----Original Message-----
>From: Mikael Abrahamsson [mailto:sw= mike@swm.pp.se]
>Sent: Sunday, April 25, 2010 1:06 AM
>To: Raymond (Juin-Hwey) Chen
>Cc: Koen Vos; codec@ietf.org
>Subject: Re: [codec] #16: Multicast?
>
>On Sat, 24 Apr 2010, Raymond (Juin-Hwey) Chen wrote:
>
>> (7) Already a lot of people are used to using Bluetooth headsets t= o make
>> phone calls today. =A0If they have a choice, many of these people = will
>> also want to use Bluetooth headsets to make Internet phone calls, = not
>> only through computers, but also through smart phones connected to= WiFi
>> or cellular networks. =A0As more and more states and countries pas= s laws
>> to ban the use of cell phones that are not in hands-free mode whil= e
>> driving, the number of Bluetooth headset users will only increase = with
>> time, and many of them will want to make Internet-based phone call= s.
>
>I purchased a BT headset with the anticipation of using it with my
>computer to make Skype calls. I tried it, but the sound quality when do= ing
>bidirectional audio (whatever that mode is called) is not good enough, = it
>worsens the "skype IP" call quality. I agree that the use cas= e is
>interesting, but as long as BT sound quality is what it is, it's re= ally
>only the "low end" type =A0sound quality we're talking ab= out.
>
>But yes, I make skype IP calls with my Nokia N900 using BT sometimes, s= o
>the use case example is definitely valid.
>
>--
>Mikael Abrahamsson =A0 =A0email: sw= mike@swm.pp.se
>
>
>_______________________________________________
>codec mailing list
>codec@ietf.org
>https://www.ietf.org/mailman/listinfo/codec

_______________________________________________
codec mailing list
codec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/codec

--001485f1d92addee380485746480-- From fluffy@cisco.com Fri Apr 30 07:34:41 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EFDE28C267 for ; Fri, 30 Apr 2010 07:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.437 X-Spam-Level: X-Spam-Status: No, score=-109.437 tagged_above=-999 required=5 tests=[AWL=-0.327, BAYES_05=-1.11, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0n+xJCKMm7lO for ; Fri, 30 Apr 2010 07:34:40 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 259B628C262 for ; Fri, 30 Apr 2010 07:34:38 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgcFADaH2kurRN+K/2dsb2JhbACRAYwfcaRnmg6FEgSDPg X-IronPort-AV: E=Sophos;i="4.52,302,1270425600"; d="scan'208";a="122990570" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-4.cisco.com with ESMTP; 30 Apr 2010 14:34:24 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id o3UEYNWR008096 for ; Fri, 30 Apr 2010 14:34:24 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <83E16843-6B66-4C04-A3E2-E3DAD0FB704F@csperkins.org> Date: Fri, 30 Apr 2010 08:34:22 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <062.4d06e5df10a25734771c5c65c2b40c5c@tools.ietf.org> <83E16843-6B66-4C04-A3E2-E3DAD0FB704F@csperkins.org> To: codec@ietf.org X-Mailer: Apple Mail (2.1078) Subject: Re: [codec] #17: Feedback and control loop? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 14:34:41 -0000 On Apr 21, 2010, at 4:57 AM, Colin Perkins wrote: >> . >=20 >=20 > My suggestion would be that you specify how the codec can adapt based = on the feedback that RTP/RTCP, and its various extensions, can provide. = More on the style of "if you have this information, this is how you can = adapt" than "you must use this information to adapt in this way". +1=20 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Fri Apr 30 07:36:16 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A63D928C263 for ; Fri, 30 Apr 2010 07:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.135 X-Spam-Level: X-Spam-Status: No, score=-110.135 tagged_above=-999 required=5 tests=[AWL=0.464, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5-Fp7LBiygP1 for ; Fri, 30 Apr 2010 07:36:15 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E832D28C262 for ; Fri, 30 Apr 2010 07:36:15 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADaH2kurRN+J/2dsb2JhbACdIHGkZ5oOhRIEgz4 X-IronPort-AV: E=Sophos;i="4.52,302,1270425600"; d="scan'208";a="122992051" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 30 Apr 2010 14:36:02 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o3UEa1Vk021933; Fri, 30 Apr 2010 14:36:02 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <002001cae13a$b0f290c0$12d7b240$@de> Date: Fri, 30 Apr 2010 08:35:59 -0600 Content-Transfer-Encoding: 7bit Message-Id: <2F367D63-8217-4E61-BBB1-9E695A8D5CBD@cisco.com> References: <062.407382d901e5e6b8dea15d6e3ae1a2c8@tools.ietf.org> <071.5e023ebb9f76cbef6eb8421c4bc0c385@tools.ietf.org> <002001cae13a$b0f290c0$12d7b240$@de> To: Christian Hoene X-Mailer: Apple Mail (2.1078) Cc: codec@ietf.org Subject: Re: [codec] #13: reference use-cases and topologies! X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 14:36:16 -0000 On Apr 21, 2010, at 4:09 AM, Christian Hoene wrote: > e) IPend-to-legal_interception-to-X See RFC 2804 Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From fluffy@cisco.com Fri Apr 30 08:01:51 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BEA903A6939 for ; Fri, 30 Apr 2010 08:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.946 X-Spam-Level: X-Spam-Status: No, score=-108.946 tagged_above=-999 required=5 tests=[AWL=-0.206, BAYES_20=-0.74, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UGzngF0MzMPJ for ; Fri, 30 Apr 2010 08:01:50 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id E3BD23A6895 for ; Fri, 30 Apr 2010 08:01:49 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABKN2kurR7Ht/2dsb2JhbACdIHGkaJoRhRIEgz4 X-IronPort-AV: E=Sophos;i="4.52,302,1270425600"; d="scan'208";a="123019139" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 30 Apr 2010 15:01:36 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o3UF1ZoH021677; Fri, 30 Apr 2010 15:01:35 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Fri, 30 Apr 2010 09:01:33 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> To: Raymond (Juin-Hwey) Chen X-Mailer: Apple Mail (2.1078) Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Apr 2010 15:01:51 -0000 I don't agree with this logic.=20 You seem to be claiming that network delay scales as a factor of audio = frame length. I don't think this is true. If the network takes 100 ms to = deliver a 5 ms audio packet from a DSL subscriber in Europe to a = conference bridge in the US, I see no reason to believe that a packet = with 20 ms of audio is going to have a significantly different network = transport time. So if we were on a conference call with over 300 ms of = latency (which is very common BTW), it does not seem that changing from = 20 ms to 5 ms is going to result in significant (say over 25%) reduction = of latency. I'm not aging for or against 5 ms packets, I'm just saying the logic of = "network latency is 5x the packet audio size" makes no sense to me.=20 Cullen =20 On Apr 23, 2010, at 7:43 PM, Raymond (Juin-Hwey) Chen wrote: > Hi Jean-Marc, >=20 > I agree that the 20 ms frame size or packet size is more efficient in = bit-rate. However, this comment doesn't address my original point on = the need to have a low-delay IETF codec for the conferencing bridge = scenario, where the voice signal will travel through the codec twice (2 = tandems), thus doubling the one-way codec delay. >=20 > As you are well aware of, codec design involves many trade-offs = between the four major attributes of a codec: delay, complexity, = bit-rate, and quality. For a given codec architecture, improving one = attribute normally means sacrificing at least one other attribute. = Nothing comes for free. Therefore, yes, to get low delay, you need to = pay the price of lower bit-rate efficiency, but you can also view it = another way: to get higher bit-rate efficiency by using a 20 ms frame = size, you pay the price of a higher codec delay. The question to ask = then, is not which frame size is more bit-rate efficient, but whether = there are application scenarios where a 20 ms frame size will simply = make the one-way delay way too long and greatly degrade the users' = communication experience. I believe the answer to the latter question is = a definite "yes". >=20 > Let's do some math to see why that is so. Essentially all cellular = codecs use a frame size of 20 ms, yet the one-way delay of a = cell-to-landline call is typically 80 to 110 ms, or 4 to 5.5 times the = codec frame size. This is because you have not only the codec buffering = delay, but also processing delay, transmission delay, and delay due to = processor sharing using real-time OS, etc. An IP phone guru told me = that for a typical IP phone application, it is also quite common to see = a one-way delay of 5 times the codec frame size. Let's just take 5X = codec frame size as the one-way delay of a typical implementation. = Then, even if all conference participants use their computers to call = the conference bridge, if the IETF codec has a frame size of 20 ms, then = after the voice signal of a talker goes through the IETF codec to the = bridge, it already takes 100 ms one-way delay. After the bridge decodes = all channels, mixes, and re-encodes with the IETF codec and send to = every particip > ant, the one-way delay is now already up to 200 ms, way more than the = 150 ms limit I mentioned in my last email. Now if a talker call into = the conference bridge through a cell phone call that has 100 ms one-way = delay to the edge of the Internet, by the time everyone else hears his = voice, it is already 300 ms later. Anyone trying to interrupt that cell = phone caller will experience the talk-stop-talk-stop problem I mentioned = before. Now if another cell phone caller call into the conference = bridge, then the one-way delay of his voice to the first cell phone = caller will be a whopping 400 ms! That would probably turn it into = half-duplex effectively. >=20 > When we talk about "high-quality" conference call, it is much more = than just the quality or distortion level of the voice signal; the = one-way delay is also an important and integral part of the perceived = quality of the communication link. This is clearly documented and = well-modeled in the E-model of the ITU-T G.107, and the 150 ms limit, = beyond which the perceived quality sort of "falls off the cliff", was = also obtained after careful study by telephony experts at the ITU-T. It = would be wise for the IETF codec WG to heed the warning of the ITU-T = experts and keep the one-way delay less than 150 ms. >=20 > In contrast, if the IETF codec has a codec frame size and packet size = of 5 ms, then the on-the-net one-way conferencing delay is only 50 ms. = Even if you use a longer jitter buffer, the one-way delay is still = unlikely to go above 100 ms, which is still well within the ITU-T's 150 = ms guideline. >=20 > True, sending 5 ms packets means the packet header overhead would be = higher, but that's a small price to pay to enable the conference = participants to have a high-quality experience by avoiding the problems = associated with a long one-way delay. The bit-rate penalty is not 64 = kb/s as you said, but 3/4 of that, or 48 kb/s, because you don't get = zero packet header overhead for a 20 ms frame size, but 16 kb/s, so 64 - = 16 =3D 48. =20 >=20 > Now, with the exception of a small percentage of Internet users who = still use dial-up modems, the vast majority of the Internet users today = connect to the Internet at a speed of at least several hundred kb/s, and = most are in the Mbps range. A 48 kb/s penalty is really a fairly small = price to pay for the majority of Internet users when it can give them a = much better high-quality experience with an much lower delay. >=20 > Furthermore, it is possible to use header compression technology to = shrink that 48 kb/s penalty to almost nothing. >=20 > Also, even if a 5 ms packet size is an overkill in some situations, a = codec with a 5 ms frame size can easily packs two frames of compressed = bit-stream into a 10 ms packet. Then the packet header overhead = bit-rate would be 32 kb/s, so the penalty shrinks by a factor of 3 from = 48 kb/s to 32 - 16 =3D 16 kb/s. With 10 ms packets, the one-way = conferencing delay would be 100 ms, still well within the 150 ms = guideline. (Actually, since the internal "thread rate" of real-time OS = can still run at 5 ms intervals, the one-way delay can be made less than = 100 ms, but that's too much detail to go into.) In contrast, a codec = with a 20 ms frame size cannot send its bit-stream with 10 ms packets, = unless it spreads each frame into two packets, which is what IETF AVT = advises against, because it will effectively double the packet loss = rate. >=20 > The way I see it, for conference bridge applications at least, I think = it would be a big mistake for IETF to recommend a codec with a frame = size of 20 ms or higher. =46rom my analysis above, by doing that we = will be stuck with too long a delay and the associated problems. =20 >=20 > Best Regards, >=20 > Raymond >=20 > -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca]=20 > Sent: Thursday, April 22, 2010 9:05 PM > To: Raymond (Juin-Hwey) Chen > Cc: Christian Hoene; 'stephen botzko'; codec@ietf.org > Subject: Re: [codec] #16: Multicast? >=20 > Hi, >=20 > See me comments below. >=20 >> [Raymond]: High quality is a given, but I would like to emphasize the=20= >> importance of low latency. >>=20 >> (1) It is well-known that the longer the latency, the lower the=20 >> perceived quality of the communication link. The E-model in the ITU-T=20= >> Recommendation G.107 models such communication quality in MOS_cqe,=20 >> which among other things depends on the so-called "delay impairment=20= >> factor" /Id/. Basically, MOS_cqe is a monotonically decreasing=20 >> function of increasing latency, and beyond about 150 ms one-way = delay,=20 >> the perceived quality of the communication link drops rapidly with=20 >> further delay increase. >>=20 >=20 > As the author of CELT, I obviously agree that latency is an important=20= > aspect for this codec :-) That being said, I tend to say that 20 ms is=20= > still the most widely used frame size, so we might as well optimise = for=20 > that. This is not really a problem because as the frame size goes = down,=20 > the overhead of the IP/UDP/RTP headers go up, so the codec bit-rate=20 > becomes a bit less of an issue. For example, with 5 ms frames, we = would=20 > already be sending 64 kb/s worth of headers (excluding the link = layer),=20 > so we might as well spend about as many bits on the actual payload as = we=20 > spend on the headers. And with 64 kb/s of payload, we can actually = have=20 > high-quality full-band audio. >=20 >> 1) If a conference bridge has to decode a large number of voice=20 >> channels, mix, and re-encode, and if compressed-domain mixing cannot=20= >> be done (which is usually the case), then it is important to keep the=20= >> decoder complexity low. >=20 > Definitely agree here. The decoder complexity is very important. Not=20= > only because of mixing issue, but also because the decoder is = generally=20 > not allowed to take shortcuts to save on complexity (unlike the=20 > encoder). As for compressed-domain mixing, as you say it is not always=20= > available, but *if* we can do it (even if only partially), then that = can=20 > result in a "free" reduction in decoder complexity for mixing. >=20 >> 2) In topology b) of your other email=20 >> (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, = or=20 >> VoIP gateway, often has to encode and decode thousands of voice=20 >> channels in a single box, so not only the computational complexity,=20= >> but also the per-instance RAM size requirement of the codec become=20 >> very important for achieving high channel density in the gateway. >>=20 >=20 > Agreed here, although I would say that per-instance RAM -- as long as=20= > it's reasonable -- is probably a bit less important than complexity. >=20 >> 3) Many telephone terminal devices at the edge of the Internet use=20 >> embedded processors with limited processing power, and the processors=20= >> also have to handle many tasks other than speech coding. If the IETF=20= >> codec complexity is too high, some of such devices may not have=20 >> sufficient processing power to run it. Even if the codec can fit, = some=20 >> battery-powered mobile devices may prefer to run a lower-complexity=20= >> codec to reduce power consumption and battery drain. For example, = even=20 >> if you make a Internet phone call from a computer, you may like the=20= >> convenience of using a Bluetooth headset that allows you to walk=20 >> around a bit and have hands-free operation. Currently most Bluetooth=20= >> headsets have small form factors with a tiny battery. This puts a=20 >> severe constraint on power consumption. Bluetooth headset chips=20 >> typically have very limited processing capability, and it has to=20 >> handle many other tasks such as echo cancellation and noise = reduction.=20 >> There is just not enough processing power to handle a relatively=20 >> high-complexity codec. Most BT headsets today relies on the extremely=20= >> low-complexity, hardware-based CVSD codec at 64 kb/s to transmit=20 >> narrowband voice, but CVSD has audible coding noise, so it degrades=20= >> the overall audio quality. If the IETF codec has low enough=20 >> complexity, it would be possible to directly encode and decode the=20 >> IETF codec bit-stream at the BT headset, thus avoiding the quality=20 >> degradation of CVSD transcoding. >>=20 >=20 > Any idea what the complexity requirements would be for this use-case = to=20 > be possible? >=20 > Cheers, >=20 > Jean-Marc >=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From rchen@broadcom.com Fri Apr 30 18:41:05 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4CD53A680D for ; Fri, 30 Apr 2010 18:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.445 X-Spam-Level: X-Spam-Status: No, score=-1.445 tagged_above=-999 required=5 tests=[AWL=1.154, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2wD5UCnbVuzA for ; Fri, 30 Apr 2010 18:41:03 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 1C7643A67EB for ; Fri, 30 Apr 2010 18:41:03 -0700 (PDT) Received: from [10.9.200.131] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Fri, 30 Apr 2010 18:40:35 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from IRVEXCHCCR01.corp.ad.broadcom.com ([10.252.49.31]) by IRVEXCHHUB01.corp.ad.broadcom.com ([10.9.200.131]) with mapi; Fri, 30 Apr 2010 18:40:36 -0700 From: "Raymond (Juin-Hwey) Chen" To: "Cullen Jennings" Date: Fri, 30 Apr 2010 18:40:31 -0700 Thread-Topic: [codec] #16: Multicast? Thread-Index: AcrodhEDoOVTQLDJTYOv/sen9LrdfwAF9z4Q Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> In-Reply-To: <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-hashedpuzzle: Ahu8 AvJ0 Brk+ B0zo CGLH CPaa EMLg FyPs GPD3 IVai IYoB LLER MTbP MmO/ QDBH SEL5; 2; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAZgBsAHUAZgBmAHkAQABjAGkAcwBjAG8ALgBjAG8AbQA=; Sosha1_v1; 7; {8A82350B-E96C-452C-81F3-211ACA0FB772}; cgBjAGgAZQBuAEAAYgByAG8AYQBkAGMAbwBtAC4AYwBvAG0A; Sat, 01 May 2010 01:40:31 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAIwAxADYAOgAgAE0AdQBsAHQAaQBjAGEAcwB0AD8A x-cr-puzzleid: {8A82350B-E96C-452C-81F3-211ACA0FB772} acceptlanguage: en-US MIME-Version: 1.0 X-WSS-ID: 67C5591931G110033959-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 01:41:05 -0000 Hi Cullen, After my original email below, there were several follow-up emails about th= is, and in those emails I have replaced this oversimplified 5X formula for = total delay with the following more detailed formula for typical IP phone i= mplementations: One-way delay =3D codec-independent delay + 3*(codec frame size) + (codec= look-ahead) + (codec filtering delay if any) This formula was obtained from an experienced engineer who has been working= on IP phones related fields for more than a decade, and the formula was ba= sed on actual observed one-way delay in real-world IP phone implementations= . Similar 3X multiplier is also observed in VoIP gateways. Even with a fa= st processor/system optimized from ground up to be low-delay, the measured = "codec-dependent" one-way delay of such a VoIP gateway using the G.711 code= c with a 5 ms frame/packet size is between 12 and 17 ms, or around 3X the f= rame size. The ITU-T uses 2X codec frame size + look-ahead as the one-way codec delay.= In some ideal situations, that 2X multiplier is probably achievable, but i= n more typical situations, 3X is what you are much more likely to find in r= eal-world implementations. Raymond =20 -----Original Message----- From: Cullen Jennings [mailto:fluffy@cisco.com]=20 Sent: Friday, April 30, 2010 8:02 AM To: Raymond (Juin-Hwey) Chen Cc: codec@ietf.org Subject: Re: [codec] #16: Multicast? I don't agree with this logic.=20 You seem to be claiming that network delay scales as a factor of audio fram= e length. I don't think this is true. If the network takes 100 ms to delive= r a 5 ms audio packet from a DSL subscriber in Europe to a conference bridg= e in the US, I see no reason to believe that a packet with 20 ms of audio i= s going to have a significantly different network transport time. So if we = were on a conference call with over 300 ms of latency (which is very commo= n BTW), it does not seem that changing from 20 ms to 5 ms is going to resul= t in significant (say over 25%) reduction of latency. I'm not aging for or against 5 ms packets, I'm just saying the logic of "ne= twork latency is 5x the packet audio size" makes no sense to me.=20 Cullen =20 On Apr 23, 2010, at 7:43 PM, Raymond (Juin-Hwey) Chen wrote: > Hi Jean-Marc, >=20 > I agree that the 20 ms frame size or packet size is more efficient in bit= -rate. However, this comment doesn't address my original point on the need= to have a low-delay IETF codec for the conferencing bridge scenario, where= the voice signal will travel through the codec twice (2 tandems), thus dou= bling the one-way codec delay. >=20 > As you are well aware of, codec design involves many trade-offs between t= he four major attributes of a codec: delay, complexity, bit-rate, and quali= ty. For a given codec architecture, improving one attribute normally means= sacrificing at least one other attribute. Nothing comes for free. Theref= ore, yes, to get low delay, you need to pay the price of lower bit-rate eff= iciency, but you can also view it another way: to get higher bit-rate effic= iency by using a 20 ms frame size, you pay the price of a higher codec dela= y. The question to ask then, is not which frame size is more bit-rate effi= cient, but whether there are application scenarios where a 20 ms frame size= will simply make the one-way delay way too long and greatly degrade the us= ers' communication experience. I believe the answer to the latter question = is a definite "yes". >=20 > Let's do some math to see why that is so. Essentially all cellular codec= s use a frame size of 20 ms, yet the one-way delay of a cell-to-landline ca= ll is typically 80 to 110 ms, or 4 to 5.5 times the codec frame size. This= is because you have not only the codec buffering delay, but also processin= g delay, transmission delay, and delay due to processor sharing using real-= time OS, etc. An IP phone guru told me that for a typical IP phone applica= tion, it is also quite common to see a one-way delay of 5 times the codec f= rame size. Let's just take 5X codec frame size as the one-way delay of a t= ypical implementation. Then, even if all conference participants use their= computers to call the conference bridge, if the IETF codec has a frame siz= e of 20 ms, then after the voice signal of a talker goes through the IETF c= odec to the bridge, it already takes 100 ms one-way delay. After the bridg= e decodes all channels, mixes, and re-encodes with the IETF codec and send = to every particip > ant, the one-way delay is now already up to 200 ms, way more than the 150= ms limit I mentioned in my last email. Now if a talker call into the conf= erence bridge through a cell phone call that has 100 ms one-way delay to th= e edge of the Internet, by the time everyone else hears his voice, it is al= ready 300 ms later. Anyone trying to interrupt that cell phone caller will= experience the talk-stop-talk-stop problem I mentioned before. Now if ano= ther cell phone caller call into the conference bridge, then the one-way de= lay of his voice to the first cell phone caller will be a whopping 400 ms! = That would probably turn it into half-duplex effectively. >=20 > When we talk about "high-quality" conference call, it is much more than j= ust the quality or distortion level of the voice signal; the one-way delay = is also an important and integral part of the perceived quality of the comm= unication link. This is clearly documented and well-modeled in the E-model= of the ITU-T G.107, and the 150 ms limit, beyond which the perceived quali= ty sort of "falls off the cliff", was also obtained after careful study by = telephony experts at the ITU-T. It would be wise for the IETF codec WG to = heed the warning of the ITU-T experts and keep the one-way delay less than = 150 ms. >=20 > In contrast, if the IETF codec has a codec frame size and packet size of = 5 ms, then the on-the-net one-way conferencing delay is only 50 ms. Even if= you use a longer jitter buffer, the one-way delay is still unlikely to go = above 100 ms, which is still well within the ITU-T's 150 ms guideline. >=20 > True, sending 5 ms packets means the packet header overhead would be high= er, but that's a small price to pay to enable the conference participants t= o have a high-quality experience by avoiding the problems associated with a= long one-way delay. The bit-rate penalty is not 64 kb/s as you said, but = 3/4 of that, or 48 kb/s, because you don't get zero packet header overhead = for a 20 ms frame size, but 16 kb/s, so 64 - 16 =3D 48. =20 >=20 > Now, with the exception of a small percentage of Internet users who still= use dial-up modems, the vast majority of the Internet users today connect = to the Internet at a speed of at least several hundred kb/s, and most are i= n the Mbps range. A 48 kb/s penalty is really a fairly small price to pay = for the majority of Internet users when it can give them a much better high= -quality experience with an much lower delay. >=20 > Furthermore, it is possible to use header compression technology to shrin= k that 48 kb/s penalty to almost nothing. >=20 > Also, even if a 5 ms packet size is an overkill in some situations, a cod= ec with a 5 ms frame size can easily packs two frames of compressed bit-str= eam into a 10 ms packet. Then the packet header overhead bit-rate would be= 32 kb/s, so the penalty shrinks by a factor of 3 from 48 kb/s to 32 - 16 = =3D 16 kb/s. With 10 ms packets, the one-way conferencing delay would be 10= 0 ms, still well within the 150 ms guideline. (Actually, since the internal= "thread rate" of real-time OS can still run at 5 ms intervals, the one-way= delay can be made less than 100 ms, but that's too much detail to go into.= ) In contrast, a codec with a 20 ms frame size cannot send its bit-stream w= ith 10 ms packets, unless it spreads each frame into two packets, which is = what IETF AVT advises against, because it will effectively double the packe= t loss rate. >=20 > The way I see it, for conference bridge applications at least, I think it= would be a big mistake for IETF to recommend a codec with a frame size of = 20 ms or higher. From my analysis above, by doing that we will be stuck wi= th too long a delay and the associated problems. =20 >=20 > Best Regards, >=20 > Raymond >=20 > -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca]=20 > Sent: Thursday, April 22, 2010 9:05 PM > To: Raymond (Juin-Hwey) Chen > Cc: Christian Hoene; 'stephen botzko'; codec@ietf.org > Subject: Re: [codec] #16: Multicast? >=20 > Hi, >=20 > See me comments below. >=20 >> [Raymond]: High quality is a given, but I would like to emphasize the=20 >> importance of low latency. >>=20 >> (1) It is well-known that the longer the latency, the lower the=20 >> perceived quality of the communication link. The E-model in the ITU-T=20 >> Recommendation G.107 models such communication quality in MOS_cqe,=20 >> which among other things depends on the so-called "delay impairment=20 >> factor" /Id/. Basically, MOS_cqe is a monotonically decreasing=20 >> function of increasing latency, and beyond about 150 ms one-way delay,=20 >> the perceived quality of the communication link drops rapidly with=20 >> further delay increase. >>=20 >=20 > As the author of CELT, I obviously agree that latency is an important=20 > aspect for this codec :-) That being said, I tend to say that 20 ms is=20 > still the most widely used frame size, so we might as well optimise for=20 > that. This is not really a problem because as the frame size goes down,=20 > the overhead of the IP/UDP/RTP headers go up, so the codec bit-rate=20 > becomes a bit less of an issue. For example, with 5 ms frames, we would=20 > already be sending 64 kb/s worth of headers (excluding the link layer),=20 > so we might as well spend about as many bits on the actual payload as we= =20 > spend on the headers. And with 64 kb/s of payload, we can actually have=20 > high-quality full-band audio. >=20 >> 1) If a conference bridge has to decode a large number of voice=20 >> channels, mix, and re-encode, and if compressed-domain mixing cannot=20 >> be done (which is usually the case), then it is important to keep the=20 >> decoder complexity low. >=20 > Definitely agree here. The decoder complexity is very important. Not=20 > only because of mixing issue, but also because the decoder is generally=20 > not allowed to take shortcuts to save on complexity (unlike the=20 > encoder). As for compressed-domain mixing, as you say it is not always=20 > available, but *if* we can do it (even if only partially), then that can= =20 > result in a "free" reduction in decoder complexity for mixing. >=20 >> 2) In topology b) of your other email=20 >> (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, or=20 >> VoIP gateway, often has to encode and decode thousands of voice=20 >> channels in a single box, so not only the computational complexity,=20 >> but also the per-instance RAM size requirement of the codec become=20 >> very important for achieving high channel density in the gateway. >>=20 >=20 > Agreed here, although I would say that per-instance RAM -- as long as=20 > it's reasonable -- is probably a bit less important than complexity. >=20 >> 3) Many telephone terminal devices at the edge of the Internet use=20 >> embedded processors with limited processing power, and the processors=20 >> also have to handle many tasks other than speech coding. If the IETF=20 >> codec complexity is too high, some of such devices may not have=20 >> sufficient processing power to run it. Even if the codec can fit, some=20 >> battery-powered mobile devices may prefer to run a lower-complexity=20 >> codec to reduce power consumption and battery drain. For example, even=20 >> if you make a Internet phone call from a computer, you may like the=20 >> convenience of using a Bluetooth headset that allows you to walk=20 >> around a bit and have hands-free operation. Currently most Bluetooth=20 >> headsets have small form factors with a tiny battery. This puts a=20 >> severe constraint on power consumption. Bluetooth headset chips=20 >> typically have very limited processing capability, and it has to=20 >> handle many other tasks such as echo cancellation and noise reduction.=20 >> There is just not enough processing power to handle a relatively=20 >> high-complexity codec. Most BT headsets today relies on the extremely=20 >> low-complexity, hardware-based CVSD codec at 64 kb/s to transmit=20 >> narrowband voice, but CVSD has audible coding noise, so it degrades=20 >> the overall audio quality. If the IETF codec has low enough=20 >> complexity, it would be possible to directly encode and decode the=20 >> IETF codec bit-stream at the BT headset, thus avoiding the quality=20 >> degradation of CVSD transcoding. >>=20 >=20 > Any idea what the complexity requirements would be for this use-case to=20 > be possible? >=20 > Cheers, >=20 > Jean-Marc >=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From swmike@swm.pp.se Fri Apr 30 21:05:12 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 055513A6923 for ; Fri, 30 Apr 2010 21:05:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.771 X-Spam-Level: X-Spam-Status: No, score=-5.771 tagged_above=-999 required=5 tests=[AWL=0.478, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SMyV24yIOVE2 for ; Fri, 30 Apr 2010 21:05:10 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) by core3.amsl.com (Postfix) with ESMTP id 99ED03A6894 for ; Fri, 30 Apr 2010 21:05:09 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 1768CA0; Sat, 1 May 2010 06:04:50 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 12CC49C; Sat, 1 May 2010 06:04:50 +0200 (CEST) Date: Sat, 1 May 2010 06:04:50 +0200 (CEST) From: Mikael Abrahamsson To: "Raymond (Juin-Hwey) Chen" In-Reply-To: Message-ID: References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: "codec@ietf.org" Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 04:05:12 -0000 On Fri, 30 Apr 2010, Raymond (Juin-Hwey) Chen wrote: I think what the 2X 3X factor is handling is what we in the networking world calls "serialisation delay". Most equipment today receives the packet, looks at it, then sends it out (store and forward). That means that on a 2 megabit/s link, it takes: 1/2000000*100*8 .0004 (0.4ms) to send out a 100 byte packet. With multiple such links for the packet to traverse, it might be possible to see those kind of amlifications of frame size (even though I can't get it to amplify that much, for instance when going from 5ms to 20ms packet interval). Could be if there are a lot of slow links for the packet to traverse (512 kilobits/s for instance). We stop worrying about serialisation delays when speeds go over several hundred megabit/s, because on a gigabit ethernet link serialisation delay for a 1500 byte packet is 0.012 ms. > Hi Cullen, > > After my original email below, there were several follow-up emails about this, and in those emails I have replaced this oversimplified 5X formula for total delay with the following more detailed formula for typical IP phone implementations: > > One-way delay = codec-independent delay + 3*(codec frame size) + (codec look-ahead) + (codec filtering delay if any) > > This formula was obtained from an experienced engineer who has been working on IP phones related fields for more than a decade, and the formula was based on actual observed one-way delay in real-world IP phone implementations. Similar 3X multiplier is also observed in VoIP gateways. Even with a fast processor/system optimized from ground up to be low-delay, the measured "codec-dependent" one-way delay of such a VoIP gateway using the G.711 codec with a 5 ms frame/packet size is between 12 and 17 ms, or around 3X the frame size. > > The ITU-T uses 2X codec frame size + look-ahead as the one-way codec delay. In some ideal situations, that 2X multiplier is probably achievable, but in more typical situations, 3X is what you are much more likely to find in real-world implementations. > > Raymond > > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, April 30, 2010 8:02 AM > To: Raymond (Juin-Hwey) Chen > Cc: codec@ietf.org > Subject: Re: [codec] #16: Multicast? > > > I don't agree with this logic. > > You seem to be claiming that network delay scales as a factor of audio frame length. I don't think this is true. If the network takes 100 ms to deliver a 5 ms audio packet from a DSL subscriber in Europe to a conference bridge in the US, I see no reason to believe that a packet with 20 ms of audio is going to have a significantly different network transport time. So if we were on a conference call with over 300 ms of latency (which is very common BTW), it does not seem that changing from 20 ms to 5 ms is going to result in significant (say over 25%) reduction of latency. > > I'm not aging for or against 5 ms packets, I'm just saying the logic of "network latency is 5x the packet audio size" makes no sense to me. > > Cullen > > > > On Apr 23, 2010, at 7:43 PM, Raymond (Juin-Hwey) Chen wrote: > >> Hi Jean-Marc, >> >> I agree that the 20 ms frame size or packet size is more efficient in bit-rate. However, this comment doesn't address my original point on the need to have a low-delay IETF codec for the conferencing bridge scenario, where the voice signal will travel through the codec twice (2 tandems), thus doubling the one-way codec delay. >> >> As you are well aware of, codec design involves many trade-offs between the four major attributes of a codec: delay, complexity, bit-rate, and quality. For a given codec architecture, improving one attribute normally means sacrificing at least one other attribute. Nothing comes for free. Therefore, yes, to get low delay, you need to pay the price of lower bit-rate efficiency, but you can also view it another way: to get higher bit-rate efficiency by using a 20 ms frame size, you pay the price of a higher codec delay. The question to ask then, is not which frame size is more bit-rate efficient, but whether there are application scenarios where a 20 ms frame size will simply make the one-way delay way too long and greatly degrade the users' communication experience. I believe the answer to the latter question is a definite "yes". >> >> Let's do some math to see why that is so. Essentially all cellular codecs use a frame size of 20 ms, yet the one-way delay of a cell-to-landline call is typically 80 to 110 ms, or 4 to 5.5 times the codec frame size. This is because you have not only the codec buffering delay, but also processing delay, transmission delay, and delay due to processor sharing using real-time OS, etc. An IP phone guru told me that for a typical IP phone application, it is also quite common to see a one-way delay of 5 times the codec frame size. Let's just take 5X codec frame size as the one-way delay of a typical implementation. Then, even if all conference participants use their computers to call the conference bridge, if the IETF codec has a frame size of 20 ms, then after the voice signal of a talker goes through the IETF codec to the bridge, it already takes 100 ms one-way delay. After the bridge decodes all channels, mixes, and re-encodes with the IETF codec and send to every parti c > ip >> ant, the one-way delay is now already up to 200 ms, way more than the 150 ms limit I mentioned in my last email. Now if a talker call into the conference bridge through a cell phone call that has 100 ms one-way delay to the edge of the Internet, by the time everyone else hears his voice, it is already 300 ms later. Anyone trying to interrupt that cell phone caller will experience the talk-stop-talk-stop problem I mentioned before. Now if another cell phone caller call into the conference bridge, then the one-way delay of his voice to the first cell phone caller will be a whopping 400 ms! That would probably turn it into half-duplex effectively. >> >> When we talk about "high-quality" conference call, it is much more than just the quality or distortion level of the voice signal; the one-way delay is also an important and integral part of the perceived quality of the communication link. This is clearly documented and well-modeled in the E-model of the ITU-T G.107, and the 150 ms limit, beyond which the perceived quality sort of "falls off the cliff", was also obtained after careful study by telephony experts at the ITU-T. It would be wise for the IETF codec WG to heed the warning of the ITU-T experts and keep the one-way delay less than 150 ms. >> >> In contrast, if the IETF codec has a codec frame size and packet size of 5 ms, then the on-the-net one-way conferencing delay is only 50 ms. Even if you use a longer jitter buffer, the one-way delay is still unlikely to go above 100 ms, which is still well within the ITU-T's 150 ms guideline. >> >> True, sending 5 ms packets means the packet header overhead would be higher, but that's a small price to pay to enable the conference participants to have a high-quality experience by avoiding the problems associated with a long one-way delay. The bit-rate penalty is not 64 kb/s as you said, but 3/4 of that, or 48 kb/s, because you don't get zero packet header overhead for a 20 ms frame size, but 16 kb/s, so 64 - 16 = 48. >> >> Now, with the exception of a small percentage of Internet users who still use dial-up modems, the vast majority of the Internet users today connect to the Internet at a speed of at least several hundred kb/s, and most are in the Mbps range. A 48 kb/s penalty is really a fairly small price to pay for the majority of Internet users when it can give them a much better high-quality experience with an much lower delay. >> >> Furthermore, it is possible to use header compression technology to shrink that 48 kb/s penalty to almost nothing. >> >> Also, even if a 5 ms packet size is an overkill in some situations, a codec with a 5 ms frame size can easily packs two frames of compressed bit-stream into a 10 ms packet. Then the packet header overhead bit-rate would be 32 kb/s, so the penalty shrinks by a factor of 3 from 48 kb/s to 32 - 16 = 16 kb/s. With 10 ms packets, the one-way conferencing delay would be 100 ms, still well within the 150 ms guideline. (Actually, since the internal "thread rate" of real-time OS can still run at 5 ms intervals, the one-way delay can be made less than 100 ms, but that's too much detail to go into.) In contrast, a codec with a 20 ms frame size cannot send its bit-stream with 10 ms packets, unless it spreads each frame into two packets, which is what IETF AVT advises against, because it will effectively double the packet loss rate. >> >> The way I see it, for conference bridge applications at least, I think it would be a big mistake for IETF to recommend a codec with a frame size of 20 ms or higher. From my analysis above, by doing that we will be stuck with too long a delay and the associated problems. >> >> Best Regards, >> >> Raymond >> >> -----Original Message----- >> From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] >> Sent: Thursday, April 22, 2010 9:05 PM >> To: Raymond (Juin-Hwey) Chen >> Cc: Christian Hoene; 'stephen botzko'; codec@ietf.org >> Subject: Re: [codec] #16: Multicast? >> >> Hi, >> >> See me comments below. >> >>> [Raymond]: High quality is a given, but I would like to emphasize the >>> importance of low latency. >>> >>> (1) It is well-known that the longer the latency, the lower the >>> perceived quality of the communication link. The E-model in the ITU-T >>> Recommendation G.107 models such communication quality in MOS_cqe, >>> which among other things depends on the so-called "delay impairment >>> factor" /Id/. Basically, MOS_cqe is a monotonically decreasing >>> function of increasing latency, and beyond about 150 ms one-way delay, >>> the perceived quality of the communication link drops rapidly with >>> further delay increase. >>> >> >> As the author of CELT, I obviously agree that latency is an important >> aspect for this codec :-) That being said, I tend to say that 20 ms is >> still the most widely used frame size, so we might as well optimise for >> that. This is not really a problem because as the frame size goes down, >> the overhead of the IP/UDP/RTP headers go up, so the codec bit-rate >> becomes a bit less of an issue. For example, with 5 ms frames, we would >> already be sending 64 kb/s worth of headers (excluding the link layer), >> so we might as well spend about as many bits on the actual payload as we >> spend on the headers. And with 64 kb/s of payload, we can actually have >> high-quality full-band audio. >> >>> 1) If a conference bridge has to decode a large number of voice >>> channels, mix, and re-encode, and if compressed-domain mixing cannot >>> be done (which is usually the case), then it is important to keep the >>> decoder complexity low. >> >> Definitely agree here. The decoder complexity is very important. Not >> only because of mixing issue, but also because the decoder is generally >> not allowed to take shortcuts to save on complexity (unlike the >> encoder). As for compressed-domain mixing, as you say it is not always >> available, but *if* we can do it (even if only partially), then that can >> result in a "free" reduction in decoder complexity for mixing. >> >>> 2) In topology b) of your other email >>> (IPend-to-transcoding_gateway-to-PSTNend), the transcoding gateway, or >>> VoIP gateway, often has to encode and decode thousands of voice >>> channels in a single box, so not only the computational complexity, >>> but also the per-instance RAM size requirement of the codec become >>> very important for achieving high channel density in the gateway. >>> >> >> Agreed here, although I would say that per-instance RAM -- as long as >> it's reasonable -- is probably a bit less important than complexity. >> >>> 3) Many telephone terminal devices at the edge of the Internet use >>> embedded processors with limited processing power, and the processors >>> also have to handle many tasks other than speech coding. If the IETF >>> codec complexity is too high, some of such devices may not have >>> sufficient processing power to run it. Even if the codec can fit, some >>> battery-powered mobile devices may prefer to run a lower-complexity >>> codec to reduce power consumption and battery drain. For example, even >>> if you make a Internet phone call from a computer, you may like the >>> convenience of using a Bluetooth headset that allows you to walk >>> around a bit and have hands-free operation. Currently most Bluetooth >>> headsets have small form factors with a tiny battery. This puts a >>> severe constraint on power consumption. Bluetooth headset chips >>> typically have very limited processing capability, and it has to >>> handle many other tasks such as echo cancellation and noise reduction. >>> There is just not enough processing power to handle a relatively >>> high-complexity codec. Most BT headsets today relies on the extremely >>> low-complexity, hardware-based CVSD codec at 64 kb/s to transmit >>> narrowband voice, but CVSD has audible coding noise, so it degrades >>> the overall audio quality. If the IETF codec has low enough >>> complexity, it would be possible to directly encode and decode the >>> IETF codec bit-stream at the BT headset, thus avoiding the quality >>> degradation of CVSD transcoding. >>> >> >> Any idea what the complexity requirements would be for this use-case to >> be possible? >> >> Cheers, >> >> Jean-Marc >> >> >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > > > Cullen Jennings > For corporate legal information go to: > http://www.cisco.com/web/about/doing_business/legal/cri/index.html > > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > -- Mikael Abrahamsson email: swmike@swm.pp.se From koen.vos@skype.net Fri Apr 30 23:08:15 2010 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDA8D3A6A64 for ; Fri, 30 Apr 2010 23:08:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.49 X-Spam-Level: X-Spam-Status: No, score=-4.49 tagged_above=-999 required=5 tests=[AWL=-0.491, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zmx1jJs2NKnC for ; Fri, 30 Apr 2010 23:08:13 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 43CF23A68B1 for ; Fri, 30 Apr 2010 23:08:13 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id A8407601337F6 for ; Sat, 1 May 2010 07:07:57 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=KwXszODC/kLk WWBL0xkVZpAn9co=; b=pGACvMSnkXkD0ajCDvbgL9OU2DogFu23YVsT/x+oePEl taz8niYeF9tBwfU3ch/Nj0ZrbsT2hDfvcIZ/IR7aipNZSSpPWC4E4CvZYU5kQOUG 7ITEMhaC2lGgeff+IK0lGtGDMZuWsrwcCmz4Vy2rIGglZEyDYB9nKn8ukbxksVU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=skype.net; h=message-id:date:from :to:subject:references:in-reply-to:mime-version:content-type: content-transfer-encoding; q=dns; s=mail; b=Skgr5q1mWXEBuvFphkKx 3g6v5GwCJ5ZZzWxswNmuatMNPgLn66jEKfio8CgtQKTA6AisihrsZQbYTTU+0j6+ YZ7WRaUtg/Hujj066IXNS+YPthqs+No7ZL5vBOJt9aPweQ2BPN8+ebtXdJbLSokw oKy+QWEGP7lBbBAomrjWxFM= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id A6B1E601337F0 for ; Sat, 1 May 2010 07:07:57 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at dub-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lfRhzmQ2Sr5b for ; Sat, 1 May 2010 07:07:57 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 07BB3601337F5; Sat, 1 May 2010 07:07:57 +0100 (IST) Received: from adsl-71-141-115-202.dsl.snfc21.pacbell.net (adsl-71-141-115-202.dsl.snfc21.pacbell.net [71.141.115.202]) by mail.skype.net (Horde Framework) with HTTP; Fri, 30 Apr 2010 23:07:56 -0700 Message-ID: <20100430230756.13687lc1s5o89gsc@mail.skype.net> Date: Fri, 30 Apr 2010 23:07:56 -0700 From: Koen Vos To: codec@ietf.org References: <062.7439ee5d5fd36480e73548f37cb10207@tools.ietf.org> <3E1D8AD1-B28F-41C5-81C6-478A15432224@csperkins.org> <000001cae173$dba012f0$92e038d0$@de> <001101cae177$e8aa6780$b9ff3680$@de> <002d01cae188$a330b2c0$e9921840$@de> <4BD11C50.2020206@usherbrooke.ca> <12151537-165D-426A-B71F-8B3D76BE4854@cisco.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Subject: Re: [codec] #16: Multicast? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Codec WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 May 2010 06:08:16 -0000 Quoting "Raymond (Juin-Hwey) Chen": > One-way delay = codec-independent delay + 3*(codec frame size) + > (codec look-ahead) + (codec filtering delay if any) > > This formula was obtained from an experienced engineer who has been > working on IP phones related fields for more than a decade, At Skype We have 100+ years of combined VoIP experience, and a focus on minimizing delay as part of our goal to maximize quality. The consensus among our engineers is that the multiplier is closer to 1 than to 2, at least for software VoIP applications over typical Internet connections. Some years ago the situation was slightly worse because dial-up was more prevalent. > Similar 3X multiplier is also observed in VoIP gateways. Even with > a fast processor/system optimized from ground up to be low-delay, > the measured "codec-dependent" one-way delay of such a VoIP gateway > using the G.711 codec with a 5 ms frame/packet size is between 12 > and 17 ms, or around 3X the frame size. As I've pointed out before, that doesn't say much about how the delay increases with larger frame sizes. Perhaps the 12~17 ms includes a constant delay of 7 ms, and the marginal growth of delay with frame size is 1x. best, koen.