From swmike@swm.pp.se Sat Aug 1 01:09:35 2009 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 1C3D93A6A71 for ; Sat, 1 Aug 2009 01:09:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.258, 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 hYVJZJkbwDSM for ; Sat, 1 Aug 2009 01:09:34 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 270B03A6A37 for ; Sat, 1 Aug 2009 01:09:13 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 7A218A0; Sat, 1 Aug 2009 10:09:14 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 77A359F; Sat, 1 Aug 2009 10:09:14 +0200 (CEST) Date: Sat, 1 Aug 2009 10:09:14 +0200 (CEST) From: Mikael Abrahamsson To: stephen botzko In-Reply-To: <6e9223710907310743u2b6ba6c7ua852f005eea3ec0a@mail.gmail.com> Message-ID: References: <6e9223710907310743u2b6ba6c7ua852f005eea3ec0a@mail.gmail.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] Architectural Considerations X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2009 08:09:35 -0000 On Fri, 31 Jul 2009, stephen botzko wrote: > Today, adaptation to network conditions is a shared responsibility, with > some requirements on the codec layer, others on the transport layer, and > still others on the application. Several comments (mostly criticism) of > the ITU-T codecs indicate that many of the posters here have a different > view of how this architecture is supposed to work. Many comments are > about inadequate response to jitter for instance are not relevant to the > codec. They *are* relevant to the RTP transport and to the application's > implementation choices, but not to the codec itself. It's my experience in my professional life that things get more efficient if you look at end-to-end, in this case thru all the layers (IP, transport and codec) than if you just focus on your "own" layer and blame problems on the other layers. It might be that there indeed are codecs out there that indeed can be properly transported in the conditions I have described, but I'd like to be able to test this in my lab (which also brings in the RF factor) to actually judge whether I personally think it's enough. So what I'd like *a* or *several* IETF WG is to come out with a "whole picture" document that selects codec, transport and settings/parameters/values for these two with firm use cases and recommendations for these, so that it will *work*. As stated before, I'm *tired* of vendors implementing non-resiliant applications and then putting all the requirements on the packet network. We all need to do our share to make it work, codec, transport and network. -- Mikael Abrahamsson email: swmike@swm.pp.se From stephen.botzko@gmail.com Sat Aug 1 04:24:36 2009 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 239543A6964 for ; Sat, 1 Aug 2009 04:24:36 -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 wxyMl8IfoEv2 for ; Sat, 1 Aug 2009 04:24:35 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.156]) by core3.amsl.com (Postfix) with ESMTP id C17F93A68A2 for ; Sat, 1 Aug 2009 04:23:42 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id e12so200558fga.18 for ; Sat, 01 Aug 2009 04: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:message-id:subject:from:to:cc:content-type; bh=0JczOzOltHoo0Rk4YJY/Sg1pwN4sFq5ICPHO0r/CRk4=; b=HJcq1TmAaggAjFG8GRx2GtTOgD766l2ScTJCUM/sRpYGhY/qEb04R9by+4VpQcslIZ Rp9WUizVcm/ZWG9+k/LlaW5BXITYJ1FWDImjfW++9FCaWcP431r1pfDuOH8B1hReGbd+ IgmZPntICJwL6llK1kKR4h4/kWpASpo0qI8tk= 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=swJgx0SNNq/uNZbwE8JK2ET9KDHK7Y4rVW1zZz07DddnKW21WyzyQ7roGYH7azruLW 6B3FZNEYyakEPZup+Frd3545itX7fcQIoXzMxncFRyozVMgxWfVcNKAwV4YlWF4xbrlc P/0rei3ncm0iJIz3VMAnQLAWjBy3nB++Se4qQ= MIME-Version: 1.0 Received: by 10.103.212.9 with SMTP id o9mr2091807muq.135.1249125821772; Sat, 01 Aug 2009 04:23:41 -0700 (PDT) In-Reply-To: References: <6e9223710907310743u2b6ba6c7ua852f005eea3ec0a@mail.gmail.com> Date: Sat, 1 Aug 2009 07:23:41 -0400 Message-ID: <6e9223710908010423h16699449k6e88bf912de08354@mail.gmail.com> From: stephen botzko To: Mikael Abrahamsson Content-Type: multipart/alternative; boundary=001636b430e7e2f558047012c4c8 Cc: codec@ietf.org Subject: Re: [codec] Architectural Considerations X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2009 11:24:36 -0000 --001636b430e7e2f558047012c4c8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >>> We all need to do our share to make it work, codec, transport and network. >>> No disagreement here, though I'd add application to the list too. In fact I think its what I said. I do think that we need to understand what the proposed codec group can (and cannot) fix though, and make sure we set the charter accordingly. It may be that Gerard is right when he says that there is no technical reason to form this group. Maybe there is even consensus on that point, I don't know. I would like to think that are technical problems that the codec group will solve, I'd like to see the case presented, in the context of the larger end-to-end context. That way we can maybe reach some consensus on the problem we are trying to solve, and whether the codec is really the issue or not. Regards, Stephen Botzko Polycom On Sat, Aug 1, 2009 at 4:09 AM, Mikael Abrahamsson wrote: > On Fri, 31 Jul 2009, stephen botzko wrote: > > Today, adaptation to network conditions is a shared responsibility, with >> some requirements on the codec layer, others on the transport layer, and >> still others on the application. Several comments (mostly criticism) of the >> ITU-T codecs indicate that many of the posters here have a different view of >> how this architecture is supposed to work. Many comments are about >> inadequate response to jitter for instance are not relevant to the codec. >> They *are* relevant to the RTP transport and to the application's >> implementation choices, but not to the codec itself. >> > > It's my experience in my professional life that things get more efficient > if you look at end-to-end, in this case thru all the layers (IP, transport > and codec) than if you just focus on your "own" layer and blame problems on > the other layers. > > It might be that there indeed are codecs out there that indeed can be > properly transported in the conditions I have described, but I'd like to be > able to test this in my lab (which also brings in the RF factor) to actually > judge whether I personally think it's enough. So what I'd like *a* or > *several* IETF WG is to come out with a "whole picture" document that > selects codec, transport and settings/parameters/values for these two with > firm use cases and recommendations for these, so that it will *work*. > > As stated before, I'm *tired* of vendors implementing non-resiliant > applications and then putting all the requirements on the packet network. > > We all need to do our share to make it work, codec, transport and network. > > > -- > Mikael Abrahamsson email: swmike@swm.pp.se > --001636b430e7e2f558047012c4c8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
=A0=A0 We all need to do our share to make it work, codec, = transport and network.
>>>
No disagreement here, though I= 9;d add application to the list too.=A0 In fact I think its what I said.
I do think that we need to understand what the proposed codec group can (an= d cannot) fix though, and make sure we set the charter accordingly.=A0 It m= ay be that Gerard is right when he says that there is no technical reason t= o form this group. Maybe there is even consensus on that point, I don't= know.=A0

I would like to think that are technical problems that the codec group = will solve, I'd like to see the case presented, in the context of the l= arger end-to-end context.=A0 That way we can maybe reach some consensus on = the problem we are trying to solve, and whether the codec is really the iss= ue or not.

Regards,
Stephen Botzko
Polycom

On Sat, Aug 1, 2009 at 4:09 AM, Mikael Abrahamsson <<= a href=3D"mailto:swmike@swm.pp.se" target=3D"_blank">swmike@swm.pp.se&g= t; wrote:
On Fri, 31 J= ul 2009, stephen botzko wrote:

Today, adaptation to network conditions is a shared responsibility, with so= me requirements on the codec layer, others on the transport layer, and stil= l others on the application. =A0Several comments (mostly criticism) of the = ITU-T codecs indicate that many of the posters here have a different view o= f how this architecture is supposed to work. =A0Many comments are about ina= dequate response to jitter for instance are not relevant to the codec. They= *are* relevant to the RTP transport and to the application's implement= ation choices, but not to the codec itself.

It's my experience in my professional life that things get more efficie= nt if you look at end-to-end, in this case thru all the layers (IP, transpo= rt and codec) than if you just focus on your "own" layer and blam= e problems on the other layers.

It might be that there indeed are codecs out there that indeed can be prope= rly transported in the conditions I have described, but I'd like to be = able to test this in my lab (which also brings in the RF factor) to actuall= y judge whether I personally think it's enough. So what I'd like *a= * or *several* IETF WG is to come out with a "whole picture" docu= ment that selects codec, transport and settings/parameters/values for these= two with firm use cases and recommendations for these, so that it will *wo= rk*.

As stated before, I'm *tired* of vendors implementing non-resiliant app= lications and then putting all the requirements on the packet network.

We all need to do our share to make it work, codec, transport and network.<= div>


--
Mikael Abrahamsson =A0 =A0email: swmike@swm.pp.se

--001636b430e7e2f558047012c4c8-- From bmschwar@fas.harvard.edu Sat Aug 1 10:00:12 2009 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 785643A697C for ; Sat, 1 Aug 2009 10:00:12 -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 z6zbtEGaQi8I for ; Sat, 1 Aug 2009 10:00:11 -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 6F95C3A6955 for ; Sat, 1 Aug 2009 10:00:11 -0700 (PDT) Received: from [192.168.1.100] (c-71-192-160-188.hsd1.nh.comcast.net [71.192.160.188]) (authenticated bits=0) by us19.unix.fas.harvard.edu (8.14.1/8.14.1) with ESMTP id n71H0Cnq012739 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 1 Aug 2009 13:00:13 -0400 Message-ID: <4A74749C.90000@fas.harvard.edu> Date: Sat, 01 Aug 2009 13:00:12 -0400 From: "Benjamin M. Schwartz" User-Agent: Thunderbird 2.0.0.22 (X11/20090714) MIME-Version: 1.0 To: codec@ietf.org References: <6e9223710907310743u2b6ba6c7ua852f005eea3ec0a@mail.gmail.com> <6e9223710908010423h16699449k6e88bf912de08354@mail.gmail.com> In-Reply-To: <6e9223710908010423h16699449k6e88bf912de08354@mail.gmail.com> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigDB31ACBD93FF40533D5039EF" Subject: Re: [codec] Architectural Considerations X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Aug 2009 17:00:12 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigDB31ACBD93FF40533D5039EF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable stephen botzko wrote: > It may be > that Gerard is right when he says that there is no technical reason to = form > this group. Standards are never written for technical reasons. Code is written for technical reasons. Standards are written for social reasons. Examples of technical reasons for writing this code can be found on http://www.celt-codec.org/comparison/ We should also not forget the possibility, emphasized by the SILK, CELT, and BV32 developers, of further improvement beyond the state of the art b= y collaborative technical development within the group. --Ben --------------enigDB31ACBD93FF40533D5039EF 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) iEYEARECAAYFAkp0dJwACgkQUJT6e6HFtqSE0QCfYhr/G8w66Q/vy9Up53PD5suz 8PcAn3wfp02xAnBvaJltPAey5dln8Na8 =rOcA -----END PGP SIGNATURE----- --------------enigDB31ACBD93FF40533D5039EF-- From samj@samj.net Mon Aug 3 12:24:59 2009 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 E9D383A6E9D for ; Mon, 3 Aug 2009 12:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.07 X-Spam-Level: X-Spam-Status: No, score=-5.07 tagged_above=-999 required=5 tests=[AWL=-3.094, 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 qZKZKnwKTlb7 for ; Mon, 3 Aug 2009 12:24:59 -0700 (PDT) Received: from eu1sys200aog106.obsmtp.com (eu1sys200aog106.obsmtp.com [207.126.144.121]) by core3.amsl.com (Postfix) with SMTP id 566C43A6E3E for ; Mon, 3 Aug 2009 12:23:58 -0700 (PDT) Received: from source ([209.85.220.210]) by eu1sys200aob106.postini.com ([207.126.147.11]) with SMTP ID DSNKSnc5UOdVoGFNzMtBRnBobPeRmaO1ymXQ@postini.com; Mon, 03 Aug 2009 19:24:01 UTC Received: by fxm6 with SMTP id 6so1680014fxm.19 for ; Mon, 03 Aug 2009 12:24:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.54.7 with SMTP id c7mr2272898fga.24.1249327017118; Mon, 03 Aug 2009 12:16:57 -0700 (PDT) Date: Mon, 3 Aug 2009 21:16:57 +0200 Message-ID: <21606dcf0908031216h6f08d850r8400bf515f9293f8@mail.gmail.com> From: Sam Johnston To: codec@ietf.org Content-Type: multipart/alternative; boundary=000e0cd29d0e104d8b0470419d91 X-Mailman-Approved-At: Mon, 03 Aug 2009 12:33:38 -0700 Subject: [codec] Should the IETF standardize wideband Internet codec(s)? X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 19:25:00 -0000 --000e0cd29d0e104d8b0470419d91 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Evening all, The list description (which I found courtesy this post) poses a very simple question: "Should the IETF standardize wideband Internet codec(s)?". In the absence of relevant audio codec expertise I'll provide a simple answer: absolutely, most definitely, without a shadow of a doubt "Yes". Sam --000e0cd29d0e104d8b0470419d91 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Evening all,

The list description (which I found courtesy this post) poses a very simple question: "Should the IETF standardize wideband Internet codec(s)?".

In the absence of relevant audio codec expertise I'll provide a simple answer: absolutely, most definitely, without a shadow of a doubt "Yes".

Sam

--000e0cd29d0e104d8b0470419d91-- From lars.eggert@nokia.com Tue Aug 4 01:45:53 2009 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 51BE73A6F97 for ; Tue, 4 Aug 2009 01:45:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 i03BgFke+xil for ; Tue, 4 Aug 2009 01:45:52 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 53C1C28C22D for ; Tue, 4 Aug 2009 01:45:52 -0700 (PDT) Received: from [10.180.41.51] ([192.100.124.156]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n748jiiQ038969 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 4 Aug 2009 11:45:44 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: <4F8B647A-6F55-43CA-A6F0-C0AD2BDE473C@nokia.com> From: Lars Eggert To: Gerard Fernando In-Reply-To: <4A7316FA.5010100@sun.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 11:45:34 +0300 References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECF8C@esealmw109.eemea.ericsson.se> <3d032e5d0907310232t54f160e5v6553c82d926deb69@mail.gmail.com> <00bf01ca11d4$26c45360$9246c80a@china.huawei.com> <3d032e5d0907310541ufd4a8a9m8b75a88eb3df7770@mail.gmail.com> <012e01ca11e8$16f39ef0$9246c80a@china.huawei.com> <4A7316FA.5010100@sun.com> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [212.213.221.39]); Tue, 04 Aug 2009 11:45:45 +0300 (EEST) Cc: "codec@ietf.org" Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 08:45:53 -0000 On 2009-7-31, at 19:08, Gerard Fernando wrote: > BTW, you can give a look from IESG BOF report: =93- understanding it =20= > would not be possible to guarantee that resulting codecs would be =20 > royalty free=94 Clarification: what you cite from is the report of the *sponsoring AD* =20= and not something an IESG consensus call was run on. (In other words, =20= it's a report *to* the IESG and not *from* the IESG.) Lars= From Ikonin@spiritdsp.com Tue Aug 4 07:04:37 2009 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 982B13A6882 for ; Tue, 4 Aug 2009 07:04:37 -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 h11EJd8s8Svz for ; Tue, 4 Aug 2009 07:04:36 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 32B2928C31F for ; Tue, 4 Aug 2009 07:04:31 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n74E4UYU074900; Tue, 4 Aug 2009 18:04:31 +0400 (MSD) (envelope-from Ikonin@spiritdsp.com) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Aug 2009 18:04:24 +0400 Message-ID: In-Reply-To: <4A7340F0.30005@iptego.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec Standardization Expertise Thread-Index: AcoVDHiL7avWoQ+6T8a2PNdZm0Xqiw== References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <4A7340F0.30005@iptego.com> From: "Sergey Ikonin" To: "Stefan Sayer" , "stephen botzko" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 14:04:37 -0000 For IP-MR only base layer is required for reconstruction of speech. This reconstruction is just regular decoding without running of PLC (Packet Loss Concealment) procedure. It is important to avoid running of PLC because it introduces artifacts and error propagation. Of course each new layer increases quality of synthesized speech. But for packet loss resilience it's betted to spread duplicates of base layer in time (in packets n+1, n+2, etc). Best regards, Sergey Ikonin www.spiritDSP.com -----Original Message----- From: Stefan Sayer [mailto:stefan.sayer@iptego.com]=20 Sent: Friday, July 31, 2009 11:07 PM To: stephen botzko Cc: codec@ietf.org Subject: Re: [codec] Codec Standardization Expertise Hello, o stephen botzko [07/30/09 23:02]: > itself. G.719's packetization RFC allows for interleaved and overlapped=20 > (redundant) audio frames, and permits the duplicate frames to be at=20 > lower rates. That allows for good quality to be maintained under packet=20 > loss conditions (though if the network is congested, of course you need=20 How much additional packet loss resilience would be possible to achieve=20 from a true multiple description mode for the codec and interleaved=20 packetization, where reconstruction of a lower quality signal would be=20 possible in the presence of one description, or some out of a few=20 descriptions? For this to work, not only the RTP packetization has to support it so=20 that the receiver understands what it is that was received, but the=20 codec itself must support this mode. (I would assume that for efficiency reasons, this needs to be an alternate coding mode, which the sender=20 could switch to if it detects, e.g. with the help of RTCP, excessive loss.) I see that in the IP-MR RTP format it is possible to reconstruct from=20 the base layer, which may be sent redundantly. How much better could=20 this work if reconstruction from any combination of layers would be=20 possible? Thanks Stefan Sayer From lars.eggert@nokia.com Tue Aug 4 11:39:42 2009 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 90CD13A6DC1 for ; Tue, 4 Aug 2009 11:39:42 -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 xXNDsZr1kr63 for ; Tue, 4 Aug 2009 11:39:41 -0700 (PDT) Received: from mail.fit.nokia.com (mail.fit.nokia.com [195.148.124.195]) by core3.amsl.com (Postfix) with ESMTP id 0F8F33A7032 for ; Tue, 4 Aug 2009 11:39:10 -0700 (PDT) Received: from [10.0.1.5] (cs95024.pp.htv.fi [212.90.95.24]) (authenticated bits=0) by mail.fit.nokia.com (8.14.3/8.14.3) with ESMTP id n74IcfLA071203 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 4 Aug 2009 21:38:42 +0300 (EEST) (envelope-from lars.eggert@nokia.com) Message-Id: From: Lars Eggert To: codec@ietf.org In-Reply-To: <4F8B647A-6F55-43CA-A6F0-C0AD2BDE473C@nokia.com> Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 4 Aug 2009 21:38:41 +0300 References: <6e9223710907301049qad37797s7623fa2358d98f2b@mail.gmail.com> <4A71FF50.5020007@joelhalpern.com> <6e9223710907301402o529cb4cdu326c236cf5d7c4b7@mail.gmail.com> <130EBB38279E9847BAAAE0B8F9905F8C018ECF8C@esealmw109.eemea.ericsson.se> <3d032e5d0907310232t54f160e5v6553c82d926deb69@mail.gmail.com> <00bf01ca11d4$26c45360$9246c80a@china.huawei.com> <3d032e5d0907310541ufd4a8a9m8b75a88eb3df7770@mail.gmail.com> <012e01ca11e8$16f39ef0$9246c80a@china.huawei.com> <4A7316FA.5010100@sun.com> <4F8B647A-6F55-43CA-A6F0-C0AD2BDE473C@nokia.com> X-Mailer: Apple Mail (2.935.3) X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.2 (mail.fit.nokia.com [195.148.124.194]); Tue, 04 Aug 2009 21:38:42 +0300 (EEST) Cc: Gerard Fernando Subject: Re: [codec] Codec Standardization Expertise X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 18:39:42 -0000 Hi, it's been pointed out to me that my email below makes it look like =20 Gerard made the statement I was referring to. This is incorrect, the =20 statement was made by Herve Taddei. Looking at the email I responded to, I see that the problem is that it =20= is a multipart/alternative MIME email, and the text/plain part that my =20= MUA renders is missing some HTML quotation that the text/html part =20 has. The problem of non-equivalent multipart/alternative emails rears =20= its ugly head again... Lars On 2009-8-4, at 11:45, Eggert Lars (Nokia-NRC/Espoo) wrote: > On 2009-7-31, at 19:08, Gerard Fernando wrote: >> BTW, you can give a look from IESG BOF report: =93- understanding it >> would not be possible to guarantee that resulting codecs would be >> royalty free=94 > > Clarification: what you cite from is the report of the *sponsoring AD* > and not something an IESG consensus call was run on. (In other words, > it's a report *to* the IESG and not *from* the IESG.) > > Lars > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From koen.vos@skype.net Tue Aug 4 17:47:26 2009 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 206A63A7119 for ; Tue, 4 Aug 2009 17:47:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.284 X-Spam-Level: X-Spam-Status: No, score=-6.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_MILLIONSOF=0.315] 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 3xgUsPpE89uL for ; Tue, 4 Aug 2009 17:47:24 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id A10983A708A for ; Tue, 4 Aug 2009 17:47:24 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 61BA92007CCE1; Wed, 5 Aug 2009 02:47:26 +0200 (CEST) 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=Pu+LuMPDVDUG K9qogI0nplLkD2Y=; b=u+MHtqvMKUHzlVSy8ymwdbYWRbYdu4usfCnES+P6geMZ WFEDQrZIWTteVeMvaGbghs9vJOKcpOn3nAxiEoU/KOE28HukTH9o8TSr/yTjP5Eb x7l5sVp+pij07gEcP1Dr8piu6X6twXwq4vSpbgEajvAEf2Mp6DMLl9OiUdzHEgA= 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=gCvO5gE23pa6AzhE5D5Z ujoVdaSBUAb9AsP5PHV28FNiWwGQmNPamC5wuqL6/py0Tpyu1UNqoSgxCGadyRIR +3SEP9AN5lw4p0F3bAwxFGrUKO3AwWctTCXIScfpjHR0OC+haOaad7+u/w5oE4eM uBboh9GgRR9r25PsE1BvfBA= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 601AA2007C221; Wed, 5 Aug 2009 02:47:26 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rolrdOqwBHWI; Wed, 5 Aug 2009 02:47:15 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id E7B6D2007CB63; Wed, 5 Aug 2009 02:47:15 +0200 (CEST) Received: from 71.141.139.96 ([71.141.139.96]) by mail.skype.net (Horde Framework) with HTTP; Tue, 04 Aug 2009 17:47:15 -0700 Message-ID: <20090804174715.8675700mpncnrdzn@mail.skype.net> Date: Tue, 04 Aug 2009 17:47:15 -0700 From: Koen Vos To: stephane.proust@orange-ftgroup.com References: <4D1AA2A55522044480C9B9CF97A9340938A323@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4D1AA2A55522044480C9B9CF97A9340938A323@ftrdmel0.rd.francetelecom.fr> 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: [codec] G.722 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 00:47:26 -0000 St=E9phane, G.722 has weaknesses: - High bitrate. - The original G.722 was not suited for the Internet because it lacked =20 a PLC. In recent years, this problem has been addressed by extending =20 the standard with appendices III and IV. Deployment on a few million hardware devices does not mean a codec is =20 widely and easily distributable. Indeed, such a requirement is not =20 among the codec selection criteria mentioned in the DECT Liaison. koen. Quoting stephane.proust@orange-ftgroup.com: > G.722 is already massively deployed and used for mass market WB =20 > telephony services overs IP and provides a very good wideband voice =20 > quality at 64 kbit/s confirmed by the feedback from customers. > > Please have a look on the LS from DECT (distributed by Cullen =20 > Jenning on this e-mail reflector in attached e-mail in =20 > "DECT38_017r1_Liaison_to_ITU_SG16_on_codecs.pdf") > > Extract : > > "Additionally, ETSI TC DECT would like to point out that millions of =20 > devices implementing ITU-T G.722 > codec were manufactured, sold in several countries and are available =20 > worldwide now" > > St=E9phane > > > -----Message d'origine----- > De : codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] De la =20 > part de Alan Johnston > Envoy=E9 : jeudi 30 juillet 2009 01:42 > =C0 : codec@ietf.org > Objet : [codec] Comments > > I'm not going to comment on the details of the charter but instead =20 > just talk about the high level issues. > > The situation today is awful - there are a number of good new =20 > Internet codecs, but few have deployed them - no one wants to be the =20 > first, and in the meantime, we are stuck with G.711 et al. We need =20 > to try something to break us out of this situation, and this effort =20 > seems like it could really help. I can't see how it could harm the =20 > situation. > > Secondly, it seems like all previous codecs have been designed in =20 > isolation, or with the needs of some specific layer 2 transport in =20 > mind. What if we really thought hard and came up with the =20 > requirements for our ultimate Internet codec? What kinds of things =20 > could we think of? If we don't do the work, we will never know, and =20 > we may yet come up with a codec that has a compelling deployment =20 > story. > > And then we'd really be getting somewhere... > > Thanks, > Alan > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From steveu@coppice.org Tue Aug 4 18:01:05 2009 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 30F1F28C486 for ; Tue, 4 Aug 2009 18:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.339 X-Spam-Level: X-Spam-Status: No, score=-2.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 qAiGMCqrjU3h for ; Tue, 4 Aug 2009 18:01:04 -0700 (PDT) Received: from cwb.pacific.net.hk (cwb.pacific.net.hk [202.14.67.92]) by core3.amsl.com (Postfix) with ESMTP id 3ABDD28C47B for ; Tue, 4 Aug 2009 18:01:04 -0700 (PDT) Received: from xeon.coppice.org (110.202.17.210.dyn.pacific.net.hk [210.17.202.110]) by cwb.pacific.net.hk with ESMTP id n75114QN005929; Wed, 5 Aug 2009 09:01:05 +0800 Message-ID: <4A78D9D0.2060903@coppice.org> Date: Wed, 05 Aug 2009 09:01:04 +0800 From: Steve Underwood User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Koen Vos References: <4D1AA2A55522044480C9B9CF97A9340938A323@ftrdmel0.rd.francetelecom.fr> <20090804174715.8675700mpncnrdzn@mail.skype.net> In-Reply-To: <20090804174715.8675700mpncnrdzn@mail.skype.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] G.722 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 01:01:05 -0000 Koen Vos wrote: > Stéphane, > > G.722 has weaknesses: > - High bitrate. > - The original G.722 was not suited for the Internet because it lacked > a PLC. In recent years, this problem has been addressed by extending > the standard with appendices III and IV. These definitions of PLC schemes in standards puzzle me. They have no effect on the signal on the wire, so why are they defined? The implementer of the receiving side is actually free to implement anything interesting they can come up with. > Deployment on a few million hardware devices does not mean a codec is > widely and easily distributable. Indeed, such a requirement is not > among the codec selection criteria mentioned in the DECT Liaison. Steve From koen.vos@skype.net Tue Aug 4 20:22:09 2009 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 5696628C4B0 for ; Tue, 4 Aug 2009 20:22:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.441 X-Spam-Level: X-Spam-Status: No, score=-6.441 tagged_above=-999 required=5 tests=[AWL=0.158, 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 qe+LcDTPMINC for ; Tue, 4 Aug 2009 20:22:08 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 3287E28C4AA for ; Tue, 4 Aug 2009 20:22:08 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id E91022007CCF5; Wed, 5 Aug 2009 05:22:09 +0200 (CEST) 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=QjBPgCqAaygi 0BnUwDU7mV3kg30=; b=Oaxf/m4lO/lbd1Y6LZQjla7Wvm1VG/De94DtAikzL5hA ljVA5YHi+mSuxFj3ActrYHmo4YKowZlmRj+DgP9wc66VB1PVGtChe9Z7oOydp6wE HwUeBt+TZZ1ap1/gnW6pT4n0I5VU9PGYKjzEThOi1KCVAZ74oexGH0j4kmsWxYY= 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=ImOAElWhVeArvMKJb1Wy hNkj1WT/00tWvVbjQD70Yh4W2r6f0p7Atrg6v1lvh2/SEWqNKDFJQfY+okSTB/Ki 147RC1de/v1yu/E7ML1tDuRWSK/yMmY7ZMGHyZCATAEYBhUmb76d709lbhmFvd1S g0JlbsDFFl3rn98QRKcuN38= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id E76782007C236; Wed, 5 Aug 2009 05:22:09 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at lux2-mail.skype.net Received: from mail.skype.net ([127.0.0.1]) by localhost (lux2-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YQmMsfdWWSUV; Wed, 5 Aug 2009 05:22:09 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 144572007CCF7; Wed, 5 Aug 2009 05:22:09 +0200 (CEST) Received: from 71.141.139.96 ([71.141.139.96]) by mail.skype.net (Horde Framework) with HTTP; Tue, 04 Aug 2009 20:22:09 -0700 Message-ID: <20090804202209.60564fpn9g1maswx@mail.skype.net> Date: Tue, 04 Aug 2009 20:22:09 -0700 From: Koen Vos To: Steve Underwood References: <4D1AA2A55522044480C9B9CF97A9340938A323@ftrdmel0.rd.francetelecom.fr> <20090804174715.8675700mpncnrdzn@mail.skype.net> <4A78D9D0.2060903@coppice.org> In-Reply-To: <4A78D9D0.2060903@coppice.org> 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] G.722 X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 03:22:09 -0000 Quoting Steve Underwood: > These definitions of PLC schemes in standards puzzle me. They have > no effect on the signal on the wire, so why are they defined? The > implementer of the receiving side is actually free to implement > anything interesting they can come up with. The same is true for the rest of the decoder. One purpose of a standard is to guarantee a certain quality level over a range of conditions. Having the PLC in the standard extends that range to include packet loss. On a technical level: For good results, a PLC operates on decoder-internal parameters and states, which requires tight algorithmic integration. Also, a good PLC method for one codec may perform poorly with another codec. So the PLC is as much part of a decoder as any other decoder module. The complete package is compiled together to create the optimized binary library typically sold by vendors. You can't mix-and-match binary decoder modules from different vendors. The above also applies to time compression/stretching methods, for handling network jitter. koen. From hoene@uni-tuebingen.de Mon Aug 17 05:36:07 2009 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 8DB093A68CD for ; Mon, 17 Aug 2009 05:36:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.39 X-Spam-Level: X-Spam-Status: No, score=-4.39 tagged_above=-999 required=5 tests=[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 hk-8IvxOiq-6 for ; Mon, 17 Aug 2009 05:36: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 6F0963A6D79 for ; Mon, 17 Aug 2009 05:36:05 -0700 (PDT) Received: from hoeneLenovoT60 (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 n7HCa3LF012841 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 17 Aug 2009 14:36:03 +0200 From: "Christian Hoene" To: Date: Mon, 17 Aug 2009 14:36:03 +0200 Message-ID: <001401ca1f37$497b4c40$dc71e4c0$@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: AcofN0SBb2WyuCoHTnmAgH4fdZoOUA== Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Subject: [codec] Draft on Requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 12:36:07 -0000 Hi all, since the 73rd IETF Meeting in Minneapolis, I have followed the = discussions on whether to standardized codecs at the IETF or not. Especially, the discussions on this mailing list have been quite fruitful - if you = ignore the turf wars, codec competitions and repeated arguments. Based on these emails and on my previous summary at https://groupware1.cs.uni-tuebingen.de/wiki/codec_bof/index.php/Requireme= nts , and on the standards and requirement documents of ITU, 3GPP and OMA, I have written this requirement document. http://www.ietf.org/id/draft-hoene-avt-acs-requirements-00.txt I tried to avoid a purely codec-centric view. Instead, I also considered = the users and the network view to get a better understanding of the real underlying problem that needs to be solved.=20 Please consider this ID as input to the discussion on a proposed WG = charter. I like to express my gratitude to all participants of the discussions = and please accept my apologies, if I have used your wordings without = mentioning you as an author. With Best Regards, Christian Hoene -------------------------------------------------------- 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: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Monday, August 17, 2009 1:56 PM To: hoene@ieee.org Subject: New Version Notification for = draft-hoene-avt-acs-requirements-00=20 A new version of I-D, draft-hoene-avt-acs-requirements-00.txt has been successfully submitted by Christian Hoene and posted to the IETF = repository. Filename: draft-hoene-avt-acs-requirements Revision: 00 Title: Requirements of an Audio Communication System (ACS) Creation_date: 2009-08-17 WG ID: Independent Submission Number_of_pages: 24 Abstract: This document describes the requirements of an audio communication=20 system (ACS) for acoustic content, especially speech and music. The=20 ACS consists of all components above the IP layer and below a digital=20 PCM audio interface. These include codec, jitter buffer, and=20 transport.=20 The goal of the ACS is to provide a bidirectional acoustic=20 communication between any two Internet hosts at a good quality,=20 constrained only by the available resources at the hosts and the=20 characteristics of the transmission path between both hosts.=20 The intention of the document is to provide the requirements for a=20 codec that is solely intended for the Internet, to provide the=20 requirements for the codec's payload specification, and to define the=20 requirements on the transport protocol. =20 The IETF Secretariat. From alexander.chemeris@gmail.com Mon Aug 17 06:01:45 2009 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 6A48B3A6EFA for ; Mon, 17 Aug 2009 06:01:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 qnQugcQi0hOc for ; Mon, 17 Aug 2009 06:01:44 -0700 (PDT) Received: from mail-bw0-f206.google.com (mail-bw0-f206.google.com [209.85.218.206]) by core3.amsl.com (Postfix) with ESMTP id 24A133A6EF6 for ; Mon, 17 Aug 2009 06:01:43 -0700 (PDT) Received: by bwz2 with SMTP id 2so2150874bwz.43 for ; Mon, 17 Aug 2009 06:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=polC9HSvm3pUdCh7MN0tG8unw/T00Y8RKJ11TjhuwAU=; b=KKEURaFFG8nCQCYXt0EHvCMu4IRgtBLhZ7b2ic39Se+bMbkvi4/rzbGAlHzKIjxS2j zoxZMvR7ikSGxmliqd2gNPMWAbvBE1X6q6n4prI6pWc2kEIWioQFFt1YeCCnZ/8PegaY NEpV0B2xepX5dJqcuWDxKLQmE189qVP+IyOls= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=EA+UuTA27megt9xrv+cDFfMlffYAS9dTFNGHo9U7iUJhXGlEdFuKUvkTr74XR7QBLt Fqq8KeO+7N3RWfltWCLxXTECaydzXx6SIQry5Nk6uTPoye3x0kCwDAkvqXKTn0GojoX6 v4m2PgIr8g6P0+4xe7jeXT4t1M6xRCPf/kXZE= MIME-Version: 1.0 Sender: alexander.chemeris@gmail.com Received: by 10.103.84.6 with SMTP id m6mr1291122mul.26.1250514105133; Mon, 17 Aug 2009 06:01:45 -0700 (PDT) In-Reply-To: <001401ca1f37$497b4c40$dc71e4c0$@de> References: <001401ca1f37$497b4c40$dc71e4c0$@de> From: Alexander Chemeris Date: Mon, 17 Aug 2009 17:01:25 +0400 X-Google-Sender-Auth: e271e80561823995 Message-ID: <3d032e5d0908170601t15e9846ax9671572e68b4cf3f@mail.gmail.com> To: Christian Hoene Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Draft on Requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 13:01:45 -0000 Hi Christian, On Mon, Aug 17, 2009 at 16:36, Christian Hoene wrote: > Based on these emails and on my previous summary at > https://groupware1.cs.uni-tuebingen.de/wiki/codec_bof/index.php/Requirements > , and on the standards and requirement documents of ITU, 3GPP and OMA, I > have written this requirement document. > http://www.ietf.org/id/draft-hoene-avt-acs-requirements-00.txt To keep things clear - what is the relationship between the wiki page and the I-D? I.e. which one contains most recent data, etc. -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 From hoene@uni-tuebingen.de Mon Aug 17 06:18:03 2009 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 0610E3A6BD5 for ; Mon, 17 Aug 2009 06:18:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.784 X-Spam-Level: X-Spam-Status: No, score=-5.784 tagged_above=-999 required=5 tests=[AWL=0.465, 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 Jy9OJ7gXNm2S for ; Mon, 17 Aug 2009 06:18:02 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id F21B43A6C9A for ; Mon, 17 Aug 2009 06:18:01 -0700 (PDT) Received: from hoeneLenovoT60 (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 n7HDI4Gb019648 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 17 Aug 2009 15:18:05 +0200 From: "Christian Hoene" To: "'Alexander Chemeris'" References: <001401ca1f37$497b4c40$dc71e4c0$@de> <3d032e5d0908170601t15e9846ax9671572e68b4cf3f@mail.gmail.com> In-Reply-To: <3d032e5d0908170601t15e9846ax9671572e68b4cf3f@mail.gmail.com> Date: Mon, 17 Aug 2009 15:18:05 +0200 Message-ID: <001b01ca1f3d$28047f90$780d7eb0$@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: AcofOwkeN9bJchgYRIG5qICKEuNaWwAATvBA Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] Draft on Requirements X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Aug 2009 13:18:03 -0000 > To keep things clear - what is the relationship between the wiki page > and the I-D? > I.e. which one contains most recent data, etc. The wiki page was only a (neutral) summary of emails. The I-D contains = more data. I added some of the requirements used for G.718, G.719 and = TS26.114. I have include same of the arguments in the emails between = July 16th and today into my I-D. The I-D does not tries to be neutral = thus is more consistent.=20 Christian From hsinnrei@adobe.com Tue Aug 25 09:33:41 2009 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 4DECF3A6F25 for ; Tue, 25 Aug 2009 09:33:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.105 X-Spam-Level: X-Spam-Status: No, score=-5.105 tagged_above=-999 required=5 tests=[AWL=0.962, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q0=0.303, SARE_SUB_OBFU_Q1=0.227] 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 udrys74gUhCZ for ; Tue, 25 Aug 2009 09:33:34 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by core3.amsl.com (Postfix) with ESMTP id 12CBC3A6AFE for ; Tue, 25 Aug 2009 09:33:33 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKSpQSCrXGjJfmbM1STb/17MZMv+Ff/tLL@postini.com; Tue, 25 Aug 2009 09:33:41 PDT Received: from inner-relay-3.eur.adobe.com (inner-relay-3b [10.128.4.236]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n7PGW3WG006350; Tue, 25 Aug 2009 09:32:08 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n7PGW0Y2007228; Tue, 25 Aug 2009 09:32:01 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Tue, 25 Aug 2009 09:31:59 -0700 From: Henry Sinnreich To: John Atkinson , "codec@ietf.org" Date: Tue, 25 Aug 2009 09:31:57 -0700 Thread-Topic: [dispatch] Optimal placement of Voice Quality Signal Processing (VQSP) features within Networks Thread-Index: AclOk7JwjC6CKQbIRUOsEdfs75dh2gDAuj0wAABfPZA00I4zAAAsibrQAABG87AABP8MXg== Message-ID: In-Reply-To: <549FD0754C7E1D468D93A34B42AC5F92156BB54D@zcarhxm1.corp.nortel.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6B97C2D58A1hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] [dispatch] Optimal placement of Voice Quality Signal Processing (VQSP) features within Networks X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Aug 2009 16:33:41 -0000 --_000_C6B97C2D58A1hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FYI - just in case you may have missed it. Such functions are distinct from codecs, but may be still of interest. Thanks, Henry On 8/25/09 9:15 AM, "John Atkinson" wrote: Optimal placement of Voice Quality Signal Processing (VQSP) features within= Networks ITU SG16 has developed a framework for coordination of voice quality signal= processing in networks that have more than one network element capable of = doing specific voice quality signal processing functions. This framework wa= s developed to allow optimal placement of the VQSP functions within the net= work and avoid voice quality degradation due to undesirable side-effects of= the interaction of the individual voice quality enhancement functions and = to improve voice quality by only applying a given VQ function in one locati= on in the network. The five voice quality signal processing features commonly applied are * Echo Control (control of echo from a hybrid) * Acoustic Echo Control * Automatic Gain Control * Feedback Gain Control * Background Noise Reduction A Node can potentially be capable of applying each of the above five VQSP f= unctions in each of the two directions of a voice path. Doing both Echo con= trol and Acoustic echo control on the same signal is not desirable or neces= sary nor is applying both automatic gain control and feedback gain control = on the same signal desirable or necessary. In addition, it's usually optima= l to do echo control as close to the echo source as possible. This ITU work has not defined the actual method by which network elements c= an communicate which VQ functions are enabled or present in the network and= in which direction they are capable of being applied. ITU has sent a Liaso= n Statement to IETF requesting assistance defining how VoIP nodes communica= te VQSP capability/state information to other nodes. For Echo Control , VoIP implementors are currently aware of two existing m= ethods of communicating between nodes that echo cancellation is being done.= In ISUP, the Echo control device indicator in the Nature of Connection Ind= icators IE is used to indicate the presence of an echo control device in th= e forward direction and the Echo Control device Indicator in the Backwards = Call Indicators IE is used to indcate the presence on an echo control devic= e in the backwards direction. RFC 3108 defines a session description protoc= ol attribute line for echo control. a=3Decan: which can be used to indicate the presence of G.165/G.168 echo cancellers i= n one or both directions. In addition, RFC 3108 defines an attribute line for gain control a=3Dgc: which can be used to indicate the presence gain control in one or both dire= ctions It would be beneficial for the Dispatch WG to review the ITU Liason Statem= ent (which can be viewed at https://datatracker.ietf.org/liaison/505/ ) a= nd discuss the best method of communicating VQSP functions between nodes .= Possible solutions include using SDP, SIP headers, RTP, RTCP, or some new= on-path control protocol. John Atkinson johnat@nortel.com --_000_C6B97C2D58A1hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [dispatch] Optimal placement of Voice Quality Signal Processing = (VQSP) features within Networks FYI – just in case you may have missed it.
Such functions are distinct from codecs, but may be still of interest.
Thanks, Henry

On 8/25/09 9:15 AM, "John Atkinson" <johnat@nortel.com> wrote:

Optimal placement of Voice Quality Signal Proces= sing (VQSP) features within Networks
 
ITU SG16 has developed = a framework for coordination of voice quality signal processing in networks= that have more than one network element capable of doing specific voice qu= ality signal processing functions. This framework was developed to allow op= timal placement of the VQSP functions within the network and avoid voice qu= ality degradation due to undesirable side-effects of the interaction of the= individual voice quality enhancement functions and to improve voice qualit= y by only applying a given VQ function in one location in the network.  
 
 
The five voice quality signal processing features commonly a= pplied are
 
·       &= nbsp; Echo Control (control of echo from a= hybrid)
·       &= nbsp; Acoustic Echo Control
·       &= nbsp; Automatic Gain Control
·       &= nbsp; Feedback Gain Control
·       &= nbsp; Background Noise Reduction
A Node can potentially = be capable of applying each of the above five VQSP functions in each of the= two directions of a voice path. Doing both Echo control and Acoustic echo = control on the same signal is not desirable or necessary nor is applying bo= th automatic gain control and feedback gain control on the same signal desi= rable or necessary. In addition, it's usually optimal to do echo control as= close to the echo source as possible.
 
This ITU work has not defined the actual method by which network elements c= an communicate which VQ functions are enabled or present in the network and= in which direction they are capable of being applied. ITU has sent a Liaso= n Statement to IETF requesting assistance defining how VoIP nodes communica= te VQSP capability/state information to other nodes.

 
For Echo Control , &nbs= p;VoIP implementors are currently aware of two existing methods of communic= ating between nodes that echo cancellation is being done. In ISUP, the Echo= control device indicator in the Nature of Connection Indicators IE is used= to indicate the presence of an echo control device in the forward directio= n and the Echo Control device Indicator in the Backwards Call Indicators IE= is used to indcate the presence on an echo control device in the backwards= direction. RFC 3108 defines a session description protocol attribute line = for echo control.

a=3Decan:<directionFlag><ecanEnable><ecanType> which can be used to indicate the presence of G.165/G= .168 echo cancellers in one or both directions.

 
In addition, RFC 3108 d= efines an attribute line for gain control

a=3Dgc:<directionFlag><gcEnable>&l= t;gcLvl>
which can be used to in= dicate the presence gain control in one or both directions

 
 It would be beneficial= for the Dispatch WG to review  the ITU Liason Statement  (which = can be viewed at  https://datatracker.ietf.org/liaison/505/ ) and discuss the best meth= od of communicating VQSP functions  between nodes .  Possible sol= utions include using SDP, SIP headers, RTP, RTCP, or some new on-path contr= ol protocol.
 
John Atkinson
johnat@nortel.com

--_000_C6B97C2D58A1hsinnreiadobecom_-- From Borilin@spiritdsp.com Wed Aug 26 23:42:24 2009 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 29D603A6A58 for ; Wed, 26 Aug 2009 23:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.29 X-Spam-Level: X-Spam-Status: No, score=-2.29 tagged_above=-999 required=5 tests=[AWL=-0.223, BAYES_00=-2.599, HTML_FONT_SIZE_LARGE=0.001, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q0=0.303, SARE_SUB_OBFU_Q1=0.227] 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 JjFjsVhYiaGd for ; Wed, 26 Aug 2009 23:42:19 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id DA42B3A6405 for ; Wed, 26 Aug 2009 23:42:17 -0700 (PDT) Received: from mail-srv.spiritcorp.com (mail-srv.spiritcorp.com [192.168.125.3]) by mail3.spiritcorp.com (8.13.8/8.14.3) with SMTP id n7R6gH1V061122; Thu, 27 Aug 2009 10:42:18 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) 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_01CA26E1.8181F3AB" Date: Thu, 27 Aug 2009 10:42:10 +0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] [dispatch] Optimal placement of Voice Quality Signal Processing (VQSP) features within Networks Thread-Index: AclOk7JwjC6CKQbIRUOsEdfs75dh2gDAuj0wAABfPZA00I4zAAAsibrQAABG87AABP8MXgBP+3+g References: <549FD0754C7E1D468D93A34B42AC5F92156BB54D@zcarhxm1.corp.nortel.com> From: "Slava Borilin" To: "Henry Sinnreich" , "John Atkinson" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: Re: [codec] [dispatch] Optimal placement of Voice Quality Signal Processing (VQSP) features within Networks X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Aug 2009 06:42:24 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA26E1.8181F3AB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks. =20 best regards, Slava Borilin ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Henry Sinnreich Sent: Tuesday, August 25, 2009 8:32 PM To: John Atkinson; codec@ietf.org Subject: Re: [codec] [dispatch] Optimal placement of Voice Quality Signal Processing (VQSP) features within Networks =20 FYI - just in case you may have missed it. Such functions are distinct from codecs, but may be still of interest. Thanks, Henry On 8/25/09 9:15 AM, "John Atkinson" wrote: Optimal placement of Voice Quality Signal Processing (VQSP) features within Networks =20 ITU SG16 has developed a framework for coordination of voice quality signal processing in networks that have more than one network element capable of doing specific voice quality signal processing functions. This framework was developed to allow optimal placement of the VQSP functions within the network and avoid voice quality degradation due to undesirable side-effects of the interaction of the individual voice quality enhancement functions and to improve voice quality by only applying a given VQ function in one location in the network. =20 =20 =20 The five voice quality signal processing features commonly applied are=20 =20 * Echo Control (control of echo from a hybrid) * Acoustic Echo Control * Automatic Gain Control * Feedback Gain Control * Background Noise Reduction A Node can potentially be capable of applying each of the above five VQSP functions in each of the two directions of a voice path. Doing both Echo control and Acoustic echo control on the same signal is not desirable or necessary nor is applying both automatic gain control and feedback gain control on the same signal desirable or necessary. In addition, it's usually optimal to do echo control as close to the echo source as possible.=20 =20 This ITU work has not defined the actual method by which network elements can communicate which VQ functions are enabled or present in the network and in which direction they are capable of being applied. ITU has sent a Liason Statement to IETF requesting assistance defining how VoIP nodes communicate VQSP capability/state information to other nodes.=20 =20 For Echo Control , VoIP implementors are currently aware of two existing methods of communicating between nodes that echo cancellation is being done. In ISUP, the Echo control device indicator in the Nature of Connection Indicators IE is used to indicate the presence of an echo control device in the forward direction and the Echo Control device Indicator in the Backwards Call Indicators IE is used to indcate the presence on an echo control device in the backwards direction. RFC 3108 defines a session description protocol attribute line for echo control.=20 a=3Decan: which can be used to indicate the presence of G.165/G.168 echo cancellers in one or both directions.=20 =20 In addition, RFC 3108 defines an attribute line for gain control=20 a=3Dgc: which can be used to indicate the presence gain control in one or both directions=20 =20 It would be beneficial for the Dispatch WG to review the ITU Liason Statement (which can be viewed at https://datatracker.ietf.org/liaison/505/ ) and discuss the best method of communicating VQSP functions between nodes . Possible solutions include using SDP, SIP headers, RTP, RTCP, or some new on-path control protocol. =20 John Atkinson johnat@nortel.com ------_=_NextPart_001_01CA26E1.8181F3AB Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [dispatch] Optimal placement of Voice Quality Signal = Processing (VQSP) features within Networks

Thanks.

 

best regards,

Slava = Borilin

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Henry Sinnreich
Sent: Tuesday, August 25, = 2009 8:32 PM
To: John Atkinson; = codec@ietf.org
Subject: Re: [codec] = [dispatch] Optimal placement of Voice Quality Signal Processing (VQSP) features = within Networks

 

FYI – just in case = you may have missed it.
Such functions are distinct from codecs, but may be still of = interest.
Thanks, Henry

On 8/25/09 9:15 AM, "John Atkinson" <johnat@nortel.com> wrote:

Optimal placement of Voice Quality Signal Processing (VQSP) features within = Networks

 
ITU SG16 has developed a framework for coordination of voice quality signal processing in networks that have = more than one network element capable of doing specific voice quality signal = processing functions. This framework was developed to allow optimal placement of = the VQSP functions within the network and avoid voice quality degradation due to undesirable side-effects of the interaction of the individual voice = quality enhancement functions and to improve voice quality by only applying a = given VQ function in one location in the network.  

 
 
The five voice quality signal processing = features commonly applied are
 
·       = ;  Echo Control (control of echo from a hybrid)
·       = ;  Acoustic Echo Control
·       = ;  Automatic Gain Control
·       = ;  Feedback Gain Control
·       = ;  Background Noise Reduction

A Node can potentially be capable of = applying each of the above five VQSP functions in each of the two directions of a = voice path. Doing both Echo control and Acoustic echo control on the same = signal is not desirable or necessary nor is applying both automatic gain control = and feedback gain control on the same signal desirable or necessary. In = addition, it's usually optimal to do echo control as close to the echo source as possible.
 
This ITU work has not defined the actual method by which network = elements can communicate which VQ functions are enabled or present in the network and = in which direction they are capable of being applied. ITU has sent a Liason Statement to IETF requesting assistance defining how VoIP nodes = communicate VQSP capability/state information to other nodes.

 
For Echo Control ,  VoIP implementors = are currently aware of two existing methods of communicating between nodes = that echo cancellation is being done. In ISUP, the Echo control device = indicator in the Nature of Connection Indicators IE is used to indicate the presence = of an echo control device in the forward direction and the Echo Control device Indicator in the Backwards Call Indicators IE is used to indcate the = presence on an echo control device in the backwards direction. RFC 3108 defines a session description protocol attribute line for echo control.

a=3Decan:<directionFlag><ecanEnable><ecanType> which can be used to indicate the presence = of G.165/G.168 echo cancellers in one or both directions.

 
In addition, RFC 3108 defines an attribute = line for gain control

a=3Dgc:<directionFlag><gcEnable><gcLvl>

which can be used to indicate the presence = gain control in one or both directions

 
It would be beneficial for the Dispatch WG = to review  the ITU Liason Statement  (which can be viewed at =  https://datatracker.ie= tf.org/liaison/505/ ) and discuss the best method of communicating VQSP functions =  between nodes .  Possible solutions include using SDP, SIP headers, RTP, = RTCP, or some new on-path control protocol.

 
John Atkinson
johnat@nortel.com=

------_=_NextPart_001_01CA26E1.8181F3AB--