From fluffy@cisco.com Thu Jun 4 11:25:38 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 AE12E3A6D3C for ; Thu, 4 Jun 2009 11:25:38 -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 y39NrLFgDcpM for ; Thu, 4 Jun 2009 11:25:37 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E5AE43A6C85 for ; Thu, 4 Jun 2009 11:25:37 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.41,306,1241395200"; d="scan'208";a="194990582" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 04 Jun 2009 18:25:40 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n54IPe1A008459 for ; Thu, 4 Jun 2009 11:25:40 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n54IPdg9011416 for ; Thu, 4 Jun 2009 18:25:40 GMT Message-Id: From: Cullen Jennings To: codec@ietf.org Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 4 Jun 2009 12:25:39 -0600 X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=25; t=1244139940; x=1245003940; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20test=201 |Sender:=20; bh=KrxydB2asfZmrL606DPRJS4rpr8mXjJ4+6OZm0W+nGc=; b=gFKdrSbvplPlbu7dAnh1zs8O1Urk+EuQ9khUQoJLHBz43juuuYMb5qtaV+ BG0mRO3qOSj2ynXI5xoP+LtU3KD3O3rFbeCdXCwg6hquCF68hPGglrIxC3Dw I5V3mVqhET; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: [codec] test 1 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, 04 Jun 2009 18:25:38 -0000 just trying this list From jean-marc.valin@octasic.com Mon Jun 8 12:07: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 9021528C116 for ; Mon, 8 Jun 2009 12:07:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.28 X-Spam-Level: X-Spam-Status: No, score=-1.28 tagged_above=-999 required=5 tests=[AWL=-0.169, BAYES_05=-1.11] 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 KhVW8hYam2PJ for ; Mon, 8 Jun 2009 12:07:23 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [216.208.79.2]) by core3.amsl.com (Postfix) with ESMTP id AEBC13A6E0D for ; Mon, 8 Jun 2009 12:07:20 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 8 Jun 2009 15:07:25 -0400 Message-ID: <4A2D61A2.2030803@octasic.com> Date: Mon, 08 Jun 2009 15:08:18 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: codec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jun 2009 19:07:25.0772 (UTC) FILETIME=[5C32E0C0:01C9E86C] Subject: [codec] Status 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, 08 Jun 2009 19:07:24 -0000 Hi, I've just noticed that the list got created. Does anyone know the status of our WG proposal and what we need to do from now on to get it accepted? Cheers, Jean-Marc From Borilin@spiritdsp.com Wed Jun 10 23:23:00 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 6B7473A6D17 for ; Wed, 10 Jun 2009 23:23:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.632 X-Spam-Level: X-Spam-Status: No, score=-1.632 tagged_above=-999 required=5 tests=[AWL=0.967, 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 IXjWEDgyUgpL for ; Wed, 10 Jun 2009 23:22:59 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 5F5613A6A41 for ; Wed, 10 Jun 2009 23:22:59 -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 n5B6N3lX045510; Thu, 11 Jun 2009 10:23:03 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 11 Jun 2009 10:22:55 +0400 Message-ID: In-Reply-To: <4A30A0E4.7010401@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [dispatch] Wideband audio codec proposal dispatched as a regular BOF Thread-Index: AcnqW/xSYmRljLJUSjy4v8+MqAymygAAPKcg References: <4A30A0E4.7010401@ericsson.com> From: "Slava Borilin" To: "Gonzalo Camarillo" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: Re: [codec] [dispatch] Wideband audio codec proposal dispatched as a regular BOF 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, 11 Jun 2009 06:23:00 -0000 Thanks. Can you please advice when such BOF is planned or how the scheduling works? regards, Slava Borilin =20 -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Gonzalo Camarillo Sent: Thursday, June 11, 2009 10:15 AM To: DISPATCH Subject: [dispatch] Wideband audio codec proposal dispatched as a regular BOF Folks, there have been significant list discussions on whether or not the IETF=20 should be working on the topics proposed in the email below: http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html As a way forward, we have decided to organize the face-to-face=20 discussions around this topic in Stockholm as a regular BOF (i.e.,=20 outside DISPATCH). We believe that, given the nature of the questions=20 that need to be answered, this topic will benefit from discussions from=20 a wide range of people. Organizing the meeting as a regular BOF ensures=20 such discussions. A regular BOF also provides more time for discussions. Therefore, from now on, please use the following mailing list (instead=20 of the DISPATCH list) for discussions on this topic: codec@ietf.org Thanks, Gonzalo DISPATCH co-chair _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From jean-marc.valin@octasic.com Thu Jun 11 08:01:25 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 791323A6997 for ; Thu, 11 Jun 2009 08:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.968 X-Spam-Level: X-Spam-Status: No, score=-1.968 tagged_above=-999 required=5 tests=[AWL=0.632, 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 lfMS8dwUt9lD for ; Thu, 11 Jun 2009 08:01:24 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [216.208.79.2]) by core3.amsl.com (Postfix) with ESMTP id 6E1F73A6932 for ; Thu, 11 Jun 2009 08:01:24 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Jun 2009 11:01:31 -0400 Message-ID: <4A311C8D.2070100@octasic.com> Date: Thu, 11 Jun 2009 11:02:37 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Slava Borilin References: <4A30A0E4.7010401@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jun 2009 15:01:31.0388 (UTC) FILETIME=[8123CBC0:01C9EAA5] Cc: codec@ietf.org, Gonzalo Camarillo Subject: Re: [codec] [dispatch] Wideband audio codec proposal dispatched as a regular BOF 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, 11 Jun 2009 15:01:25 -0000 Slava Borilin wrote: > Thanks. > Can you please advice when such BOF is planned or how the scheduling > works? > So far, all that I have been able to find is this: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt Also, I can now confirm that I will be present at this BoF. Cheers, Jean-Marc > regards, > Slava Borilin > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: Thursday, June 11, 2009 10:15 AM > To: DISPATCH > Subject: [dispatch] Wideband audio codec proposal dispatched as a > regular BOF > > Folks, > > there have been significant list discussions on whether or not the IETF > should be working on the topics proposed in the email below: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html > > As a way forward, we have decided to organize the face-to-face > discussions around this topic in Stockholm as a regular BOF (i.e., > outside DISPATCH). We believe that, given the nature of the questions > that need to be answered, this topic will benefit from discussions from > a wide range of people. Organizing the meeting as a regular BOF ensures > such discussions. A regular BOF also provides more time for discussions. > > Therefore, from now on, please use the following mailing list (instead > of the DISPATCH list) for discussions on this topic: > > codec@ietf.org > > Thanks, > > Gonzalo > DISPATCH co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From gonzalo.camarillo@ericsson.com Wed Jun 10 23:40:18 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 3BE233A6B38 for ; Wed, 10 Jun 2009 23:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 uYk0IDNcEZxr for ; Wed, 10 Jun 2009 23:40:17 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C2DED3A68FF for ; Wed, 10 Jun 2009 23:40:16 -0700 (PDT) X-AuditID: c1b4fb3e-b7b2dae00000205f-58-4a30a6d6c76d Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 24.65.08287.6D6A03A4; Thu, 11 Jun 2009 08:40:22 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jun 2009 08:40:22 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 11 Jun 2009 08:40:21 +0200 Received: from [131.160.126.159] (rvi2-126-159.lmf.ericsson.se [131.160.126.159]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 52E83246A; Thu, 11 Jun 2009 09:40:21 +0300 (EEST) Message-ID: <4A30A6D5.8060806@ericsson.com> Date: Thu, 11 Jun 2009 09:40:21 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Slava Borilin References: <4A30A0E4.7010401@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jun 2009 06:40:21.0558 (UTC) FILETIME=[7E1FDD60:01C9EA5F] X-Brightmail-Tracker: AAAAAA== X-Mailman-Approved-At: Thu, 11 Jun 2009 08:02:49 -0700 Cc: codec@ietf.org Subject: Re: [codec] [dispatch] Wideband audio codec proposal dispatched as a regular BOF 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, 11 Jun 2009 06:40:18 -0000 Hi, the IAB and the IESG will have a conference call today to talk about all BOF proposals for Stockholm. The secretariat will then take care of scheduling all sessions (WG and BOF sessions), as usual. Cheers, Gonzalo Slava Borilin wrote: > Thanks. > Can you please advice when such BOF is planned or how the scheduling > works? > > regards, > Slava Borilin > > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: Thursday, June 11, 2009 10:15 AM > To: DISPATCH > Subject: [dispatch] Wideband audio codec proposal dispatched as a > regular BOF > > Folks, > > there have been significant list discussions on whether or not the IETF > should be working on the topics proposed in the email below: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html > > As a way forward, we have decided to organize the face-to-face > discussions around this topic in Stockholm as a regular BOF (i.e., > outside DISPATCH). We believe that, given the nature of the questions > that need to be answered, this topic will benefit from discussions from > a wide range of people. Organizing the meeting as a regular BOF ensures > such discussions. A regular BOF also provides more time for discussions. > > Therefore, from now on, please use the following mailing list (instead > of the DISPATCH list) for discussions on this topic: > > codec@ietf.org > > Thanks, > > Gonzalo > DISPATCH co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From Borilin@spiritdsp.com Thu Jun 11 15:12:19 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 595553A6C3D for ; Thu, 11 Jun 2009 15:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.793 X-Spam-Level: X-Spam-Status: No, score=-1.793 tagged_above=-999 required=5 tests=[AWL=0.806, 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 I2UEujoLgxPc for ; Thu, 11 Jun 2009 15:12:18 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 1A6AD3A6BFC for ; Thu, 11 Jun 2009 15:12:16 -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 n5BMCKn3059875; Fri, 12 Jun 2009 02:12:21 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 12 Jun 2009 02:12:11 +0400 Message-ID: In-Reply-To: <4A311C8D.2070100@octasic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] [dispatch] Wideband audio codec proposal dispatched as a regular BOF Thread-Index: AcnqpYbUhjPd1sCuQt+YQ9agKsKAqAAO+/yw References: <4A30A0E4.7010401@ericsson.com> <4A311C8D.2070100@octasic.com> From: "Slava Borilin" To: "Jean-Marc Valin" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org, Gonzalo Camarillo Subject: Re: [codec] [dispatch] Wideband audio codec proposal dispatched as a regular BOF 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, 11 Jun 2009 22:12:19 -0000 Subject to the dates (have some arrangements already), I also confirm being at the BoF. regards, Slava Borilin =20 -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com]=20 Sent: Thursday, June 11, 2009 7:03 PM To: Slava Borilin Cc: Gonzalo Camarillo; codec@ietf.org Subject: Re: [codec] [dispatch] Wideband audio codec proposal dispatched as a regular BOF Slava Borilin wrote: > Thanks. > Can you please advice when such BOF is planned or how the scheduling > works? > =20 So far, all that I have been able to find is this: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt Also, I can now confirm that I will be present at this BoF. Cheers, Jean-Marc > regards, > Slava Borilin > =20 > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: Thursday, June 11, 2009 10:15 AM > To: DISPATCH > Subject: [dispatch] Wideband audio codec proposal dispatched as a > regular BOF > > Folks, > > there have been significant list discussions on whether or not the IETF=20 > should be working on the topics proposed in the email below: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html > > As a way forward, we have decided to organize the face-to-face=20 > discussions around this topic in Stockholm as a regular BOF (i.e.,=20 > outside DISPATCH). We believe that, given the nature of the questions=20 > that need to be answered, this topic will benefit from discussions from=20 > a wide range of people. Organizing the meeting as a regular BOF ensures=20 > such discussions. A regular BOF also provides more time for discussions. > > Therefore, from now on, please use the following mailing list (instead > of the DISPATCH list) for discussions on this topic: > > codec@ietf.org > > Thanks, > > Gonzalo > DISPATCH co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > =20 From hsinnrei@adobe.com Thu Jun 11 17:32:56 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 879573A6A83 for ; Thu, 11 Jun 2009 17:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.929 X-Spam-Level: X-Spam-Status: No, score=-5.929 tagged_above=-999 required=5 tests=[AWL=0.669, BAYES_00=-2.599, 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 Tjmx6rZm9aLd for ; Thu, 11 Jun 2009 17:32:55 -0700 (PDT) Received: from psmtp.com (exprod6ob111.obsmtp.com [64.18.1.26]) by core3.amsl.com (Postfix) with ESMTP id B2C6D3A69D3 for ; Thu, 11 Jun 2009 17:32:48 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKSjGiOFk4Fu9H/J+RoMq2Lp/BCI2XzgBn@postini.com; Thu, 11 Jun 2009 17:33:03 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5C0WqWG016932; Thu, 11 Jun 2009 17:32:53 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5C0WqtQ000916; Thu, 11 Jun 2009 17:32:52 -0700 (PDT) Received: from excas03.corp.adobe.com (10.8.189.123) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 11 Jun 2009 17:32:52 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas03.corp.adobe.com ([10.8.189.123]) with mapi; Thu, 11 Jun 2009 17:32:51 -0700 From: Henry Sinnreich To: Slava Borilin , Jean-Marc Valin Date: Thu, 11 Jun 2009 17:32:50 -0700 Thread-Topic: [codec] [dispatch] Wideband audio codec proposal dispatched as a regular BOF Thread-Index: AcnqpYbUhjPd1sCuQt+YQ9agKsKAqAAO+/ywAAT2gdU= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6570C6240CAhsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" , Gonzalo Camarillo Subject: Re: [codec] [dispatch] Wideband audio codec proposal dispatched as a regular BOF 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: Fri, 12 Jun 2009 00:32:56 -0000 --_000_C6570C6240CAhsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I plan to attend at the BOF. Please put me on the list for updates (I have subscribed to codec@ietf.org)= . Thanks, Henry > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: Thursday, June 11, 2009 10:15 AM > To: DISPATCH > Subject: [dispatch] Wideband audio codec proposal dispatched as a > regular BOF > > Folks, > > there have been significant list discussions on whether or not the IETF > should be working on the topics proposed in the email below: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html > > As a way forward, we have decided to organize the face-to-face > discussions around this topic in Stockholm as a regular BOF (i.e., > outside DISPATCH). We believe that, given the nature of the questions > that need to be answered, this topic will benefit from discussions from > a wide range of people. Organizing the meeting as a regular BOF ensures > such discussions. A regular BOF also provides more time for discussions. > > Therefore, from now on, please use the following mailing list (instead > of the DISPATCH list) for discussions on this topic: > > codec@ietf.org > > Thanks, > > Gonzalo > DISPATCH co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > 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_C6570C6240CAhsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] [dispatch] Wideband audio codec proposal dispatched as a= regular BOF
I plan to attend at the BOF.
Please put me on the list for updates (I have subscribed to codec@ietf.org).
Thanks, Henry

> From: dispatch-bounces@ietf.org<= /a> [mailto:dispatch-bounces@i= etf.org] On
> Behalf Of Gonzalo Camarillo
> Sent: Thursday, June 11, 2009 10:15 AM
> To: DISPATCH
> Subject: [dispatch] Wideband audio codec proposal dispatched as a
> regular BOF
>
> Folks,
>
> there have been significant list discussions on whether or not the
IETF
> should be working on the topics proposed in the email below:
>
> http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.ht= ml
>
> As a way forward, we have decided to organize the face-to-face
> discussions around this topic in Stockholm as a regular BOF (i.e.,
> outside DISPATCH). We believe that, given the nature of the questions<= BR> > that need to be answered, this topic will benefit from discussions
from
> a wide range of people. Organizing the meeting as a regular BOF
ensures
> such discussions. A regular BOF also provides more time for
discussions.
>
> Therefore, from now on, please use the following mailing list (instead=

> of the DISPATCH list) for discussions on this topic:
>
>    codec@ietf.org
>
> Thanks,
>
> Gonzalo
> DISPATCH co-chair
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www= .ietf.org/mailman/listinfo/dispatch
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ie= tf.org/mailman/listinfo/codec
>  

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

--_000_C6570C6240CAhsinnreiadobecom_-- From Borilin@spiritdsp.com Thu Jun 11 22:17:50 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 3BF103A6850 for ; Thu, 11 Jun 2009 22:17:50 -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.537, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 XiTSOXAT2v-6 for ; Thu, 11 Jun 2009 22:17:49 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id DB1503A63CB for ; Thu, 11 Jun 2009 22:17:48 -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 n5C5HnlL064483; Fri, 12 Jun 2009 09:17:49 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EB1D.1D44BEC5" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 12 Jun 2009 09:17:41 +0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] [dispatch] Wideband audio codec proposal dispatched as a regular BOF Thread-Index: AcnqpYbUhjPd1sCuQt+YQ9agKsKAqAAO+/ywAAT2gdUACe+qYA== References: From: "Slava Borilin" To: "Henry Sinnreich" , "Jean-Marc Valin" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org, Gonzalo Camarillo Subject: Re: [codec] [dispatch] Wideband audio codec proposal dispatched as a regular BOF 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: Fri, 12 Jun 2009 05:17:50 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EB1D.1D44BEC5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I plan to attend this BOF as well. =20 regards, Slava Borilin =20 ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Friday, June 12, 2009 4:33 AM To: Slava Borilin; Jean-Marc Valin Cc: codec@ietf.org; Gonzalo Camarillo Subject: Re: [codec] [dispatch] Wideband audio codec proposal dispatched as a regular BOF =20 I plan to attend at the BOF. Please put me on the list for updates (I have subscribed to codec@ietf.org). Thanks, Henry =09 > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: Thursday, June 11, 2009 10:15 AM > To: DISPATCH > Subject: [dispatch] Wideband audio codec proposal dispatched as a > regular BOF > > Folks, > > there have been significant list discussions on whether or not the IETF > should be working on the topics proposed in the email below: > > http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html > > As a way forward, we have decided to organize the face-to-face > discussions around this topic in Stockholm as a regular BOF (i.e., > outside DISPATCH). We believe that, given the nature of the questions > that need to be answered, this topic will benefit from discussions from > a wide range of people. Organizing the meeting as a regular BOF ensures > such discussions. A regular BOF also provides more time for discussions. > > Therefore, from now on, please use the following mailing list (instead =09 > of the DISPATCH list) for discussions on this topic: > > codec@ietf.org > > Thanks, > > Gonzalo > DISPATCH co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > =20 =09 _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ------_=_NextPart_001_01C9EB1D.1D44BEC5 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [codec] [dispatch] Wideband audio codec proposal dispatched = as a regular BOF

I plan to attend = this BOF as well.

 =

regards,

Slava Borilin

 

=

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Friday, June 12, = 2009 4:33 AM
To: Slava Borilin; = Jean-Marc Valin
Cc: codec@ietf.org; = Gonzalo Camarillo
Subject: Re: [codec] = [dispatch] Wideband audio codec proposal dispatched as a regular = BOF

 

I plan to attend at the = BOF.
Please put me on the list for updates (I have subscribed to codec@ietf.org).
Thanks, Henry

> From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.or= g] On
> Behalf Of Gonzalo Camarillo
> Sent: Thursday, June 11, 2009 10:15 AM
> To: DISPATCH
> Subject: [dispatch] Wideband audio codec proposal dispatched as = a
> regular BOF
>
> Folks,
>
> there have been significant list discussions on whether or not = the
IETF
> should be working on the topics proposed in the email below:
>
> http://www.ietf.org/mail-archive/web/dispatch/current/msg00080.html
>
> As a way forward, we have decided to organize the face-to-face
> discussions around this topic in Stockholm as a regular BOF = (i.e.,
> outside DISPATCH). We believe that, given the nature of the = questions
> that need to be answered, this topic will benefit from = discussions
from
> a wide range of people. Organizing the meeting as a regular BOF
ensures
> such discussions. A regular BOF also provides more time for
discussions.
>
> Therefore, from now on, please use the following mailing list = (instead

> of the DISPATCH list) for discussions on this topic:
>
>    codec@ietf.org
>
> Thanks,
>
> Gonzalo
> DISPATCH co-chair
> _______________________________________________
> dispatch mailing list
> dispatch@ietf.org
> https://www.ietf.= org/mailman/listinfo/dispatch
> _______________________________________________
> 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

------_=_NextPart_001_01C9EB1D.1D44BEC5-- From fluffy@cisco.com Fri Jun 12 10:31:48 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 68A953A6806 for ; Fri, 12 Jun 2009 10:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.578 X-Spam-Level: X-Spam-Status: No, score=-106.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 v6CIxsqrXids for ; Fri, 12 Jun 2009 10:31:47 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6D0573A67D7 for ; Fri, 12 Jun 2009 10:31:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,210,1243814400"; d="scan'208";a="80550899" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 12 Jun 2009 17:31:55 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5CHVtnx030580 for ; Fri, 12 Jun 2009 10:31:55 -0700 Received: from [192.168.0.101] (sjc-vpn7-1408.cisco.com [10.21.149.128]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n5CHVsDw004574 for ; Fri, 12 Jun 2009 17:31:55 GMT Message-Id: <1286A822-C9A0-489E-B5C1-8BCACF5023C8@cisco.com> From: Cullen Jennings To: codec@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 12 Jun 2009 11:31:52 -0600 X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1556; t=1244827915; x=1245691915; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Codec=20BOF=20approved,=20much=20work=20needed= 20 |Sender:=20; bh=+LIVTbJKNr0+XDiM2CDfb4YE9Q2IpU43gR3eqQs4eiQ=; b=Y6ErCr8/J2NUw0IROQS7wLOC1xJGMqfRJ0yhMgXfHQRB0Eh8DwSH7toG70 5MfmA0NXEvbgd/Hr/WAXNH+6fX804k1kclGLyvnqqnzWR9ViTlAHVhFn+bJI wToMqk2m+TqBG5d6d8KMydEImsJS4DaOOfRnqI61vZaWX9QoLrVtM=; Authentication-Results: sj-dkim-1; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [codec] Codec BOF approved, much work needed 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: Fri, 12 Jun 2009 17:31:48 -0000 I have approved the CODEC BOF proposal. However, we need a bunch of work to get ready. Various people on IESG/IAB were not comfortable with the current charter and agenda so we need to work on theses before the meeting. A draft agenda/charter Jason provided are at Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt After discussion with the IESG/IAB: I'd like to remove the "as Proposed Standard" from the charter text for both milestones and see how the discussion goes in the BOF before deciding which way this should go. I'd like to see more consideration around the issues of designing a codec that did a good job of mapping a real time stream onto IP packets. The way IP deals with packet loss and congestion has implications for designing a codec that works well over IP. I know some of the discussion I have had off list people talked about how we wanted a codec that supported adaptive bit rates that could change on the fly to be able to work well on an IP network. I will be working the folks to make sure the agenda has time to directly address the key topics which include (more may be coming): Will we be able to get qualified people to do and review the work? Key design goals of a new codec? Do we need a new codec or are there already ones defined that meet the needs? I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. Thanks, Cullen From Even.roni@huawei.com Fri Jun 12 12:08: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 157CD3A6A0E for ; Fri, 12 Jun 2009 12:08:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.519 X-Spam-Level: X-Spam-Status: No, score=-1.519 tagged_above=-999 required=5 tests=[AWL=1.080, 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 mhuPZoj9OVFC for ; Fri, 12 Jun 2009 12:08:02 -0700 (PDT) Received: from szxga01-in.huawei.com (szxga01-in.huawei.com [119.145.14.64]) by core3.amsl.com (Postfix) with ESMTP id E5D153A677C for ; Fri, 12 Jun 2009 12:08:01 -0700 (PDT) Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL5008ML3CH6S@szxga01-in.huawei.com> for codec@ietf.org; Sat, 13 Jun 2009 02:57:53 +0800 (CST) Received: from huawei.com ([172.24.1.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KL500LXP3CHUD@szxga01-in.huawei.com> for codec@ietf.org; Sat, 13 Jun 2009 02:57:53 +0800 (CST) Received: from windows8d787f9 (bzq-79-177-76-15.red.bezeqint.net [79.177.76.15]) by szxml01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KL500JT63CDR5@szxml01-in.huawei.com> for codec@ietf.org; Sat, 13 Jun 2009 02:57:53 +0800 (CST) Date: Fri, 12 Jun 2009 21:56:14 +0300 From: Roni Even In-reply-to: <1286A822-C9A0-489E-B5C1-8BCACF5023C8@cisco.com> To: codec@ietf.org Message-id: <018501c9eb8f$78976c10$69c64430$%roni@huawei.com> MIME-version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Content-type: text/plain; charset=us-ascii Content-language: en-us Content-transfer-encoding: 7BIT Thread-index: Acnrg7Geu5s5P5zNR4OSEheDDVkqeAACcrlg References: <1286A822-C9A0-489E-B5C1-8BCACF5023C8@cisco.com> Subject: Re: [codec] Codec BOF approved, much work needed 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: Fri, 12 Jun 2009 19:08:03 -0000 Hi, I would like to suggest other key topics for the BOF 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / others 2. Describe the process of defining a codec in other standard bodies - my view is that not everyone knows what is required to create a quality codec. 3. Is the purpose of the WG to publish one codec or multiple codecs based on different requirements. 4. If a WG will be formed there are more decision to make like, what is the selection criteria if there is more than one candidate or do we require some cooperation, what are the deliverable - source code, encoder specification (do we require bit exactness ), how to defines the quality tests and evaluate the results to check if the codec addresses the requirements. Roni Even -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Friday, June 12, 2009 8:32 PM To: codec@ietf.org Subject: [codec] Codec BOF approved, much work needed I have approved the CODEC BOF proposal. However, we need a bunch of work to get ready. Various people on IESG/IAB were not comfortable with the current charter and agenda so we need to work on theses before the meeting. A draft agenda/charter Jason provided are at Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt After discussion with the IESG/IAB: I'd like to remove the "as Proposed Standard" from the charter text for both milestones and see how the discussion goes in the BOF before deciding which way this should go. I'd like to see more consideration around the issues of designing a codec that did a good job of mapping a real time stream onto IP packets. The way IP deals with packet loss and congestion has implications for designing a codec that works well over IP. I know some of the discussion I have had off list people talked about how we wanted a codec that supported adaptive bit rates that could change on the fly to be able to work well on an IP network. I will be working the folks to make sure the agenda has time to directly address the key topics which include (more may be coming): Will we be able to get qualified people to do and review the work? Key design goals of a new codec? Do we need a new codec or are there already ones defined that meet the needs? I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. Thanks, Cullen _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From koen.vos@skype.net Fri Jun 12 14:32:13 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 4F0353A681D for ; Fri, 12 Jun 2009 14:32:13 -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 YCu1beYySgVJ for ; Fri, 12 Jun 2009 14:32:12 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id F170C3A6976 for ; Fri, 12 Jun 2009 14:32:11 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 7FD062007A80D for ; Fri, 12 Jun 2009 23:32:19 +0200 (CEST) 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=kbxtvGxjdd9i n9x1cdC0PqOzzCg=; b=TaBX3PGiFlD9n2nNBdep4qqo0k7bJqaLGY/OWZUjGw48 Lv4Un//VUBNfMHdcf2Vr4NDhIDG47m1F60NrnOcJeQYa05wIpz2n5JNZjU6fnxsC NnjR7NTASOjbsZv7XhvoEjYSGC9a3ET7QVFJ2rs6R/9tBGzTdIz/QAYKi+8SCd8= 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=Np57cXI4eEzOMVzwxsVx IWHRW3GYWJhEKDzwkyBvVP/skemvu5N+V0oLBJpAZartcDwymI/0iOWj3+ab9pUB f8WjPpsLjk3ynkmVRxRrDSYcGspfdJ0CkhrSmyTUbBQfvSvwahPn6qZlVcFB9/8o x7sQeD+ax1L3PHv4e+z0VFg= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 7E6012007A809 for ; Fri, 12 Jun 2009 23:32:19 +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 UhaZFViKlPEE for ; Fri, 12 Jun 2009 23:32:09 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 5EE0A2007A958; Fri, 12 Jun 2009 23:32:09 +0200 (CEST) Received: from adsl-71-141-96-214.dsl.snfc21.pacbell.net (adsl-71-141-96-214.dsl.snfc21.pacbell.net [71.141.96.214]) by mail.skype.net (Horde Framework) with HTTP; Fri, 12 Jun 2009 14:32:09 -0700 Message-ID: <20090612143209.322329x8eal8n2op@mail.skype.net> Date: Fri, 12 Jun 2009 14:32:09 -0700 From: Koen Vos To: codec@ietf.org References: <1286A822-C9A0-489E-B5C1-8BCACF5023C8@cisco.com> <018501c9eb8f$78976c10$69c64430$%roni@huawei.com> In-Reply-To: <018501c9eb8f$78976c10$69c64430$%roni@huawei.com> 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] Codec BOF approved, much work needed 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: Fri, 12 Jun 2009 21:32:13 -0000 Roni Even: > 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / > others Also: discuss goals about licensing cost and complexity ? regards, Koen Vos > 2. Describe the process of defining a codec in other standard bodies - my > view is that not everyone knows what is required to create a quality codec. > > 3. Is the purpose of the WG to publish one codec or multiple codecs based on > different requirements. > > 4. If a WG will be formed there are more decision to make like, what is the > selection criteria if there is more than one candidate or do we require some > cooperation, what are the deliverable - source code, encoder specification > (do we require bit exactness ), how to defines the quality tests and > evaluate the results to check if the codec addresses the requirements. > > Roni Even > > > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > Cullen Jennings > Sent: Friday, June 12, 2009 8:32 PM > To: codec@ietf.org > Subject: [codec] Codec BOF approved, much work needed > > > I have approved the CODEC BOF proposal. However, we need a bunch of > work to get ready. Various people on IESG/IAB were not comfortable > with the current charter and agenda so we need to work on theses > before the meeting. > > A draft agenda/charter Jason provided are at > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt > > After discussion with the IESG/IAB: > > I'd like to remove the "as Proposed Standard" from the charter text > for both milestones and see how the discussion goes in the BOF before > deciding which way this should go. > > I'd like to see more consideration around the issues of designing a > codec that did a good job of mapping a real time stream onto IP > packets. The way IP deals with packet loss and congestion has > implications for designing a codec that works well over IP. I know > some of the discussion I have had off list people talked about how we > wanted a codec that supported adaptive bit rates that could change on > the fly to be able to work well on an IP network. > > I will be working the folks to make sure the agenda has time to > directly address the key topics which include (more may be coming): > > Will we be able to get qualified people to do and review the work? > > Key design goals of a new codec? > > Do we need a new codec or are there already ones defined that meet the > needs? > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. > > Thanks, > > Cullen > > > > > > _______________________________________________ > 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 Tue Jun 16 02:09: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 68F453A69B4; Tue, 16 Jun 2009 02:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 HkTzrhl+6sDB; Tue, 16 Jun 2009 02:09:11 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 539573A69E1; Tue, 16 Jun 2009 02:09:11 -0700 (PDT) Received: from hoeneLenovoT60 (isc-router6.urz.tu-dresden.de [141.30.3.115]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n5G98g8d023646 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 16 Jun 2009 11:08:48 +0200 From: "Christian Hoene" To: , Date: Tue, 16 Jun 2009 11:08:40 +0200 Message-ID: <00fc01c9ee62$0e1fa390$2a5eeab0$@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: AcnuXwUA0d2/AKpzTI+fH2V/Y9HOpgAATGbQ 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.0.187; VDF: 7.1.4.97; host: mx05); id=16854-wx6tmP Subject: [codec] FW: New Version Notification for draft-hoene-avt-rtp-sbc-03 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, 16 Jun 2009 09:09:12 -0000 Dear all, we have uploaded a new version of the RTP payload format for the = Bluetooth SBC audio codec. SBC support mono and stereo audio coding = supporting variable frame- and bit rates and having a very low = complexity. It is part of the open-source BlueZ protocol stack for = supporting Bluetooth device in Linux. To the best of our knowledge, its = IPRs will expire in one year and then its usage will be license-free = even for non-Bluetooth systems.=20 Having these features, the SBC is can be considered as a candidate for = the Internet Wideband Audio Codecs working group (CODEC BOF). While its = audio quality does not reach the efficiency of CELT, its much complexity = is lower. Best regards, Christian Hoene -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Tuesday, June 16, 2009 10:47 AM To: hoene@uni-tuebingen.de Cc: frans.de.bont@philips.com Subject: New Version Notification for draft-hoene-avt-rtp-sbc-03=20 A new version of I-D, draft-hoene-avt-rtp-sbc-03.txt has been = successfuly submitted by Christian Hoene and posted to the IETF = repository. Filename: draft-hoene-avt-rtp-sbc Revision: 03 Title: RTP Payload Format for Bluetooth's SBC audio codec Creation_date: 2009-06-15 WG ID: Independent Submission Number_of_pages: 23 Abstract: This document specifies a Real-time Transport Protocol (RTP) payload=20 format to be used for the low complexity subband codec (SBC), which=20 is the mandatory audio codec of the Advanced Audio Distribution=20 Profile (A2DP) Specification written by the Bluetooth(r) Special=20 Interest Group (SIG). The payload format is designed to be able to=20 interoperate with existing Bluetooth A2DP devices, to provide high=20 streaming audio quality, interactive audio transmission over the=20 internet, and ultra-low delay coding for jam sessions on the=20 internet. This document contains also a media type registration which=20 specifies the use of the RTP payload format. = =20 The IETF Secretariat. From Borilin@spiritdsp.com Tue Jun 16 11:28:15 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 B5D473A6BDD for ; Tue, 16 Jun 2009 11:28:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.841 X-Spam-Level: X-Spam-Status: No, score=-1.841 tagged_above=-999 required=5 tests=[AWL=0.758, 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 U7t5b0Vt6ywO for ; Tue, 16 Jun 2009 11:28:14 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 86CE63A6BA4 for ; Tue, 16 Jun 2009 11:28:14 -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 n5GISGn8041514; Tue, 16 Jun 2009 22:28:17 +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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 22:28:09 +0400 Message-ID: In-Reply-To: <00fc01c9ee62$0e1fa390$2a5eeab0$@de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] FW: New Version Notification for draft-hoene-avt-rtp-sbc-03 Thread-Index: AcnuXwUA0d2/AKpzTI+fH2V/Y9HOpgAATGbQABPrO4A= References: <00fc01c9ee62$0e1fa390$2a5eeab0$@de> From: "Slava Borilin" To: "Christian Hoene" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: Re: [codec] FW: New Version Notification for draft-hoene-avt-rtp-sbc-03 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, 16 Jun 2009 18:28:15 -0000 Christian,=20 Thanks, but the most important probably for IWAC (internet..codec) is robustness for packet loss and similar techniques, which is not the strong point afaik for SBC. regards, Slava Borilin =20 -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Christian Hoene Sent: Tuesday, June 16, 2009 1:09 PM To: avt@ietf.org; codec@ietf.org Subject: [codec] FW: New Version Notification for draft-hoene-avt-rtp-sbc-03 Dear all, we have uploaded a new version of the RTP payload format for the Bluetooth SBC audio codec. SBC support mono and stereo audio coding supporting variable frame- and bit rates and having a very low complexity. It is part of the open-source BlueZ protocol stack for supporting Bluetooth device in Linux. To the best of our knowledge, its IPRs will expire in one year and then its usage will be license-free even for non-Bluetooth systems.=20 Having these features, the SBC is can be considered as a candidate for the Internet Wideband Audio Codecs working group (CODEC BOF). While its audio quality does not reach the efficiency of CELT, its much complexity is lower. Best regards, Christian Hoene -----Original Message----- From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org]=20 Sent: Tuesday, June 16, 2009 10:47 AM To: hoene@uni-tuebingen.de Cc: frans.de.bont@philips.com Subject: New Version Notification for draft-hoene-avt-rtp-sbc-03=20 A new version of I-D, draft-hoene-avt-rtp-sbc-03.txt has been successfuly submitted by Christian Hoene and posted to the IETF repository. Filename: draft-hoene-avt-rtp-sbc Revision: 03 Title: RTP Payload Format for Bluetooth's SBC audio codec Creation_date: 2009-06-15 WG ID: Independent Submission Number_of_pages: 23 Abstract: This document specifies a Real-time Transport Protocol (RTP) payload=20 format to be used for the low complexity subband codec (SBC), which=20 is the mandatory audio codec of the Advanced Audio Distribution=20 Profile (A2DP) Specification written by the Bluetooth(r) Special=20 Interest Group (SIG). The payload format is designed to be able to=20 interoperate with existing Bluetooth A2DP devices, to provide high=20 streaming audio quality, interactive audio transmission over the=20 internet, and ultra-low delay coding for jam sessions on the=20 internet. This document contains also a media type registration which=20 specifies the use of the RTP payload format. =20 The IETF Secretariat. _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From hoene@uni-tuebingen.de Tue Jun 16 13:45: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 8F1093A6824 for ; Tue, 16 Jun 2009 13:45:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.63 X-Spam-Level: X-Spam-Status: No, score=-5.63 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 FJYNP5K6waPO for ; Tue, 16 Jun 2009 13:45:11 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 57F0328C19F for ; Tue, 16 Jun 2009 13:45:11 -0700 (PDT) Received: from wm01.uni-tuebingen.de (wm01.uni-tuebingen.de [134.2.3.20]) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n5GKikBx003300; Tue, 16 Jun 2009 22:44:46 +0200 Received: by wm01.uni-tuebingen.de (Postfix, from userid 30) id 2C3987241DE; Tue, 16 Jun 2009 22:44:46 +0200 (CEST) Received: from 82.113.106.158 ([82.113.106.158]) by webmail.uni-tuebingen.de (Horde Framework) with HTTP; Tue, 16 Jun 2009 22:44:46 +0200 Message-ID: <20090616224446.102610mt24c4o56m@webmail.uni-tuebingen.de> Date: Tue, 16 Jun 2009 22:44:46 +0200 From: "Dr. Christian Hoene" To: Slava Borilin References: <00fc01c9ee62$0e1fa390$2a5eeab0$@de> In-Reply-To: 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) 4.3.3 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.0.187; VDF: 7.1.4.100; host: mx05); id=16854-wv1pB2 Cc: codec@ietf.org Subject: Re: [codec] FW: New Version Notification for draft-hoene-avt-rtp-sbc-03 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, 16 Jun 2009 20:45:12 -0000 Hi Slava Borilin, > Christian, > > Thanks, but the most important probably for IWAC (internet..codec) is > robustness for packet loss and similar techniques, which is not the > strong point afaik for SBC. We usually use SBC together with a PLC concealment based on G.711a1 (extended to 48000). This combination works quite fine in case of packet losses because the SBC decoder does not de-synchronise. Regards, Christian > > regards, > Slava Borilin > > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Christian Hoene > Sent: Tuesday, June 16, 2009 1:09 PM > To: avt@ietf.org; codec@ietf.org > Subject: [codec] FW: New Version Notification for > draft-hoene-avt-rtp-sbc-03 > > Dear all, > > we have uploaded a new version of the RTP payload format for the > Bluetooth SBC audio codec. SBC support mono and stereo audio coding > supporting variable frame- and bit rates and having a very low > complexity. It is part of the open-source BlueZ protocol stack for > supporting Bluetooth device in Linux. To the best of our knowledge, its > IPRs will expire in one year and then its usage will be license-free > even for non-Bluetooth systems. > > Having these features, the SBC is can be considered as a candidate for > the Internet Wideband Audio Codecs working group (CODEC BOF). While its > audio quality does not reach the efficiency of CELT, its much complexity > is lower. > > Best regards, > > Christian Hoene > > -----Original Message----- > From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] > Sent: Tuesday, June 16, 2009 10:47 AM > To: hoene@uni-tuebingen.de > Cc: frans.de.bont@philips.com > Subject: New Version Notification for draft-hoene-avt-rtp-sbc-03 > > > A new version of I-D, draft-hoene-avt-rtp-sbc-03.txt has been > successfuly submitted by Christian Hoene and posted to the IETF > repository. > > Filename: draft-hoene-avt-rtp-sbc > Revision: 03 > Title: RTP Payload Format for Bluetooth's SBC audio codec > Creation_date: 2009-06-15 > WG ID: Independent Submission > Number_of_pages: 23 > > Abstract: > This document specifies a Real-time Transport Protocol (RTP) payload > format to be used for the low complexity subband codec (SBC), which > is the mandatory audio codec of the Advanced Audio Distribution > Profile (A2DP) Specification written by the Bluetooth(r) Special > Interest Group (SIG). The payload format is designed to be able to > interoperate with existing Bluetooth A2DP devices, to provide high > streaming audio quality, interactive audio transmission over the > internet, and ultra-low delay coding for jam sessions on the > internet. This document contains also a media type registration which > specifies the use of the RTP payload format. > > > > > The IETF Secretariat. > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From Borilin@spiritdsp.com Tue Jun 16 13:56:50 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 16BAF3A697E for ; Tue, 16 Jun 2009 13:56:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.925 X-Spam-Level: X-Spam-Status: No, score=-1.925 tagged_above=-999 required=5 tests=[AWL=0.674, 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 tFOlPc1DDGPd for ; Tue, 16 Jun 2009 13:56:49 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 8484D3A6DA1 for ; Tue, 16 Jun 2009 13:56:48 -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 n5GKuAsq044075; Wed, 17 Jun 2009 00:56:11 +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: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 00:56:04 +0400 Message-ID: In-Reply-To: <018501c9eb8f$78976c10$69c64430$%roni@huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acnrg7Geu5s5P5zNR4OSEheDDVkqeAACcrlgAM1yp6A= References: <1286A822-C9A0-489E-B5C1-8BCACF5023C8@cisco.com> <018501c9eb8f$78976c10$69c64430$%roni@huawei.com> From: "Slava Borilin" To: "Roni Even" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: Re: [codec] Codec BOF approved, much work needed 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, 16 Jun 2009 20:56:50 -0000 Roni, and whole international team, I have one more question here - sorry if this is na=EFve- but still = please advice. Background: all of us do wish wish wish (vendors, customers, end-users, = etc) to have ONE IWAC (internet wideband audio codec) for all. But assuming we (IETF) will come to the agreement which codec we like = best (existing or new one) and make RFC. What will then be the destiny of the that RFC?=20 And who and why should be choosing the certain codec into their app? Afaik IETF, like ITU just "agree on the specs", while industry or = country-specific organizations are enforcing using or not using certain = standards, like CableLabs (Vertical market + geography). The major driver for agreeing on the standard is interop, as I see.=20 Currently in the internet communications (web collaboration, voip = services, videoconferencing) - do you believe is there any force to push = interop, or everyone "plays in his own walled garden"? Should we: - agree on RFC and then dig into smaller (geographical or vertical = industry) communities to push them to force using this RFC (IWAC) as = part of certification to make sure they do enforce the IWAC? - or we should just have IWAC RFC and believe "better staff will find = its way to the market itself"? regards, Slava Borilin =20 -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Roni Even Sent: Friday, June 12, 2009 10:56 PM To: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Hi, I would like to suggest other key topics for the BOF 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / others 2. Describe the process of defining a codec in other standard bodies - = my view is that not everyone knows what is required to create a quality = codec. 3. Is the purpose of the WG to publish one codec or multiple codecs = based on different requirements. 4. If a WG will be formed there are more decision to make like, what is = the selection criteria if there is more than one candidate or do we require = some cooperation, what are the deliverable - source code, encoder = specification (do we require bit exactness ), how to defines the quality tests and evaluate the results to check if the codec addresses the requirements. Roni Even=20 -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Cullen Jennings Sent: Friday, June 12, 2009 8:32 PM To: codec@ietf.org Subject: [codec] Codec BOF approved, much work needed I have approved the CODEC BOF proposal. However, we need a bunch of =20 work to get ready. Various people on IESG/IAB were not comfortable =20 with the current charter and agenda so we need to work on theses =20 before the meeting. A draft agenda/charter Jason provided are at Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt Charter: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt After discussion with the IESG/IAB: I'd like to remove the "as Proposed Standard" from the charter text =20 for both milestones and see how the discussion goes in the BOF before =20 deciding which way this should go. I'd like to see more consideration around the issues of designing a =20 codec that did a good job of mapping a real time stream onto IP =20 packets. The way IP deals with packet loss and congestion has =20 implications for designing a codec that works well over IP. I know =20 some of the discussion I have had off list people talked about how we =20 wanted a codec that supported adaptive bit rates that could change on =20 the fly to be able to work well on an IP network. I will be working the folks to make sure the agenda has time to =20 directly address the key topics which include (more may be coming): Will we be able to get qualified people to do and review the work? Key design goals of a new codec? Do we need a new codec or are there already ones defined that meet the =20 needs? I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. Thanks, Cullen _______________________________________________ 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@octasic.com Tue Jun 16 14:05: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 6E4113A6C41 for ; Tue, 16 Jun 2009 14:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.073 X-Spam-Level: X-Spam-Status: No, score=-1.073 tagged_above=-999 required=5 tests=[AWL=-0.578, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 EcXwigYpaWW6 for ; Tue, 16 Jun 2009 14:05:04 -0700 (PDT) Received: from MAILEXCH.octasic.com (unknown [216.208.79.2]) by core3.amsl.com (Postfix) with ESMTP id F32173A6D71 for ; Tue, 16 Jun 2009 14:05:03 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 17:04:15 -0400 Message-ID: <4A3808CF.7080404@octasic.com> Date: Tue, 16 Jun 2009 17:04:15 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Dr. Christian Hoene" References: <00fc01c9ee62$0e1fa390$2a5eeab0$@de> <20090616224446.102610mt24c4o56m@webmail.uni-tuebingen.de> In-Reply-To: <20090616224446.102610mt24c4o56m@webmail.uni-tuebingen.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jun 2009 21:04:15.0544 (UTC) FILETIME=[01A73380:01C9EEC6] Cc: Slava Borilin , codec@ietf.org Subject: Re: [codec] FW: New Version Notification for draft-hoene-avt-rtp-sbc-03 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, 16 Jun 2009 21:05:05 -0000 Hi Christian, Dr. Christian Hoene wrote: >> Thanks, but the most important probably for IWAC (internet..codec) is >> robustness for packet loss and similar techniques, which is not the >> strong point afaik for SBC. > We usually use SBC together with a PLC concealment based on G.711a1 > (extended to 48000). This combination works quite fine in case of > packet losses because the SBC decoder does not de-synchronise. If we look at CELT vs SBC specifically, CELT has the possibility to encode frames independently to increase loss robustness at a small cost in bit-rate. Even with independent frames, CELT still needs only half the bitrate to achieve the same quality as SBC, according to the results that you presented at the ITU workshop: http://net.cs.uni-tuebingen.de/html/ristore2net/publications/papers/hoene2008_itu.pdf . I would say that SBC's lower complexity isn't worth the quality/robustness cost, especially considering that CELT can do encoding+decoding with about 30 MHz on a Core2 and easily runs in real-time on just about any DSP. Cheers, Jean-Marc > Regards, > > Christian > >> >> regards, >> Slava Borilin >> >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >> Of Christian Hoene >> Sent: Tuesday, June 16, 2009 1:09 PM >> To: avt@ietf.org; codec@ietf.org >> Subject: [codec] FW: New Version Notification for >> draft-hoene-avt-rtp-sbc-03 >> >> Dear all, >> >> we have uploaded a new version of the RTP payload format for the >> Bluetooth SBC audio codec. SBC support mono and stereo audio coding >> supporting variable frame- and bit rates and having a very low >> complexity. It is part of the open-source BlueZ protocol stack for >> supporting Bluetooth device in Linux. To the best of our knowledge, its >> IPRs will expire in one year and then its usage will be license-free >> even for non-Bluetooth systems. >> >> Having these features, the SBC is can be considered as a candidate for >> the Internet Wideband Audio Codecs working group (CODEC BOF). While its >> audio quality does not reach the efficiency of CELT, its much complexity >> is lower. >> >> Best regards, >> >> Christian Hoene >> >> -----Original Message----- >> From: IETF I-D Submission Tool [mailto:idsubmission@ietf.org] >> Sent: Tuesday, June 16, 2009 10:47 AM >> To: hoene@uni-tuebingen.de >> Cc: frans.de.bont@philips.com >> Subject: New Version Notification for draft-hoene-avt-rtp-sbc-03 >> >> >> A new version of I-D, draft-hoene-avt-rtp-sbc-03.txt has been >> successfuly submitted by Christian Hoene and posted to the IETF >> repository. >> >> Filename: draft-hoene-avt-rtp-sbc >> Revision: 03 >> Title: RTP Payload Format for Bluetooth's SBC audio codec >> Creation_date: 2009-06-15 >> WG ID: Independent Submission >> Number_of_pages: 23 >> >> Abstract: >> This document specifies a Real-time Transport Protocol (RTP) payload >> format to be used for the low complexity subband codec (SBC), which >> is the mandatory audio codec of the Advanced Audio Distribution >> Profile (A2DP) Specification written by the Bluetooth(r) Special >> Interest Group (SIG). The payload format is designed to be able to >> interoperate with existing Bluetooth A2DP devices, to provide high >> streaming audio quality, interactive audio transmission over the >> internet, and ultra-low delay coding for jam sessions on the >> internet. This document contains also a media type registration which >> specifies the use of the RTP payload format. >> >> >> >> >> The IETF Secretariat. >> >> >> _______________________________________________ >> 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@octasic.com Tue Jun 16 14:33:23 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 87B2A3A6D6C for ; Tue, 16 Jun 2009 14:33:23 -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.589, 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 OROhBTV3elbi for ; Tue, 16 Jun 2009 14:33:22 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [216.208.79.2]) by core3.amsl.com (Postfix) with ESMTP id EC76F3A69B0 for ; Tue, 16 Jun 2009 14:33:21 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 17:30:07 -0400 Message-ID: <4A380EDF.6070204@octasic.com> Date: Tue, 16 Jun 2009 17:30:07 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Slava Borilin References: <1286A822-C9A0-489E-B5C1-8BCACF5023C8@cisco.com> <018501c9eb8f$78976c10$69c64430$%roni@huawei.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Jun 2009 21:30:07.0079 (UTC) FILETIME=[9E70A770:01C9EEC9] Cc: codec@ietf.org, Roni Even Subject: Re: [codec] Codec BOF approved, much work needed 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, 16 Jun 2009 21:33:23 -0000 Hi, Slava Borilin wrote: > Roni, and whole international team, > > I have one more question here - sorry if this is naïve- but still please advice. > > Background: all of us do wish wish wish (vendors, customers, end-users, etc) to have ONE IWAC (internet wideband audio codec) for all. > Well, technically it doesn't have to be a single codec. Just like the ITU, we can have more than one codec as long as there is no overlap between them (i.e. making sure the codecs aren't "competing" one against the other). Of course, this is to be further discussed in the BOF. > But assuming we (IETF) will come to the agreement which codec we like best (existing or new one) and make RFC. > What will then be the destiny of the that RFC? > And who and why should be choosing the certain codec into their app? > > Afaik IETF, like ITU just "agree on the specs", while industry or country-specific organizations are enforcing using or not using certain standards, like CableLabs (Vertical market + geography). > As you say, neither the IETF, nor the ITU can force anyone to use a codec. The idea would be to come up with a codec that really meets the needs of "Internet users". This can be achieved by addressing the issues Jason mentioned in his original post (loss robustness, scalability, low delay, no IPR, ...). Again, the exact requirements should be further discussed, but there are certainly many issues that the current ITU/ETSI/MPEG codecs do not address. > Should we: > - agree on RFC and then dig into smaller (geographical or vertical industry) communities to push them to force using this RFC (IWAC) as part of certification to make sure they do enforce the IWAC? > - or we should just have IWAC RFC and believe "better staff will find its way to the market itself"? > Well, the IETF can't force anyone to use anything, but making a codec an IETF standard will hopefully convince some people to adopt it. Of course, the codec will first have to meet the users' needs. Cheers, Jean-Marc > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Roni Even > Sent: Friday, June 12, 2009 10:56 PM > To: codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > Hi, > I would like to suggest other key topics for the BOF > > 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / > others > > 2. Describe the process of defining a codec in other standard bodies - my > view is that not everyone knows what is required to create a quality codec. > > 3. Is the purpose of the WG to publish one codec or multiple codecs based on > different requirements. > > 4. If a WG will be formed there are more decision to make like, what is the > selection criteria if there is more than one candidate or do we require some > cooperation, what are the deliverable - source code, encoder specification > (do we require bit exactness ), how to defines the quality tests and > evaluate the results to check if the codec addresses the requirements. > > Roni Even > > > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > Cullen Jennings > Sent: Friday, June 12, 2009 8:32 PM > To: codec@ietf.org > Subject: [codec] Codec BOF approved, much work needed > > > I have approved the CODEC BOF proposal. However, we need a bunch of > work to get ready. Various people on IESG/IAB were not comfortable > with the current charter and agenda so we need to work on theses > before the meeting. > > A draft agenda/charter Jason provided are at > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt > > After discussion with the IESG/IAB: > > I'd like to remove the "as Proposed Standard" from the charter text > for both milestones and see how the discussion goes in the BOF before > deciding which way this should go. > > I'd like to see more consideration around the issues of designing a > codec that did a good job of mapping a real time stream onto IP > packets. The way IP deals with packet loss and congestion has > implications for designing a codec that works well over IP. I know > some of the discussion I have had off list people talked about how we > wanted a codec that supported adaptive bit rates that could change on > the fly to be able to work well on an IP network. > > I will be working the folks to make sure the agenda has time to > directly address the key topics which include (more may be coming): > > Will we be able to get qualified people to do and review the work? > > Key design goals of a new codec? > > Do we need a new codec or are there already ones defined that meet the > needs? > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. > > Thanks, > > Cullen > > > > > > _______________________________________________ > 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 hsinnrei@adobe.com Tue Jun 16 14:33:51 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 24EE328C1AE for ; Tue, 16 Jun 2009 14:33:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.063 X-Spam-Level: X-Spam-Status: No, score=-6.063 tagged_above=-999 required=5 tests=[AWL=0.535, BAYES_00=-2.599, 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 DJeFw9Du0bhn for ; Tue, 16 Jun 2009 14:33:49 -0700 (PDT) Received: from exprod6og108.obsmtp.com (exprod6og108.obsmtp.com [64.18.1.21]) by core3.amsl.com (Postfix) with ESMTP id 2670528C0D0 for ; Tue, 16 Jun 2009 14:33:49 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob108.postini.com ([64.18.5.12]) with SMTP ID DSNKSjgPoJ/XceL609g28xeQesfFb1RiRZiH@postini.com; Tue, 16 Jun 2009 14:34:00 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5GLR8ao027723; Tue, 16 Jun 2009 14:27:08 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5GLXJtQ008583; Tue, 16 Jun 2009 14:33:19 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Tue, 16 Jun 2009 14:33:19 -0700 From: Henry Sinnreich To: Slava Borilin , Roni Even , "codec@ietf.org" Date: Tue, 16 Jun 2009 14:33:15 -0700 Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acnrg7Geu5s5P5zNR4OSEheDDVkqeAACcrlgAM1yp6AAAbHVzw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C65D79CB424Ahsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] Codec BOF approved, much work needed 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, 16 Jun 2009 21:33:51 -0000 --_000_C65D79CB424Ahsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Slava, >Currently in the internet communications (web collaboration, voip services= , videoconferencing) - >do you believe is there any force to push interop, or everyone "plays in h= is own walled garden"? IMO one of the main the strengths of the Internet is its global reach. The = user can be anywhere and reach content from and communicate with anyone, an= ywhere. Just like we are doing here with email. The Internet codec will hopefully do for voice the same as text communicati= ons + attachments work in email. >sorry if this is na=EFve This applies to my message as well :-) Henry On 6/16/09 3:56 PM, "Slava Borilin" wrote: Roni, and whole international team, I have one more question here - sorry if this is na=EFve- but still please = advice. Background: all of us do wish wish wish (vendors, customers, end-users, etc= ) to have ONE IWAC (internet wideband audio codec) for all. But assuming we (IETF) will come to the agreement which codec we like best = (existing or new one) and make RFC. What will then be the destiny of the that RFC? And who and why should be choosing the certain codec into their app? Afaik IETF, like ITU just "agree on the specs", while industry or country-s= pecific organizations are enforcing using or not using certain standards, l= ike CableLabs (Vertical market + geography). The major driver for agreeing on the standard is interop, as I see. Currently in the internet communications (web collaboration, voip services,= videoconferencing) - do you believe is there any force to push interop, or= everyone "plays in his own walled garden"? Should we: - agree on RFC and then dig into smaller (geographical or vertical industry= ) communities to push them to force using this RFC (IWAC) as part of certif= ication to make sure they do enforce the IWAC? - or we should just have IWAC RFC and believe "better staff will find its w= ay to the market itself"? regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of R= oni Even Sent: Friday, June 12, 2009 10:56 PM To: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Hi, I would like to suggest other key topics for the BOF 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / others 2. Describe the process of defining a codec in other standard bodies - my view is that not everyone knows what is required to create a quality codec. 3. Is the purpose of the WG to publish one codec or multiple codecs based o= n different requirements. 4. If a WG will be formed there are more decision to make like, what is the selection criteria if there is more than one candidate or do we require som= e cooperation, what are the deliverable - source code, encoder specification (do we require bit exactness ), how to defines the quality tests and evaluate the results to check if the codec addresses the requirements. Roni Even -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Friday, June 12, 2009 8:32 PM To: codec@ietf.org Subject: [codec] Codec BOF approved, much work needed I have approved the CODEC BOF proposal. However, we need a bunch of work to get ready. Various people on IESG/IAB were not comfortable with the current charter and agenda so we need to work on theses before the meeting. A draft agenda/charter Jason provided are at Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt After discussion with the IESG/IAB: I'd like to remove the "as Proposed Standard" from the charter text for both milestones and see how the discussion goes in the BOF before deciding which way this should go. I'd like to see more consideration around the issues of designing a codec that did a good job of mapping a real time stream onto IP packets. The way IP deals with packet loss and congestion has implications for designing a codec that works well over IP. I know some of the discussion I have had off list people talked about how we wanted a codec that supported adaptive bit rates that could change on the fly to be able to work well on an IP network. I will be working the folks to make sure the agenda has time to directly address the key topics which include (more may be coming): Will we be able to get qualified people to do and review the work? Key design goals of a new codec? Do we need a new codec or are there already ones defined that meet the needs? I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. Thanks, Cullen _______________________________________________ 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 --_000_C65D79CB424Ahsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Codec BOF approved, much work needed Hi Slava,

>Currently in the internet communications (web collaboration, voip servi= ces, videoconferencing) -
>do you believe is there any force to push interop, or everyone "pl= ays in his own walled garden"?

IMO one of the main the strengths of the Internet is its global reach. The = user can be anywhere and reach content from and communicate with anyone, an= ywhere. Just like we are doing here with email.
The Internet codec will hopefully do for voice the same as text communicati= ons + attachments work in email.

>sorry if this is naïve
This applies to my message as well :-)

Henry

On 6/16/09 3:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:

Roni, and whole international team,

I have one more question here - sorry if this is naïve- but still plea= se advice.

Background: all of us do wish wish wish (vendors, customers, end-users, etc= ) to have ONE IWAC (internet wideband audio codec) for all.

But assuming we (IETF) will come to the agreement which codec we like best = (existing or new one) and make RFC.
What will then be the destiny of the that RFC?
And who and why should be choosing the certain codec into their app?

Afaik IETF, like ITU just "agree on the specs", while industry or= country-specific organizations are enforcing using or not using certain st= andards, like CableLabs (Vertical market + geography).

The major driver for agreeing on the standard is interop, as I see.
Currently in the internet communications (web collaboration, voip services,= videoconferencing) - do you believe is there any force to push interop, or= everyone "plays in his own walled garden"?

Should we:
- agree on RFC and then dig into smaller (geographical or vertical industry= ) communities to push them to force using this RFC (IWAC) as part of certif= ication to make sure they do enforce the IWAC?
- or we should just have IWAC RFC and believe "better staff will find = its way to the market itself"?

regards,
Slava Borilin


-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On B= ehalf Of Roni Even
Sent: Friday, June 12, 2009 10:56 PM
To: codec@ietf.org
Subject: Re: [codec] Codec BOF approved, much work needed

Hi,
I would like to suggest other key topics for the BOF

1. Why should the IETF start a codec WG - why not do it as ITU / MPEG /
others

2. Describe the process of defining a codec in other standard bodies - my view is that not everyone knows what is required to create a quality codec.=

3. Is the purpose of the WG to publish one codec or multiple codecs based o= n
different requirements.

4. If a WG will be formed there are more decision to make like, what is the=
selection criteria if there is more than one candidate or do we require som= e
cooperation, what are the deliverable - source code, encoder specification<= BR> (do we require bit exactness ), how to defines the quality tests and
evaluate the results to check if the codec addresses the requirements.

Roni Even



-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On B= ehalf Of
Cullen Jennings
Sent: Friday, June 12, 2009 8:32 PM
To: codec@ietf.org
Subject: [codec] Codec BOF approved, much work needed


I have approved the CODEC BOF proposal. However, we need a bunch of
work to get ready.  Various people on IESG/IAB were not comfortable with the current charter and agenda so we need to work on theses
before the meeting.

A draft agenda/charter Jason provided are at

Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt

Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt=

After discussion with the IESG/IAB:

I'd like to remove the "as Proposed Standard" from the charter te= xt
for both milestones and see how the discussion goes in the BOF before
deciding which way this should go.

I'd like to see more consideration around the issues of designing a
codec that did a good job of mapping a real time stream onto IP
packets. The way IP deals with packet loss and congestion has
implications for designing a codec that works well over IP. I know
some of the discussion I have had off list people talked about how we
wanted a codec that supported adaptive bit rates that could change on
the fly to be able to work well on an IP network.

I will be working the folks to make sure the agenda has time to
directly address the key topics which include (more may be coming):

Will we be able to get qualified people to do and review the work?

Key design goals of a new codec?

Do we need a new codec or are there already ones defined that meet the
needs?

I have asked Jason Fischl  and Jean-Marc Valin to co-chair this BOF.
Thanks,

Cullen <RAI AD>





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

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

--_000_C65D79CB424Ahsinnreiadobecom_-- From Borilin@spiritdsp.com Tue Jun 16 14:56: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 332C428C1BA for ; Tue, 16 Jun 2009 14:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.765 X-Spam-Level: X-Spam-Status: No, score=-0.765 tagged_above=-999 required=5 tests=[AWL=-0.622, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 u21Mi2m63oKq for ; Tue, 16 Jun 2009 14:56:34 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id D678A3A6AA1 for ; Tue, 16 Jun 2009 14:56:32 -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 n5GLuTox044956; Wed, 17 Jun 2009 01:56:29 +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_01C9EECD.4A0DAD0A" Date: Wed, 17 Jun 2009 01:56:23 +0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acnrg7Geu5s5P5zNR4OSEheDDVkqeAACcrlgAM1yp6AAAbHVzwAAEL0w References: From: "Slava Borilin" To: "Henry Sinnreich" , "Roni Even" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: Re: [codec] Codec BOF approved, much work needed 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, 16 Jun 2009 21:56:45 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EECD.4A0DAD0A Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Dear Henry, =20 It is probably not the same as with email (or maybe just timing is = different). We are talking not about "enabling technology" to make everyone = understand each other (email case), but "enhancement" - everyone can = today understand each other via 711 or 722, but we want to push the = quality bar while keeping the interop. =20 So really the magic question is that once we have the agreement on = "recommended" IWAC- either one or several (agree with Jean-Marc), who is = to enforce? PROBABLY the force to enforce are telecom operators? As telco, against internet companies (Cisco, Skype, MSFT, etc), do not = like walled gardens by definition: - The telco landscape is not (well, not only) Skype/cheap IP calls = versus Cellular or Wireline. - The mid-term battle is between internet and its rich communication = techniques (web conferencing, social networking) and telco's phone-only = service. - Battle is not only for call $$, but for the time spent on the media = (trend is users spending more minutes on internet comms then on phones) - so carriers have to move from NGN core networks to offer IP-based = "social network-like" communication models to subscribers, therefore, = have IP-service at the last mile for the user, and not only for = enterprise IP-phones, but every consumer. - And as Telco need subscribers to pay for the service, here comes the = HD(=3Dwideband + packet loss robustness), as the necessary step to keep = user satisfied with the carrier IP-service. - So actually, HD sounds to be the cornerstone for keeping the landscape = of whole Telco industry versus Internet communications (or vice versa). - so for telcos it will be really important to have IWAC RFC and telcos = have the power to enforce using it (via geo or industry forums - = examples are PAL/NTSC in geo, industry - CableLabs), and they are used = to the standard/certification process? =20 Again, apart from the ambitions, what all of us (as vendors and as = users) would like to achieve, is interop. And interop should, probably, be enforced, not "recommended" via some = sort of certification? =20 Everyone, please advice. =20 regards, Slava Borilin =20 ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Wednesday, June 17, 2009 1:33 AM To: Slava Borilin; Roni Even; codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed =20 Hi Slava, >Currently in the internet communications (web collaboration, voip = services, videoconferencing) -=20 >do you believe is there any force to push interop, or everyone "plays = in his own walled garden"? IMO one of the main the strengths of the Internet is its global reach. = The user can be anywhere and reach content from and communicate with = anyone, anywhere. Just like we are doing here with email. The Internet codec will hopefully do for voice the same as text = communications + attachments work in email. >sorry if this is na=EFve This applies to my message as well :-) Henry On 6/16/09 3:56 PM, "Slava Borilin" wrote: Roni, and whole international team, I have one more question here - sorry if this is na=EFve- but still = please advice. Background: all of us do wish wish wish (vendors, customers, end-users, = etc) to have ONE IWAC (internet wideband audio codec) for all. But assuming we (IETF) will come to the agreement which codec we like = best (existing or new one) and make RFC. What will then be the destiny of the that RFC? And who and why should be choosing the certain codec into their app? Afaik IETF, like ITU just "agree on the specs", while industry or = country-specific organizations are enforcing using or not using certain = standards, like CableLabs (Vertical market + geography). The major driver for agreeing on the standard is interop, as I see. Currently in the internet communications (web collaboration, voip = services, videoconferencing) - do you believe is there any force to push = interop, or everyone "plays in his own walled garden"? Should we: - agree on RFC and then dig into smaller (geographical or vertical = industry) communities to push them to force using this RFC (IWAC) as = part of certification to make sure they do enforce the IWAC? - or we should just have IWAC RFC and believe "better staff will find = its way to the market itself"? regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Roni Even Sent: Friday, June 12, 2009 10:56 PM To: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Hi, I would like to suggest other key topics for the BOF 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / others 2. Describe the process of defining a codec in other standard bodies - = my view is that not everyone knows what is required to create a quality = codec. 3. Is the purpose of the WG to publish one codec or multiple codecs = based on different requirements. 4. If a WG will be formed there are more decision to make like, what is = the selection criteria if there is more than one candidate or do we require = some cooperation, what are the deliverable - source code, encoder = specification (do we require bit exactness ), how to defines the quality tests and evaluate the results to check if the codec addresses the requirements. Roni Even -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Cullen Jennings Sent: Friday, June 12, 2009 8:32 PM To: codec@ietf.org Subject: [codec] Codec BOF approved, much work needed I have approved the CODEC BOF proposal. However, we need a bunch of=20 work to get ready. Various people on IESG/IAB were not comfortable=20 with the current charter and agenda so we need to work on theses=20 before the meeting. A draft agenda/charter Jason provided are at Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt Charter: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt After discussion with the IESG/IAB: I'd like to remove the "as Proposed Standard" from the charter text=20 for both milestones and see how the discussion goes in the BOF before=20 deciding which way this should go. I'd like to see more consideration around the issues of designing a=20 codec that did a good job of mapping a real time stream onto IP=20 packets. The way IP deals with packet loss and congestion has=20 implications for designing a codec that works well over IP. I know=20 some of the discussion I have had off list people talked about how we=20 wanted a codec that supported adaptive bit rates that could change on=20 the fly to be able to work well on an IP network. I will be working the folks to make sure the agenda has time to=20 directly address the key topics which include (more may be coming): Will we be able to get qualified people to do and review the work? Key design goals of a new codec? Do we need a new codec or are there already ones defined that meet the=20 needs? I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. Thanks, Cullen _______________________________________________ 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 ------_=_NextPart_001_01C9EECD.4A0DAD0A Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Codec BOF approved, much work needed

Dear = Henry,

 =

It is probably = not the same as with email (or maybe just timing is = different).

We are talking = not about “enabling technology” to make everyone understand each other (email case), = but “enhancement” - =A0everyone can today understand each other via 711 or 722, but we = want to push the quality bar while keeping the interop.

 =

So really the = magic question is that once we have the agreement on “recommended” = IWAC- either one or several (agree with Jean-Marc), who is to = enforce?

PROBABLY the = force to enforce are telecom operators?

As telco, = against internet companies (Cisco, Skype, MSFT, etc), do not like walled gardens = by definition:

=A0- The telco landscape is not (well, not only) Skype/cheap = IP calls versus Cellular or Wireline.

=A0- The mid-term battle is between internet and its rich = communication techniques (web conferencing, social networking) and =A0telco's = phone-only service.

=A0- Battle is not only for call $$, but for the time spent on the media (trend is = users spending more minutes on internet comms then on = phones)

=A0- so carriers have to move from NGN core networks to = offer IP-based "social network-like" communication models to subscribers, = therefore, have IP-service at the last mile for the user, and not only for = enterprise IP-phones, but every consumer.

- And as Telco need subscribers to pay for the service, here = comes the HD(=3Dwideband + packet loss robustness), as the necessary step to = keep user satisfied with the carrier IP-service.

- So actually, HD sounds to be the cornerstone for keeping = the landscape of whole Telco industry versus Internet communications (or = vice versa).

- so for telcos it will be really important to have IWAC RFC = and telcos have the power to enforce using it (via geo or industry forums = – examples are PAL/NTSC in geo, industry – CableLabs), and they are = used to the standard/certification process?

 

Again, apart = from the ambitions, what all of us (as vendors and as users) would like to = achieve, is interop.

And interop = should, probably, be enforced, not “recommended” via some sort of certification?

 =

Everyone, please = advice.

 =

regards,

Slava = Borilin

 

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Wednesday, June 17, = 2009 1:33 AM
To: Slava Borilin; Roni = Even; codec@ietf.org
Subject: Re: [codec] = Codec BOF approved, much work needed

 

Hi Slava,

>Currently in the internet communications (web collaboration, voip = services, videoconferencing) -
>do you believe is there any force to push interop, or everyone = "plays in his own walled garden"?

IMO one of the main the strengths of the Internet is its global reach. = The user can be anywhere and reach content from and communicate with anyone, = anywhere. Just like we are doing here with email.
The Internet codec will hopefully do for voice the same as text = communications + attachments work in email.

>sorry if this is na=EFve
This applies to my message as well :-)

Henry

On 6/16/09 3:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> = wrote:

Roni, and whole = international team,

I have one more question here - sorry if this is na=EFve- but still = please advice.

Background: all of us do wish wish wish (vendors, customers, end-users, = etc) to have ONE IWAC (internet wideband audio codec) for all.

But assuming we (IETF) will come to the agreement which codec we like = best (existing or new one) and make RFC.
What will then be the destiny of the that RFC?
And who and why should be choosing the certain codec into their app?

Afaik IETF, like ITU just "agree on the specs", while industry = or country-specific organizations are enforcing using or not using certain standards, like CableLabs (Vertical market + geography).

The major driver for agreeing on the standard is interop, as I see.
Currently in the internet communications (web collaboration, voip = services, videoconferencing) - do you believe is there any force to push interop, = or everyone "plays in his own walled garden"?

Should we:
- agree on RFC and then dig into smaller (geographical or vertical = industry) communities to push them to force using this RFC (IWAC) as part of certification to make sure they do enforce the IWAC?
- or we should just have IWAC RFC and believe "better staff will = find its way to the market itself"?

regards,
Slava Borilin


-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf Of Roni Even
Sent: Friday, June 12, 2009 10:56 PM
To: codec@ietf.org
Subject: Re: [codec] Codec BOF approved, much work needed

Hi,
I would like to suggest other key topics for the BOF

1. Why should the IETF start a codec WG - why not do it as ITU / MPEG = /
others

2. Describe the process of defining a codec in other standard bodies - = my
view is that not everyone knows what is required to create a quality = codec.

3. Is the purpose of the WG to publish one codec or multiple codecs = based on
different requirements.

4. If a WG will be formed there are more decision to make like, what is = the
selection criteria if there is more than one candidate or do we require = some
cooperation, what are the deliverable - source code, encoder = specification
(do we require bit exactness ), how to defines the quality tests and
evaluate the results to check if the codec addresses the = requirements.

Roni Even



-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf Of
Cullen Jennings
Sent: Friday, June 12, 2009 8:32 PM
To: codec@ietf.org
Subject: [codec] Codec BOF approved, much work needed


I have approved the CODEC BOF proposal. However, we need a bunch of
work to get ready.  Various people on IESG/IAB were not comfortable =
with the current charter and agenda so we need to work on theses
before the meeting.

A draft agenda/charter Jason provided are at

Agenda: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt

Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt
=
After discussion with the IESG/IAB:

I'd like to remove the "as Proposed Standard" from the charter = text
for both milestones and see how the discussion goes in the BOF before =
deciding which way this should go.

I'd like to see more consideration around the issues of designing a
codec that did a good job of mapping a real time stream onto IP
packets. The way IP deals with packet loss and congestion has
implications for designing a codec that works well over IP. I know
some of the discussion I have had off list people talked about how we =
wanted a codec that supported adaptive bit rates that could change on =
the fly to be able to work well on an IP network.

I will be working the folks to make sure the agenda has time to
directly address the key topics which include (more may be coming):

Will we be able to get qualified people to do and review the work?

Key design goals of a new codec?

Do we need a new codec or are there already ones defined that meet the =
needs?

I have asked Jason Fischl  and Jean-Marc Valin to co-chair this = BOF.

Thanks,

Cullen <RAI AD>





_______________________________________________
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

------_=_NextPart_001_01C9EECD.4A0DAD0A-- From hsinnrei@adobe.com Tue Jun 16 15:16:27 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 A059B28C1CD for ; Tue, 16 Jun 2009 15:16:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.924 X-Spam-Level: X-Spam-Status: No, score=-4.924 tagged_above=-999 required=5 tests=[AWL=-0.781, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 1Rn4CxvLGmv3 for ; Tue, 16 Jun 2009 15:16:16 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by core3.amsl.com (Postfix) with ESMTP id 6C4F828C1C3 for ; Tue, 16 Jun 2009 15:16:15 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKSjgZtS+9ka+v/+1egA0zXW2gUpQWHPmE@postini.com; Tue, 16 Jun 2009 15:16:27 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5GMGIWG014901; Tue, 16 Jun 2009 15:16:19 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5GMGHit014401; Tue, 16 Jun 2009 15:16:18 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Tue, 16 Jun 2009 15:14:59 -0700 From: Henry Sinnreich To: Slava Borilin , Roni Even , "codec@ietf.org" Date: Tue, 16 Jun 2009 15:14:57 -0700 Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acnrg7Geu5s5P5zNR4OSEheDDVkqeAACcrlgAM1yp6AAAbHVzwAAEL0wAAFkFy8= Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C65D83914251hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] Codec BOF approved, much work needed 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, 16 Jun 2009 22:16:27 -0000 --_000_C65D83914251hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Slava, >We are talking not about "enabling technology" to make everyone understand= each other (email case), >but "enhancement" - everyone can today understand each other via 711 or 7= 22, but we want to push the quality bar while keeping the interop. This is an excellent point. We are talking about the Internet here in in th= e IETF. Henry On 6/16/09 4:56 PM, "Slava Borilin" wrote: Dear Henry, It is probably not the same as with email (or maybe just timing is differen= t). We are talking not about "enabling technology" to make everyone understand = each other (email case), but "enhancement" - everyone can today understand= each other via 711 or 722, but we want to push the quality bar while keepi= ng the interop. So really the magic question is that once we have the agreement on "recomme= nded" IWAC- either one or several (agree with Jean-Marc), who is to enforce= ? PROBABLY the force to enforce are telecom operators? As telco, against internet companies (Cisco, Skype, MSFT, etc), do not like= walled gardens by definition: - The telco landscape is not (well, not only) Skype/cheap IP calls versus = Cellular or Wireline. - The mid-term battle is between internet and its rich communication techn= iques (web conferencing, social networking) and telco's phone-only service= . - Battle is not only for call $$, but for the time spent on the media (tre= nd is users spending more minutes on internet comms then on phones) - so carriers have to move from NGN core networks to offer IP-based "socia= l network-like" communication models to subscribers, therefore, have IP-ser= vice at the last mile for the user, and not only for enterprise IP-phones, = but every consumer. - And as Telco need subscribers to pay for the service, here comes the HD(= =3Dwideband + packet loss robustness), as the necessary step to keep user s= atisfied with the carrier IP-service. - So actually, HD sounds to be the cornerstone for keeping the landscape of= whole Telco industry versus Internet communications (or vice versa). - so for telcos it will be really important to have IWAC RFC and telcos hav= e the power to enforce using it (via geo or industry forums - examples are = PAL/NTSC in geo, industry - CableLabs), and they are used to the standard/c= ertification process? Again, apart from the ambitions, what all of us (as vendors and as users) w= ould like to achieve, is interop. And interop should, probably, be enforced, not "recommended" via some sort = of certification? Everyone, please advice. regards, Slava Borilin ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Wednesday, June 17, 2009 1:33 AM To: Slava Borilin; Roni Even; codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Hi Slava, >Currently in the internet communications (web collaboration, voip services= , videoconferencing) - >do you believe is there any force to push interop, or everyone "plays in h= is own walled garden"? IMO one of the main the strengths of the Internet is its global reach. The = user can be anywhere and reach content from and communicate with anyone, an= ywhere. Just like we are doing here with email. The Internet codec will hopefully do for voice the same as text communicati= ons + attachments work in email. >sorry if this is na=EFve This applies to my message as well :-) Henry On 6/16/09 3:56 PM, "Slava Borilin" wrote: Roni, and whole international team, I have one more question here - sorry if this is na=EFve- but still please = advice. Background: all of us do wish wish wish (vendors, customers, end-users, etc= ) to have ONE IWAC (internet wideband audio codec) for all. But assuming we (IETF) will come to the agreement which codec we like best = (existing or new one) and make RFC. What will then be the destiny of the that RFC? And who and why should be choosing the certain codec into their app? Afaik IETF, like ITU just "agree on the specs", while industry or country-s= pecific organizations are enforcing using or not using certain standards, l= ike CableLabs (Vertical market + geography). The major driver for agreeing on the standard is interop, as I see. Currently in the internet communications (web collaboration, voip services,= videoconferencing) - do you believe is there any force to push interop, or= everyone "plays in his own walled garden"? Should we: - agree on RFC and then dig into smaller (geographical or vertical industry= ) communities to push them to force using this RFC (IWAC) as part of certif= ication to make sure they do enforce the IWAC? - or we should just have IWAC RFC and believe "better staff will find its w= ay to the market itself"? regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of R= oni Even Sent: Friday, June 12, 2009 10:56 PM To: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Hi, I would like to suggest other key topics for the BOF 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / others 2. Describe the process of defining a codec in other standard bodies - my view is that not everyone knows what is required to create a quality codec. 3. Is the purpose of the WG to publish one codec or multiple codecs based o= n different requirements. 4. If a WG will be formed there are more decision to make like, what is the selection criteria if there is more than one candidate or do we require som= e cooperation, what are the deliverable - source code, encoder specification (do we require bit exactness ), how to defines the quality tests and evaluate the results to check if the codec addresses the requirements. Roni Even -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Friday, June 12, 2009 8:32 PM To: codec@ietf.org Subject: [codec] Codec BOF approved, much work needed I have approved the CODEC BOF proposal. However, we need a bunch of work to get ready. Various people on IESG/IAB were not comfortable with the current charter and agenda so we need to work on theses before the meeting. A draft agenda/charter Jason provided are at Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt After discussion with the IESG/IAB: I'd like to remove the "as Proposed Standard" from the charter text for both milestones and see how the discussion goes in the BOF before deciding which way this should go. I'd like to see more consideration around the issues of designing a codec that did a good job of mapping a real time stream onto IP packets. The way IP deals with packet loss and congestion has implications for designing a codec that works well over IP. I know some of the discussion I have had off list people talked about how we wanted a codec that supported adaptive bit rates that could change on the fly to be able to work well on an IP network. I will be working the folks to make sure the agenda has time to directly address the key topics which include (more may be coming): Will we be able to get qualified people to do and review the work? Key design goals of a new codec? Do we need a new codec or are there already ones defined that meet the needs? I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. Thanks, Cullen _______________________________________________ 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 --_000_C65D83914251hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Codec BOF approved, much work needed Dear Slava,
 
>We are talki= ng not about “enabling technology” to make everyone understand = each other (email case),
>but “enhancement” -  everyone can today understand eac= h other via 711 or 722, but we want to push the quality bar while keeping t= he interop.

This is an excellent= point. We are talking about the Internet here in in the IETF.

Henry


On 6/16/09 4:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:

Dear Henry,
 
It is probably not the same as with email (or maybe just timing is differen= t).
We are talking not about “enabling technology” to make everyone= understand each other (email case), but “enhancement” -  = everyone can today understand each other via 711 or 722, but we want to pus= h the quality bar while keeping the interop.
 
So really the magic question is that once we have the agreement on “r= ecommended” IWAC- either one or several (agree with Jean-Marc), who i= s to enforce?
PROBABLY the force to enforce are telecom operators?
As telco, against internet companies (Cisco, Skype, MSFT, etc), do not = like walled gardens by definition:
 - The telco landscape is not (well, not only) Skype/cheap IP calls ve= rsus Cellular or Wireline.
 - The mid-term battle is between internet and its rich communication = techniques (web conferencing, social networking) and  telco's phone-on= ly service.
 - Battle is not only for call $$, but for the time spent on the media= (trend is users spending more minutes on internet comms then on phones)  - so carriers have to move from NGN core networks to offer IP-based &= quot;social network-like" communication models to subscribers, therefo= re, have IP-service at the last mile for the user, and not only for enterpr= ise IP-phones, but every consumer.
- And as Telco need subscribers to pay for the service, here comes the HD(= =3Dwideband + packet loss robustness), as the necessary step to keep user s= atisfied with the carrier IP-service.
- So actually, HD sounds to be the cornerstone for keeping the landscape of= whole Telco industry versus Internet communications (or vice versa).
- so for telcos it will be really important to have IWAC RFC and telcos hav= e the power to enforce using it (via geo or industry forums – example= s are PAL/NTSC in geo, industry – CableLabs), and they are used to th= e standard/certification process?
 
Again, apart from the ambitions, what all of us (as vendors and as users) w= ould like to achieve, is interop.
And interop should, probably, be enforced, not “recommended” vi= a some sort of certification?
 
Everyone, please advice.
 

regards,
Slava Borilin

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Wednesday, June 17, 2009 1:33 AM
To: Slava Borilin; Roni Even; codec@ietf.= org
Subject: Re: [codec] Codec BOF approved, much work needed
Hi Slava,

>Currently in the internet communications (web collaboration, voip servi= ces, videoconferencing) -
>do you believe is there any force to push interop, or everyone "pl= ays in his own walled garden"?

IMO one of the main the strengths of the Internet is its global reach. The = user can be anywhere and reach content from and communicate with anyone, an= ywhere. Just like we are doing here with email.
The Internet codec will hopefully do for voice the same as text communicati= ons + attachments work in email.

>sorry if this is naïve
This applies to my message as well :-)

Henry

On 6/16/09 3:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
Roni, and whole international team,

I have one more question here - sorry if this is naïve- but still plea= se advice.

Background: all of us do wish wish wish (vendors, customers, end-users, etc= ) to have ONE IWAC (internet wideband audio codec) for all.

But assuming we (IETF) will come to the agreement which codec we like best = (existing or new one) and make RFC.
What will then be the destiny of the that RFC?
And who and why should be choosing the certain codec into their app?

Afaik IETF, like ITU just "agree on the specs", while industry or= country-specific organizations are enforcing using or not using certain st= andards, like CableLabs (Vertical market + geography).

The major driver for agreeing on the standard is interop, as I see.
Currently in the internet communications (web collaboration, voip services,= videoconferencing) - do you believe is there any force to push interop, or= everyone "plays in his own walled garden"?

Should we:
- agree on RFC and then dig into smaller (geographical or vertical industry= ) communities to push them to force using this RFC (IWAC) as part of certif= ication to make sure they do enforce the IWAC?
- or we should just have IWAC RFC and believe "better staff will find = its way to the market itself"?

regards,
Slava Borilin


-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On B= ehalf Of Roni Even
Sent: Friday, June 12, 2009 10:56 PM
To: codec@ietf.org
Subject: Re: [codec] Codec BOF approved, much work needed

Hi,
I would like to suggest other key topics for the BOF

1. Why should the IETF start a codec WG - why not do it as ITU / MPEG /
others

2. Describe the process of defining a codec in other standard bodies - my view is that not everyone knows what is required to create a quality codec.=

3. Is the purpose of the WG to publish one codec or multiple codecs based o= n
different requirements.

4. If a WG will be formed there are more decision to make like, what is the=
selection criteria if there is more than one candidate or do we require som= e
cooperation, what are the deliverable - source code, encoder specification<= BR> (do we require bit exactness ), how to defines the quality tests and
evaluate the results to check if the codec addresses the requirements.

Roni Even



-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On B= ehalf Of
Cullen Jennings
Sent: Friday, June 12, 2009 8:32 PM
To: codec@ietf.org
Subject: [codec] Codec BOF approved, much work needed


I have approved the CODEC BOF proposal. However, we need a bunch of
work to get ready.  Various people on IESG/IAB were not comfortable with the current charter and agenda so we need to work on theses
before the meeting.

A draft agenda/charter Jason provided are at

Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt

Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt=

After discussion with the IESG/IAB:

I'd like to remove the "as Proposed Standard" from the charter te= xt
for both milestones and see how the discussion goes in the BOF before
deciding which way this should go.

I'd like to see more consideration around the issues of designing a
codec that did a good job of mapping a real time stream onto IP
packets. The way IP deals with packet loss and congestion has
implications for designing a codec that works well over IP. I know
some of the discussion I have had off list people talked about how we
wanted a codec that supported adaptive bit rates that could change on
the fly to be able to work well on an IP network.

I will be working the folks to make sure the agenda has time to
directly address the key topics which include (more may be coming):

Will we be able to get qualified people to do and review the work?

Key design goals of a new codec?

Do we need a new codec or are there already ones defined that meet the
needs?

I have asked Jason Fischl  and Jean-Marc Valin to co-chair this BOF.
Thanks,

Cullen <RAI AD>





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

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

--_000_C65D83914251hsinnreiadobecom_-- From macinnis@broadcom.com Tue Jun 16 15:20:06 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 BDC8128C1D9 for ; Tue, 16 Jun 2009 15:20:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.371 X-Spam-Level: X-Spam-Status: No, score=-1.371 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 fSE+Fks0wJTh for ; Tue, 16 Jun 2009 15:20:04 -0700 (PDT) Received: from mms1.broadcom.com (mms1.broadcom.com [216.31.210.17]) by core3.amsl.com (Postfix) with ESMTP id D2CAA28C1C3 for ; Tue, 16 Jun 2009 15:20:04 -0700 (PDT) Received: from [10.16.192.224] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 16 Jun 2009 15:20:06 -0700 X-Server-Uuid: 02CED230-5797-4B57-9875-D5D2FEE4708A Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB01.corp.ad.broadcom.com ([10.16.192.224]) with mapi; Tue, 16 Jun 2009 15:20:06 -0700 From: "Sandy (Alexander) MacInnis" To: "codec@ietf.org" , "Henry Sinnreich" , "Slava Borilin" , "Roni Even" Date: Tue, 16 Jun 2009 15:18:59 -0700 Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acnrg7Geu5s5P5zNR4OSEheDDVkqeAACcrlgAM1yp6AAAbHVzwAAEL0wAAFkFy8AABUdQA== Message-ID: <568A92CB079CCF43BA5C8D7B08BCB4AE8150B5524D@SJEXCHCCR02.corp.ad.broadcom.com> References: 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: 6626C51C0YS9786595-01-01 Content-Type: multipart/alternative; boundary=_000_568A92CB079CCF43BA5C8D7B08BCB4AE8150B5524DSJEXCHCCR02co_ Subject: Re: [codec] Codec BOF approved, much work needed 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, 16 Jun 2009 22:20:06 -0000 --_000_568A92CB079CCF43BA5C8D7B08BCB4AE8150B5524DSJEXCHCCR02co_ Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Are we talking here about speech, or generic audio? There's a difference in terms of coding (bit rate, quality, etc.) and in te= rms of applicability. Or do we want both, i.e. two codecs? --Sandy ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of H= enry Sinnreich Sent: Tuesday, June 16, 2009 6:15 PM To: Slava Borilin; Roni Even; codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Dear Slava, >We are talking not about "enabling technology" to make everyone understand= each other (email case), >but "enhancement" - everyone can today understand each other via 711 or 7= 22, but we want to push the quality bar while keeping the interop. This is an excellent point. We are talking about the Internet here in in th= e IETF. Henry On 6/16/09 4:56 PM, "Slava Borilin" wrote: Dear Henry, It is probably not the same as with email (or maybe just timing is differen= t). We are talking not about "enabling technology" to make everyone understand = each other (email case), but "enhancement" - everyone can today understand= each other via 711 or 722, but we want to push the quality bar while keepi= ng the interop. So really the magic question is that once we have the agreement on "recomme= nded" IWAC- either one or several (agree with Jean-Marc), who is to enforce= ? PROBABLY the force to enforce are telecom operators? As telco, against internet companies (Cisco, Skype, MSFT, etc), do not like= walled gardens by definition: - The telco landscape is not (well, not only) Skype/cheap IP calls versus = Cellular or Wireline. - The mid-term battle is between internet and its rich communication techn= iques (web conferencing, social networking) and telco's phone-only service= . - Battle is not only for call $$, but for the time spent on the media (tre= nd is users spending more minutes on internet comms then on phones) - so carriers have to move from NGN core networks to offer IP-based "socia= l network-like" communication models to subscribers, therefore, have IP-ser= vice at the last mile for the user, and not only for enterprise IP-phones, = but every consumer. - And as Telco need subscribers to pay for the service, here comes the HD(= =3Dwideband + packet loss robustness), as the necessary step to keep user s= atisfied with the carrier IP-service. - So actually, HD sounds to be the cornerstone for keeping the landscape of= whole Telco industry versus Internet communications (or vice versa). - so for telcos it will be really important to have IWAC RFC and telcos hav= e the power to enforce using it (via geo or industry forums - examples are = PAL/NTSC in geo, industry - CableLabs), and they are used to the standard/c= ertification process? Again, apart from the ambitions, what all of us (as vendors and as users) w= ould like to achieve, is interop. And interop should, probably, be enforced, not "recommended" via some sort = of certification? Everyone, please advice. regards, Slava Borilin ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Wednesday, June 17, 2009 1:33 AM To: Slava Borilin; Roni Even; codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Hi Slava, >Currently in the internet communications (web collaboration, voip services= , videoconferencing) - >do you believe is there any force to push interop, or everyone "plays in h= is own walled garden"? IMO one of the main the strengths of the Internet is its global reach. The = user can be anywhere and reach content from and communicate with anyone, an= ywhere. Just like we are doing here with email. The Internet codec will hopefully do for voice the same as text communicati= ons + attachments work in email. >sorry if this is na=EFve This applies to my message as well :-) Henry On 6/16/09 3:56 PM, "Slava Borilin" wrote: Roni, and whole international team, I have one more question here - sorry if this is na=EFve- but still please = advice. Background: all of us do wish wish wish (vendors, customers, end-users, etc= ) to have ONE IWAC (internet wideband audio codec) for all. But assuming we (IETF) will come to the agreement which codec we like best = (existing or new one) and make RFC. What will then be the destiny of the that RFC? And who and why should be choosing the certain codec into their app? Afaik IETF, like ITU just "agree on the specs", while industry or country-s= pecific organizations are enforcing using or not using certain standards, l= ike CableLabs (Vertical market + geography). The major driver for agreeing on the standard is interop, as I see. Currently in the internet communications (web collaboration, voip services,= videoconferencing) - do you believe is there any force to push interop, or= everyone "plays in his own walled garden"? Should we: - agree on RFC and then dig into smaller (geographical or vertical industry= ) communities to push them to force using this RFC (IWAC) as part of certif= ication to make sure they do enforce the IWAC? - or we should just have IWAC RFC and believe "better staff will find its w= ay to the market itself"? regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of R= oni Even Sent: Friday, June 12, 2009 10:56 PM To: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Hi, I would like to suggest other key topics for the BOF 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / others 2. Describe the process of defining a codec in other standard bodies - my view is that not everyone knows what is required to create a quality codec. 3. Is the purpose of the WG to publish one codec or multiple codecs based o= n different requirements. 4. If a WG will be formed there are more decision to make like, what is the selection criteria if there is more than one candidate or do we require som= e cooperation, what are the deliverable - source code, encoder specification (do we require bit exactness ), how to defines the quality tests and evaluate the results to check if the codec addresses the requirements. Roni Even -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Friday, June 12, 2009 8:32 PM To: codec@ietf.org Subject: [codec] Codec BOF approved, much work needed I have approved the CODEC BOF proposal. However, we need a bunch of work to get ready. Various people on IESG/IAB were not comfortable with the current charter and agenda so we need to work on theses before the meeting. A draft agenda/charter Jason provided are at Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt After discussion with the IESG/IAB: I'd like to remove the "as Proposed Standard" from the charter text for both milestones and see how the discussion goes in the BOF before deciding which way this should go. I'd like to see more consideration around the issues of designing a codec that did a good job of mapping a real time stream onto IP packets. The way IP deals with packet loss and congestion has implications for designing a codec that works well over IP. I know some of the discussion I have had off list people talked about how we wanted a codec that supported adaptive bit rates that could change on the fly to be able to work well on an IP network. I will be working the folks to make sure the agenda has time to directly address the key topics which include (more may be coming): Will we be able to get qualified people to do and review the work? Key design goals of a new codec? Do we need a new codec or are there already ones defined that meet the needs? I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. Thanks, Cullen _______________________________________________ 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 --_000_568A92CB079CCF43BA5C8D7B08BCB4AE8150B5524DSJEXCHCCR02co_ Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Re: [codec] Codec BOF approved, much work needed
Are we talking here about speech, or generic=20 audio?
 
There's a difference in terms of coding (bit rate,= quality,=20 etc.) and in terms of applicability.
 
Or do we want both, i.e. two codecs?=
 
--Sandy
 

From: codec-bounces@ietf.org=20 [mailto:codec-bounces@ietf.org] On Behalf Of Henry=20 Sinnreich
Sent: Tuesday, June 16, 2009 6:15 PM
To: Slav= a=20 Borilin; Roni Even; codec@ietf.org
Subject: Re: [codec] Codec BOF= =20 approved, much work needed

Dear Slava,
 
>We are talking not about =93en= abling=20 technology=94 to make everyone understand each other (email case),
>= but=20 =93enhancement=94 -  everyone can today understand each other via 711 = or 722,=20 but we want to push the quality bar while keeping the=20 interop.

This is an excellent point. We are talking about = the=20 Internet here in in the IETF.

Henry


On 6/16/09 4:56 PM, "= Slava=20 Borilin" <Borilin@spiritdsp.com>= ;=20 wrote:
Dear Henry,
 
It is probably not the= same=20 as with email (or maybe just timing is different).
We are talking not = about=20 =93enabling technology=94 to make everyone understand each other (email c= ase), but=20 =93enhancement=94 -  everyone can today understand each other via 71= 1 or 722,=20 but we want to push the quality bar while keeping the interop.
 <= BR>So=20 really the magic question is that once we have the agreement on =93recomm= ended=94=20 IWAC- either one or several (agree with Jean-Marc), who is to=20 enforce?
PROBABLY the force to enforce are telecom operators?
As=20 telco, against internet companies (Cisco, Skype, MSFT, etc), do not like= =20 walled gardens by definition:
 - The telco landscape is not (well= , not=20 only) Skype/cheap IP calls versus Cellular or Wireline.
 - The=20 mid-term battle is between internet and its rich communication techniques= (web=20 conferencing, social networking) and  telco's phone-only=20 service.
 - Battle is not only for call $$, but for the time spen= t on=20 the media (trend is users spending more minutes on internet comms then on= =20 phones)
 - so carriers have to move from NGN core networks to off= er=20 IP-based "social network-like" communication models to subscribers, there= fore,=20 have IP-service at the last mile for the user, and not only for enterpris= e=20 IP-phones, but every consumer.
- And as Telco need subscribers to pay = for=20 the service, here comes the HD(=3Dwideband + packet loss robustness), as = the=20 necessary step to keep user satisfied with the carrier IP-service.
- S= o=20 actually, HD sounds to be the cornerstone for keeping the landscape of wh= ole=20 Telco industry versus Internet communications (or vice versa).
- so fo= r=20 telcos it will be really important to have IWAC RFC and telcos have the p= ower=20 to enforce using it (via geo or industry forums =96 examples are PAL/NTSC= in=20 geo, industry =96 CableLabs), and they are used to the standard/certifica= tion=20 process?
 
Again, apart from the ambitions, what all of us (as= =20 vendors and as users) would like to achieve, is interop.
And interop=20 should, probably, be enforced, not =93recommended=94 via some sort of=20 certification?
 
Everyone, please=20 advice.
 

regards,
S= lava=20 Borilin

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20
Sent: Wednesday, June 17, 2009 1:33 AM
To: Slava Bor= ilin;=20 Roni Even; codec@ietf.org
Subject: Re:=20 [codec] Codec BOF approved, much work needed

Hi=20 Slava,

>Currently in the internet communications (web collabora= tion,=20 voip services, videoconferencing) -
>do you believe is there any f= orce=20 to push interop, or everyone "plays in his own walled garden"?

IMO= one=20 of the main the strengths of the Internet is its global reach. The user c= an be=20 anywhere and reach content from and communicate with anyone, anywhere. Ju= st=20 like we are doing here with email.
The Internet codec will hopefully d= o for=20 voice the same as text communications + attachments work in=20 email.

>sorry if this is na=EFve
This applies to my message = as well=20 :-)

Henry

On 6/16/09 3:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
Ro= ni, and=20 whole international team,

I have one more question here - sorry if= this=20 is na=EFve- but still please advice.

Background: all of us do wish= wish=20 wish (vendors, customers, end-users, etc) to have ONE IWAC (internet wide= band=20 audio codec) for all.

But assuming we (IETF) will come to the agre= ement=20 which codec we like best (existing or new one) and make RFC.
What will= then=20 be the destiny of the that RFC?
And who and why should be choosing the= =20 certain codec into their app?

Afaik IETF, like ITU just "agree on = the=20 specs", while industry or country-specific organizations are enforcing us= ing=20 or not using certain standards, like CableLabs (Vertical market +=20 geography).

The major driver for agreeing on the standard is inter= op,=20 as I see.
Currently in the internet communications (web collaboration,= voip=20 services, videoconferencing) - do you believe is there any force to push= =20 interop, or everyone "plays in his own walled garden"?

Should we:<= BR>-=20 agree on RFC and then dig into smaller (geographical or vertical industry= )=20 communities to push them to force using this RFC (IWAC) as part of=20 certification to make sure they do enforce the IWAC?
- or we should ju= st=20 have IWAC RFC and believe "better staff will find its way to the market=20 itself"?

regards,
Slava Borilin


-----Original=20 Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On=20 Behalf Of Roni Even
Sent: Friday, June 12, 2009 10:56 PM
To: codec@ietf.org
Subject: Re: [codec] Codec = BOF=20 approved, much work needed

Hi,
I would like to suggest other ke= y=20 topics for the BOF

1. Why should the IETF start a codec WG - why n= ot do=20 it as ITU / MPEG /
others

2. Describe the process of defining a= =20 codec in other standard bodies - my
view is that not everyone knows wh= at is=20 required to create a quality codec.

3. Is the purpose of the WG to= =20 publish one codec or multiple codecs based on
different=20 requirements.

4. If a WG will be formed there are more decision to= make=20 like, what is the
selection criteria if there is more than one candida= te or=20 do we require some
cooperation, what are the deliverable - source code= ,=20 encoder specification
(do we require bit exactness ), how to defines t= he=20 quality tests and
evaluate the results to check if the codec addresses= the=20 requirements.

Roni Even



-----Original=20 Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On=20 Behalf Of
Cullen Jennings
Sent: Friday, June 12, 2009 8:32 PM
To= : codec@ietf.org
Subject: [codec] Codec BOF= =20 approved, much work needed


I have approved the CODEC BOF propo= sal.=20 However, we need a bunch of
work to get ready.  Various people o= n=20 IESG/IAB were not comfortable
with the current charter and agenda so = we=20 need to work on theses
before the meeting.

A draft agenda/char= ter=20 Jason provided are at

Agenda: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt

= Charter:=20 http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt
After=20 discussion with the IESG/IAB:

I'd like to remove the "as Proposed= =20 Standard" from the charter text
for both milestones and see how the=20 discussion goes in the BOF before
deciding which way this should=20 go.

I'd like to see more consideration around the issues of design= ing a=20
codec that did a good job of mapping a real time stream onto IP=20
packets. The way IP deals with packet loss and congestion has=20
implications for designing a codec that works well over IP. I know=20
some of the discussion I have had off list people talked about how we= =20
wanted a codec that supported adaptive bit rates that could change on= =20
the fly to be able to work well on an IP network.

I will be wo= rking=20 the folks to make sure the agenda has time to
directly address the ke= y=20 topics which include (more may be coming):

Will we be able to get= =20 qualified people to do and review the work?

Key design goals of a = new=20 codec?

Do we need a new codec or are there already ones defined th= at=20 meet the
needs?

I have asked Jason Fischl  and Jean-Marc = Valin=20 to co-chair this BOF.

Thanks,

Cullen <RAI=20 AD>





___________________________________________= ____
codec=20 mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec

________________________________________= _______
codec=20 mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec
____________________________________________= ___
codec=20 mailing list
codec@ietf.org
https://www.ietf.org= /mailman/listinfo/codec

--_000_568A92CB079CCF43BA5C8D7B08BCB4AE8150B5524DSJEXCHCCR02co_-- From Borilin@spiritdsp.com Tue Jun 16 15:22:43 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 7BC9B28C1D8 for ; Tue, 16 Jun 2009 15:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.708 X-Spam-Level: X-Spam-Status: No, score=-0.708 tagged_above=-999 required=5 tests=[AWL=-0.565, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 YgZKka7z+Ep0 for ; Tue, 16 Jun 2009 15:22:31 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id CE4DB28C1C3 for ; Tue, 16 Jun 2009 15:22:30 -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 n5GMMUpq045330; Wed, 17 Jun 2009 02:22:30 +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_01C9EED0.EC792F21" Date: Wed, 17 Jun 2009 02:22:23 +0400 Message-ID: In-Reply-To: <568A92CB079CCF43BA5C8D7B08BCB4AE8150B5524D@SJEXCHCCR02.corp.ad.broadcom.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acnrg7Geu5s5P5zNR4OSEheDDVkqeAACcrlgAM1yp6AAAbHVzwAAEL0wAAFkFy8AABUdQAAAJ+yw References: <568A92CB079CCF43BA5C8D7B08BCB4AE8150B5524D@SJEXCHCCR02.corp.ad.broadcom.com> From: "Slava Borilin" To: "Sandy (Alexander) MacInnis" , , "Henry Sinnreich" , "Roni Even" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: Re: [codec] Codec BOF approved, much work needed 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, 16 Jun 2009 22:22:43 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EED0.EC792F21 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Not necessarily two - examples are of combined codecs. Primarily, however, I believe we are about VOICE (wideband, or higher). =20 regards, Slava Borilin =20 ________________________________ From: Sandy (Alexander) MacInnis [mailto:macinnis@broadcom.com]=20 Sent: Wednesday, June 17, 2009 2:19 AM To: codec@ietf.org; Henry Sinnreich; Slava Borilin; Roni Even Subject: RE: [codec] Codec BOF approved, much work needed =20 Are we talking here about speech, or generic audio? =20 There's a difference in terms of coding (bit rate, quality, etc.) and in = terms of applicability. =20 Or do we want both, i.e. two codecs? =20 --Sandy =20 =20 ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Henry Sinnreich Sent: Tuesday, June 16, 2009 6:15 PM To: Slava Borilin; Roni Even; codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Dear Slava, =20 >We are talking not about "enabling technology" to make everyone = understand each other (email case),=20 >but "enhancement" - everyone can today understand each other via 711 = or 722, but we want to push the quality bar while keeping the interop. This is an excellent point. We are talking about the Internet here in in = the IETF. Henry On 6/16/09 4:56 PM, "Slava Borilin" wrote: Dear Henry, =20 It is probably not the same as with email (or maybe just timing is = different). We are talking not about "enabling technology" to make everyone = understand each other (email case), but "enhancement" - everyone can = today understand each other via 711 or 722, but we want to push the = quality bar while keeping the interop. =20 So really the magic question is that once we have the agreement on = "recommended" IWAC- either one or several (agree with Jean-Marc), who is = to enforce? PROBABLY the force to enforce are telecom operators? As telco, against internet companies (Cisco, Skype, MSFT, etc), do not = like walled gardens by definition: - The telco landscape is not (well, not only) Skype/cheap IP calls = versus Cellular or Wireline. - The mid-term battle is between internet and its rich communication = techniques (web conferencing, social networking) and telco's phone-only = service. - Battle is not only for call $$, but for the time spent on the media = (trend is users spending more minutes on internet comms then on phones) - so carriers have to move from NGN core networks to offer IP-based = "social network-like" communication models to subscribers, therefore, = have IP-service at the last mile for the user, and not only for = enterprise IP-phones, but every consumer. - And as Telco need subscribers to pay for the service, here comes the = HD(=3Dwideband + packet loss robustness), as the necessary step to keep = user satisfied with the carrier IP-service. - So actually, HD sounds to be the cornerstone for keeping the landscape = of whole Telco industry versus Internet communications (or vice versa). - so for telcos it will be really important to have IWAC RFC and telcos = have the power to enforce using it (via geo or industry forums - = examples are PAL/NTSC in geo, industry - CableLabs), and they are used = to the standard/certification process? =20 Again, apart from the ambitions, what all of us (as vendors and as = users) would like to achieve, is interop. And interop should, probably, be enforced, not "recommended" via some = sort of certification? =20 Everyone, please advice. =20 regards, Slava Borilin ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Wednesday, June 17, 2009 1:33 AM To: Slava Borilin; Roni Even; codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Hi Slava, >Currently in the internet communications (web collaboration, voip = services, videoconferencing) -=20 >do you believe is there any force to push interop, or everyone "plays = in his own walled garden"? IMO one of the main the strengths of the Internet is its global reach. = The user can be anywhere and reach content from and communicate with = anyone, anywhere. Just like we are doing here with email. The Internet codec will hopefully do for voice the same as text = communications + attachments work in email. >sorry if this is na=EFve This applies to my message as well :-) Henry On 6/16/09 3:56 PM, "Slava Borilin" wrote: Roni, and whole international team, I have one more question here - sorry if this is na=EFve- but still = please advice. Background: all of us do wish wish wish (vendors, customers, end-users, = etc) to have ONE IWAC (internet wideband audio codec) for all. But assuming we (IETF) will come to the agreement which codec we like = best (existing or new one) and make RFC. What will then be the destiny of the that RFC? And who and why should be choosing the certain codec into their app? Afaik IETF, like ITU just "agree on the specs", while industry or = country-specific organizations are enforcing using or not using certain = standards, like CableLabs (Vertical market + geography). The major driver for agreeing on the standard is interop, as I see. Currently in the internet communications (web collaboration, voip = services, videoconferencing) - do you believe is there any force to push = interop, or everyone "plays in his own walled garden"? Should we: - agree on RFC and then dig into smaller (geographical or vertical = industry) communities to push them to force using this RFC (IWAC) as = part of certification to make sure they do enforce the IWAC? - or we should just have IWAC RFC and believe "better staff will find = its way to the market itself"? regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Roni Even Sent: Friday, June 12, 2009 10:56 PM To: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Hi, I would like to suggest other key topics for the BOF 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / others 2. Describe the process of defining a codec in other standard bodies - = my view is that not everyone knows what is required to create a quality = codec. 3. Is the purpose of the WG to publish one codec or multiple codecs = based on different requirements. 4. If a WG will be formed there are more decision to make like, what is = the selection criteria if there is more than one candidate or do we require = some cooperation, what are the deliverable - source code, encoder = specification (do we require bit exactness ), how to defines the quality tests and evaluate the results to check if the codec addresses the requirements. Roni Even -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Cullen Jennings Sent: Friday, June 12, 2009 8:32 PM To: codec@ietf.org Subject: [codec] Codec BOF approved, much work needed I have approved the CODEC BOF proposal. However, we need a bunch of=20 work to get ready. Various people on IESG/IAB were not comfortable=20 with the current charter and agenda so we need to work on theses=20 before the meeting. A draft agenda/charter Jason provided are at Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt Charter: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt After discussion with the IESG/IAB: I'd like to remove the "as Proposed Standard" from the charter text=20 for both milestones and see how the discussion goes in the BOF before=20 deciding which way this should go. I'd like to see more consideration around the issues of designing a=20 codec that did a good job of mapping a real time stream onto IP=20 packets. The way IP deals with packet loss and congestion has=20 implications for designing a codec that works well over IP. I know=20 some of the discussion I have had off list people talked about how we=20 wanted a codec that supported adaptive bit rates that could change on=20 the fly to be able to work well on an IP network. I will be working the folks to make sure the agenda has time to=20 directly address the key topics which include (more may be coming): Will we be able to get qualified people to do and review the work? Key design goals of a new codec? Do we need a new codec or are there already ones defined that meet the=20 needs? I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. Thanks, Cullen _______________________________________________ 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 ------_=_NextPart_001_01C9EED0.EC792F21 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Codec BOF approved, much work needed

Not necessarily = two – examples are of combined codecs.

Primarily, = however, I believe we are about VOICE (wideband, or higher).

 =

regards,

Slava = Borilin

 

From: Sandy (Alexander) MacInnis [mailto:macinnis@broadcom.com]
Sent: Wednesday, June 17, = 2009 2:19 AM
To: codec@ietf.org; Henry = Sinnreich; Slava Borilin; Roni Even
Subject: RE: [codec] = Codec BOF approved, much work needed

 

Are we talking here about speech, = or generic audio?

 

There's a difference in terms of = coding (bit rate, quality, etc.) and in terms of = applicability.

 

Or do we want both, i.e. two = codecs?

 

--Sandy

=

 

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Henry Sinnreich
Sent: Tuesday, June 16, = 2009 6:15 PM
To: Slava Borilin; Roni = Even; codec@ietf.org
Subject: Re: [codec] = Codec BOF approved, much work needed

Dear Slava,
 
>We are = talking not about “enabling technology” to make everyone understand each = other (email case),
>but “enhancement” -  everyone can today understand = each other via 711 or 722, but we want to push the quality bar while keeping = the interop.

This is an excellent point. We are talking about the Internet here in in the = IETF.

Henry


On 6/16/09 4:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> = wrote:

Dear Henry,
 
It is probably not the same as with email (or maybe just timing is = different).
We are talking not about “enabling technology” to make = everyone understand each other (email case), but “enhancement” -  everyone can today understand each other via 711 or 722, but we = want to push the quality bar while keeping the interop.
 
So really the magic question is that once we have the agreement on “recommended” IWAC- either one or several (agree with = Jean-Marc), who is to enforce?
PROBABLY the force to enforce are telecom operators?
As telco, against internet companies (Cisco, Skype, MSFT, etc), do = not like walled gardens by definition:
 - The telco landscape is not (well, not only) Skype/cheap IP calls = versus Cellular or Wireline.
 - The mid-term battle is between internet and its rich = communication techniques (web conferencing, social networking) and  telco's = phone-only service.
 - Battle is not only for call $$, but for the time spent on the = media (trend is users spending more minutes on internet comms then on = phones)
 - so carriers have to move from NGN core networks to offer = IP-based "social network-like" communication models to subscribers, = therefore, have IP-service at the last mile for the user, and not only for = enterprise IP-phones, but every consumer.
- And as Telco need subscribers to pay for the service, here comes the HD(=3Dwideband + packet loss robustness), as the necessary step to keep = user satisfied with the carrier IP-service.
- So actually, HD sounds to be the cornerstone for keeping the landscape = of whole Telco industry versus Internet communications (or vice versa).
- so for telcos it will be really important to have IWAC RFC and telcos = have the power to enforce using it (via geo or industry forums – = examples are PAL/NTSC in geo, industry – CableLabs), and they are used to the standard/certification process?
 
Again, apart from the ambitions, what all of us (as vendors and as = users) would like to achieve, is interop.
And interop should, probably, be enforced, not “recommended” = via some sort of certification?
 
Everyone, please advice.
 

regards,
Slava Borilin

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Wednesday, June 17, = 2009 1:33 AM
To: Slava Borilin; Roni = Even; codec@ietf.org
Subject: Re: [codec] = Codec BOF approved, much work needed

Hi Slava,

>Currently in the internet communications (web collaboration, voip = services, videoconferencing) -
>do you believe is there any force to push interop, or everyone = "plays in his own walled garden"?

IMO one of the main the strengths of the Internet is its global reach. = The user can be anywhere and reach content from and communicate with anyone, = anywhere. Just like we are doing here with email.
The Internet codec will hopefully do for voice the same as text = communications + attachments work in email.

>sorry if this is na=EFve
This applies to my message as well :-)

Henry

On 6/16/09 3:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
Roni, and whole international team,

I have one more question here - sorry if this is na=EFve- but still = please advice.

Background: all of us do wish wish wish (vendors, customers, end-users, = etc) to have ONE IWAC (internet wideband audio codec) for all.

But assuming we (IETF) will come to the agreement which codec we like = best (existing or new one) and make RFC.
What will then be the destiny of the that RFC?
And who and why should be choosing the certain codec into their app?

Afaik IETF, like ITU just "agree on the specs", while industry = or country-specific organizations are enforcing using or not using certain standards, like CableLabs (Vertical market + geography).

The major driver for agreeing on the standard is interop, as I see.
Currently in the internet communications (web collaboration, voip = services, videoconferencing) - do you believe is there any force to push interop, = or everyone "plays in his own walled garden"?

Should we:
- agree on RFC and then dig into smaller (geographical or vertical = industry) communities to push them to force using this RFC (IWAC) as part of certification to make sure they do enforce the IWAC?
- or we should just have IWAC RFC and believe "better staff will = find its way to the market itself"?

regards,
Slava Borilin


-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf Of Roni Even
Sent: Friday, June 12, 2009 10:56 PM
To: codec@ietf.org
Subject: Re: [codec] Codec BOF approved, much work needed

Hi,
I would like to suggest other key topics for the BOF

1. Why should the IETF start a codec WG - why not do it as ITU / MPEG = /
others

2. Describe the process of defining a codec in other standard bodies - = my
view is that not everyone knows what is required to create a quality = codec.

3. Is the purpose of the WG to publish one codec or multiple codecs = based on
different requirements.

4. If a WG will be formed there are more decision to make like, what is = the
selection criteria if there is more than one candidate or do we require = some
cooperation, what are the deliverable - source code, encoder = specification
(do we require bit exactness ), how to defines the quality tests and
evaluate the results to check if the codec addresses the = requirements.

Roni Even



-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf Of
Cullen Jennings
Sent: Friday, June 12, 2009 8:32 PM
To: codec@ietf.org
Subject: [codec] Codec BOF approved, much work needed


I have approved the CODEC BOF proposal. However, we need a bunch of
work to get ready.  Various people on IESG/IAB were not comfortable =
with the current charter and agenda so we need to work on theses
before the meeting.

A draft agenda/charter Jason provided are at

Agenda: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt

Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt
=
After discussion with the IESG/IAB:

I'd like to remove the "as Proposed Standard" from the charter = text
for both milestones and see how the discussion goes in the BOF before =
deciding which way this should go.

I'd like to see more consideration around the issues of designing a
codec that did a good job of mapping a real time stream onto IP
packets. The way IP deals with packet loss and congestion has
implications for designing a codec that works well over IP. I know
some of the discussion I have had off list people talked about how we =
wanted a codec that supported adaptive bit rates that could change on =
the fly to be able to work well on an IP network.

I will be working the folks to make sure the agenda has time to
directly address the key topics which include (more may be coming):

Will we be able to get qualified people to do and review the work?

Key design goals of a new codec?

Do we need a new codec or are there already ones defined that meet the =
needs?

I have asked Jason Fischl  and Jean-Marc Valin to co-chair this = BOF.

Thanks,

Cullen <RAI AD>





_______________________________________________
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

------_=_NextPart_001_01C9EED0.EC792F21-- From hsinnrei@adobe.com Tue Jun 16 15:32:08 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 EF0F03A6DB9 for ; Tue, 16 Jun 2009 15:32:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.813 X-Spam-Level: X-Spam-Status: No, score=-4.813 tagged_above=-999 required=5 tests=[AWL=-0.670, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 Zruqz8TsPphU for ; Tue, 16 Jun 2009 15:31:56 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by core3.amsl.com (Postfix) with ESMTP id C39693A6C5E for ; Tue, 16 Jun 2009 15:31:51 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKSjgdYtZPy0Gx/ZTrIQRQvwKfpE+zg1OJ@postini.com; Tue, 16 Jun 2009 15:32:07 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5GMVxWG016983; Tue, 16 Jun 2009 15:32:00 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5GMVwtQ023987; Tue, 16 Jun 2009 15:31:58 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Tue, 16 Jun 2009 15:31:58 -0700 From: Henry Sinnreich To: "Sandy (Alexander) MacInnis" , "codec@ietf.org" , Slava Borilin , Roni Even Date: Tue, 16 Jun 2009 15:31:56 -0700 Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acnrg7Geu5s5P5zNR4OSEheDDVkqeAACcrlgAM1yp6AAAbHVzwAAEL0wAAFkFy8AABUdQAAAgrr3 Message-ID: In-Reply-To: <568A92CB079CCF43BA5C8D7B08BCB4AE8150B5524D@SJEXCHCCR02.corp.ad.broadcom.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_C65D878C4258hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] Codec BOF approved, much work needed 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, 16 Jun 2009 22:32:09 -0000 --_000_C65D878C4258hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >Are we talking here about speech, or generic audio? As Slava has pointed out it is about wideband speech, that is the low laten= cy (150ms or so) still applies, but having wideband audio (8-16 kHz audio B= W) and why not, stereo. All this and many other however is to be worked out= in the proposed Internet Codec WG. Henry On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis" wr= ote: Are we talking here about speech, or generic audio? There's a difference in terms of coding (bit rate, quality, etc.) and in te= rms of applicability. Or do we want both, i.e. two codecs? --Sandy ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of H= enry Sinnreich Sent: Tuesday, June 16, 2009 6:15 PM To: Slava Borilin; Roni Even; codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Dear Slava, >We are talking not about "enabling technology" to make everyone understand= each other (email case), >but "enhancement" - everyone can today understand each other via 711 or 7= 22, but we want to push the quality bar while keeping the interop. This is an excellent point. We are talking about the Internet here in in th= e IETF. Henry On 6/16/09 4:56 PM, "Slava Borilin" wrote: Dear Henry, It is probably not the same as with email (or maybe just timing is differe= nt). We are talking not about "enabling technology" to make everyone understand= each other (email case), but "enhancement" - everyone can today understa= nd each other via 711 or 722, but we want to push the quality bar while ke= eping the interop. So really the magic question is that once we have the agreement on "recomm= ended" IWAC- either one or several (agree with Jean-Marc), who is to enfo= rce? PROBABLY the force to enforce are telecom operators? As telco, against internet companies (Cisco, Skype, MSFT, etc), do not lik= e walled gardens by definition: - The telco landscape is not (well, not only) Skype/cheap IP calls versus= Cellular or Wireline. - The mid-term battle is between internet and its rich communication tech= niques (web conferencing, social networking) and telco's phone-only serv= ice. - Battle is not only for call $$, but for the time spent on the media (tr= end is users spending more minutes on internet comms then on phones) - so carriers have to move from NGN core networks to offer IP-based "soci= al network-like" communication models to subscribers, therefore, have IP-s= ervice at the last mile for the user, and not only for enterprise IP-phone= s, but every consumer. - And as Telco need subscribers to pay for the service, here comes the HD(= =3Dwideband + packet loss robustness), as the necessary step to keep user = satisfied with the carrier IP-service. - So actually, HD sounds to be the cornerstone for keeping the landscape o= f whole Telco industry versus Internet communications (or vice versa). - so for telcos it will be really important to have IWAC RFC and telcos ha= ve the power to enforce using it (via geo or industry forums - examples ar= e PAL/NTSC in geo, industry - CableLabs), and they are used to the standar= d/certification process? Again, apart from the ambitions, what all of us (as vendors and as users) = would like to achieve, is interop. And interop should, probably, be enforced, not "recommended" via some sort= of certification? Everyone, please advice. regards, Slava Borilin ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Wednesday, June 17, 2009 1:33 AM To: Slava Borilin; Roni Even; codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Hi Slava, >Currently in the internet communications (web collaboration, voip service= s, videoconferencing) - >do you believe is there any force to push interop, or everyone "plays in = his own walled garden"? IMO one of the main the strengths of the Internet is its global reach. The= user can be anywhere and reach content from and communicate with anyone, = anywhere. Just like we are doing here with email. The Internet codec will hopefully do for voice the same as text communicat= ions + attachments work in email. >sorry if this is na=EFve This applies to my message as well :-) Henry On 6/16/09 3:56 PM, "Slava Borilin" wrote: Roni, and whole international team, I have one more question here - sorry if this is na=EFve- but still please= advice. Background: all of us do wish wish wish (vendors, customers, end-users, et= c) to have ONE IWAC (internet wideband audio codec) for all. But assuming we (IETF) will come to the agreement which codec we like best= (existing or new one) and make RFC. What will then be the destiny of the that RFC? And who and why should be choosing the certain codec into their app? Afaik IETF, like ITU just "agree on the specs", while industry or country-= specific organizations are enforcing using or not using certain standards,= like CableLabs (Vertical market + geography). The major driver for agreeing on the standard is interop, as I see. Currently in the internet communications (web collaboration, voip services= , videoconferencing) - do you believe is there any force to push interop, = or everyone "plays in his own walled garden"? Should we: - agree on RFC and then dig into smaller (geographical or vertical industr= y) communities to push them to force using this RFC (IWAC) as part of cer= tification to make sure they do enforce the IWAC? - or we should just have IWAC RFC and believe "better staff will find its = way to the market itself"? regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Roni Even Sent: Friday, June 12, 2009 10:56 PM To: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Hi, I would like to suggest other key topics for the BOF 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / others 2. Describe the process of defining a codec in other standard bodies - my view is that not everyone knows what is required to create a quality codec= . 3. Is the purpose of the WG to publish one codec or multiple codecs based = on different requirements. 4. If a WG will be formed there are more decision to make like, what is th= e selection criteria if there is more than one candidate or do we require so= me cooperation, what are the deliverable - source code, encoder specification (do we require bit exactness ), how to defines the quality tests and evaluate the results to check if the codec addresses the requirements. Roni Even -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Friday, June 12, 2009 8:32 PM To: codec@ietf.org Subject: [codec] Codec BOF approved, much work needed I have approved the CODEC BOF proposal. However, we need a bunch of work to get ready. Various people on IESG/IAB were not comfortable with the current charter and agenda so we need to work on theses before the meeting. A draft agenda/charter Jason provided are at Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt After discussion with the IESG/IAB: I'd like to remove the "as Proposed Standard" from the charter text for both milestones and see how the discussion goes in the BOF before deciding which way this should go. I'd like to see more consideration around the issues of designing a codec that did a good job of mapping a real time stream onto IP packets. The way IP deals with packet loss and congestion has implications for designing a codec that works well over IP. I know some of the discussion I have had off list people talked about how we wanted a codec that supported adaptive bit rates that could change on the fly to be able to work well on an IP network. I will be working the folks to make sure the agenda has time to directly address the key topics which include (more may be coming): Will we be able to get qualified people to do and review the work? Key design goals of a new codec? Do we need a new codec or are there already ones defined that meet the needs? I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. Thanks, Cullen _______________________________________________ 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 --_000_C65D878C4258hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Codec BOF approved, much work needed >Are we talking here about speech, or generic audio= ?

As Slava has pointed out it is about wideband speech, that is the low laten= cy (150ms or so) still applies, but having wideband audio (8-16 kHz audio B= W) and why not, stereo. All this and many other however is to be worked out= in the proposed Internet Codec WG.

Henry


On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis" <macinnis@broadcom.com> wrote:

Are we talking here about speech, or generic aud= io?
There's a difference in= terms of coding (bit rate, quality, etc.) and in terms of applicability.
Or do we want both, i.e= . two codecs?
--Sandy

From: c= odec-bounces@ietf.org [mailto= :codec-bounces@ietf.org] On Behalf Of Henry Sinnreich
Sent: Tuesday, June 16, 2009 6:15 PM
To: Slava Borilin; Roni Even; codec@ietf.= org
Subject: Re: [codec] Codec BOF approved, much work needed

Dear Slava,
 
>We are talking not about “enabling technology” to make e= veryone understand each other (email case),
>but “enhancement” -  everyone can today understand eac= h other via 711 or 722, but we want to push the quality bar while keeping t= he interop.

This is an excellent= point. We are talking about the Internet here in in the IETF.

Henry


On 6/16/09 4:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:

Dear Henry,
 
It is probably not the same  as with email (or maybe just timing is di= fferent).
We are talking not about  “enabling technology” to make ev= eryone understand each other (email case), but  “enhancementR= 21; -  everyone can today understand each other via 711 or 722,  = but we want to push the quality bar while keeping the interop.
 
So  really the magic question is that once we have the agreement on &#= 8220;recommended”  IWAC- either one or several (agree with Jean-= Marc), who is to  enforce?
PROBABLY the force to enforce are telecom operators?
As  telco, against internet companies (Cisco, Skype, MSFT, etc), d= o not like  walled gardens by definition:
 - The telco landscape is not (well, not  only) Skype/cheap IP ca= lls versus Cellular or Wireline.
 - The  mid-term battle is between internet and its rich communic= ation techniques (web  conferencing, social networking) and  telc= o's phone-only  service.
 - Battle is not only for call $$, but for the time spent on  the= media (trend is users spending more minutes on internet comms then on &nbs= p;phones)
 - so carriers have to move from NGN core networks to offer  IP-b= ased "social network-like" communication models to subscribers, t= herefore,  have IP-service at the last mile for the user, and not only= for enterprise  IP-phones, but every consumer.
- And as Telco need subscribers to pay for  the service, here comes th= e HD(=3Dwideband + packet loss robustness), as the  necessary step to = keep user satisfied with the carrier IP-service.
- So  actually, HD sounds to be the cornerstone for keeping the landsc= ape of whole  Telco industry versus Internet communications (or vice v= ersa).
- so for  telcos it will be really important to have IWAC RFC and telc= os have the power  to enforce using it (via geo or industry forums = 211; examples are PAL/NTSC in  geo, industry – CableLabs), and t= hey are used to the standard/certification  process?
 
Again, apart from the ambitions, what all of us (as  vendors and as us= ers) would like to achieve, is interop.
And interop  should, probably, be enforced, not “recommendedR= 21; via some sort of  certification?
 
Everyone, please  advice.
 

regards,
Slava  Borilin

=20


=20

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]  
Sent: Wednesday, June 17, 2009 1:33 AM
To: Slava Borilin;  Roni Even; codec= @ietf.org
Subject: Re:  [codec] Codec BOF approved, much work needed

Hi  Slava,

>Currently in the internet communications (web collaboration,  voip= services, videoconferencing) -
>do you believe is there any force  to push interop, or everyone &q= uot;plays in his own walled garden"?

IMO one  of the main the strengths of the Internet is its global reach= . The user can be  anywhere and reach content from and communicate wit= h anyone, anywhere. Just  like we are doing here with email.
The Internet codec will hopefully do for  voice the same as text commu= nications + attachments work in  email.

>sorry if this is naïve
This applies to my message as well  :-)

Henry

On 6/16/09 3:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
Roni, and  whole international team,

I have one more question here - sorry if this  is naïve- but stil= l please advice.

Background: all of us do wish wish  wish (vendors, customers, end-user= s, etc) to have ONE IWAC (internet wideband  audio codec) for all.

But assuming we (IETF) will come to the agreement  which codec we like= best (existing or new one) and make RFC.
What will then  be the destiny of the that RFC?
And who and why should be choosing the  certain codec into their app?<= BR>
Afaik IETF, like ITU just "agree on the  specs", while indus= try or country-specific organizations are enforcing using  or not usin= g certain standards, like CableLabs (Vertical market +  geography).
The major driver for agreeing on the standard is interop,  as I see. Currently in the internet communications (web collaboration, voip  ser= vices, videoconferencing) - do you believe is there any force to push  = ;interop, or everyone "plays in his own walled garden"?

Should we:
-  agree on RFC and then dig into smaller (geographical or vertical in= dustry)  communities to push them to force using this RFC (IWAC) as pa= rt of  certification to make sure they do enforce the IWAC?
- or we should just  have IWAC RFC and believe "better staff will= find its way to the market  itself"?

regards,
Slava Borilin


-----Original  Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On &= nbsp;Behalf Of Roni Even
Sent: Friday, June 12, 2009 10:56 PM
To: codec@ietf.org
Subject: Re: [codec] Codec BOF  approved, much work needed

Hi,
I would like to suggest other key  topics for the BOF

1. Why should the IETF start a codec WG - why not do  it as ITU / MPEG= /
others

2. Describe the process of defining a  codec in other standard bodies = - my
view is that not everyone knows what is  required to create a quality = codec.

3. Is the purpose of the WG to  publish one codec or multiple codecs b= ased on
different  requirements.

4. If a WG will be formed there are more decision to make  like, what = is the
selection criteria if there is more than one candidate or  do we requi= re some
cooperation, what are the deliverable - source code,  encoder specific= ation
(do we require bit exactness ), how to defines the  quality tests and<= BR> evaluate the results to check if the codec addresses the  requirements= .

Roni Even



-----Original  Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On &= nbsp;Behalf Of
Cullen Jennings
Sent: Friday, June 12, 2009 8:32 PM
To: codec@ietf.org
Subject: [codec] Codec BOF  approved, much work needed


I have approved the CODEC BOF proposal.  However, we need a bunch of <= BR> work to get ready.  Various people on  IESG/IAB were not comforta= ble
with the current charter and agenda so we  need to work on theses
before the meeting.

A draft agenda/charter  Jason provided are at

Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt

Charter:  http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/chart= er.txt

After  discussion with the IESG/IAB:

I'd like to remove the "as Proposed  Standard" from the char= ter text
for both milestones and see how the  discussion goes in the BOF before=
deciding which way this should  go.

I'd like to see more consideration around the issues of designing a  <= BR> codec that did a good job of mapping a real time stream onto IP  
packets. The way IP deals with packet loss and congestion has  
implications for designing a codec that works well over IP. I know   some of the discussion I have had off list people talked about how we  = ;
wanted a codec that supported adaptive bit rates that could change on  = ;
the fly to be able to work well on an IP network.

I will be working  the folks to make sure the agenda has time to
directly address the key  topics which include (more may be coming):
Will we be able to get  qualified people to do and review the work?
Key design goals of a new  codec?

Do we need a new codec or are there already ones defined that  meet th= e
needs?

I have asked Jason Fischl  and Jean-Marc Valin  to co-chair this = BOF.

Thanks,

Cullen <RAI  AD>





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

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


--_000_C65D878C4258hsinnreiadobecom_-- From tme@americafree.tv Tue Jun 16 17:02:43 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 6ADA03A6C6B for ; Tue, 16 Jun 2009 17:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.305, BAYES_00=-2.599, FRT_ADOBE2=2.455] 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 C52LXOv31I3D for ; Tue, 16 Jun 2009 17:02:42 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id AEE353A6849 for ; Tue, 16 Jun 2009 17:02:41 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id E73F24080883; Tue, 16 Jun 2009 20:02:50 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Henry Sinnreich 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 v935.3) Date: Tue, 16 Jun 2009 20:02:49 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: Slava Borilin , "codec@ietf.org" , Roni Even Subject: Re: [codec] Codec BOF approved, much work needed 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, 17 Jun 2009 00:02:43 -0000 Has anyone written up why OGG/Vorbis is not an acceptable solution for =20= this ? Regards Marshall On Jun 16, 2009, at 6:31 PM, Henry Sinnreich wrote: > >Are we talking here about speech, or generic audio? > > As Slava has pointed out it is about wideband speech, that is the =20 > low latency (150ms or so) still applies, but having wideband audio =20 > (8-16 kHz audio BW) and why not, stereo. All this and many other =20 > however is to be worked out in the proposed Internet Codec WG. > > Henry > > > On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis" = > wrote: > > Are we talking here about speech, or generic audio? > > There's a difference in terms of coding (bit rate, quality, etc.) =20 > and in terms of applicability. > > Or do we want both, i.e. two codecs? > > --Sandy > > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 > Behalf Of Henry Sinnreich > Sent: Tuesday, June 16, 2009 6:15 PM > To: Slava Borilin; Roni Even; codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > Dear Slava, > > >We are talking not about =93enabling technology=94 to make everyone =20= > understand each other (email case), > >but =93enhancement=94 - everyone can today understand each other via = =20 > 711 or 722, but we want to push the quality bar while keeping the =20 > interop. > > This is an excellent point. We are talking about the Internet here =20 > in in the IETF. > > Henry > > > On 6/16/09 4:56 PM, "Slava Borilin" wrote: > > Dear Henry, > > It is probably not the same as with email (or maybe just timing is =20= > different). > We are talking not about =93enabling technology=94 to make everyone =20= > understand each other (email case), but =93enhancement=94 - everyone = =20 > can today understand each other via 711 or 722, but we want to push =20= > the quality bar while keeping the interop. > > So really the magic question is that once we have the agreement on =20= > =93recommended=94 IWAC- either one or several (agree with Jean-Marc), = =20 > who is to enforce? > PROBABLY the force to enforce are telecom operators? > As telco, against internet companies (Cisco, Skype, MSFT, etc), do =20= > not like walled gardens by definition: > - The telco landscape is not (well, not only) Skype/cheap IP calls =20= > versus Cellular or Wireline. > - The mid-term battle is between internet and its rich =20 > communication techniques (web conferencing, social networking) and =20= > telco's phone-only service. > - Battle is not only for call $$, but for the time spent on the =20 > media (trend is users spending more minutes on internet comms then =20 > on phones) > - so carriers have to move from NGN core networks to offer IP-=20 > based "social network-like" communication models to subscribers, =20 > therefore, have IP-service at the last mile for the user, and not =20 > only for enterprise IP-phones, but every consumer. > - And as Telco need subscribers to pay for the service, here comes =20= > the HD(=3Dwideband + packet loss robustness), as the necessary step =20= > to keep user satisfied with the carrier IP-service. > - So actually, HD sounds to be the cornerstone for keeping the =20 > landscape of whole Telco industry versus Internet communications =20 > (or vice versa). > - so for telcos it will be really important to have IWAC RFC and =20 > telcos have the power to enforce using it (via geo or industry =20 > forums =96 examples are PAL/NTSC in geo, industry =96 CableLabs), and = =20 > they are used to the standard/certification process? > > Again, apart from the ambitions, what all of us (as vendors and as =20= > users) would like to achieve, is interop. > And interop should, probably, be enforced, not =93recommended=94 via =20= > some sort of certification? > > Everyone, please advice. > > > regards, > Slava Borilin > > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Wednesday, June 17, 2009 1:33 AM > To: Slava Borilin; Roni Even; codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > Hi Slava, > > >Currently in the internet communications (web collaboration, voip =20= > services, videoconferencing) - > >do you believe is there any force to push interop, or everyone =20 > "plays in his own walled garden"? > > IMO one of the main the strengths of the Internet is its global =20 > reach. The user can be anywhere and reach content from and =20 > communicate with anyone, anywhere. Just like we are doing here with =20= > email. > The Internet codec will hopefully do for voice the same as text =20 > communications + attachments work in email. > > >sorry if this is na=EFve > This applies to my message as well :-) > > Henry > > On 6/16/09 3:56 PM, "Slava Borilin" wrote: > Roni, and whole international team, > > I have one more question here - sorry if this is na=EFve- but still =20= > please advice. > > Background: all of us do wish wish wish (vendors, customers, end-=20 > users, etc) to have ONE IWAC (internet wideband audio codec) for all. > > But assuming we (IETF) will come to the agreement which codec we =20 > like best (existing or new one) and make RFC. > What will then be the destiny of the that RFC? > And who and why should be choosing the certain codec into their app? > > Afaik IETF, like ITU just "agree on the specs", while industry or =20 > country-specific organizations are enforcing using or not using =20 > certain standards, like CableLabs (Vertical market + geography). > > The major driver for agreeing on the standard is interop, as I see. > Currently in the internet communications (web collaboration, voip =20 > services, videoconferencing) - do you believe is there any force to =20= > push interop, or everyone "plays in his own walled garden"? > > Should we: > - agree on RFC and then dig into smaller (geographical or vertical =20= > industry) communities to push them to force using this RFC (IWAC) =20 > as part of certification to make sure they do enforce the IWAC? > - or we should just have IWAC RFC and believe "better staff will =20 > find its way to the market itself"? > > regards, > Slava Borilin > > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 > Behalf Of Roni Even > Sent: Friday, June 12, 2009 10:56 PM > To: codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > Hi, > I would like to suggest other key topics for the BOF > > 1. Why should the IETF start a codec WG - why not do it as ITU / =20 > MPEG / > others > > 2. Describe the process of defining a codec in other standard =20 > bodies - my > view is that not everyone knows what is required to create a =20 > quality codec. > > 3. Is the purpose of the WG to publish one codec or multiple codecs =20= > based on > different requirements. > > 4. If a WG will be formed there are more decision to make like, =20 > what is the > selection criteria if there is more than one candidate or do we =20 > require some > cooperation, what are the deliverable - source code, encoder =20 > specification > (do we require bit exactness ), how to defines the quality tests and > evaluate the results to check if the codec addresses the =20 > requirements. > > Roni Even > > > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 > Behalf Of > Cullen Jennings > Sent: Friday, June 12, 2009 8:32 PM > To: codec@ietf.org > Subject: [codec] Codec BOF approved, much work needed > > > I have approved the CODEC BOF proposal. However, we need a bunch of > work to get ready. Various people on IESG/IAB were not comfortable > with the current charter and agenda so we need to work on theses > before the meeting. > > A draft agenda/charter Jason provided are at > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/=20 > agenda.txt > > Charter: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt > > After discussion with the IESG/IAB: > > I'd like to remove the "as Proposed Standard" from the charter text > for both milestones and see how the discussion goes in the BOF before > deciding which way this should go. > > I'd like to see more consideration around the issues of designing a > codec that did a good job of mapping a real time stream onto IP > packets. The way IP deals with packet loss and congestion has > implications for designing a codec that works well over IP. I know > some of the discussion I have had off list people talked about how we > wanted a codec that supported adaptive bit rates that could change on > the fly to be able to work well on an IP network. > > I will be working the folks to make sure the agenda has time to > directly address the key topics which include (more may be coming): > > Will we be able to get qualified people to do and review the work? > > Key design goals of a new codec? > > Do we need a new codec or are there already ones defined that meet =20= > the > needs? > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. > > Thanks, > > Cullen > > > > > > _______________________________________________ > 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 > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From koen.vos@skype.net Tue Jun 16 19:13: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 9B2413A680F for ; Tue, 16 Jun 2009 19:13:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.674 X-Spam-Level: X-Spam-Status: No, score=-4.674 tagged_above=-999 required=5 tests=[AWL=-1.925, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 XTWltiThnge2 for ; Tue, 16 Jun 2009 19:13:04 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 9F72D3A6880 for ; Tue, 16 Jun 2009 19:13:03 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 8B9372007A7BC for ; Wed, 17 Jun 2009 04:13:13 +0200 (CEST) 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=mPMtCOy1lFob bP5K/MyGRHt5hrc=; b=QkijxVL+QklNlP2zajG0MBeIUbf6sExbFHwyRmy/2Mur 9LQ79FhqhbAs0An3Rjcq0+EgMNNJZUTdIyGDJihYFJrJRiQ7qRkG0aBVfjUrFMor nLp3EC/+mCir6r0qBbzLZJ1/Es+h5Q5b3NxvPHwjSogRjVsp4fxtr65tN6ZcHT4= 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=uEOBZ8vT0b715REwd6sH xBHfjXlA/cSN2pcJ5uJysf6junFluHUoGECKG8wIEW+Qqu8Hc2N4aFA4OB7AfjMw WgJOtpHrN3wnzDVD0wzvDsmeERk63cN7xVH+XifRw2VhKtFPAPFobjTi2OiL5BKW ApLJr/RfGBt0WxtfehJBH4I= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 89EE82007A7B0 for ; Wed, 17 Jun 2009 04:13:13 +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 euF1QubwYRTL for ; Wed, 17 Jun 2009 04:13:02 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id D91272007A7B9; Wed, 17 Jun 2009 04:13:02 +0200 (CEST) Received: from adsl-71-141-96-214.dsl.snfc21.pacbell.net (adsl-71-141-96-214.dsl.snfc21.pacbell.net [71.141.96.214]) by mail.skype.net (Horde Framework) with HTTP; Tue, 16 Jun 2009 19:13:02 -0700 Message-ID: <20090616191302.12956gx9uavee33i@mail.skype.net> Date: Tue, 16 Jun 2009 19:13:02 -0700 From: Koen Vos To: codec@ietf.org References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; 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] Codec BOF approved, much work needed 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, 17 Jun 2009 02:13:05 -0000 Quoting Marshall Eubanks: > Has anyone written up why OGG/Vorbis is not an acceptable solution for thi= s ? Several reasons: - Vorbis runs at bitrates that are higher than a good speech codec. - Vorbis is not very efficient at coding speech: at a given bitrate it =20 delivers worse quality than a good speech codec. - Vorbis' algorithmic delay seems on the high side for real-time =20 communcations. best, koen. > > Regards > Marshall > > On Jun 16, 2009, at 6:31 PM, Henry Sinnreich wrote: > >>> Are we talking here about speech, or generic audio? >> >> As Slava has pointed out it is about wideband speech, that is the =20 >> low latency (150ms or so) still applies, but having wideband audio =20 >> (8-16 kHz audio BW) and why not, stereo. All this and many other =20 >> however is to be worked out in the proposed Internet Codec WG. >> >> Henry >> >> >> On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis" =20 >> wrote: >> >> Are we talking here about speech, or generic audio? >> >> There's a difference in terms of coding (bit rate, quality, etc.) =20 >> and in terms of applicability. >> >> Or do we want both, i.e. two codecs? >> >> --Sandy >> >> >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 >> Behalf Of Henry Sinnreich >> Sent: Tuesday, June 16, 2009 6:15 PM >> To: Slava Borilin; Roni Even; codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Dear Slava, >> >>> We are talking not about =E2=80=9Cenabling technology=E2=80=9D to make e= veryone =20 >>> understand each other (email case), >>> but =E2=80=9Cenhancement=E2=80=9D - everyone can today understand each = other via =20 >>> 711 or 722, but we want to push the quality bar while keeping the =20 >>> interop. >> >> This is an excellent point. We are talking about the Internet here =20 >> in in the IETF. >> >> Henry >> >> >> On 6/16/09 4:56 PM, "Slava Borilin" wrote: >> >> Dear Henry, >> >> It is probably not the same as with email (or maybe just timing is =20 >> different). >> We are talking not about =E2=80=9Cenabling technology=E2=80=9D to make e= veryone =20 >> understand each other (email case), but =E2=80=9Cenhancement=E2=80=9D - = everyone =20 >> can today understand each other via 711 or 722, but we want to =20 >> push the quality bar while keeping the interop. >> >> So really the magic question is that once we have the agreement on =20 >> =E2=80=9Crecommended=E2=80=9D IWAC- either one or several (agree with Je= an-Marc), =20 >> who is to enforce? >> PROBABLY the force to enforce are telecom operators? >> As telco, against internet companies (Cisco, Skype, MSFT, etc), do =20 >> not like walled gardens by definition: >> - The telco landscape is not (well, not only) Skype/cheap IP calls =20 >> versus Cellular or Wireline. >> - The mid-term battle is between internet and its rich =20 >> communication techniques (web conferencing, social networking) and =20 >> telco's phone-only service. >> - Battle is not only for call $$, but for the time spent on the =20 >> media (trend is users spending more minutes on internet comms then =20 >> on phones) >> - so carriers have to move from NGN core networks to offer =20 >> IP-based "social network-like" communication models to subscribers, =20 >> therefore, have IP-service at the last mile for the user, and not =20 >> only for enterprise IP-phones, but every consumer. >> - And as Telco need subscribers to pay for the service, here comes =20 >> the HD(=3Dwideband + packet loss robustness), as the necessary step =20 >> to keep user satisfied with the carrier IP-service. >> - So actually, HD sounds to be the cornerstone for keeping the =20 >> landscape of whole Telco industry versus Internet communications =20 >> (or vice versa). >> - so for telcos it will be really important to have IWAC RFC and =20 >> telcos have the power to enforce using it (via geo or industry =20 >> forums =E2=80=93 examples are PAL/NTSC in geo, industry =E2=80=93 CableL= abs), and =20 >> they are used to the standard/certification process? >> >> Again, apart from the ambitions, what all of us (as vendors and as =20 >> users) would like to achieve, is interop. >> And interop should, probably, be enforced, not =E2=80=9Crecommended=E2= =80=9D via =20 >> some sort of certification? >> >> Everyone, please advice. >> >> >> regards, >> Slava Borilin >> >> >> >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Sent: Wednesday, June 17, 2009 1:33 AM >> To: Slava Borilin; Roni Even; codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Hi Slava, >> >>> Currently in the internet communications (web collaboration, voip =20 >>> services, videoconferencing) - >>> do you believe is there any force to push interop, or everyone =20 >>> "plays in his own walled garden"? >> >> IMO one of the main the strengths of the Internet is its global =20 >> reach. The user can be anywhere and reach content from and =20 >> communicate with anyone, anywhere. Just like we are doing here =20 >> with email. >> The Internet codec will hopefully do for voice the same as text =20 >> communications + attachments work in email. >> >>> sorry if this is na=C3=AFve >> This applies to my message as well :-) >> >> Henry >> >> On 6/16/09 3:56 PM, "Slava Borilin" wrote: >> Roni, and whole international team, >> >> I have one more question here - sorry if this is na=C3=AFve- but still = =20 >> please advice. >> >> Background: all of us do wish wish wish (vendors, customers, =20 >> end-users, etc) to have ONE IWAC (internet wideband audio codec) =20 >> for all. >> >> But assuming we (IETF) will come to the agreement which codec we =20 >> like best (existing or new one) and make RFC. >> What will then be the destiny of the that RFC? >> And who and why should be choosing the certain codec into their app? >> >> Afaik IETF, like ITU just "agree on the specs", while industry or =20 >> country-specific organizations are enforcing using or not using =20 >> certain standards, like CableLabs (Vertical market + geography). >> >> The major driver for agreeing on the standard is interop, as I see. >> Currently in the internet communications (web collaboration, voip =20 >> services, videoconferencing) - do you believe is there any force to =20 >> push interop, or everyone "plays in his own walled garden"? >> >> Should we: >> - agree on RFC and then dig into smaller (geographical or vertical =20 >> industry) communities to push them to force using this RFC (IWAC) =20 >> as part of certification to make sure they do enforce the IWAC? >> - or we should just have IWAC RFC and believe "better staff will =20 >> find its way to the market itself"? >> >> regards, >> Slava Borilin >> >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 >> Behalf Of Roni Even >> Sent: Friday, June 12, 2009 10:56 PM >> To: codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Hi, >> I would like to suggest other key topics for the BOF >> >> 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / >> others >> >> 2. Describe the process of defining a codec in other standard bodies - m= y >> view is that not everyone knows what is required to create a quality cod= ec. >> >> 3. Is the purpose of the WG to publish one codec or multiple =20 >> codecs based on >> different requirements. >> >> 4. If a WG will be formed there are more decision to make like, what is = the >> selection criteria if there is more than one candidate or do we =20 >> require some >> cooperation, what are the deliverable - source code, encoder specificati= on >> (do we require bit exactness ), how to defines the quality tests and >> evaluate the results to check if the codec addresses the requirements. >> >> Roni Even >> >> >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf O= f >> Cullen Jennings >> Sent: Friday, June 12, 2009 8:32 PM >> To: codec@ietf.org >> Subject: [codec] Codec BOF approved, much work needed >> >> >> I have approved the CODEC BOF proposal. However, we need a bunch of >> work to get ready. Various people on IESG/IAB were not comfortable >> with the current charter and agenda so we need to work on theses >> before the meeting. >> >> A draft agenda/charter Jason provided are at >> >> Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt >> >> Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.tx= t >> >> After discussion with the IESG/IAB: >> >> I'd like to remove the "as Proposed Standard" from the charter text >> for both milestones and see how the discussion goes in the BOF before >> deciding which way this should go. >> >> I'd like to see more consideration around the issues of designing a >> codec that did a good job of mapping a real time stream onto IP >> packets. The way IP deals with packet loss and congestion has >> implications for designing a codec that works well over IP. I know >> some of the discussion I have had off list people talked about how we >> wanted a codec that supported adaptive bit rates that could change on >> the fly to be able to work well on an IP network. >> >> I will be working the folks to make sure the agenda has time to >> directly address the key topics which include (more may be coming): >> >> Will we be able to get qualified people to do and review the work? >> >> Key design goals of a new codec? >> >> Do we need a new codec or are there already ones defined that meet the >> needs? >> >> I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. >> >> Thanks, >> >> Cullen >> >> >> >> >> >> _______________________________________________ >> 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 >> >> >> >> _______________________________________________ >> 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@octasic.com Tue Jun 16 19:41: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 F331F3A6880 for ; Tue, 16 Jun 2009 19:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.261 X-Spam-Level: ** X-Spam-Status: No, score=2.261 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FRT_ADOBE2=2.455, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RDNS_NONE=0.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 b+G0wAJky3bV for ; Tue, 16 Jun 2009 19:41:33 -0700 (PDT) Received: from MAILEXCH.octasic.com (unknown [216.208.79.2]) by core3.amsl.com (Postfix) with ESMTP id 8430B3A6778 for ; Tue, 16 Jun 2009 19:41:32 -0700 (PDT) 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_01C9EEF5.1A1052E5" Date: Tue, 16 Jun 2009 22:41:22 -0400 Message-ID: <390831ED3DF58E41A3D2FB82591E2C3603F5F45F@MAILEXCH.octasic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acnrg7Geu5s5P5zNR4OSEheDDVkqeAACcrlgAM1yp6AAAbHVzwAAEL0wAAFkFy8AABUdQAAAgrr3AAhYh7s= References: From: "Jean-Marc Valin" To: "Henry Sinnreich" , "Sandy (Alexander) MacInnis" , , "Slava Borilin" , "Roni Even" Subject: [codec] =?iso-8859-1?q?RE=A0=3A__Codec_BOF_approved=2C_much_work_?= =?iso-8859-1?q?needed?= 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, 17 Jun 2009 02:41:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EEF5.1A1052E5 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable For wideband (16 kHz sampling), I think speech-only (ideally without = mutilating background music) is sufficient. However, for super wideband = (32 kHz and up), I think it's important to start supporting music. When = it comes to latency (by that I mean the codec's algorithmic delay), the = lower the better. I consider anything above ~40 ms to be unacceptable = (ruling out Vorbis, MP3 and standard AAC), but it should ideally be = lower than that. The lower the delay, the less problems you have with = acoustic echo.=20 Jean-Marc -------- Message d'origine-------- De: codec-bounces@ietf.org de la part de Henry Sinnreich Date: mar. 16/06/2009 18:31 =C0: Sandy (Alexander) MacInnis; codec@ietf.org; Slava Borilin; Roni = Even Objet : Re: [codec] Codec BOF approved, much work needed =20 >Are we talking here about speech, or generic audio? As Slava has pointed out it is about wideband speech, that is the low = latency (150ms or so) still applies, but having wideband audio (8-16 kHz = audio BW) and why not, stereo. All this and many other however is to be = worked out in the proposed Internet Codec WG. Henry On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis" = wrote: Are we talking here about speech, or generic audio? There's a difference in terms of coding (bit rate, quality, etc.) and in = terms of applicability. Or do we want both, i.e. two codecs? --Sandy ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Henry Sinnreich Sent: Tuesday, June 16, 2009 6:15 PM To: Slava Borilin; Roni Even; codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Dear Slava, >We are talking not about "enabling technology" to make everyone = understand each other (email case), >but "enhancement" - everyone can today understand each other via 711 = or 722, but we want to push the quality bar while keeping the interop. This is an excellent point. We are talking about the Internet here in in = the IETF. Henry On 6/16/09 4:56 PM, "Slava Borilin" wrote: Dear Henry, It is probably not the same as with email (or maybe just timing is = different). We are talking not about "enabling technology" to make everyone = understand each other (email case), but "enhancement" - everyone can = today understand each other via 711 or 722, but we want to push the = quality bar while keeping the interop. So really the magic question is that once we have the agreement on = "recommended" IWAC- either one or several (agree with Jean-Marc), who = is to enforce? PROBABLY the force to enforce are telecom operators? As telco, against internet companies (Cisco, Skype, MSFT, etc), do not = like walled gardens by definition: - The telco landscape is not (well, not only) Skype/cheap IP calls = versus Cellular or Wireline. - The mid-term battle is between internet and its rich communication = techniques (web conferencing, social networking) and telco's = phone-only service. - Battle is not only for call $$, but for the time spent on the media = (trend is users spending more minutes on internet comms then on phones) - so carriers have to move from NGN core networks to offer IP-based = "social network-like" communication models to subscribers, therefore, = have IP-service at the last mile for the user, and not only for = enterprise IP-phones, but every consumer. - And as Telco need subscribers to pay for the service, here comes the = HD(=3Dwideband + packet loss robustness), as the necessary step to keep = user satisfied with the carrier IP-service. - So actually, HD sounds to be the cornerstone for keeping the = landscape of whole Telco industry versus Internet communications (or = vice versa). - so for telcos it will be really important to have IWAC RFC and telcos = have the power to enforce using it (via geo or industry forums - = examples are PAL/NTSC in geo, industry - CableLabs), and they are used = to the standard/certification process? Again, apart from the ambitions, what all of us (as vendors and as = users) would like to achieve, is interop. And interop should, probably, be enforced, not "recommended" via some = sort of certification? Everyone, please advice. regards, Slava Borilin ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Wednesday, June 17, 2009 1:33 AM To: Slava Borilin; Roni Even; codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Hi Slava, >Currently in the internet communications (web collaboration, voip = services, videoconferencing) - >do you believe is there any force to push interop, or everyone "plays = in his own walled garden"? IMO one of the main the strengths of the Internet is its global reach. = The user can be anywhere and reach content from and communicate with = anyone, anywhere. Just like we are doing here with email. The Internet codec will hopefully do for voice the same as text = communications + attachments work in email. >sorry if this is na=EFve This applies to my message as well :-) Henry On 6/16/09 3:56 PM, "Slava Borilin" wrote: Roni, and whole international team, I have one more question here - sorry if this is na=EFve- but still = please advice. Background: all of us do wish wish wish (vendors, customers, end-users, = etc) to have ONE IWAC (internet wideband audio codec) for all. But assuming we (IETF) will come to the agreement which codec we like = best (existing or new one) and make RFC. What will then be the destiny of the that RFC? And who and why should be choosing the certain codec into their app? Afaik IETF, like ITU just "agree on the specs", while industry or = country-specific organizations are enforcing using or not using certain = standards, like CableLabs (Vertical market + geography). The major driver for agreeing on the standard is interop, as I see. Currently in the internet communications (web collaboration, voip = services, videoconferencing) - do you believe is there any force to push = interop, or everyone "plays in his own walled garden"? Should we: - agree on RFC and then dig into smaller (geographical or vertical = industry) communities to push them to force using this RFC (IWAC) as = part of certification to make sure they do enforce the IWAC? - or we should just have IWAC RFC and believe "better staff will find = its way to the market itself"? regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Roni Even Sent: Friday, June 12, 2009 10:56 PM To: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Hi, I would like to suggest other key topics for the BOF 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / others 2. Describe the process of defining a codec in other standard bodies - = my view is that not everyone knows what is required to create a quality = codec. 3. Is the purpose of the WG to publish one codec or multiple codecs = based on different requirements. 4. If a WG will be formed there are more decision to make like, what is = the selection criteria if there is more than one candidate or do we require = some cooperation, what are the deliverable - source code, encoder = specification (do we require bit exactness ), how to defines the quality tests and evaluate the results to check if the codec addresses the requirements. Roni Even -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Cullen Jennings Sent: Friday, June 12, 2009 8:32 PM To: codec@ietf.org Subject: [codec] Codec BOF approved, much work needed I have approved the CODEC BOF proposal. However, we need a bunch of work to get ready. Various people on IESG/IAB were not comfortable with the current charter and agenda so we need to work on theses before the meeting. A draft agenda/charter Jason provided are at Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt Charter: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt After discussion with the IESG/IAB: I'd like to remove the "as Proposed Standard" from the charter text for both milestones and see how the discussion goes in the BOF before deciding which way this should go. I'd like to see more consideration around the issues of designing a codec that did a good job of mapping a real time stream onto IP packets. The way IP deals with packet loss and congestion has implications for designing a codec that works well over IP. I know some of the discussion I have had off list people talked about how we wanted a codec that supported adaptive bit rates that could change on the fly to be able to work well on an IP network. I will be working the folks to make sure the agenda has time to directly address the key topics which include (more may be coming): Will we be able to get qualified people to do and review the work? Key design goals of a new codec? Do we need a new codec or are there already ones defined that meet the needs? I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. Thanks, Cullen _______________________________________________ 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 ------_=_NextPart_001_01C9EEF5.1A1052E5 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE=A0: [codec] Codec BOF approved, much work needed

For wideband (16 kHz sampling), I think speech-only = (ideally without mutilating background music) is sufficient. However, = for super wideband (32 kHz and up), I think it's important to start = supporting music. When it comes to latency (by that I mean the codec's = algorithmic delay), the lower the better. I consider anything above ~40 = ms to be unacceptable (ruling out Vorbis, MP3 and standard AAC), but it = should ideally be lower than that. The lower the delay, the less = problems you have with acoustic echo.

   Jean-Marc

-------- Message d'origine--------
De: codec-bounces@ietf.org de la part de Henry Sinnreich
Date: mar. 16/06/2009 18:31
=C0: Sandy (Alexander) MacInnis; codec@ietf.org; Slava Borilin; Roni = Even
Objet : Re: [codec] Codec BOF approved, much work needed

>Are we talking here about speech, or generic audio?

As Slava has pointed out it is about wideband speech, that is the low = latency (150ms or so) still applies, but having wideband audio (8-16 kHz = audio BW) and why not, stereo. All this and many other however is to be = worked out in the proposed Internet Codec WG.

Henry


On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis" = <macinnis@broadcom.com> wrote:

Are we talking here about speech, or generic audio?

There's a difference in terms of coding (bit rate, quality, etc.) and in = terms of applicability.

Or do we want both, i.e. two codecs?

--Sandy


________________________________
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf Of Henry Sinnreich
Sent: Tuesday, June 16, 2009 6:15 PM
To: Slava Borilin; Roni Even; codec@ietf.org
Subject: Re: [codec] Codec BOF approved, much work needed

Dear Slava,

>We are talking not about "enabling technology" to make = everyone understand each other (email case),
>but "enhancement" -  everyone can today understand = each other via 711 or 722, but we want to push the quality bar while = keeping the interop.

This is an excellent point. We are talking about the Internet here in in = the IETF.

Henry


On 6/16/09 4:56 PM, "Slava Borilin" = <Borilin@spiritdsp.com> wrote:

Dear Henry,

It is probably not the same  as with email (or maybe just timing is = different).
We are talking not about  "enabling technology" to make = everyone understand each other (email case), but  = "enhancement" -  everyone can today understand each other = via 711 or 722,  but we want to push the quality bar while keeping = the interop.

So  really the magic question is that once we have the agreement on = "recommended"  IWAC- either one or several (agree with = Jean-Marc), who is to  enforce?
PROBABLY the force to enforce are telecom operators?
As  telco, against internet companies (Cisco, Skype, MSFT, etc), do = not like  walled gardens by definition:
 - The telco landscape is not (well, not  only) Skype/cheap IP = calls versus Cellular or Wireline.
 - The  mid-term battle is between internet and its rich = communication techniques (web  conferencing, social networking) = and  telco's phone-only  service.
 - Battle is not only for call $$, but for the time spent on  = the media (trend is users spending more minutes on internet comms then = on  phones)
 - so carriers have to move from NGN core networks to offer  = IP-based "social network-like" communication models to = subscribers, therefore,  have IP-service at the last mile for the = user, and not only for enterprise  IP-phones, but every = consumer.
- And as Telco need subscribers to pay for  the service, here comes = the HD(=3Dwideband + packet loss robustness), as the  necessary = step to keep user satisfied with the carrier IP-service.
- So  actually, HD sounds to be the cornerstone for keeping the = landscape of whole  Telco industry versus Internet communications = (or vice versa).
- so for  telcos it will be really important to have IWAC RFC and = telcos have the power  to enforce using it (via geo or industry = forums - examples are PAL/NTSC in  geo, industry - CableLabs), and = they are used to the standard/certification  process?

Again, apart from the ambitions, what all of us (as  vendors and as = users) would like to achieve, is interop.
And interop  should, probably, be enforced, not = "recommended" via some sort of  certification?

Everyone, please  advice.


regards,
Slava  Borilin


________________________________

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Wednesday, June 17, 2009 1:33 AM
To: Slava Borilin;  Roni Even; codec@ietf.org
Subject: Re:  [codec] Codec BOF approved, much work needed

Hi  Slava,

>Currently in the internet communications (web collaboration,  = voip services, videoconferencing) -
>do you believe is there any force  to push interop, or everyone = "plays in his own walled garden"?

IMO one  of the main the strengths of the Internet is its global = reach. The user can be  anywhere and reach content from and = communicate with anyone, anywhere. Just  like we are doing here = with email.
The Internet codec will hopefully do for  voice the same as text = communications + attachments work in  email.

>sorry if this is na=EFve
This applies to my message as well  :-)

Henry

On 6/16/09 3:56 PM, "Slava Borilin" = <Borilin@spiritdsp.com> wrote:
Roni, and  whole international team,

I have one more question here - sorry if this  is na=EFve- but = still please advice.

Background: all of us do wish wish  wish (vendors, customers, = end-users, etc) to have ONE IWAC (internet wideband  audio codec) = for all.

But assuming we (IETF) will come to the agreement  which codec we = like best (existing or new one) and make RFC.
What will then  be the destiny of the that RFC?
And who and why should be choosing the  certain codec into their = app?

Afaik IETF, like ITU just "agree on the  specs", while = industry or country-specific organizations are enforcing using  or = not using certain standards, like CableLabs (Vertical market +  = geography).

The major driver for agreeing on the standard is interop,  as I = see.
Currently in the internet communications (web collaboration, voip  = services, videoconferencing) - do you believe is there any force to = push  interop, or everyone "plays in his own walled = garden"?

Should we:
-  agree on RFC and then dig into smaller (geographical or vertical = industry)  communities to push them to force using this RFC (IWAC) = as part of  certification to make sure they do enforce the = IWAC?
- or we should just  have IWAC RFC and believe "better staff = will find its way to the market  itself"?

regards,
Slava Borilin


-----Original  Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On  Behalf Of Roni Even
Sent: Friday, June 12, 2009 10:56 PM
To: codec@ietf.org
Subject: Re: [codec] Codec BOF  approved, much work needed

Hi,
I would like to suggest other key  topics for the BOF

1. Why should the IETF start a codec WG - why not do  it as ITU / = MPEG /
others

2. Describe the process of defining a  codec in other standard = bodies - my
view is that not everyone knows what is  required to create a = quality codec.

3. Is the purpose of the WG to  publish one codec or multiple = codecs based on
different  requirements.

4. If a WG will be formed there are more decision to make  like, = what is the
selection criteria if there is more than one candidate or  do we = require some
cooperation, what are the deliverable - source code,  encoder = specification
(do we require bit exactness ), how to defines the  quality tests = and
evaluate the results to check if the codec addresses the  = requirements.

Roni Even



-----Original  Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On  Behalf Of
Cullen Jennings
Sent: Friday, June 12, 2009 8:32 PM
To: codec@ietf.org
Subject: [codec] Codec BOF  approved, much work needed


I have approved the CODEC BOF proposal.  However, we need a bunch = of
work to get ready.  Various people on  IESG/IAB were not = comfortable
with the current charter and agenda so we  need to work on = theses
before the meeting.

A draft agenda/charter  Jason provided are at

Agenda: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt

Charter:  http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt
=
After  discussion with the IESG/IAB:

I'd like to remove the "as Proposed  Standard" from the = charter text
for both milestones and see how the  discussion goes in the BOF = before
deciding which way this should  go.

I'd like to see more consideration around the issues of designing a
codec that did a good job of mapping a real time stream onto IP
packets. The way IP deals with packet loss and congestion has
implications for designing a codec that works well over IP. I know
some of the discussion I have had off list people talked about how = we
wanted a codec that supported adaptive bit rates that could change = on
the fly to be able to work well on an IP network.

I will be working  the folks to make sure the agenda has time = to
directly address the key  topics which include (more may be = coming):

Will we be able to get  qualified people to do and review the = work?

Key design goals of a new  codec?

Do we need a new codec or are there already ones defined that  meet = the
needs?

I have asked Jason Fischl  and Jean-Marc Valin  to co-chair = this BOF.

Thanks,

Cullen <RAI  AD>





_______________________________________________
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

------_=_NextPart_001_01C9EEF5.1A1052E5-- From hoene@uni-tuebingen.de Tue Jun 16 23:33: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 223CD3A6DDA for ; Tue, 16 Jun 2009 23:33:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.021 X-Spam-Level: X-Spam-Status: No, score=-5.021 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 bS-CB8Q04rnp for ; Tue, 16 Jun 2009 23:32:54 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 6E71B3A6BCC for ; Tue, 16 Jun 2009 23:32:49 -0700 (PDT) Received: from hoeneLenovoT60 (isc-router6.urz.tu-dresden.de [141.30.3.115]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n5H6WkiG013592 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 17 Jun 2009 08:32:52 +0200 From: "Christian Hoene" To: References: <568A92CB079CCF43BA5C8D7B08BCB4AE8150B5524D@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <568A92CB079CCF43BA5C8D7B08BCB4AE8150B5524D@SJEXCHCCR02.corp.ad.broadcom.com> Date: Wed, 17 Jun 2009 08:32:45 +0200 Message-ID: <01e801c9ef15$702c8f90$5085aeb0$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01E9_01C9EF26.33B55F90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnrg7Geu5s5P5zNR4OSEheDDVkqeAACcrlgAM1yp6AAAbHVzwAAEL0wAAFkFy8AABUdQAAREidQ 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.0.187; VDF: 7.1.4.100; host: mx05); id=16854-OlnQdw Subject: Re: [codec] Codec BOF approved, much work needed 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, 17 Jun 2009 06:33:07 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_01E9_01C9EF26.33B55F90 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 in case of SBC, we are considering it using it for wide-band speech, = too. Then we run it at a lower sampling and bit rate. It outperforms other = wide band speech codecs such as G.722.=20 =20 I would suggest that a future audio codec shall be able to work at very = low bit and frame rates, at which it can transmit only speech. This feature might be quite useful to increase the codec=92s robustness in cases of = limited bandwidth and congestion. Also, the codec shall adapt itself to limited bandwidth automatically. =20 With best regards, =20 Christian=20 =20 =20 =20 =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Sandy (Alexander) MacInnis Sent: Wednesday, June 17, 2009 12:19 AM To: codec@ietf.org; Henry Sinnreich; Slava Borilin; Roni Even Subject: Re: [codec] Codec BOF approved, much work needed =20 Are we talking here about speech, or generic audio? =20 There's a difference in terms of coding (bit rate, quality, etc.) and in terms of applicability. =20 Or do we want both, i.e. two codecs? =20 --Sandy =20 =20 _____ =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Henry Sinnreich Sent: Tuesday, June 16, 2009 6:15 PM To: Slava Borilin; Roni Even; codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Dear Slava, =20 >We are talking not about =93enabling technology=94 to make everyone = understand each other (email case),=20 >but =93enhancement=94 - everyone can today understand each other via = 711 or 722, but we want to push the quality bar while keeping the interop. This is an excellent point. We are talking about the Internet here in in = the IETF. Henry On 6/16/09 4:56 PM, "Slava Borilin" wrote: Dear Henry, =20 It is probably not the same as with email (or maybe just timing is different). We are talking not about =93enabling technology=94 to make everyone = understand each other (email case), but =93enhancement=94 - everyone can today = understand each other via 711 or 722, but we want to push the quality bar while = keeping the interop. =20 So really the magic question is that once we have the agreement on =93recommended=94 IWAC- either one or several (agree with Jean-Marc), = who is to enforce? PROBABLY the force to enforce are telecom operators? As telco, against internet companies (Cisco, Skype, MSFT, etc), do not = like walled gardens by definition: - The telco landscape is not (well, not only) Skype/cheap IP calls = versus Cellular or Wireline. - The mid-term battle is between internet and its rich communication techniques (web conferencing, social networking) and telco's phone-only service. - Battle is not only for call $$, but for the time spent on the media (trend is users spending more minutes on internet comms then on phones) - so carriers have to move from NGN core networks to offer IP-based = "social network-like" communication models to subscribers, therefore, have IP-service at the last mile for the user, and not only for enterprise IP-phones, but every consumer. - And as Telco need subscribers to pay for the service, here comes the HD(=3Dwideband + packet loss robustness), as the necessary step to keep = user satisfied with the carrier IP-service. - So actually, HD sounds to be the cornerstone for keeping the landscape = of whole Telco industry versus Internet communications (or vice versa). - so for telcos it will be really important to have IWAC RFC and telcos = have the power to enforce using it (via geo or industry forums =96 examples = are PAL/NTSC in geo, industry =96 CableLabs), and they are used to the standard/certification process? =20 Again, apart from the ambitions, what all of us (as vendors and as = users) would like to achieve, is interop. And interop should, probably, be enforced, not =93recommended=94 via = some sort of certification? =20 Everyone, please advice. =20 regards, Slava Borilin _____ =20 From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Wednesday, June 17, 2009 1:33 AM To: Slava Borilin; Roni Even; codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Hi Slava, >Currently in the internet communications (web collaboration, voip = services, videoconferencing) -=20 >do you believe is there any force to push interop, or everyone "plays = in his own walled garden"? IMO one of the main the strengths of the Internet is its global reach. = The user can be anywhere and reach content from and communicate with anyone, anywhere. Just like we are doing here with email. The Internet codec will hopefully do for voice the same as text communications + attachments work in email. >sorry if this is na=EFve This applies to my message as well :-) Henry On 6/16/09 3:56 PM, "Slava Borilin" wrote: Roni, and whole international team, I have one more question here - sorry if this is na=EFve- but still = please advice. Background: all of us do wish wish wish (vendors, customers, end-users, = etc) to have ONE IWAC (internet wideband audio codec) for all. But assuming we (IETF) will come to the agreement which codec we like = best (existing or new one) and make RFC. What will then be the destiny of the that RFC? And who and why should be choosing the certain codec into their app? Afaik IETF, like ITU just "agree on the specs", while industry or country-specific organizations are enforcing using or not using certain standards, like CableLabs (Vertical market + geography). The major driver for agreeing on the standard is interop, as I see. Currently in the internet communications (web collaboration, voip = services, videoconferencing) - do you believe is there any force to push interop, = or everyone "plays in his own walled garden"? Should we: - agree on RFC and then dig into smaller (geographical or vertical = industry) communities to push them to force using this RFC (IWAC) as part of certification to make sure they do enforce the IWAC? - or we should just have IWAC RFC and believe "better staff will find = its way to the market itself"? regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Roni Even Sent: Friday, June 12, 2009 10:56 PM To: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Hi, I would like to suggest other key topics for the BOF 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / others 2. Describe the process of defining a codec in other standard bodies - = my view is that not everyone knows what is required to create a quality = codec. 3. Is the purpose of the WG to publish one codec or multiple codecs = based on different requirements. 4. If a WG will be formed there are more decision to make like, what is = the selection criteria if there is more than one candidate or do we require = some cooperation, what are the deliverable - source code, encoder = specification (do we require bit exactness ), how to defines the quality tests and evaluate the results to check if the codec addresses the requirements. Roni Even -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Cullen Jennings Sent: Friday, June 12, 2009 8:32 PM To: codec@ietf.org Subject: [codec] Codec BOF approved, much work needed I have approved the CODEC BOF proposal. However, we need a bunch of=20 work to get ready. Various people on IESG/IAB were not comfortable=20 with the current charter and agenda so we need to work on theses=20 before the meeting. A draft agenda/charter Jason provided are at Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt Charter: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt After discussion with the IESG/IAB: I'd like to remove the "as Proposed Standard" from the charter text=20 for both milestones and see how the discussion goes in the BOF before=20 deciding which way this should go. I'd like to see more consideration around the issues of designing a=20 codec that did a good job of mapping a real time stream onto IP=20 packets. The way IP deals with packet loss and congestion has=20 implications for designing a codec that works well over IP. I know=20 some of the discussion I have had off list people talked about how we=20 wanted a codec that supported adaptive bit rates that could change on=20 the fly to be able to work well on an IP network. I will be working the folks to make sure the agenda has time to=20 directly address the key topics which include (more may be coming): Will we be able to get qualified people to do and review the work? Key design goals of a new codec? Do we need a new codec or are there already ones defined that meet the=20 needs? I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. Thanks, Cullen _______________________________________________ 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 ------=_NextPart_000_01E9_01C9EF26.33B55F90 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Codec BOF approved, much work needed

Hi all,

 

in case of SBC, we are considering it using it for = wide-band speech, too. =A0Then we run it at a lower sampling and bit rate. It = outperforms other wide band speech codecs such as G.722.

 

I would suggest that a future audio codec shall be able = to work at very low bit and frame rates, at which it can transmit only speech. = This feature might be quite useful to increase the codec’s robustness = in cases of limited bandwidth and congestion. Also, the codec shall adapt itself = to limited bandwidth automatically.

 

With best regards,

 

=A0Christian

 

 

 

 

From:= codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Sandy (Alexander) MacInnis
Sent: Wednesday, June 17, 2009 12:19 AM
To: codec@ietf.org; Henry Sinnreich; Slava Borilin; Roni Even
Subject: Re: [codec] Codec BOF approved, much work = needed

 

Are we talking here about = speech, or generic audio?

 

There's a difference in = terms of coding (bit rate, quality, etc.) and in terms of = applicability.

 

Or do we want both, i.e. = two codecs?

 

--Sandy

 

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Henry Sinnreich
Sent: Tuesday, June 16, 2009 6:15 PM
To: Slava Borilin; Roni Even; codec@ietf.org
Subject: Re: [codec] Codec BOF approved, much work = needed

Dear Slava,
 
>= We are talking not about “enabling technology” to make everyone = understand each other (email case),
>but “enhancement” -  everyone can today understand = each other via 711 or 722, but we want to push the quality bar while keeping = the interop.

This is an = excellent point. We are talking about the Internet here in in the IETF.

Henry


On 6/16/09 4:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> = wrote:

Dear Henry,
 
It is probably not the same as with email (or maybe just timing is = different).
We are talking not about “enabling technology” to make = everyone understand each other (email case), but “enhancement” -  everyone can today understand each other via 711 or 722, but we = want to push the quality bar while keeping the interop.
 
So really the magic question is that once we have the agreement on “recommended” IWAC- either one or several (agree with = Jean-Marc), who is to enforce?
PROBABLY the force to enforce are telecom operators?
As telco, against internet companies (Cisco, Skype, MSFT, etc), do = not like walled gardens by definition:
 - The telco landscape is not (well, not only) Skype/cheap IP calls = versus Cellular or Wireline.
 - The mid-term battle is between internet and its rich = communication techniques (web conferencing, social networking) and  telco's = phone-only service.
 - Battle is not only for call $$, but for the time spent on the = media (trend is users spending more minutes on internet comms then on = phones)
 - so carriers have to move from NGN core networks to offer = IP-based "social network-like" communication models to subscribers, = therefore, have IP-service at the last mile for the user, and not only for = enterprise IP-phones, but every consumer.
- And as Telco need subscribers to pay for the service, here comes the HD(=3Dwideband + packet loss robustness), as the necessary step to keep = user satisfied with the carrier IP-service.
- So actually, HD sounds to be the cornerstone for keeping the landscape = of whole Telco industry versus Internet communications (or vice versa).
- so for telcos it will be really important to have IWAC RFC and telcos = have the power to enforce using it (via geo or industry forums – = examples are PAL/NTSC in geo, industry – CableLabs), and they are used to the standard/certification process?
 
Again, apart from the ambitions, what all of us (as vendors and as = users) would like to achieve, is interop.
And interop should, probably, be enforced, not “recommended” = via some sort of certification?
 
Everyone, please advice.
 

regards,
Slava Borilin

From:= Henry = Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Wednesday, June 17, 2009 1:33 AM
To: Slava Borilin; Roni Even; codec@ietf.org
Subject: Re: [codec] Codec BOF approved, much work needed

Hi = Slava,

>Currently in the internet communications (web collaboration, voip = services, videoconferencing) -
>do you believe is there any force to push interop, or everyone = "plays in his own walled garden"?

IMO one of the main the strengths of the Internet is its global reach. = The user can be anywhere and reach content from and communicate with anyone, = anywhere. Just like we are doing here with email.
The Internet codec will hopefully do for voice the same as text = communications + attachments work in email.

>sorry if this is na=EFve
This applies to my message as well :-)

Henry

On 6/16/09 3:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
Roni, and whole international team,

I have one more question here - sorry if this is na=EFve- but still = please advice.

Background: all of us do wish wish wish (vendors, customers, end-users, = etc) to have ONE IWAC (internet wideband audio codec) for all.

But assuming we (IETF) will come to the agreement which codec we like = best (existing or new one) and make RFC.
What will then be the destiny of the that RFC?
And who and why should be choosing the certain codec into their app?

Afaik IETF, like ITU just "agree on the specs", while industry = or country-specific organizations are enforcing using or not using certain standards, like CableLabs (Vertical market + geography).

The major driver for agreeing on the standard is interop, as I see.
Currently in the internet communications (web collaboration, voip = services, videoconferencing) - do you believe is there any force to push interop, = or everyone "plays in his own walled garden"?

Should we:
- agree on RFC and then dig into smaller (geographical or vertical = industry) communities to push them to force using this RFC (IWAC) as part of certification to make sure they do enforce the IWAC?
- or we should just have IWAC RFC and believe "better staff will = find its way to the market itself"?

regards,
Slava Borilin


-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf Of Roni Even
Sent: Friday, June 12, 2009 10:56 PM
To: codec@ietf.org
Subject: Re: [codec] Codec BOF approved, much work needed

Hi,
I would like to suggest other key topics for the BOF

1. Why should the IETF start a codec WG - why not do it as ITU / MPEG = /
others

2. Describe the process of defining a codec in other standard bodies - = my
view is that not everyone knows what is required to create a quality = codec.

3. Is the purpose of the WG to publish one codec or multiple codecs = based on
different requirements.

4. If a WG will be formed there are more decision to make like, what is = the
selection criteria if there is more than one candidate or do we require = some
cooperation, what are the deliverable - source code, encoder = specification
(do we require bit exactness ), how to defines the quality tests and
evaluate the results to check if the codec addresses the = requirements.

Roni Even



-----Original Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf Of
Cullen Jennings
Sent: Friday, June 12, 2009 8:32 PM
To: codec@ietf.org
Subject: [codec] Codec BOF approved, much work needed


I have approved the CODEC BOF proposal. However, we need a bunch of
work to get ready.  Various people on IESG/IAB were not comfortable =
with the current charter and agenda so we need to work on theses
before the meeting.

A draft agenda/charter Jason provided are at

Agenda: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt

Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt
=
After discussion with the IESG/IAB:

I'd like to remove the "as Proposed Standard" from the charter = text
for both milestones and see how the discussion goes in the BOF before =
deciding which way this should go.

I'd like to see more consideration around the issues of designing a
codec that did a good job of mapping a real time stream onto IP
packets. The way IP deals with packet loss and congestion has
implications for designing a codec that works well over IP. I know
some of the discussion I have had off list people talked about how we =
wanted a codec that supported adaptive bit rates that could change on =
the fly to be able to work well on an IP network.

I will be working the folks to make sure the agenda has time to
directly address the key topics which include (more may be coming):

Will we be able to get qualified people to do and review the work?

Key design goals of a new codec?

Do we need a new codec or are there already ones defined that meet the =
needs?

I have asked Jason Fischl  and Jean-Marc Valin to co-chair this = BOF.

Thanks,

Cullen <RAI AD>





_______________________________________________
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

------=_NextPart_000_01E9_01C9EF26.33B55F90-- From xiphmont@gmail.com Wed Jun 17 02:55: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 9BEC23A68D5 for ; Wed, 17 Jun 2009 02:55:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.456 X-Spam-Level: X-Spam-Status: No, score=-2.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 w8ZaQ7HOd9je for ; Wed, 17 Jun 2009 02:55:11 -0700 (PDT) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id CBF4A3A6B6F for ; Wed, 17 Jun 2009 02:55:11 -0700 (PDT) Received: by gxk10 with SMTP id 10so315045gxk.13 for ; Wed, 17 Jun 2009 02:54:27 -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 :content-transfer-encoding; bh=jRxP6Tn5LxuB3dYnclX0tQOsjQdd/1FlK3kSkGNdGuM=; b=L6EHdvAOb8Wt+Vg7NZadf05/U9qbpwGZwO2Eo/um6T8vWWd6G54EHyXX5KSdsjoajn foBt4Qr1sKd2WjYy1AcvLpbIEaVwvICS5WjLp5AD+FvfkvwVJe086/h9fKsqWkdp7VB1 0NRSt8Q5JH0naW5Qy9+RSAlBInCZtbCgh44NI= 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:content-transfer-encoding; b=S5pOqiU3hz6rKeCBV0565lKDBpwSNA+DfzmVKdzdzW5dnvo7jDIRESvcC0LKBx+oJ3 MwshQ9INItm4SlMrCfM9Ps4YOEQGKodMqRNmx5ctvqfG4GjHZ8CkoAFmPObET5SfeDEk CbXqEnm6ErzWGPUpuNtXlOzuKayp0/YJ5Ybvg= MIME-Version: 1.0 Received: by 10.231.10.136 with SMTP id p8mr3358644ibp.14.1245232466887; Wed, 17 Jun 2009 02:54:26 -0700 (PDT) In-Reply-To: <20090616191302.12956gx9uavee33i@mail.skype.net> References: <20090616191302.12956gx9uavee33i@mail.skype.net> Date: Wed, 17 Jun 2009 05:54:26 -0400 Message-ID: <806dafc20906170254v35ff3f93x8a3a62038afd4f41@mail.gmail.com> From: Christopher Montgomery To: Koen Vos Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 17 Jun 2009 09:55:12 -0000 On Tue, Jun 16, 2009 at 10:13 PM, Koen Vos wrote: > Quoting Marshall Eubanks: >> >> Has anyone written up why OGG/Vorbis is not an acceptable solution for >> this ? > > Several reasons: > - Vorbis runs at bitrates that are higher than a good speech codec. > - Vorbis is not very efficient at coding speech: at a given bitrate it > delivers worse quality than a good speech codec. > - Vorbis' algorithmic delay seems on the high side for real-time > communcations. Piping up as the designer of Vorbis, these points are correct. It is meant to be a high-latency highest-possible-fidelity codec for general audio. Monty From hsinnrei@adobe.com Wed Jun 17 07:38:17 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 4DE323A685E for ; Wed, 17 Jun 2009 07:38:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.579 X-Spam-Level: X-Spam-Status: No, score=-4.579 tagged_above=-999 required=5 tests=[AWL=-0.736, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 QM3k91IFPJrA for ; Wed, 17 Jun 2009 07:38:03 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by core3.amsl.com (Postfix) with ESMTP id 319413A69CD for ; Wed, 17 Jun 2009 07:37:55 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKSjj/kYT5trrki+8z1a86/qMvxWh9G2V2@postini.com; Wed, 17 Jun 2009 07:38:15 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5HEb2WG021470; Wed, 17 Jun 2009 07:37:03 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5HEavir022314; Wed, 17 Jun 2009 07:37:01 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Wed, 17 Jun 2009 07:37:00 -0700 From: Henry Sinnreich To: Jean-Marc Valin , "Sandy (Alexander) MacInnis" , "codec@ietf.org" , Slava Borilin , Roni Even Date: Wed, 17 Jun 2009 07:36:56 -0700 Thread-Topic: =?iso-8859-1?Q?RE=A0:_[codec]_Codec_BOF_approved, _much_work_needed?= Thread-Index: Acnrg7Geu5s5P5zNR4OSEheDDVkqeAACcrlgAM1yp6AAAbHVzwAAEL0wAAFkFy8AABUdQAAAgrr3AAhYh7sAGVs/LQ== Message-ID: In-Reply-To: <390831ED3DF58E41A3D2FB82591E2C3603F5F45F@MAILEXCH.octasic.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_C65E69B8428Ehsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] =?iso-8859-1?q?RE=A0=3A__Codec_BOF_approved=2C_much_work_?= =?iso-8859-1?q?needed?= 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, 17 Jun 2009 14:38:17 -0000 --_000_C65E69B8428Ehsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Supporting music is a good point in case, given the emergence of Telepresen= ce and the Digital Living room. As for supporting bandwidth constrained links, where congestion can occur, = I believe the mobile phone industry has already done a good job that we nee= d not duplicate. Given the choice between designing for narrowband links and broadband Inter= net, let's chose therefore broadband. Henry On 6/16/09 9:41 PM, "Jean-Marc Valin" wrote: For wideband (16 kHz sampling), I think speech-only (ideally without mutila= ting background music) is sufficient. However, for super wideband (32 kHz a= nd up), I think it's important to start supporting music. When it comes to = latency (by that I mean the codec's algorithmic delay), the lower the bette= r. I consider anything above ~40 ms to be unacceptable (ruling out Vorbis, = MP3 and standard AAC), but it should ideally be lower than that. The lower = the delay, the less problems you have with acoustic echo. Jean-Marc -------- Message d'origine-------- De: codec-bounces@ietf.org de la part de Henry Sinnreich Date: mar. 16/06/2009 18:31 =C0: Sandy (Alexander) MacInnis; codec@ietf.org; Slava Borilin; Roni Even Objet : Re: [codec] Codec BOF approved, much work needed >Are we talking here about speech, or generic audio? As Slava has pointed out it is about wideband speech, that is the low laten= cy (150ms or so) still applies, but having wideband audio (8-16 kHz audio B= W) and why not, stereo. All this and many other however is to be worked out= in the proposed Internet Codec WG. Henry On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis" wr= ote: Are we talking here about speech, or generic audio? There's a difference in terms of coding (bit rate, quality, etc.) and in te= rms of applicability. Or do we want both, i.e. two codecs? --Sandy ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of H= enry Sinnreich Sent: Tuesday, June 16, 2009 6:15 PM To: Slava Borilin; Roni Even; codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Dear Slava, >We are talking not about "enabling technology" to make everyone understand= each other (email case), >but "enhancement" - everyone can today understand each other via 711 or 7= 22, but we want to push the quality bar while keeping the interop. This is an excellent point. We are talking about the Internet here in in th= e IETF. Henry On 6/16/09 4:56 PM, "Slava Borilin" wrote: Dear Henry, It is probably not the same as with email (or maybe just timing is differe= nt). We are talking not about "enabling technology" to make everyone understand= each other (email case), but "enhancement" - everyone can today understa= nd each other via 711 or 722, but we want to push the quality bar while ke= eping the interop. So really the magic question is that once we have the agreement on "recomm= ended" IWAC- either one or several (agree with Jean-Marc), who is to enfo= rce? PROBABLY the force to enforce are telecom operators? As telco, against internet companies (Cisco, Skype, MSFT, etc), do not lik= e walled gardens by definition: - The telco landscape is not (well, not only) Skype/cheap IP calls versus= Cellular or Wireline. - The mid-term battle is between internet and its rich communication tech= niques (web conferencing, social networking) and telco's phone-only serv= ice. - Battle is not only for call $$, but for the time spent on the media (tr= end is users spending more minutes on internet comms then on phones) - so carriers have to move from NGN core networks to offer IP-based "soci= al network-like" communication models to subscribers, therefore, have IP-s= ervice at the last mile for the user, and not only for enterprise IP-phone= s, but every consumer. - And as Telco need subscribers to pay for the service, here comes the HD(= =3Dwideband + packet loss robustness), as the necessary step to keep user = satisfied with the carrier IP-service. - So actually, HD sounds to be the cornerstone for keeping the landscape o= f whole Telco industry versus Internet communications (or vice versa). - so for telcos it will be really important to have IWAC RFC and telcos ha= ve the power to enforce using it (via geo or industry forums - examples ar= e PAL/NTSC in geo, industry - CableLabs), and they are used to the standar= d/certification process? Again, apart from the ambitions, what all of us (as vendors and as users) = would like to achieve, is interop. And interop should, probably, be enforced, not "recommended" via some sort= of certification? Everyone, please advice. regards, Slava Borilin ________________________________ From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Wednesday, June 17, 2009 1:33 AM To: Slava Borilin; Roni Even; codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Hi Slava, >Currently in the internet communications (web collaboration, voip service= s, videoconferencing) - >do you believe is there any force to push interop, or everyone "plays in = his own walled garden"? IMO one of the main the strengths of the Internet is its global reach. The= user can be anywhere and reach content from and communicate with anyone, = anywhere. Just like we are doing here with email. The Internet codec will hopefully do for voice the same as text communicat= ions + attachments work in email. >sorry if this is na=EFve This applies to my message as well :-) Henry On 6/16/09 3:56 PM, "Slava Borilin" wrote: Roni, and whole international team, I have one more question here - sorry if this is na=EFve- but still please= advice. Background: all of us do wish wish wish (vendors, customers, end-users, et= c) to have ONE IWAC (internet wideband audio codec) for all. But assuming we (IETF) will come to the agreement which codec we like best= (existing or new one) and make RFC. What will then be the destiny of the that RFC? And who and why should be choosing the certain codec into their app? Afaik IETF, like ITU just "agree on the specs", while industry or country-= specific organizations are enforcing using or not using certain standards,= like CableLabs (Vertical market + geography). The major driver for agreeing on the standard is interop, as I see. Currently in the internet communications (web collaboration, voip services= , videoconferencing) - do you believe is there any force to push interop, = or everyone "plays in his own walled garden"? Should we: - agree on RFC and then dig into smaller (geographical or vertical industr= y) communities to push them to force using this RFC (IWAC) as part of cer= tification to make sure they do enforce the IWAC? - or we should just have IWAC RFC and believe "better staff will find its = way to the market itself"? regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Roni Even Sent: Friday, June 12, 2009 10:56 PM To: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Hi, I would like to suggest other key topics for the BOF 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / others 2. Describe the process of defining a codec in other standard bodies - my view is that not everyone knows what is required to create a quality codec= . 3. Is the purpose of the WG to publish one codec or multiple codecs based = on different requirements. 4. If a WG will be formed there are more decision to make like, what is th= e selection criteria if there is more than one candidate or do we require so= me cooperation, what are the deliverable - source code, encoder specification (do we require bit exactness ), how to defines the quality tests and evaluate the results to check if the codec addresses the requirements. Roni Even -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Cullen Jennings Sent: Friday, June 12, 2009 8:32 PM To: codec@ietf.org Subject: [codec] Codec BOF approved, much work needed I have approved the CODEC BOF proposal. However, we need a bunch of work to get ready. Various people on IESG/IAB were not comfortable with the current charter and agenda so we need to work on theses before the meeting. A draft agenda/charter Jason provided are at Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt After discussion with the IESG/IAB: I'd like to remove the "as Proposed Standard" from the charter text for both milestones and see how the discussion goes in the BOF before deciding which way this should go. I'd like to see more consideration around the issues of designing a codec that did a good job of mapping a real time stream onto IP packets. The way IP deals with packet loss and congestion has implications for designing a codec that works well over IP. I know some of the discussion I have had off list people talked about how we wanted a codec that supported adaptive bit rates that could change on the fly to be able to work well on an IP network. I will be working the folks to make sure the agenda has time to directly address the key topics which include (more may be coming): Will we be able to get qualified people to do and review the work? Key design goals of a new codec? Do we need a new codec or are there already ones defined that meet the needs? I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. Thanks, Cullen _______________________________________________ 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 --_000_C65E69B8428Ehsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: RE=A0: [codec] Codec BOF approved, much work needed Supporting music is a good point in case, given the emergence of Tele= presence and the Digital Living room.

As for supporting bandwidth constrained links, where congestion can occur, = I believe the mobile phone industry has already done a good job that we nee= d not duplicate.

Given the choice between designing for narrowband links and broadband Inter= net, let’s chose therefore broadband.

Henry

On 6/16/09 9:41 PM, "Jean-Marc Valin" <jean-marc.valin@octasic.com> wrote:

For wideband (16 kHz sampling), I think spe= ech-only (ideally without mutilating background music) is sufficient. Howev= er, for super wideband (32 kHz and up), I think it's important to start sup= porting music. When it comes to latency (by that I mean the codec's algorit= hmic delay), the lower the better. I consider anything above ~40 ms to be u= nacceptable (ruling out Vorbis, MP3 and standard AAC), but it should ideall= y be lower than that. The lower the delay, the less problems you have with = acoustic echo.

   Jean-Marc

-------- Message d'origine--------
De: codec-bounces@ietf.org de la par= t de Henry Sinnreich
Date: mar. 16/06/2009 18:31
À: Sandy (Alexander) MacInnis; codec@ietf= .org; Slava Borilin; Roni Even
Objet : Re: [codec] Codec BOF approved, much work needed

>Are we talking here about speech, or generic audio?

As Slava has pointed out it is about wideband speech, that is the low laten= cy (150ms or so) still applies, but having wideband audio (8-16 kHz audio B= W) and why not, stereo. All this and many other however is to be worked out= in the proposed Internet Codec WG.

Henry


On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis" <macinnis@broadcom.com> wrote:

Are we talking here about speech, or generic audio?

There's a difference in terms of coding (bit rate, quality, etc.) and in te= rms of applicability.

Or do we want both, i.e. two codecs?

--Sandy


________________________________
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On B= ehalf Of Henry Sinnreich
Sent: Tuesday, June 16, 2009 6:15 PM
To: Slava Borilin; Roni Even; codec@ietf.org=
Subject: Re: [codec] Codec BOF approved, much work needed

Dear Slava,

>We are talking not about "enabling technology" to make everyo= ne understand each other (email case),
>but "enhancement" -  everyone can today understand each = other via 711 or 722, but we want to push the quality bar while keeping the= interop.

This is an excellent point. We are talking about the Internet here in in th= e IETF.

Henry


On 6/16/09 4:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:

Dear Henry,

It is probably not the same  as with email (or maybe just timing is di= fferent).
We are talking not about  "enabling technology" to make ever= yone understand each other (email case), but  "enhancement" = -  everyone can today understand each other via 711 or 722,  but = we want to push the quality bar while keeping the interop.

So  really the magic question is that once we have the agreement on &q= uot;recommended"  IWAC- either one or several (agree with Jean-Ma= rc), who is to  enforce?
PROBABLY the force to enforce are telecom operators?
As  telco, against internet companies (Cisco, Skype, MSFT, etc), do no= t like  walled gardens by definition:
 - The telco landscape is not (well, not  only) Skype/cheap IP ca= lls versus Cellular or Wireline.
 - The  mid-term battle is between internet and its rich communic= ation techniques (web  conferencing, social networking) and  telc= o's phone-only  service.
 - Battle is not only for call $$, but for the time spent on  the= media (trend is users spending more minutes on internet comms then on &nbs= p;phones)
 - so carriers have to move from NGN core networks to offer  IP-b= ased "social network-like" communication models to subscribers, t= herefore,  have IP-service at the last mile for the user, and not only= for enterprise  IP-phones, but every consumer.
- And as Telco need subscribers to pay for  the service, here comes th= e HD(=3Dwideband + packet loss robustness), as the  necessary step to = keep user satisfied with the carrier IP-service.
- So  actually, HD sounds to be the cornerstone for keeping the landsc= ape of whole  Telco industry versus Internet communications (or vice v= ersa).
- so for  telcos it will be really important to have IWAC RFC and telc= os have the power  to enforce using it (via geo or industry forums - e= xamples are PAL/NTSC in  geo, industry - CableLabs), and they are used= to the standard/certification  process?

Again, apart from the ambitions, what all of us (as  vendors and as us= ers) would like to achieve, is interop.
And interop  should, probably, be enforced, not "recommended"= ; via some sort of  certification?

Everyone, please  advice.


regards,
Slava  Borilin


________________________________

From: Henry Sinnreich [mailto:hsinnre= i@adobe.com]
Sent: Wednesday, June 17, 2009 1:33 AM
To: Slava Borilin;  Roni Even; codec@ietf.o= rg
Subject: Re:  [codec] Codec BOF approved, much work needed

Hi  Slava,

>Currently in the internet communications (web collaboration,  voip= services, videoconferencing) -
>do you believe is there any force  to push interop, or everyone &q= uot;plays in his own walled garden"?

IMO one  of the main the strengths of the Internet is its global reach= . The user can be  anywhere and reach content from and communicate wit= h anyone, anywhere. Just  like we are doing here with email.
The Internet codec will hopefully do for  voice the same as text commu= nications + attachments work in  email.

>sorry if this is naïve
This applies to my message as well  :-)

Henry

On 6/16/09 3:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
Roni, and  whole international team,

I have one more question here - sorry if this  is naïve- but stil= l please advice.

Background: all of us do wish wish  wish (vendors, customers, end-user= s, etc) to have ONE IWAC (internet wideband  audio codec) for all.

But assuming we (IETF) will come to the agreement  which codec we like= best (existing or new one) and make RFC.
What will then  be the destiny of the that RFC?
And who and why should be choosing the  certain codec into their app?<= BR>
Afaik IETF, like ITU just "agree on the  specs", while indus= try or country-specific organizations are enforcing using  or not usin= g certain standards, like CableLabs (Vertical market +  geography).
The major driver for agreeing on the standard is interop,  as I see. Currently in the internet communications (web collaboration, voip  ser= vices, videoconferencing) - do you believe is there any force to push  = ;interop, or everyone "plays in his own walled garden"?

Should we:
-  agree on RFC and then dig into smaller (geographical or vertical in= dustry)  communities to push them to force using this RFC (IWAC) as pa= rt of  certification to make sure they do enforce the IWAC?
- or we should just  have IWAC RFC and believe "better staff will= find its way to the market  itself"?

regards,
Slava Borilin


-----Original  Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On &= nbsp;Behalf Of Roni Even
Sent: Friday, June 12, 2009 10:56 PM
To: codec@ietf.org
Subject: Re: [codec] Codec BOF  approved, much work needed

Hi,
I would like to suggest other key  topics for the BOF

1. Why should the IETF start a codec WG - why not do  it as ITU / MPEG= /
others

2. Describe the process of defining a  codec in other standard bodies = - my
view is that not everyone knows what is  required to create a quality = codec.

3. Is the purpose of the WG to  publish one codec or multiple codecs b= ased on
different  requirements.

4. If a WG will be formed there are more decision to make  like, what = is the
selection criteria if there is more than one candidate or  do we requi= re some
cooperation, what are the deliverable - source code,  encoder specific= ation
(do we require bit exactness ), how to defines the  quality tests and<= BR> evaluate the results to check if the codec addresses the  requirements= .

Roni Even



-----Original  Message-----
From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On &= nbsp;Behalf Of
Cullen Jennings
Sent: Friday, June 12, 2009 8:32 PM
To: codec@ietf.org
Subject: [codec] Codec BOF  approved, much work needed


I have approved the CODEC BOF proposal.  However, we need a bunch of work to get ready.  Various people on  IESG/IAB were not comforta= ble
with the current charter and agenda so we  need to work on theses
before the meeting.

A draft agenda/charter  Jason provided are at

Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt

Charter:  http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/chart= er.txt

After  discussion with the IESG/IAB:

I'd like to remove the "as Proposed  Standard" from the char= ter text
for both milestones and see how the  discussion goes in the BOF before=
deciding which way this should  go.

I'd like to see more consideration around the issues of designing a
codec that did a good job of mapping a real time stream onto IP
packets. The way IP deals with packet loss and congestion has
implications for designing a codec that works well over IP. I know
some of the discussion I have had off list people talked about how we
wanted a codec that supported adaptive bit rates that could change on
the fly to be able to work well on an IP network.

I will be working  the folks to make sure the agenda has time to
directly address the key  topics which include (more may be coming):
Will we be able to get  qualified people to do and review the work?
Key design goals of a new  codec?

Do we need a new codec or are there already ones defined that  meet th= e
needs?

I have asked Jason Fischl  and Jean-Marc Valin  to co-chair this = BOF.

Thanks,

Cullen <RAI  AD>





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

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




--_000_C65E69B8428Ehsinnreiadobecom_-- From tme@americafree.tv Wed Jun 17 07:42:31 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 48EF83A6C44 for ; Wed, 17 Jun 2009 07:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.271 X-Spam-Level: X-Spam-Status: No, score=-1.271 tagged_above=-999 required=5 tests=[AWL=-1.427, BAYES_00=-2.599, FRT_ADOBE2=2.455, MIME_8BIT_HEADER=0.3] 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 gOh8HhLo7JW4 for ; Wed, 17 Jun 2009 07:42:30 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id ADE773A6A7A for ; Wed, 17 Jun 2009 07:42:29 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 05EA84090389; Wed, 17 Jun 2009 10:41:44 -0400 (EDT) Message-Id: From: Marshall Eubanks To: Henry Sinnreich 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 v935.3) Date: Wed, 17 Jun 2009 10:41:43 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: Roni Even , Slava Borilin , "codec@ietf.org" Subject: Re: [codec] =?iso-8859-1?q?RE=A0=3A__Codec_BOF_approved=2C_much_work_?= =?iso-8859-1?q?needed?= 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, 17 Jun 2009 14:42:31 -0000 On Jun 17, 2009, at 10:36 AM, Henry Sinnreich wrote: > Supporting music is a good point in case, given the emergence of =20 > Telepresence and the Digital Living room. > > As for supporting bandwidth constrained links, where congestion can =20= > occur, I believe the mobile phone industry has already done a good =20 > job that we need not duplicate. > > Given the choice between designing for narrowband links and =20 > broadband Internet, let=92s chose therefore broadband. > I would agree. I work in Telepresence, by the way, and there is =20 interest there in good quality, high bit rate, audio codec with low =20 latency and support for surround sound. Saving bandwidth is not the =20 issue there. Regards Marshall > Henry > > On 6/16/09 9:41 PM, "Jean-Marc Valin" =20= > wrote: > > For wideband (16 kHz sampling), I think speech-only (ideally without =20= > mutilating background music) is sufficient. However, for super =20 > wideband (32 kHz and up), I think it's important to start supporting =20= > music. When it comes to latency (by that I mean the codec's =20 > algorithmic delay), the lower the better. I consider anything above =20= > ~40 ms to be unacceptable (ruling out Vorbis, MP3 and standard AAC), =20= > but it should ideally be lower than that. The lower the delay, the =20 > less problems you have with acoustic echo. > > Jean-Marc > > -------- Message d'origine-------- > De: codec-bounces@ietf.org de la part de Henry Sinnreich > Date: mar. 16/06/2009 18:31 > =C0: Sandy (Alexander) MacInnis; codec@ietf.org; Slava Borilin; Roni =20= > Even > Objet : Re: [codec] Codec BOF approved, much work needed > > >Are we talking here about speech, or generic audio? > > As Slava has pointed out it is about wideband speech, that is the =20 > low latency (150ms or so) still applies, but having wideband audio =20 > (8-16 kHz audio BW) and why not, stereo. All this and many other =20 > however is to be worked out in the proposed Internet Codec WG. > > Henry > > > On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis" = > wrote: > > Are we talking here about speech, or generic audio? > > There's a difference in terms of coding (bit rate, quality, etc.) =20 > and in terms of applicability. > > Or do we want both, i.e. two codecs? > > --Sandy > > > ________________________________ > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 > Behalf Of Henry Sinnreich > Sent: Tuesday, June 16, 2009 6:15 PM > To: Slava Borilin; Roni Even; codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > Dear Slava, > > >We are talking not about "enabling technology" to make everyone =20 > understand each other (email case), > >but "enhancement" - everyone can today understand each other via =20 > 711 or 722, but we want to push the quality bar while keeping the =20 > interop. > > This is an excellent point. We are talking about the Internet here =20 > in in the IETF. > > Henry > > > On 6/16/09 4:56 PM, "Slava Borilin" wrote: > > Dear Henry, > > It is probably not the same as with email (or maybe just timing is =20= > different). > We are talking not about "enabling technology" to make everyone =20 > understand each other (email case), but "enhancement" - everyone =20 > can today understand each other via 711 or 722, but we want to push =20= > the quality bar while keeping the interop. > > So really the magic question is that once we have the agreement on =20= > "recommended" IWAC- either one or several (agree with Jean-Marc), =20 > who is to enforce? > PROBABLY the force to enforce are telecom operators? > As telco, against internet companies (Cisco, Skype, MSFT, etc), do =20= > not like walled gardens by definition: > - The telco landscape is not (well, not only) Skype/cheap IP calls =20= > versus Cellular or Wireline. > - The mid-term battle is between internet and its rich =20 > communication techniques (web conferencing, social networking) and =20= > telco's phone-only service. > - Battle is not only for call $$, but for the time spent on the =20 > media (trend is users spending more minutes on internet comms then =20 > on phones) > - so carriers have to move from NGN core networks to offer IP-=20 > based "social network-like" communication models to subscribers, =20 > therefore, have IP-service at the last mile for the user, and not =20 > only for enterprise IP-phones, but every consumer. > - And as Telco need subscribers to pay for the service, here comes =20= > the HD(=3Dwideband + packet loss robustness), as the necessary step =20= > to keep user satisfied with the carrier IP-service. > - So actually, HD sounds to be the cornerstone for keeping the =20 > landscape of whole Telco industry versus Internet communications =20 > (or vice versa). > - so for telcos it will be really important to have IWAC RFC and =20 > telcos have the power to enforce using it (via geo or industry =20 > forums - examples are PAL/NTSC in geo, industry - CableLabs), and =20 > they are used to the standard/certification process? > > Again, apart from the ambitions, what all of us (as vendors and as =20= > users) would like to achieve, is interop. > And interop should, probably, be enforced, not "recommended" via =20 > some sort of certification? > > Everyone, please advice. > > > regards, > Slava Borilin > > > ________________________________ > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Wednesday, June 17, 2009 1:33 AM > To: Slava Borilin; Roni Even; codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > Hi Slava, > > >Currently in the internet communications (web collaboration, voip =20= > services, videoconferencing) - > >do you believe is there any force to push interop, or everyone =20 > "plays in his own walled garden"? > > IMO one of the main the strengths of the Internet is its global =20 > reach. The user can be anywhere and reach content from and =20 > communicate with anyone, anywhere. Just like we are doing here with =20= > email. > The Internet codec will hopefully do for voice the same as text =20 > communications + attachments work in email. > > >sorry if this is na=EFve > This applies to my message as well :-) > > Henry > > On 6/16/09 3:56 PM, "Slava Borilin" wrote: > Roni, and whole international team, > > I have one more question here - sorry if this is na=EFve- but still =20= > please advice. > > Background: all of us do wish wish wish (vendors, customers, end-=20 > users, etc) to have ONE IWAC (internet wideband audio codec) for all. > > But assuming we (IETF) will come to the agreement which codec we =20 > like best (existing or new one) and make RFC. > What will then be the destiny of the that RFC? > And who and why should be choosing the certain codec into their app? > > Afaik IETF, like ITU just "agree on the specs", while industry or =20 > country-specific organizations are enforcing using or not using =20 > certain standards, like CableLabs (Vertical market + geography). > > The major driver for agreeing on the standard is interop, as I see. > Currently in the internet communications (web collaboration, voip =20 > services, videoconferencing) - do you believe is there any force to =20= > push interop, or everyone "plays in his own walled garden"? > > Should we: > - agree on RFC and then dig into smaller (geographical or vertical =20= > industry) communities to push them to force using this RFC (IWAC) =20 > as part of certification to make sure they do enforce the IWAC? > - or we should just have IWAC RFC and believe "better staff will =20 > find its way to the market itself"? > > regards, > Slava Borilin > > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 > Behalf Of Roni Even > Sent: Friday, June 12, 2009 10:56 PM > To: codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > Hi, > I would like to suggest other key topics for the BOF > > 1. Why should the IETF start a codec WG - why not do it as ITU / =20 > MPEG / > others > > 2. Describe the process of defining a codec in other standard =20 > bodies - my > view is that not everyone knows what is required to create a =20 > quality codec. > > 3. Is the purpose of the WG to publish one codec or multiple codecs =20= > based on > different requirements. > > 4. If a WG will be formed there are more decision to make like, =20 > what is the > selection criteria if there is more than one candidate or do we =20 > require some > cooperation, what are the deliverable - source code, encoder =20 > specification > (do we require bit exactness ), how to defines the quality tests and > evaluate the results to check if the codec addresses the =20 > requirements. > > Roni Even > > > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 > Behalf Of > Cullen Jennings > Sent: Friday, June 12, 2009 8:32 PM > To: codec@ietf.org > Subject: [codec] Codec BOF approved, much work needed > > > I have approved the CODEC BOF proposal. However, we need a bunch of > work to get ready. Various people on IESG/IAB were not comfortable > with the current charter and agenda so we need to work on theses > before the meeting. > > A draft agenda/charter Jason provided are at > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/=20 > agenda.txt > > Charter: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt > > After discussion with the IESG/IAB: > > I'd like to remove the "as Proposed Standard" from the charter text > for both milestones and see how the discussion goes in the BOF before > deciding which way this should go. > > I'd like to see more consideration around the issues of designing a > codec that did a good job of mapping a real time stream onto IP > packets. The way IP deals with packet loss and congestion has > implications for designing a codec that works well over IP. I know > some of the discussion I have had off list people talked about how we > wanted a codec that supported adaptive bit rates that could change on > the fly to be able to work well on an IP network. > > I will be working the folks to make sure the agenda has time to > directly address the key topics which include (more may be coming): > > Will we be able to get qualified people to do and review the work? > > Key design goals of a new codec? > > Do we need a new codec or are there already ones defined that meet =20= > the > needs? > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. > > Thanks, > > Cullen > > > > > > _______________________________________________ > 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 > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From singer@apple.com Wed Jun 17 10:44: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 D14B128C170 for ; Wed, 17 Jun 2009 10:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.999 X-Spam-Level: X-Spam-Status: No, score=-106.999 tagged_above=-999 required=5 tests=[AWL=-0.400, 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 zZwVL+N8JV6J for ; Wed, 17 Jun 2009 10:44:45 -0700 (PDT) Received: from mail-out3.apple.com (mail-out3.apple.com [17.254.13.22]) by core3.amsl.com (Postfix) with ESMTP id 3FCD128C141 for ; Wed, 17 Jun 2009 10:44:45 -0700 (PDT) Received: from relay13.apple.com (relay13.apple.com [17.128.113.29]) by mail-out3.apple.com (Postfix) with ESMTP id 2FDCB65A455B; Wed, 17 Jun 2009 10:44:17 -0700 (PDT) Received: from relay13.apple.com (unknown [127.0.0.1]) by relay13.apple.com (Symantec Brightmail Gateway) with ESMTP id 0AF192808C; Wed, 17 Jun 2009 10:44:17 -0700 (PDT) X-AuditID: 1180711d-aa604bb000005f4f-cd-4a392b70cc81 Received: from [17.202.35.52] (singda.apple.com [17.202.35.52]) by relay13.apple.com (Apple SCV relay) with ESMTP id B312C28081; Wed, 17 Jun 2009 10:44:16 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 17 Jun 2009 10:41:06 -0700 To: Marshall Eubanks , Henry Sinnreich From: David Singer Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Brightmail-Tracker: AAAAAA== Cc: Slava Borilin , "codec@ietf.org" , Roni Even Subject: Re: [codec] "RE : Codec BOF approved, much work " needed 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, 17 Jun 2009 17:44:45 -0000 note that combined speech and audio at moderately low bit-rates is fairly cutting edge. The 3GPP experiments with AMR wideband plus, and HE-AACv2, were good, a few years ago, and MPEG has unified speech and audio coding under way (with very encouraging early results). -- David Singer Multimedia Standards, Apple Inc. From tme@americafree.tv Wed Jun 17 10:47: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 47D1A3A6E7A for ; Wed, 17 Jun 2009 10:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[AWL=-0.020, 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 jan+68qo5Ytk for ; Wed, 17 Jun 2009 10:47:23 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 779013A6E2F for ; Wed, 17 Jun 2009 10:47:23 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 703D94094B05; Wed, 17 Jun 2009 13:47:23 -0400 (EDT) Message-Id: <45D0609D-5442-49A1-92EF-A9C77C6EA1C4@americafree.tv> From: Marshall Eubanks To: David Singer In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 13:47:19 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: Slava Borilin , "codec@ietf.org" , Roni Even Subject: Re: [codec] "RE : Codec BOF approved, much work " needed 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, 17 Jun 2009 17:47:24 -0000 Note also that MP3 can't do this, not with low latency. Marshall On Jun 17, 2009, at 1:41 PM, David Singer wrote: > note that combined speech and audio at moderately low bit-rates is > fairly cutting edge. The 3GPP experiments with AMR wideband plus, > and HE-AACv2, were good, a few years ago, and MPEG has unified > speech and audio coding under way (with very encouraging early > results). > -- > David Singer > Multimedia Standards, Apple Inc. > From Borilin@spiritdsp.com Wed Jun 17 10:49: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 249FC3A6E9B for ; Wed, 17 Jun 2009 10:49:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.589 X-Spam-Level: X-Spam-Status: No, score=-1.589 tagged_above=-999 required=5 tests=[AWL=0.410, BAYES_00=-2.599, J_CHICKENPOX_65=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 T9znutclblKs for ; Wed, 17 Jun 2009 10:49:11 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 64EE628C141 for ; Wed, 17 Jun 2009 10:49:05 -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 n5HHmpXh065464; Wed, 17 Jun 2009 21:48:52 +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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 21:48:45 +0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] "RE : Codec BOF approved, much work " needed Thread-Index: Acnvc0K6ZnJoFumpS7G4gddEeBf6LQAAHwvw References: From: "Slava Borilin" To: "David Singer" , "Marshall Eubanks" , "Henry Sinnreich" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org, Roni Even Subject: Re: [codec] "RE : Codec BOF approved, much work " needed 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, 17 Jun 2009 17:49:12 -0000 We at SPIRIT have done the design of mixed speech+audio codec 5years ago. regards, Slava Borilin =20 -----Original Message----- From: David Singer [mailto:singer@apple.com]=20 Sent: Wednesday, June 17, 2009 9:41 PM To: Marshall Eubanks; Henry Sinnreich Cc: Roni Even; Slava Borilin; codec@ietf.org Subject: Re: [codec] "RE : Codec BOF approved, much work " needed note that combined speech and audio at moderately low bit-rates is=20 fairly cutting edge. The 3GPP experiments with AMR wideband plus,=20 and HE-AACv2, were good, a few years ago, and MPEG has unified speech=20 and audio coding under way (with very encouraging early results). --=20 David Singer Multimedia Standards, Apple Inc. From jean-marc.valin@octasic.com Wed Jun 17 11:09: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 3262E28C205 for ; Wed, 17 Jun 2009 11:09:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.108 X-Spam-Level: X-Spam-Status: No, score=-2.108 tagged_above=-999 required=5 tests=[AWL=0.491, 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 Yz9M0d4fEd4n for ; Wed, 17 Jun 2009 11:09:08 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [216.208.79.2]) by core3.amsl.com (Postfix) with ESMTP id B176428C173 for ; Wed, 17 Jun 2009 11:08:53 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 14:09:03 -0400 Message-ID: <4A393144.5080809@octasic.com> Date: Wed, 17 Jun 2009 14:09:08 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: David Singer References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jun 2009 18:09:03.0907 (UTC) FILETIME=[B2A46F30:01C9EF76] Cc: Slava Borilin , "codec@ietf.org" , Roni Even Subject: Re: [codec] "RE : Codec BOF approved, much work " needed 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, 17 Jun 2009 18:09:09 -0000 David Singer wrote: > note that combined speech and audio at moderately low bit-rates is > fairly cutting edge. The 3GPP experiments with AMR wideband plus, and > HE-AACv2, were good, a few years ago, and MPEG has unified speech and > audio coding under way (with very encouraging early results). I don't think we want something like AMR-WB+ or HE-AAC. As far as I know, AMR-WB+ has around 100 ms delay and HE-AACv2 is probably similar. As far as I know, these codecs are mostly designed for streaming music on mobile networks, rather than bi-directional communication. I think it's worth increasing the bit-rate to have (much!) lower delay, and possibly higher quality too. After all, bandwidth on the Internet isn't as expensive as it is on 3G wireless networks. I would tend to target a range of bitrates that are appropriate for a low- to medium-range ADSL connection. Jean-Marc From Borilin@spiritdsp.com Wed Jun 17 11:22: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 4C6AC28B56A for ; Wed, 17 Jun 2009 11:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.621 X-Spam-Level: X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5 tests=[AWL=0.378, BAYES_00=-2.599, J_CHICKENPOX_65=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 2SOooImVXGGf for ; Wed, 17 Jun 2009 11:22:04 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 4E2603A6EAA for ; Wed, 17 Jun 2009 11:22:02 -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 n5HIM2JM066108; Wed, 17 Jun 2009 22:22:03 +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: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 22:21:55 +0400 Message-ID: In-Reply-To: <4A393144.5080809@octasic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] "RE : Codec BOF approved, much work " needed Thread-Index: AcnvdrgSMRl4vWgzTFaaxsLcJDZifQAAPTfg References: <4A393144.5080809@octasic.com> From: "Slava Borilin" To: "Jean-Marc Valin" , "David Singer" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org, Roni Even Subject: Re: [codec] "RE : Codec BOF approved, much work " needed 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, 17 Jun 2009 18:22:05 -0000 Right. 100ms is too much.=20 SPIRIT's mentioned combined speech+audio codec have 25ms delay. regards, Slava Borilin =20 -----Original Message----- From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com]=20 Sent: Wednesday, June 17, 2009 10:09 PM To: David Singer Cc: Marshall Eubanks; Henry Sinnreich; Slava Borilin; codec@ietf.org; Roni Even Subject: Re: [codec] "RE : Codec BOF approved, much work " needed David Singer wrote: > note that combined speech and audio at moderately low bit-rates is=20 > fairly cutting edge. The 3GPP experiments with AMR wideband plus, and > HE-AACv2, were good, a few years ago, and MPEG has unified speech and=20 > audio coding under way (with very encouraging early results). I don't think we want something like AMR-WB+ or HE-AAC. As far as I=20 know, AMR-WB+ has around 100 ms delay and HE-AACv2 is probably similar.=20 As far as I know, these codecs are mostly designed for streaming music=20 on mobile networks, rather than bi-directional communication. I think=20 it's worth increasing the bit-rate to have (much!) lower delay, and=20 possibly higher quality too. After all, bandwidth on the Internet isn't=20 as expensive as it is on 3G wireless networks. I would tend to target a=20 range of bitrates that are appropriate for a low- to medium-range ADSL=20 connection. Jean-Marc From koen.vos@skype.net Wed Jun 17 16:21:51 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 620993A6A95 for ; Wed, 17 Jun 2009 16:21:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.561 X-Spam-Level: X-Spam-Status: No, score=-3.561 tagged_above=-999 required=5 tests=[AWL=-1.113, BAYES_00=-2.599, FRT_ADOBE2=2.455, MIME_8BIT_HEADER=0.3, 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 bLzzdEvcR+jJ for ; Wed, 17 Jun 2009 16:21:49 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 55CE43A6A53 for ; Wed, 17 Jun 2009 16:21:49 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 83E3B2007AB07 for ; Thu, 18 Jun 2009 01:22:00 +0200 (CEST) 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=t3tSL0B0BpCT W4kGU4ijcnkgCX4=; b=lA2IjNBL7TlTrZ9fbMkJMlTl8q05WmKKSzMKnSPFBFlh 9qMxSqbnHyT01AolBJxbw1jf1R3NacCrTUBGBL6iDPZfVrtwy+g5XMSDOQLbdmfB 4OOIdl0/TcN9bCIbAc4+xmbtLKEMAkB1na2WUJplngNabwuI9wiNhdtn1XGPl4o= 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=tmx/foMfrUAYByF3LZJ6 WmrpjLn5WvnH4HZOMAvWVoL11MQ3+6ydsvISglLY7rLUCVKVDIDF41wzC6EgCT4T zMclleJjUtdS0lhy6uoFDvmqiuA1iCB5yJ+UShC2Jdew/c646IyNPNAOPQjgZBqt DbXSZIStOilOYeBV4fV/x3g= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 823502007A79A for ; Thu, 18 Jun 2009 01:22:00 +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 tIkZrq4xukqO for ; Thu, 18 Jun 2009 01:21:50 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 004452007AAC5; Thu, 18 Jun 2009 01:21:49 +0200 (CEST) Received: from adsl-71-141-96-214.dsl.snfc21.pacbell.net (adsl-71-141-96-214.dsl.snfc21.pacbell.net [71.141.96.214]) by mail.skype.net (Horde Framework) with HTTP; Wed, 17 Jun 2009 16:21:49 -0700 Message-ID: <20090617162149.17607bikalc6h219@mail.skype.net> Date: Wed, 17 Jun 2009 16:21:49 -0700 From: Koen Vos To: codec@ietf.org References: 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] =?iso-8859-1?q?RE=A0=3A_Codec_BOF_approved=2C_much_work_n?= =?iso-8859-1?q?eeded?= 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, 17 Jun 2009 23:21:51 -0000 Quoting Henry Sinnreich: > As for supporting bandwidth constrained links, where congestion can =20 > occur, I believe the mobile phone industry has already done a good =20 > job that we need not duplicate. Mobile phones use codecs that are expensive and complex to license though. And audio quality on mobile phones is mediocre or worse. koen. > Given the choice between designing for narrowband links and =20 > broadband Internet, let's chose therefore broadband. > > Henry > > On 6/16/09 9:41 PM, "Jean-Marc Valin" wrote: > > For wideband (16 kHz sampling), I think speech-only (ideally without =20 > mutilating background music) is sufficient. However, for super =20 > wideband (32 kHz and up), I think it's important to start supporting =20 > music. When it comes to latency (by that I mean the codec's =20 > algorithmic delay), the lower the better. I consider anything above =20 > ~40 ms to be unacceptable (ruling out Vorbis, MP3 and standard AAC), =20 > but it should ideally be lower than that. The lower the delay, the =20 > less problems you have with acoustic echo. > > Jean-Marc > > -------- Message d'origine-------- > De: codec-bounces@ietf.org de la part de Henry Sinnreich > Date: mar. 16/06/2009 18:31 > =C0: Sandy (Alexander) MacInnis; codec@ietf.org; Slava Borilin; Roni Even > Objet : Re: [codec] Codec BOF approved, much work needed > >> Are we talking here about speech, or generic audio? > > As Slava has pointed out it is about wideband speech, that is the =20 > low latency (150ms or so) still applies, but having wideband audio =20 > (8-16 kHz audio BW) and why not, stereo. All this and many other =20 > however is to be worked out in the proposed Internet Codec WG. > > Henry > > > On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis" =20 > wrote: > > Are we talking here about speech, or generic audio? > > There's a difference in terms of coding (bit rate, quality, etc.) =20 > and in terms of applicability. > > Or do we want both, i.e. two codecs? > > --Sandy > > > ________________________________ > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 > Behalf Of Henry Sinnreich > Sent: Tuesday, June 16, 2009 6:15 PM > To: Slava Borilin; Roni Even; codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > Dear Slava, > >> We are talking not about "enabling technology" to make everyone =20 >> understand each other (email case), >> but "enhancement" - everyone can today understand each other via =20 >> 711 or 722, but we want to push the quality bar while keeping the =20 >> interop. > > This is an excellent point. We are talking about the Internet here =20 > in in the IETF. > > Henry > > > On 6/16/09 4:56 PM, "Slava Borilin" wrote: > > Dear Henry, > > It is probably not the same as with email (or maybe just timing is =20 > different). > We are talking not about "enabling technology" to make everyone =20 > understand each other (email case), but "enhancement" - everyone =20 > can today understand each other via 711 or 722, but we want to push =20 > the quality bar while keeping the interop. > > So really the magic question is that once we have the agreement on =20 > "recommended" IWAC- either one or several (agree with Jean-Marc), =20 > who is to enforce? > PROBABLY the force to enforce are telecom operators? > As telco, against internet companies (Cisco, Skype, MSFT, etc), do =20 > not like walled gardens by definition: > - The telco landscape is not (well, not only) Skype/cheap IP calls =20 > versus Cellular or Wireline. > - The mid-term battle is between internet and its rich =20 > communication techniques (web conferencing, social networking) and =20 > telco's phone-only service. > - Battle is not only for call $$, but for the time spent on the =20 > media (trend is users spending more minutes on internet comms then =20 > on phones) > - so carriers have to move from NGN core networks to offer =20 > IP-based "social network-like" communication models to subscribers, =20 > therefore, have IP-service at the last mile for the user, and not =20 > only for enterprise IP-phones, but every consumer. > - And as Telco need subscribers to pay for the service, here comes =20 > the HD(=3Dwideband + packet loss robustness), as the necessary step =20 > to keep user satisfied with the carrier IP-service. > - So actually, HD sounds to be the cornerstone for keeping the =20 > landscape of whole Telco industry versus Internet communications =20 > (or vice versa). > - so for telcos it will be really important to have IWAC RFC and =20 > telcos have the power to enforce using it (via geo or industry =20 > forums - examples are PAL/NTSC in geo, industry - CableLabs), and =20 > they are used to the standard/certification process? > > Again, apart from the ambitions, what all of us (as vendors and as =20 > users) would like to achieve, is interop. > And interop should, probably, be enforced, not "recommended" via =20 > some sort of certification? > > Everyone, please advice. > > > regards, > Slava Borilin > > > ________________________________ > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Wednesday, June 17, 2009 1:33 AM > To: Slava Borilin; Roni Even; codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > Hi Slava, > >> Currently in the internet communications (web collaboration, voip =20 >> services, videoconferencing) - >> do you believe is there any force to push interop, or everyone =20 >> "plays in his own walled garden"? > > IMO one of the main the strengths of the Internet is its global =20 > reach. The user can be anywhere and reach content from and =20 > communicate with anyone, anywhere. Just like we are doing here with =20 > email. > The Internet codec will hopefully do for voice the same as text =20 > communications + attachments work in email. > >> sorry if this is na=EFve > This applies to my message as well :-) > > Henry > > On 6/16/09 3:56 PM, "Slava Borilin" wrote: > Roni, and whole international team, > > I have one more question here - sorry if this is na=EFve- but still =20 > please advice. > > Background: all of us do wish wish wish (vendors, customers, =20 > end-users, etc) to have ONE IWAC (internet wideband audio codec) =20 > for all. > > But assuming we (IETF) will come to the agreement which codec we =20 > like best (existing or new one) and make RFC. > What will then be the destiny of the that RFC? > And who and why should be choosing the certain codec into their app? > > Afaik IETF, like ITU just "agree on the specs", while industry or =20 > country-specific organizations are enforcing using or not using =20 > certain standards, like CableLabs (Vertical market + geography). > > The major driver for agreeing on the standard is interop, as I see. > Currently in the internet communications (web collaboration, voip =20 > services, videoconferencing) - do you believe is there any force to =20 > push interop, or everyone "plays in his own walled garden"? > > Should we: > - agree on RFC and then dig into smaller (geographical or vertical =20 > industry) communities to push them to force using this RFC (IWAC) =20 > as part of certification to make sure they do enforce the IWAC? > - or we should just have IWAC RFC and believe "better staff will =20 > find its way to the market itself"? > > regards, > Slava Borilin > > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 > Behalf Of Roni Even > Sent: Friday, June 12, 2009 10:56 PM > To: codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > Hi, > I would like to suggest other key topics for the BOF > > 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / > others > > 2. Describe the process of defining a codec in other standard bodies - my > view is that not everyone knows what is required to create a quality code= c. > > 3. Is the purpose of the WG to publish one codec or multiple codecs based= on > different requirements. > > 4. If a WG will be formed there are more decision to make like, what is t= he > selection criteria if there is more than one candidate or do we require s= ome > cooperation, what are the deliverable - source code, encoder specificatio= n > (do we require bit exactness ), how to defines the quality tests and > evaluate the results to check if the codec addresses the requirements. > > Roni Even > > > > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > Cullen Jennings > Sent: Friday, June 12, 2009 8:32 PM > To: codec@ietf.org > Subject: [codec] Codec BOF approved, much work needed > > > I have approved the CODEC BOF proposal. However, we need a bunch of > work to get ready. Various people on IESG/IAB were not comfortable > with the current charter and agenda so we need to work on theses > before the meeting. > > A draft agenda/charter Jason provided are at > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt > > After discussion with the IESG/IAB: > > I'd like to remove the "as Proposed Standard" from the charter text > for both milestones and see how the discussion goes in the BOF before > deciding which way this should go. > > I'd like to see more consideration around the issues of designing a > codec that did a good job of mapping a real time stream onto IP > packets. The way IP deals with packet loss and congestion has > implications for designing a codec that works well over IP. I know > some of the discussion I have had off list people talked about how we > wanted a codec that supported adaptive bit rates that could change on > the fly to be able to work well on an IP network. > > I will be working the folks to make sure the agenda has time to > directly address the key topics which include (more may be coming): > > Will we be able to get qualified people to do and review the work? > > Key design goals of a new codec? > > Do we need a new codec or are there already ones defined that meet the > needs? > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. > > Thanks, > > Cullen > > > > > > _______________________________________________ > 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 Thu Jun 18 01:33:57 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 9FD3128C0F2 for ; Thu, 18 Jun 2009 01:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.484 X-Spam-Level: X-Spam-Status: No, score=-3.484 tagged_above=-999 required=5 tests=[AWL=-1.538, BAYES_00=-2.599, FRT_ADOBE2=2.455, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] 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 N4L3XTIoXl2U for ; Thu, 18 Jun 2009 01:33:56 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id A31ED3A6973 for ; Thu, 18 Jun 2009 01:33:55 -0700 (PDT) Received: from wm01.uni-tuebingen.de (wm01.uni-tuebingen.de [134.2.3.20]) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n5I8Y5eu015302; Thu, 18 Jun 2009 10:34:05 +0200 Received: by wm01.uni-tuebingen.de (Postfix, from userid 30) id 0AD487241DD; Thu, 18 Jun 2009 10:34:05 +0200 (CEST) Received: from isc-router6.urz.tu-dresden.de (isc-router6.urz.tu-dresden.de [141.30.3.115]) by webmail.uni-tuebingen.de (Horde Framework) with HTTP; Thu, 18 Jun 2009 10:34:04 +0200 Message-ID: <20090618103404.20747hsmkwbyohdo@webmail.uni-tuebingen.de> Date: Thu, 18 Jun 2009 10:34:04 +0200 From: "Dr. Christian Hoene" To: Koen Vos References: <20090617162149.17607bikalc6h219@mail.skype.net> In-Reply-To: <20090617162149.17607bikalc6h219@mail.skype.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) 4.3.3 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.0.191; VDF: 7.1.4.108; host: mx05); id=14547-9yGobi Cc: codec@ietf.org Subject: Re: [codec] =?utf-8?q?RE=C2=A0=3A_Codec_BOF_approved=2C_much_work_nee?= =?utf-8?q?ded?= 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, 18 Jun 2009 08:33:57 -0000 In order to support a high degree of reliability and available, I =20 think the audio codec should support an acceptable operation mode even =20 if the bandwidth is low. If the ultra low delay music transmission is =20 not possible, the codec shall degrade to 25ms delayed music =20 transmission and further degrade to speech quality. Jean-Marc: What is the coding rate of CELT, if it shall transmit voice =20 at a quality of about MOS 3.5? > Quoting Henry Sinnreich: >> As for supporting bandwidth constrained links, where congestion can =20 >> occur, I believe the mobile phone industry has already done a good =20 >> job that we need not duplicate. > > Mobile phones use codecs that are expensive and complex to license though. > And audio quality on mobile phones is mediocre or worse. > > koen. > > > >> Given the choice between designing for narrowband links and =20 >> broadband Internet, let's chose therefore broadband. >> >> Henry >> >> On 6/16/09 9:41 PM, "Jean-Marc Valin" wrote= : >> >> For wideband (16 kHz sampling), I think speech-only (ideally =20 >> without mutilating background music) is sufficient. However, for =20 >> super wideband (32 kHz and up), I think it's important to start =20 >> supporting music. When it comes to latency (by that I mean the =20 >> codec's algorithmic delay), the lower the better. I consider =20 >> anything above ~40 ms to be unacceptable (ruling out Vorbis, MP3 =20 >> and standard AAC), but it should ideally be lower than that. The =20 >> lower the delay, the less problems you have with acoustic echo. >> >> Jean-Marc >> >> -------- Message d'origine-------- >> De: codec-bounces@ietf.org de la part de Henry Sinnreich >> Date: mar. 16/06/2009 18:31 >> =C3=80: Sandy (Alexander) MacInnis; codec@ietf.org; Slava Borilin; Roni E= ven >> Objet : Re: [codec] Codec BOF approved, much work needed >> >>> Are we talking here about speech, or generic audio? >> >> As Slava has pointed out it is about wideband speech, that is the =20 >> low latency (150ms or so) still applies, but having wideband audio =20 >> (8-16 kHz audio BW) and why not, stereo. All this and many other =20 >> however is to be worked out in the proposed Internet Codec WG. >> >> Henry >> >> >> On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis" =20 >> wrote: >> >> Are we talking here about speech, or generic audio? >> >> There's a difference in terms of coding (bit rate, quality, etc.) =20 >> and in terms of applicability. >> >> Or do we want both, i.e. two codecs? >> >> --Sandy >> >> >> ________________________________ >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 >> Behalf Of Henry Sinnreich >> Sent: Tuesday, June 16, 2009 6:15 PM >> To: Slava Borilin; Roni Even; codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Dear Slava, >> >>> We are talking not about "enabling technology" to make everyone =20 >>> understand each other (email case), >>> but "enhancement" - everyone can today understand each other via =20 >>> 711 or 722, but we want to push the quality bar while keeping the =20 >>> interop. >> >> This is an excellent point. We are talking about the Internet here =20 >> in in the IETF. >> >> Henry >> >> >> On 6/16/09 4:56 PM, "Slava Borilin" wrote: >> >> Dear Henry, >> >> It is probably not the same as with email (or maybe just timing is =20 >> different). >> We are talking not about "enabling technology" to make everyone =20 >> understand each other (email case), but "enhancement" - everyone =20 >> can today understand each other via 711 or 722, but we want to =20 >> push the quality bar while keeping the interop. >> >> So really the magic question is that once we have the agreement on =20 >> "recommended" IWAC- either one or several (agree with Jean-Marc), =20 >> who is to enforce? >> PROBABLY the force to enforce are telecom operators? >> As telco, against internet companies (Cisco, Skype, MSFT, etc), do =20 >> not like walled gardens by definition: >> - The telco landscape is not (well, not only) Skype/cheap IP calls =20 >> versus Cellular or Wireline. >> - The mid-term battle is between internet and its rich =20 >> communication techniques (web conferencing, social networking) and =20 >> telco's phone-only service. >> - Battle is not only for call $$, but for the time spent on the =20 >> media (trend is users spending more minutes on internet comms then =20 >> on phones) >> - so carriers have to move from NGN core networks to offer =20 >> IP-based "social network-like" communication models to subscribers, =20 >> therefore, have IP-service at the last mile for the user, and not =20 >> only for enterprise IP-phones, but every consumer. >> - And as Telco need subscribers to pay for the service, here comes =20 >> the HD(=3Dwideband + packet loss robustness), as the necessary step =20 >> to keep user satisfied with the carrier IP-service. >> - So actually, HD sounds to be the cornerstone for keeping the =20 >> landscape of whole Telco industry versus Internet communications =20 >> (or vice versa). >> - so for telcos it will be really important to have IWAC RFC and =20 >> telcos have the power to enforce using it (via geo or industry =20 >> forums - examples are PAL/NTSC in geo, industry - CableLabs), and =20 >> they are used to the standard/certification process? >> >> Again, apart from the ambitions, what all of us (as vendors and as =20 >> users) would like to achieve, is interop. >> And interop should, probably, be enforced, not "recommended" via =20 >> some sort of certification? >> >> Everyone, please advice. >> >> >> regards, >> Slava Borilin >> >> >> ________________________________ >> >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Sent: Wednesday, June 17, 2009 1:33 AM >> To: Slava Borilin; Roni Even; codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Hi Slava, >> >>> Currently in the internet communications (web collaboration, voip =20 >>> services, videoconferencing) - >>> do you believe is there any force to push interop, or everyone =20 >>> "plays in his own walled garden"? >> >> IMO one of the main the strengths of the Internet is its global =20 >> reach. The user can be anywhere and reach content from and =20 >> communicate with anyone, anywhere. Just like we are doing here =20 >> with email. >> The Internet codec will hopefully do for voice the same as text =20 >> communications + attachments work in email. >> >>> sorry if this is na=C3=AFve >> This applies to my message as well :-) >> >> Henry >> >> On 6/16/09 3:56 PM, "Slava Borilin" wrote: >> Roni, and whole international team, >> >> I have one more question here - sorry if this is na=C3=AFve- but still = =20 >> please advice. >> >> Background: all of us do wish wish wish (vendors, customers, =20 >> end-users, etc) to have ONE IWAC (internet wideband audio codec) =20 >> for all. >> >> But assuming we (IETF) will come to the agreement which codec we =20 >> like best (existing or new one) and make RFC. >> What will then be the destiny of the that RFC? >> And who and why should be choosing the certain codec into their app? >> >> Afaik IETF, like ITU just "agree on the specs", while industry or =20 >> country-specific organizations are enforcing using or not using =20 >> certain standards, like CableLabs (Vertical market + geography). >> >> The major driver for agreeing on the standard is interop, as I see. >> Currently in the internet communications (web collaboration, voip =20 >> services, videoconferencing) - do you believe is there any force to =20 >> push interop, or everyone "plays in his own walled garden"? >> >> Should we: >> - agree on RFC and then dig into smaller (geographical or vertical =20 >> industry) communities to push them to force using this RFC (IWAC) =20 >> as part of certification to make sure they do enforce the IWAC? >> - or we should just have IWAC RFC and believe "better staff will =20 >> find its way to the market itself"? >> >> regards, >> Slava Borilin >> >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 >> Behalf Of Roni Even >> Sent: Friday, June 12, 2009 10:56 PM >> To: codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Hi, >> I would like to suggest other key topics for the BOF >> >> 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / >> others >> >> 2. Describe the process of defining a codec in other standard bodies - m= y >> view is that not everyone knows what is required to create a quality cod= ec. >> >> 3. Is the purpose of the WG to publish one codec or multiple =20 >> codecs based on >> different requirements. >> >> 4. If a WG will be formed there are more decision to make like, what is = the >> selection criteria if there is more than one candidate or do we =20 >> require some >> cooperation, what are the deliverable - source code, encoder specificati= on >> (do we require bit exactness ), how to defines the quality tests and >> evaluate the results to check if the codec addresses the requirements. >> >> Roni Even >> >> >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf O= f >> Cullen Jennings >> Sent: Friday, June 12, 2009 8:32 PM >> To: codec@ietf.org >> Subject: [codec] Codec BOF approved, much work needed >> >> >> I have approved the CODEC BOF proposal. However, we need a bunch of >> work to get ready. Various people on IESG/IAB were not comfortable >> with the current charter and agenda so we need to work on theses >> before the meeting. >> >> A draft agenda/charter Jason provided are at >> >> Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt >> >> Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.tx= t >> >> After discussion with the IESG/IAB: >> >> I'd like to remove the "as Proposed Standard" from the charter text >> for both milestones and see how the discussion goes in the BOF before >> deciding which way this should go. >> >> I'd like to see more consideration around the issues of designing a >> codec that did a good job of mapping a real time stream onto IP >> packets. The way IP deals with packet loss and congestion has >> implications for designing a codec that works well over IP. I know >> some of the discussion I have had off list people talked about how we >> wanted a codec that supported adaptive bit rates that could change on >> the fly to be able to work well on an IP network. >> >> I will be working the folks to make sure the agenda has time to >> directly address the key topics which include (more may be coming): >> >> Will we be able to get qualified people to do and review the work? >> >> Key design goals of a new codec? >> >> Do we need a new codec or are there already ones defined that meet the >> needs? >> >> I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. >> >> Thanks, >> >> Cullen >> >> >> >> >> >> _______________________________________________ >> 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 >> >> >> >> >> > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From hsinnrei@adobe.com Thu Jun 18 06:34:15 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 0CD3F3A67A3 for ; Thu, 18 Jun 2009 06:34:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.569 X-Spam-Level: X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[AWL=-0.727, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 UV2vB78qGOZJ for ; Thu, 18 Jun 2009 06:34:12 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by core3.amsl.com (Postfix) with ESMTP id F081928C11F for ; Thu, 18 Jun 2009 06:33:34 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKSjpCOic+0yQvYz+zbZ6nT2X0xUEcpUAl@postini.com; Thu, 18 Jun 2009 06:33:57 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5IDXhWG008459; Thu, 18 Jun 2009 06:33:43 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5IDXctQ020353; Thu, 18 Jun 2009 06:33:40 -0700 (PDT) Received: from nacas03.corp.adobe.com (10.8.189.121) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 18 Jun 2009 06:33:38 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Thu, 18 Jun 2009 06:33:38 -0700 From: Henry Sinnreich To: "Dr. Christian Hoene" , Koen Vos Date: Thu, 18 Jun 2009 06:33:35 -0700 Thread-Topic: =?iso-8859-1?Q?[codec]_RE=A0:_Codec_BOF_approved, _much_work_needed?= Thread-Index: Acnv74/EOPinVpyIRQSmEiAopWXOHwAKdFKo Message-ID: In-Reply-To: <20090618103404.20747hsmkwbyohdo@webmail.uni-tuebingen.de> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C65FAC5F432Ahsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] =?iso-8859-1?q?RE=A0=3A_Codec_BOF_approved=2C_much_work_n?= =?iso-8859-1?q?eeded?= 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, 18 Jun 2009 13:34:15 -0000 --_000_C65FAC5F432Ahsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >MOS 3.5? It appears MOS metrics are obsolete and inadequate for BB Internet, Telepre= sence (mostly for business) and Digital Living Room (mostly for consumer). = The highest MOS is 5.0 aspired for 3.1 kHz telephony :-) Also, how do you accommodate metrics for cut-offs of entire sentences, as i= s the case for congested narrowband channels? Are there better metrics? Henry On 6/18/09 3:34 AM, "Dr. Christian Hoene" wrote: In order to support a high degree of reliability and available, I think the audio codec should support an acceptable operation mode even if the bandwidth is low. If the ultra low delay music transmission is not possible, the codec shall degrade to 25ms delayed music transmission and further degrade to speech quality. Jean-Marc: What is the coding rate of CELT, if it shall transmit voice at a quality of about MOS 3.5? > Quoting Henry Sinnreich: >> As for supporting bandwidth constrained links, where congestion can >> occur, I believe the mobile phone industry has already done a good >> job that we need not duplicate. > > Mobile phones use codecs that are expensive and complex to license though= . > And audio quality on mobile phones is mediocre or worse. > > koen. > > > >> Given the choice between designing for narrowband links and >> broadband Internet, let's chose therefore broadband. >> >> Henry >> >> On 6/16/09 9:41 PM, "Jean-Marc Valin" wrot= e: >> >> For wideband (16 kHz sampling), I think speech-only (ideally >> without mutilating background music) is sufficient. However, for >> super wideband (32 kHz and up), I think it's important to start >> supporting music. When it comes to latency (by that I mean the >> codec's algorithmic delay), the lower the better. I consider >> anything above ~40 ms to be unacceptable (ruling out Vorbis, MP3 >> and standard AAC), but it should ideally be lower than that. The >> lower the delay, the less problems you have with acoustic echo. >> >> Jean-Marc >> >> -------- Message d'origine-------- >> De: codec-bounces@ietf.org de la part de Henry Sinnreich >> Date: mar. 16/06/2009 18:31 >> =C0: Sandy (Alexander) MacInnis; codec@ietf.org; Slava Borilin; Roni Eve= n >> Objet : Re: [codec] Codec BOF approved, much work needed >> >>> Are we talking here about speech, or generic audio? >> >> As Slava has pointed out it is about wideband speech, that is the >> low latency (150ms or so) still applies, but having wideband audio >> (8-16 kHz audio BW) and why not, stereo. All this and many other >> however is to be worked out in the proposed Internet Codec WG. >> >> Henry >> >> >> On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis" >> wrote: >> >> Are we talking here about speech, or generic audio? >> >> There's a difference in terms of coding (bit rate, quality, etc.) >> and in terms of applicability. >> >> Or do we want both, i.e. two codecs? >> >> --Sandy >> >> >> ________________________________ >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >> Behalf Of Henry Sinnreich >> Sent: Tuesday, June 16, 2009 6:15 PM >> To: Slava Borilin; Roni Even; codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Dear Slava, >> >>> We are talking not about "enabling technology" to make everyone >>> understand each other (email case), >>> but "enhancement" - everyone can today understand each other via >>> 711 or 722, but we want to push the quality bar while keeping the >>> interop. >> >> This is an excellent point. We are talking about the Internet here >> in in the IETF. >> >> Henry >> >> >> On 6/16/09 4:56 PM, "Slava Borilin" wrote: >> >> Dear Henry, >> >> It is probably not the same as with email (or maybe just timing is >> different). >> We are talking not about "enabling technology" to make everyone >> understand each other (email case), but "enhancement" - everyone >> can today understand each other via 711 or 722, but we want to >> push the quality bar while keeping the interop. >> >> So really the magic question is that once we have the agreement on >> "recommended" IWAC- either one or several (agree with Jean-Marc), >> who is to enforce? >> PROBABLY the force to enforce are telecom operators? >> As telco, against internet companies (Cisco, Skype, MSFT, etc), do >> not like walled gardens by definition: >> - The telco landscape is not (well, not only) Skype/cheap IP calls >> versus Cellular or Wireline. >> - The mid-term battle is between internet and its rich >> communication techniques (web conferencing, social networking) and >> telco's phone-only service. >> - Battle is not only for call $$, but for the time spent on the >> media (trend is users spending more minutes on internet comms then >> on phones) >> - so carriers have to move from NGN core networks to offer >> IP-based "social network-like" communication models to subscribers, >> therefore, have IP-service at the last mile for the user, and not >> only for enterprise IP-phones, but every consumer. >> - And as Telco need subscribers to pay for the service, here comes >> the HD(=3Dwideband + packet loss robustness), as the necessary step >> to keep user satisfied with the carrier IP-service. >> - So actually, HD sounds to be the cornerstone for keeping the >> landscape of whole Telco industry versus Internet communications >> (or vice versa). >> - so for telcos it will be really important to have IWAC RFC and >> telcos have the power to enforce using it (via geo or industry >> forums - examples are PAL/NTSC in geo, industry - CableLabs), and >> they are used to the standard/certification process? >> >> Again, apart from the ambitions, what all of us (as vendors and as >> users) would like to achieve, is interop. >> And interop should, probably, be enforced, not "recommended" via >> some sort of certification? >> >> Everyone, please advice. >> >> >> regards, >> Slava Borilin >> >> >> ________________________________ >> >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Sent: Wednesday, June 17, 2009 1:33 AM >> To: Slava Borilin; Roni Even; codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Hi Slava, >> >>> Currently in the internet communications (web collaboration, voip >>> services, videoconferencing) - >>> do you believe is there any force to push interop, or everyone >>> "plays in his own walled garden"? >> >> IMO one of the main the strengths of the Internet is its global >> reach. The user can be anywhere and reach content from and >> communicate with anyone, anywhere. Just like we are doing here >> with email. >> The Internet codec will hopefully do for voice the same as text >> communications + attachments work in email. >> >>> sorry if this is na=EFve >> This applies to my message as well :-) >> >> Henry >> >> On 6/16/09 3:56 PM, "Slava Borilin" wrote: >> Roni, and whole international team, >> >> I have one more question here - sorry if this is na=EFve- but still >> please advice. >> >> Background: all of us do wish wish wish (vendors, customers, >> end-users, etc) to have ONE IWAC (internet wideband audio codec) >> for all. >> >> But assuming we (IETF) will come to the agreement which codec we >> like best (existing or new one) and make RFC. >> What will then be the destiny of the that RFC? >> And who and why should be choosing the certain codec into their app? >> >> Afaik IETF, like ITU just "agree on the specs", while industry or >> country-specific organizations are enforcing using or not using >> certain standards, like CableLabs (Vertical market + geography). >> >> The major driver for agreeing on the standard is interop, as I see. >> Currently in the internet communications (web collaboration, voip >> services, videoconferencing) - do you believe is there any force to >> push interop, or everyone "plays in his own walled garden"? >> >> Should we: >> - agree on RFC and then dig into smaller (geographical or vertical >> industry) communities to push them to force using this RFC (IWAC) >> as part of certification to make sure they do enforce the IWAC? >> - or we should just have IWAC RFC and believe "better staff will >> find its way to the market itself"? >> >> regards, >> Slava Borilin >> >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >> Behalf Of Roni Even >> Sent: Friday, June 12, 2009 10:56 PM >> To: codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Hi, >> I would like to suggest other key topics for the BOF >> >> 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / >> others >> >> 2. Describe the process of defining a codec in other standard bodies - = my >> view is that not everyone knows what is required to create a quality co= dec. >> >> 3. Is the purpose of the WG to publish one codec or multiple >> codecs based on >> different requirements. >> >> 4. If a WG will be formed there are more decision to make like, what is= the >> selection criteria if there is more than one candidate or do we >> require some >> cooperation, what are the deliverable - source code, encoder specificat= ion >> (do we require bit exactness ), how to defines the quality tests and >> evaluate the results to check if the codec addresses the requirements. >> >> Roni Even >> >> >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of >> Cullen Jennings >> Sent: Friday, June 12, 2009 8:32 PM >> To: codec@ietf.org >> Subject: [codec] Codec BOF approved, much work needed >> >> >> I have approved the CODEC BOF proposal. However, we need a bunch of >> work to get ready. Various people on IESG/IAB were not comfortable >> with the current charter and agenda so we need to work on theses >> before the meeting. >> >> A draft agenda/charter Jason provided are at >> >> Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt >> >> Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.t= xt >> >> After discussion with the IESG/IAB: >> >> I'd like to remove the "as Proposed Standard" from the charter text >> for both milestones and see how the discussion goes in the BOF before >> deciding which way this should go. >> >> I'd like to see more consideration around the issues of designing a >> codec that did a good job of mapping a real time stream onto IP >> packets. The way IP deals with packet loss and congestion has >> implications for designing a codec that works well over IP. I know >> some of the discussion I have had off list people talked about how we >> wanted a codec that supported adaptive bit rates that could change on >> the fly to be able to work well on an IP network. >> >> I will be working the folks to make sure the agenda has time to >> directly address the key topics which include (more may be coming): >> >> Will we be able to get qualified people to do and review the work? >> >> Key design goals of a new codec? >> >> Do we need a new codec or are there already ones defined that meet the >> needs? >> >> I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. >> >> Thanks, >> >> Cullen >> >> >> >> >> >> _______________________________________________ >> 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 >> >> >> >> >> > > _______________________________________________ > 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_C65FAC5F432Ahsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] RE=A0: Codec BOF approved, much work needed >MOS 3.5?

It appears MOS metrics are obsolete and inadequate for BB Internet, Telepre= sence (mostly for business) and Digital Living Room (mostly for consumer). = The highest MOS is 5.0 aspired for 3.1 kHz telephony :-)

Also, how do you accommodate metrics for cut-offs of entire sentences, as i= s the case for congested narrowband channels?

Are there better metrics?

Henry

On 6/18/09 3:34 AM, "Dr. Christian Hoene" <hoene@uni-tuebingen.de> wrote:

In order to support a high degree of reliab= ility and available, I
think the audio codec should support an acceptable operation mode even
if the bandwidth is low. If the ultra low delay music transmission is
not possible, the codec shall degrade to 25ms delayed music
transmission and further degrade to speech quality.

Jean-Marc: What is the coding rate of CELT, if it shall transmit voice
at a quality of about MOS 3.5?




> Quoting Henry Sinnreich:
>> As for supporting bandwidth constrained links, where congestion ca= n
>> occur, I believe the mobile phone industry has already done a good=
>> job that we need not duplicate.
>
> Mobile phones use codecs that are expensive and complex to license tho= ugh.
> And audio quality on mobile phones is mediocre or worse.
>
> koen.
>
>
>
>> Given the choice between designing for narrowband links and
>> broadband Internet, let's chose therefore broadband.
>>
>> Henry
>>
>> On 6/16/09 9:41 PM, "Jean-Marc Valin" <jean-marc.valin@octasic.com> wrote:
>>
>> For wideband (16 kHz sampling), I think speech-only (ideally
>> without mutilating background music) is sufficient. However, for <= BR> >> super wideband (32 kHz and up), I think it's important to start >> supporting music. When it comes to latency (by that I mean the >> codec's algorithmic delay), the lower the better. I consider
>> anything above ~40 ms to be unacceptable (ruling out Vorbis, MP3 <= BR> >> and standard AAC), but it should ideally be lower than that. The <= BR> >> lower the delay, the less problems you have with acoustic echo. >>
>>   Jean-Marc
>>
>> -------- Message d'origine--------
>> De: codec-bounces@ietf.org = de la part de Henry Sinnreich
>> Date: mar. 16/06/2009 18:31
>> À: Sandy (Alexander) MacInnis; c= odec@ietf.org; Slava Borilin; Roni Even
>> Objet : Re: [codec] Codec BOF approved, much work needed
>>
>>> Are we talking here about speech, or generic audio?
>>
>> As Slava has pointed out it is about wideband speech, that is the =
>> low latency (150ms or so) still applies, but having wideband audio=
>> (8-16 kHz audio BW) and why not, stereo. All this and many other <= BR> >> however is to be worked out in the proposed Internet Codec WG.
>>
>> Henry
>>
>>
>> On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis"
>> <macinnis@broadcom.com>= ; wrote:
>>
>> Are we talking here about speech, or generic audio?
>>
>> There's a difference in terms of coding (bit rate, quality, etc.) =
>> and in terms of applicability.
>>
>> Or do we want both, i.e. two codecs?
>>
>> --Sandy
>>
>>
>> ________________________________
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org<= /a>] On
>> Behalf Of Henry Sinnreich
>> Sent: Tuesday, June 16, 2009 6:15 PM
>> To: Slava Borilin; Roni Even; codec@iet= f.org
>> Subject: Re: [codec] Codec BOF approved, much work needed
>>
>> Dear Slava,
>>
>>> We are talking not about "enabling technology" to ma= ke everyone
>>> understand each other (email case),
>>> but "enhancement" -  everyone can today underst= and each other via
>>> 711 or 722, but we want to push the quality bar while keeping = the
>>> interop.
>>
>> This is an excellent point. We are talking about the Internet here=
>> in in the IETF.
>>
>> Henry
>>
>>
>> On 6/16/09 4:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
>>
>> Dear Henry,
>>
>> It is probably not the same  as with email (or maybe just tim= ing is
>> different).
>> We are talking not about  "enabling technology" to = make everyone
>> understand each other (email case), but  "enhancement&qu= ot; -  everyone
>> can today understand each other via 711 or 722,  but we want = to
>> push the quality bar while keeping the interop.
>>
>> So  really the magic question is that once we have the agreem= ent on
>> "recommended"  IWAC- either one or several (agree w= ith Jean-Marc),
>> who is to  enforce?
>> PROBABLY the force to enforce are telecom operators?
>> As  telco, against internet companies (Cisco, Skype, MSFT, et= c), do
>> not like  walled gardens by definition:
>> - The telco landscape is not (well, not  only) Skype/cheap IP= calls
>> versus Cellular or Wireline.
>> - The  mid-term battle is between internet and its rich
>> communication techniques (web  conferencing, social networkin= g) and
>>  telco's phone-only  service.
>> - Battle is not only for call $$, but for the time spent on  = the
>> media (trend is users spending more minutes on internet comms then=
>> on  phones)
>> - so carriers have to move from NGN core networks to offer  <= BR> >> IP-based "social network-like" communication models to s= ubscribers,
>> therefore,  have IP-service at the last mile for the user, an= d not
>> only for enterprise  IP-phones, but every consumer.
>> - And as Telco need subscribers to pay for  the service, here= comes
>> the HD(=3Dwideband + packet loss robustness), as the  necessa= ry step
>> to keep user satisfied with the carrier IP-service.
>> - So  actually, HD sounds to be the cornerstone for keeping t= he
>> landscape of whole  Telco industry versus Internet communicat= ions
>> (or vice versa).
>> - so for  telcos it will be really important to have IWAC RFC= and
>> telcos have the power  to enforce using it (via geo or indust= ry
>> forums - examples are PAL/NTSC in  geo, industry - CableLabs)= , and
>> they are used to the standard/certification  process?
>>
>> Again, apart from the ambitions, what all of us (as  vendors = and as
>> users) would like to achieve, is interop.
>> And interop  should, probably, be enforced, not "recomme= nded" via
>> some sort of  certification?
>>
>> Everyone, please  advice.
>>
>>
>> regards,
>> Slava  Borilin
>>
>>
>> ________________________________
>>
>> From: Henry Sinnreich [mailt= o:hsinnrei@adobe.com]
>> Sent: Wednesday, June 17, 2009 1:33 AM
>> To: Slava Borilin;  Roni Even; cod= ec@ietf.org
>> Subject: Re:  [codec] Codec BOF approved, much work needed >>
>> Hi  Slava,
>>
>>> Currently in the internet communications (web collaboration, &= nbsp;voip
>>> services, videoconferencing) -
>>> do you believe is there any force  to push interop, or ev= eryone
>>> "plays in his own walled garden"?
>>
>> IMO one  of the main the strengths of the Internet is its glo= bal
>> reach. The user can be  anywhere and reach content from and <= BR> >> communicate with anyone, anywhere. Just  like we are doing he= re
>> with email.
>> The Internet codec will hopefully do for  voice the same as t= ext
>> communications + attachments work in  email.
>>
>>> sorry if this is naïve
>> This applies to my message as well  :-)
>>
>> Henry
>>
>> On 6/16/09 3:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
>> Roni, and  whole international team,
>>
>> I have one more question here - sorry if this  is naïve-= but still
>> please advice.
>>
>> Background: all of us do wish wish  wish (vendors, customers,=
>> end-users, etc) to have ONE IWAC (internet wideband  audio co= dec)
>> for all.
>>
>> But assuming we (IETF) will come to the agreement  which code= c we
>> like best (existing or new one) and make RFC.
>> What will then  be the destiny of the that RFC?
>> And who and why should be choosing the  certain codec into th= eir app?
>>
>> Afaik IETF, like ITU just "agree on the  specs", wh= ile industry or
>> country-specific organizations are enforcing using  or not us= ing
>> certain standards, like CableLabs (Vertical market +  geograp= hy).
>>
>> The major driver for agreeing on the standard is interop,  as= I see.
>> Currently in the internet communications (web collaboration, voip =  
>> services, videoconferencing) - do you believe is there any force t= o
>> push  interop, or everyone "plays in his own walled gard= en"?
>>
>> Should we:
>> -  agree on RFC and then dig into smaller (geographical or ve= rtical
>> industry)  communities to push them to force using this RFC (= IWAC)
>> as part of  certification to make sure they do enforce the IW= AC?
>> - or we should just  have IWAC RFC and believe "better s= taff will
>> find its way to the market  itself"?
>>
>> regards,
>> Slava Borilin
>>
>>
>> -----Original  Message-----
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org<= /a>] On  
>> Behalf Of Roni Even
>> Sent: Friday, June 12, 2009 10:56 PM
>> To: codec@ietf.org
>> Subject: Re: [codec] Codec BOF  approved, much work needed >>
>> Hi,
>> I would like to suggest other key  topics for the BOF
>>
>> 1. Why should the IETF start a codec WG - why not do  it as I= TU / MPEG /
>> others
>>
>> 2. Describe the process of defining a  codec in other standar= d bodies - my
>> view is that not everyone knows what is  required to create a= quality codec.
>>
>> 3. Is the purpose of the WG to  publish one codec or multiple=
>> codecs based on
>> different  requirements.
>>
>> 4. If a WG will be formed there are more decision to make  li= ke, what is the
>> selection criteria if there is more than one candidate or  do= we
>> require some
>> cooperation, what are the deliverable - source code,  encoder= specification
>> (do we require bit exactness ), how to defines the  quality t= ests and
>> evaluate the results to check if the codec addresses the  req= uirements.
>>
>> Roni Even
>>
>>
>>
>> -----Original  Message-----
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org<= /a>] On  Behalf Of
>> Cullen Jennings
>> Sent: Friday, June 12, 2009 8:32 PM
>> To: codec@ietf.org
>> Subject: [codec] Codec BOF  approved, much work needed
>>
>>
>> I have approved the CODEC BOF proposal.  However, we need a b= unch of
>> work to get ready.  Various people on  IESG/IAB were not= comfortable
>> with the current charter and agenda so we  need to work on th= eses
>> before the meeting.
>>
>> A draft agenda/charter  Jason provided are at
>>
>> Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agen= da.txt
>>
>> Charter:  http://svn.resiprocate.org/rep/ietf-drafts/codec-= bof/charter.txt
>>
>> After  discussion with the IESG/IAB:
>>
>> I'd like to remove the "as Proposed  Standard" from= the charter text
>> for both milestones and see how the  discussion goes in the B= OF before
>> deciding which way this should  go.
>>
>> I'd like to see more consideration around the issues of designing = a
>> codec that did a good job of mapping a real time stream onto IP >> packets. The way IP deals with packet loss and congestion has
>> implications for designing a codec that works well over IP. I know=
>> some of the discussion I have had off list people talked about how= we
>> wanted a codec that supported adaptive bit rates that could change= on
>> the fly to be able to work well on an IP network.
>>
>> I will be working  the folks to make sure the agenda has time= to
>> directly address the key  topics which include (more may be c= oming):
>>
>> Will we be able to get  qualified people to do and review the= work?
>>
>> Key design goals of a new  codec?
>>
>> Do we need a new codec or are there already ones defined that &nbs= p;meet the
>> needs?
>>
>> I have asked Jason Fischl  and Jean-Marc Valin  to co-ch= air this BOF.
>>
>> Thanks,
>>
>> Cullen <RAI  AD>
>>
>>
>>
>>
>>
>> _______________________________________________
>> codec  mailing list
>> codec@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/codec
>>
>> _______________________________________________
>> codec  mailing list
>> codec@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/codec
>> _______________________________________________
>> codec  mailing list
>> codec@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/codec
>>
>>
>>
>>
>>
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ie= tf.org/mailman/listinfo/codec
>

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

--_000_C65FAC5F432Ahsinnreiadobecom_-- From hoene@uni-tuebingen.de Thu Jun 18 06:51:39 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 59EA228C327 for ; Thu, 18 Jun 2009 06:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.745 X-Spam-Level: X-Spam-Status: No, score=-3.745 tagged_above=-999 required=5 tests=[AWL=-0.252, BAYES_00=-2.599, FRT_ADOBE2=2.455, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 Hb78t9zXYRtD for ; Thu, 18 Jun 2009 06:51:36 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id D093528C127 for ; Thu, 18 Jun 2009 06:51:35 -0700 (PDT) Received: from hoeneLenovoT60 (isc-router6.urz.tu-dresden.de [141.30.3.115]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n5IDpZxV008165 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Jun 2009 15:51:41 +0200 From: "Christian Hoene" To: "'Henry Sinnreich'" , "'Koen Vos'" References: <20090618103404.20747hsmkwbyohdo@webmail.uni-tuebingen.de> In-Reply-To: Date: Thu, 18 Jun 2009 15:51:35 +0200 Message-ID: <003901c9f01b$e8eab950$bac02bf0$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003A_01C9F02C.AC738950" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnv74/EOPinVpyIRQSmEiAopWXOHwAKdFKoAAAe10A= Content-language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] =?iso-8859-1?q?RE=A0=3A_Codec_BOF_approved=2C_much_work_n?= =?iso-8859-1?q?eeded?= 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, 18 Jun 2009 13:51:39 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C9F02C.AC738950 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I do have the opinion that a main design metric beside audio quality, complexity, costs, and delay shall be reliability.=20 =20 We all know that the PSTN has a reliability of about 99.999%. If = designing a reliable Audio over IP codec, we shall consider to make it as robust as possible. Robust not only against packet losses but also for periods of = low bandwidth. =20 To make a system reliability, you must make it aware of this failures = and try to cope smartly with them. Thus, a codec which is aware of the = packet loss rate, shall decrease its bit/frame rates. Also, if it operates in = the presence of very high packet losses it stops, it make sense to switch = off the sending of the audio stream. (The encoder might then send a busy = signal) =20 The mean availability of the audio transmissions, calculated over all = users, might be one of the metrics for assessing the performance of an Internet audio codec. =20 Christian =20 =20 From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Thursday, June 18, 2009 3:34 PM To: Dr. Christian Hoene; Koen Vos Cc: codec@ietf.org Subject: Re: [codec] RE : Codec BOF approved, much work needed =20 >MOS 3.5? It appears MOS metrics are obsolete and inadequate for BB Internet, Telepresence (mostly for business) and Digital Living Room (mostly for consumer). The highest MOS is 5.0 aspired for 3.1 kHz telephony :-) Also, how do you accommodate metrics for cut-offs of entire sentences, = as is the case for congested narrowband channels? Are there better metrics? Henry On 6/18/09 3:34 AM, "Dr. Christian Hoene" = wrote: In order to support a high degree of reliability and available, I=20 think the audio codec should support an acceptable operation mode even=20 if the bandwidth is low. If the ultra low delay music transmission is=20 not possible, the codec shall degrade to 25ms delayed music=20 transmission and further degrade to speech quality. Jean-Marc: What is the coding rate of CELT, if it shall transmit voice=20 at a quality of about MOS 3.5? > Quoting Henry Sinnreich: >> As for supporting bandwidth constrained links, where congestion can=20 >> occur, I believe the mobile phone industry has already done a good=20 >> job that we need not duplicate. > > Mobile phones use codecs that are expensive and complex to license = though. > And audio quality on mobile phones is mediocre or worse. > > koen. > > > >> Given the choice between designing for narrowband links and=20 >> broadband Internet, let's chose therefore broadband. >> >> Henry >> >> On 6/16/09 9:41 PM, "Jean-Marc Valin" wrote: >> >> For wideband (16 kHz sampling), I think speech-only (ideally=20 >> without mutilating background music) is sufficient. However, for=20 >> super wideband (32 kHz and up), I think it's important to start=20 >> supporting music. When it comes to latency (by that I mean the=20 >> codec's algorithmic delay), the lower the better. I consider=20 >> anything above ~40 ms to be unacceptable (ruling out Vorbis, MP3=20 >> and standard AAC), but it should ideally be lower than that. The=20 >> lower the delay, the less problems you have with acoustic echo. >> >> Jean-Marc >> >> -------- Message d'origine-------- >> De: codec-bounces@ietf.org de la part de Henry Sinnreich >> Date: mar. 16/06/2009 18:31 >> =C0: Sandy (Alexander) MacInnis; codec@ietf.org; Slava Borilin; Roni = Even >> Objet : Re: [codec] Codec BOF approved, much work needed >> >>> Are we talking here about speech, or generic audio? >> >> As Slava has pointed out it is about wideband speech, that is the=20 >> low latency (150ms or so) still applies, but having wideband audio=20 >> (8-16 kHz audio BW) and why not, stereo. All this and many other=20 >> however is to be worked out in the proposed Internet Codec WG. >> >> Henry >> >> >> On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis"=20 >> wrote: >> >> Are we talking here about speech, or generic audio? >> >> There's a difference in terms of coding (bit rate, quality, etc.)=20 >> and in terms of applicability. >> >> Or do we want both, i.e. two codecs? >> >> --Sandy >> >> >> ________________________________ >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On=20 >> Behalf Of Henry Sinnreich >> Sent: Tuesday, June 16, 2009 6:15 PM >> To: Slava Borilin; Roni Even; codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Dear Slava, >> >>> We are talking not about "enabling technology" to make everyone=20 >>> understand each other (email case), >>> but "enhancement" - everyone can today understand each other via=20 >>> 711 or 722, but we want to push the quality bar while keeping the=20 >>> interop. >> >> This is an excellent point. We are talking about the Internet here=20 >> in in the IETF. >> >> Henry >> >> >> On 6/16/09 4:56 PM, "Slava Borilin" wrote: >> >> Dear Henry, >> >> It is probably not the same as with email (or maybe just timing is=20 >> different). >> We are talking not about "enabling technology" to make everyone=20 >> understand each other (email case), but "enhancement" - everyone=20 >> can today understand each other via 711 or 722, but we want to=20 >> push the quality bar while keeping the interop. >> >> So really the magic question is that once we have the agreement on=20 >> "recommended" IWAC- either one or several (agree with Jean-Marc),=20 >> who is to enforce? >> PROBABLY the force to enforce are telecom operators? >> As telco, against internet companies (Cisco, Skype, MSFT, etc), do=20 >> not like walled gardens by definition: >> - The telco landscape is not (well, not only) Skype/cheap IP calls=20 >> versus Cellular or Wireline. >> - The mid-term battle is between internet and its rich=20 >> communication techniques (web conferencing, social networking) and=20 >> telco's phone-only service. >> - Battle is not only for call $$, but for the time spent on the=20 >> media (trend is users spending more minutes on internet comms then=20 >> on phones) >> - so carriers have to move from NGN core networks to offer =20 >> IP-based "social network-like" communication models to subscribers,=20 >> therefore, have IP-service at the last mile for the user, and not=20 >> only for enterprise IP-phones, but every consumer. >> - And as Telco need subscribers to pay for the service, here comes=20 >> the HD(=3Dwideband + packet loss robustness), as the necessary step=20 >> to keep user satisfied with the carrier IP-service. >> - So actually, HD sounds to be the cornerstone for keeping the=20 >> landscape of whole Telco industry versus Internet communications=20 >> (or vice versa). >> - so for telcos it will be really important to have IWAC RFC and=20 >> telcos have the power to enforce using it (via geo or industry=20 >> forums - examples are PAL/NTSC in geo, industry - CableLabs), and=20 >> they are used to the standard/certification process? >> >> Again, apart from the ambitions, what all of us (as vendors and as=20 >> users) would like to achieve, is interop. >> And interop should, probably, be enforced, not "recommended" via=20 >> some sort of certification? >> >> Everyone, please advice. >> >> >> regards, >> Slava Borilin >> >> >> ________________________________ >> >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Sent: Wednesday, June 17, 2009 1:33 AM >> To: Slava Borilin; Roni Even; codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Hi Slava, >> >>> Currently in the internet communications (web collaboration, voip=20 >>> services, videoconferencing) - >>> do you believe is there any force to push interop, or everyone=20 >>> "plays in his own walled garden"? >> >> IMO one of the main the strengths of the Internet is its global=20 >> reach. The user can be anywhere and reach content from and=20 >> communicate with anyone, anywhere. Just like we are doing here=20 >> with email. >> The Internet codec will hopefully do for voice the same as text=20 >> communications + attachments work in email. >> >>> sorry if this is na=EFve >> This applies to my message as well :-) >> >> Henry >> >> On 6/16/09 3:56 PM, "Slava Borilin" wrote: >> Roni, and whole international team, >> >> I have one more question here - sorry if this is na=EFve- but still=20 >> please advice. >> >> Background: all of us do wish wish wish (vendors, customers,=20 >> end-users, etc) to have ONE IWAC (internet wideband audio codec)=20 >> for all. >> >> But assuming we (IETF) will come to the agreement which codec we=20 >> like best (existing or new one) and make RFC. >> What will then be the destiny of the that RFC? >> And who and why should be choosing the certain codec into their app? >> >> Afaik IETF, like ITU just "agree on the specs", while industry or=20 >> country-specific organizations are enforcing using or not using=20 >> certain standards, like CableLabs (Vertical market + geography). >> >> The major driver for agreeing on the standard is interop, as I see. >> Currently in the internet communications (web collaboration, voip =20 >> services, videoconferencing) - do you believe is there any force to=20 >> push interop, or everyone "plays in his own walled garden"? >> >> Should we: >> - agree on RFC and then dig into smaller (geographical or vertical=20 >> industry) communities to push them to force using this RFC (IWAC)=20 >> as part of certification to make sure they do enforce the IWAC? >> - or we should just have IWAC RFC and believe "better staff will=20 >> find its way to the market itself"? >> >> regards, >> Slava Borilin >> >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 >> Behalf Of Roni Even >> Sent: Friday, June 12, 2009 10:56 PM >> To: codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Hi, >> I would like to suggest other key topics for the BOF >> >> 1. Why should the IETF start a codec WG - why not do it as ITU / = MPEG / >> others >> >> 2. Describe the process of defining a codec in other standard bodies = - my >> view is that not everyone knows what is required to create a quality codec. >> >> 3. Is the purpose of the WG to publish one codec or multiple=20 >> codecs based on >> different requirements. >> >> 4. If a WG will be formed there are more decision to make like, what = is the >> selection criteria if there is more than one candidate or do we=20 >> require some >> cooperation, what are the deliverable - source code, encoder specification >> (do we require bit exactness ), how to defines the quality tests and >> evaluate the results to check if the codec addresses the = requirements. >> >> Roni Even >> >> >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On = Behalf Of >> Cullen Jennings >> Sent: Friday, June 12, 2009 8:32 PM >> To: codec@ietf.org >> Subject: [codec] Codec BOF approved, much work needed >> >> >> I have approved the CODEC BOF proposal. However, we need a bunch of >> work to get ready. Various people on IESG/IAB were not comfortable >> with the current charter and agenda so we need to work on theses >> before the meeting. >> >> A draft agenda/charter Jason provided are at >> >> Agenda: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt >> >> Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt >> >> After discussion with the IESG/IAB: >> >> I'd like to remove the "as Proposed Standard" from the charter text >> for both milestones and see how the discussion goes in the BOF = before >> deciding which way this should go. >> >> I'd like to see more consideration around the issues of designing a >> codec that did a good job of mapping a real time stream onto IP >> packets. The way IP deals with packet loss and congestion has >> implications for designing a codec that works well over IP. I know >> some of the discussion I have had off list people talked about how we >> wanted a codec that supported adaptive bit rates that could change on >> the fly to be able to work well on an IP network. >> >> I will be working the folks to make sure the agenda has time to >> directly address the key topics which include (more may be coming): >> >> Will we be able to get qualified people to do and review the work? >> >> Key design goals of a new codec? >> >> Do we need a new codec or are there already ones defined that meet = the >> needs? >> >> I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. >> >> Thanks, >> >> Cullen >> >> >> >> >> >> _______________________________________________ >> 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 >> >> >> >> >> > > _______________________________________________ > 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 ------=_NextPart_000_003A_01C9F02C.AC738950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] RE : Codec BOF approved, much work = needed

I do have the opinion that a main design metric beside = audio quality, complexity, costs, and delay shall be reliability. =

 

We all know that the PSTN has a reliability of about = 99.999%. If designing a reliable Audio over IP codec, we shall consider to make it = as robust as possible. Robust not only against packet losses but also for periods = of low bandwidth.

 

To make a system reliability, you must make it aware of = this failures and try to cope smartly with them. Thus, a codec which is aware = of the packet loss rate, shall decrease its bit/frame rates. Also, if it = operates in the presence of very high packet losses it stops, it make sense to = switch off the sending of the audio stream. (The encoder might then send a busy = signal)

 

The mean availability of the audio transmissions, = calculated over all users, might be one of the metrics for assessing the performance of = an Internet audio codec.

 

Christian

 

 

From:= Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Thursday, June 18, 2009 3:34 PM
To: Dr. Christian Hoene; Koen Vos
Cc: codec@ietf.org
Subject: Re: [codec] RE : Codec BOF approved, much work = needed

 

>MOS 3.5?

It appears MOS metrics are obsolete and inadequate for BB Internet, Telepresence (mostly for business) and Digital Living Room (mostly for consumer). The highest MOS is 5.0 aspired for 3.1 kHz telephony :-)

Also, how do you accommodate metrics for cut-offs of entire sentences, = as is the case for congested narrowband channels?

Are there better metrics?

Henry

On 6/18/09 3:34 AM, "Dr. Christian Hoene" <hoene@uni-tuebingen.de> = wrote:

In order to support a high degree of reliability and available, I
think the audio codec should support an acceptable operation mode even =
if the bandwidth is low. If the ultra low delay music transmission is =
not possible, the codec shall degrade to 25ms delayed music
transmission and further degrade to speech quality.

Jean-Marc: What is the coding rate of CELT, if it shall transmit voice =
at a quality of about MOS 3.5?




> Quoting Henry Sinnreich:
>> As for supporting bandwidth constrained links, where congestion = can
>> occur, I believe the mobile phone industry has already done a = good
>> job that we need not duplicate.
>
> Mobile phones use codecs that are expensive and complex to license = though.
> And audio quality on mobile phones is mediocre or worse.
>
> koen.
>
>
>
>> Given the choice between designing for narrowband links and =
>> broadband Internet, let's chose therefore broadband.
>>
>> Henry
>>
>> On 6/16/09 9:41 PM, "Jean-Marc Valin" <jean-marc.valin@octasic.com> = wrote:
>>
>> For wideband (16 kHz sampling), I think speech-only (ideally =
>> without mutilating background music) is sufficient. However, = for
>> super wideband (32 kHz and up), I think it's important to start =
>> supporting music. When it comes to latency (by that I mean the =
>> codec's algorithmic delay), the lower the better. I consider =
>> anything above ~40 ms to be unacceptable (ruling out Vorbis, = MP3
>> and standard AAC), but it should ideally be lower than that. = The
>> lower the delay, the less problems you have with acoustic = echo.
>>
>>   Jean-Marc
>>
>> -------- Message d'origine--------
>> De: codec-bounces@ietf.org de la part de Henry Sinnreich
>> Date: mar. 16/06/2009 18:31
>> =C0: Sandy (Alexander) MacInnis; codec@ietf.org; Slava Borilin; Roni Even
>> Objet : Re: [codec] Codec BOF approved, much work needed
>>
>>> Are we talking here about speech, or generic audio?
>>
>> As Slava has pointed out it is about wideband speech, that is = the
>> low latency (150ms or so) still applies, but having wideband = audio
>> (8-16 kHz audio BW) and why not, stereo. All this and many = other
>> however is to be worked out in the proposed Internet Codec = WG.
>>
>> Henry
>>
>>
>> On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis"
>> <macinnis@broadcom.com> wrote:
>>
>> Are we talking here about speech, or generic audio?
>>
>> There's a difference in terms of coding (bit rate, quality, = etc.)
>> and in terms of applicability.
>>
>> Or do we want both, i.e. two codecs?
>>
>> --Sandy
>>
>>
>> ________________________________
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On
>> Behalf Of Henry Sinnreich
>> Sent: Tuesday, June 16, 2009 6:15 PM
>> To: Slava Borilin; Roni Even; codec@ietf.org
>> Subject: Re: [codec] Codec BOF approved, much work needed
>>
>> Dear Slava,
>>
>>> We are talking not about "enabling technology" to = make everyone
>>> understand each other (email case),
>>> but "enhancement" -  everyone can today = understand each other via
>>> 711 or 722, but we want to push the quality bar while = keeping the
>>> interop.
>>
>> This is an excellent point. We are talking about the Internet = here
>> in in the IETF.
>>
>> Henry
>>
>>
>> On 6/16/09 4:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
>>
>> Dear Henry,
>>
>> It is probably not the same  as with email (or maybe just = timing is
>> different).
>> We are talking not about  "enabling technology" = to make everyone
>> understand each other (email case), but =  "enhancement" -  everyone
>> can today understand each other via 711 or 722,  but we = want to
>> push the quality bar while keeping the interop.
>>
>> So  really the magic question is that once we have the = agreement on
>> "recommended"  IWAC- either one or several = (agree with Jean-Marc),
>> who is to  enforce?
>> PROBABLY the force to enforce are telecom operators?
>> As  telco, against internet companies (Cisco, Skype, MSFT, = etc), do
>> not like  walled gardens by definition:
>> - The telco landscape is not (well, not  only) Skype/cheap = IP calls
>> versus Cellular or Wireline.
>> - The  mid-term battle is between internet and its rich =
>> communication techniques (web  conferencing, social = networking) and
>>  telco's phone-only  service.
>> - Battle is not only for call $$, but for the time spent on =  the
>> media (trend is users spending more minutes on internet comms = then
>> on  phones)
>> - so carriers have to move from NGN core networks to offer =  
>> IP-based "social network-like" communication models = to subscribers,
>> therefore,  have IP-service at the last mile for the user, = and not
>> only for enterprise  IP-phones, but every consumer.
>> - And as Telco need subscribers to pay for  the service, = here comes
>> the HD(=3Dwideband + packet loss robustness), as the =  necessary step
>> to keep user satisfied with the carrier IP-service.
>> - So  actually, HD sounds to be the cornerstone for = keeping the
>> landscape of whole  Telco industry versus Internet = communications
>> (or vice versa).
>> - so for  telcos it will be really important to have IWAC = RFC and
>> telcos have the power  to enforce using it (via geo or = industry
>> forums - examples are PAL/NTSC in  geo, industry - = CableLabs), and
>> they are used to the standard/certification  process?
>>
>> Again, apart from the ambitions, what all of us (as =  vendors and as
>> users) would like to achieve, is interop.
>> And interop  should, probably, be enforced, not "recommended" via
>> some sort of  certification?
>>
>> Everyone, please  advice.
>>
>>
>> regards,
>> Slava  Borilin
>>
>>
>> ________________________________
>>
>> From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
>> Sent: Wednesday, June 17, 2009 1:33 AM
>> To: Slava Borilin;  Roni Even; codec@ietf.org
>> Subject: Re:  [codec] Codec BOF approved, much work = needed
>>
>> Hi  Slava,
>>
>>> Currently in the internet communications (web = collaboration,  voip
>>> services, videoconferencing) -
>>> do you believe is there any force  to push interop, or = everyone
>>> "plays in his own walled garden"?
>>
>> IMO one  of the main the strengths of the Internet is its = global
>> reach. The user can be  anywhere and reach content from = and
>> communicate with anyone, anywhere. Just  like we are doing = here
>> with email.
>> The Internet codec will hopefully do for  voice the same = as text
>> communications + attachments work in  email.
>>
>>> sorry if this is na=EFve
>> This applies to my message as well  :-)
>>
>> Henry
>>
>> On 6/16/09 3:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
>> Roni, and  whole international team,
>>
>> I have one more question here - sorry if this  is na=EFve- = but still
>> please advice.
>>
>> Background: all of us do wish wish  wish (vendors, = customers,
>> end-users, etc) to have ONE IWAC (internet wideband  audio = codec)
>> for all.
>>
>> But assuming we (IETF) will come to the agreement  which = codec we
>> like best (existing or new one) and make RFC.
>> What will then  be the destiny of the that RFC?
>> And who and why should be choosing the  certain codec into = their app?
>>
>> Afaik IETF, like ITU just "agree on the  specs", = while industry or
>> country-specific organizations are enforcing using  or not = using
>> certain standards, like CableLabs (Vertical market + =  geography).
>>
>> The major driver for agreeing on the standard is interop, =  as I see.
>> Currently in the internet communications (web collaboration, = voip  
>> services, videoconferencing) - do you believe is there any = force to
>> push  interop, or everyone "plays in his own walled garden"?
>>
>> Should we:
>> -  agree on RFC and then dig into smaller (geographical or vertical
>> industry)  communities to push them to force using this = RFC (IWAC)
>> as part of  certification to make sure they do enforce the = IWAC?
>> - or we should just  have IWAC RFC and believe = "better staff will
>> find its way to the market  itself"?
>>
>> regards,
>> Slava Borilin
>>
>>
>> -----Original  Message-----
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On  
>> Behalf Of Roni Even
>> Sent: Friday, June 12, 2009 10:56 PM
>> To: codec@ietf.org
>> Subject: Re: [codec] Codec BOF  approved, much work = needed
>>
>> Hi,
>> I would like to suggest other key  topics for the BOF
>>
>> 1. Why should the IETF start a codec WG - why not do  it = as ITU / MPEG /
>> others
>>
>> 2. Describe the process of defining a  codec in other = standard bodies - my
>> view is that not everyone knows what is  required to = create a quality codec.
>>
>> 3. Is the purpose of the WG to  publish one codec or = multiple
>> codecs based on
>> different  requirements.
>>
>> 4. If a WG will be formed there are more decision to make =  like, what is the
>> selection criteria if there is more than one candidate or =  do we
>> require some
>> cooperation, what are the deliverable - source code, =  encoder specification
>> (do we require bit exactness ), how to defines the =  quality tests and
>> evaluate the results to check if the codec addresses the  requirements.
>>
>> Roni Even
>>
>>
>>
>> -----Original  Message-----
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On  Behalf Of
>> Cullen Jennings
>> Sent: Friday, June 12, 2009 8:32 PM
>> To: codec@ietf.org
>> Subject: [codec] Codec BOF  approved, much work needed
>>
>>
>> I have approved the CODEC BOF proposal.  However, we need = a bunch of
>> work to get ready.  Various people on  IESG/IAB were = not comfortable
>> with the current charter and agenda so we  need to work on = theses
>> before the meeting.
>>
>> A draft agenda/charter  Jason provided are at
>>
>> Agenda: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt
>>
>> Charter:  http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt
= >>
>> After  discussion with the IESG/IAB:
>>
>> I'd like to remove the "as Proposed  Standard" = from the charter text
>> for both milestones and see how the  discussion goes in = the BOF before
>> deciding which way this should  go.
>>
>> I'd like to see more consideration around the issues of = designing a
>> codec that did a good job of mapping a real time stream onto = IP
>> packets. The way IP deals with packet loss and congestion = has
>> implications for designing a codec that works well over IP. I = know
>> some of the discussion I have had off list people talked about = how we
>> wanted a codec that supported adaptive bit rates that could = change on
>> the fly to be able to work well on an IP network.
>>
>> I will be working  the folks to make sure the agenda has = time to
>> directly address the key  topics which include (more may = be coming):
>>
>> Will we be able to get  qualified people to do and review = the work?
>>
>> Key design goals of a new  codec?
>>
>> Do we need a new codec or are there already ones defined that  meet the
>> needs?
>>
>> I have asked Jason Fischl  and Jean-Marc Valin  to = co-chair this BOF.
>>
>> Thanks,
>>
>> Cullen <RAI  AD>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>>
>>
>
> _______________________________________________
> 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

------=_NextPart_000_003A_01C9F02C.AC738950-- From Borilin@spiritdsp.com Thu Jun 18 06:57:02 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 5681628C32A for ; Thu, 18 Jun 2009 06:57:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.613 X-Spam-Level: X-Spam-Status: No, score=-0.613 tagged_above=-999 required=5 tests=[AWL=-0.770, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 vWxKcR2MeUKm for ; Thu, 18 Jun 2009 06:56:49 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id D110E28C13E for ; Thu, 18 Jun 2009 06:56:48 -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 n5IDuqLN084449; Thu, 18 Jun 2009 17:56:53 +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_01C9F01C.9EC549D6" Date: Thu, 18 Jun 2009 17:56:42 +0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?ISO-8859-1?Q?=5Bcodec=5DRE=A0=3A_Codec_BOF_approved=2C_much_work_needed?= Thread-Index: Acnv74/EOPinVpyIRQSmEiAopWXOHwAKdFKoAABiWSA= References: <20090618103404.20747hsmkwbyohdo@webmail.uni-tuebingen.de> From: "Slava Borilin" To: "Henry Sinnreich" , "Dr. Christian Hoene" , "Koen Vos" X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Cc: codec@ietf.org Subject: Re: [codec] =?iso-8859-1?q?RE=A0=3A_Codec_BOF_approved=2C_much_work_n?= =?iso-8859-1?q?eeded?= 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, 18 Jun 2009 13:57:02 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9F01C.9EC549D6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable For congested networks - I assume that the way to judge the codec is to = judge the MOS over TIA-921 network profiles (that's what we use) which = covers realistic packet loss and congestion scenarios, and not just = "average normally distributed XX% packet loss". =20 However, the reality is that while making the comparison, one will = actually test the whole voice engine, not just the codec inside it. And normally codec and voiceengine are separate potions of the voip = solution. =20 It is probably possible to test different codecs within the same = voiceeenigne, to get the comparative data. =20 I doubt however, that we can have a codec which does "adapt" to network = itself, without upper level (signaling, statistics, etc) And the scope of designing the complete voiceengine and not just codec = part of it, is so much more complex that I do not believe we should even = try it. =20 regards, Slava Borilin =20 ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Henry Sinnreich Sent: Thursday, June 18, 2009 5:34 PM To: Dr. Christian Hoene; Koen Vos Cc: codec@ietf.org Subject: Re: [codec]RE : Codec BOF approved, much work needed =20 >MOS 3.5? It appears MOS metrics are obsolete and inadequate for BB Internet, = Telepresence (mostly for business) and Digital Living Room (mostly for = consumer). The highest MOS is 5.0 aspired for 3.1 kHz telephony :-) Also, how do you accommodate metrics for cut-offs of entire sentences, = as is the case for congested narrowband channels? Are there better metrics? Henry On 6/18/09 3:34 AM, "Dr. Christian Hoene" = wrote: In order to support a high degree of reliability and available, I=20 think the audio codec should support an acceptable operation mode even=20 if the bandwidth is low. If the ultra low delay music transmission is=20 not possible, the codec shall degrade to 25ms delayed music=20 transmission and further degrade to speech quality. Jean-Marc: What is the coding rate of CELT, if it shall transmit voice=20 at a quality of about MOS 3.5? > Quoting Henry Sinnreich: >> As for supporting bandwidth constrained links, where congestion can=20 >> occur, I believe the mobile phone industry has already done a good=20 >> job that we need not duplicate. > > Mobile phones use codecs that are expensive and complex to license = though. > And audio quality on mobile phones is mediocre or worse. > > koen. > > > >> Given the choice between designing for narrowband links and=20 >> broadband Internet, let's chose therefore broadband. >> >> Henry >> >> On 6/16/09 9:41 PM, "Jean-Marc Valin" = wrote: >> >> For wideband (16 kHz sampling), I think speech-only (ideally=20 >> without mutilating background music) is sufficient. However, for=20 >> super wideband (32 kHz and up), I think it's important to start=20 >> supporting music. When it comes to latency (by that I mean the=20 >> codec's algorithmic delay), the lower the better. I consider=20 >> anything above ~40 ms to be unacceptable (ruling out Vorbis, MP3=20 >> and standard AAC), but it should ideally be lower than that. The=20 >> lower the delay, the less problems you have with acoustic echo. >> >> Jean-Marc >> >> -------- Message d'origine-------- >> De: codec-bounces@ietf.org de la part de Henry Sinnreich >> Date: mar. 16/06/2009 18:31 >> =C0: Sandy (Alexander) MacInnis; codec@ietf.org; Slava Borilin; Roni = Even >> Objet : Re: [codec] Codec BOF approved, much work needed >> >>> Are we talking here about speech, or generic audio? >> >> As Slava has pointed out it is about wideband speech, that is the=20 >> low latency (150ms or so) still applies, but having wideband audio=20 >> (8-16 kHz audio BW) and why not, stereo. All this and many other=20 >> however is to be worked out in the proposed Internet Codec WG. >> >> Henry >> >> >> On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis"=20 >> wrote: >> >> Are we talking here about speech, or generic audio? >> >> There's a difference in terms of coding (bit rate, quality, etc.)=20 >> and in terms of applicability. >> >> Or do we want both, i.e. two codecs? >> >> --Sandy >> >> >> ________________________________ >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On=20 >> Behalf Of Henry Sinnreich >> Sent: Tuesday, June 16, 2009 6:15 PM >> To: Slava Borilin; Roni Even; codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Dear Slava, >> >>> We are talking not about "enabling technology" to make everyone=20 >>> understand each other (email case), >>> but "enhancement" - everyone can today understand each other via=20 >>> 711 or 722, but we want to push the quality bar while keeping the=20 >>> interop. >> >> This is an excellent point. We are talking about the Internet here=20 >> in in the IETF. >> >> Henry >> >> >> On 6/16/09 4:56 PM, "Slava Borilin" wrote: >> >> Dear Henry, >> >> It is probably not the same as with email (or maybe just timing is=20 >> different). >> We are talking not about "enabling technology" to make everyone=20 >> understand each other (email case), but "enhancement" - everyone=20 >> can today understand each other via 711 or 722, but we want to=20 >> push the quality bar while keeping the interop. >> >> So really the magic question is that once we have the agreement on=20 >> "recommended" IWAC- either one or several (agree with Jean-Marc),=20 >> who is to enforce? >> PROBABLY the force to enforce are telecom operators? >> As telco, against internet companies (Cisco, Skype, MSFT, etc), do=20 >> not like walled gardens by definition: >> - The telco landscape is not (well, not only) Skype/cheap IP calls=20 >> versus Cellular or Wireline. >> - The mid-term battle is between internet and its rich=20 >> communication techniques (web conferencing, social networking) and=20 >> telco's phone-only service. >> - Battle is not only for call $$, but for the time spent on the=20 >> media (trend is users spending more minutes on internet comms then=20 >> on phones) >> - so carriers have to move from NGN core networks to offer =20 >> IP-based "social network-like" communication models to subscribers,=20 >> therefore, have IP-service at the last mile for the user, and not=20 >> only for enterprise IP-phones, but every consumer. >> - And as Telco need subscribers to pay for the service, here comes=20 >> the HD(=3Dwideband + packet loss robustness), as the necessary step=20 >> to keep user satisfied with the carrier IP-service. >> - So actually, HD sounds to be the cornerstone for keeping the=20 >> landscape of whole Telco industry versus Internet communications=20 >> (or vice versa). >> - so for telcos it will be really important to have IWAC RFC and=20 >> telcos have the power to enforce using it (via geo or industry=20 >> forums - examples are PAL/NTSC in geo, industry - CableLabs), and=20 >> they are used to the standard/certification process? >> >> Again, apart from the ambitions, what all of us (as vendors and as=20 >> users) would like to achieve, is interop. >> And interop should, probably, be enforced, not "recommended" via=20 >> some sort of certification? >> >> Everyone, please advice. >> >> >> regards, >> Slava Borilin >> >> >> ________________________________ >> >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Sent: Wednesday, June 17, 2009 1:33 AM >> To: Slava Borilin; Roni Even; codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Hi Slava, >> >>> Currently in the internet communications (web collaboration, voip=20 >>> services, videoconferencing) - >>> do you believe is there any force to push interop, or everyone=20 >>> "plays in his own walled garden"? >> >> IMO one of the main the strengths of the Internet is its global=20 >> reach. The user can be anywhere and reach content from and=20 >> communicate with anyone, anywhere. Just like we are doing here=20 >> with email. >> The Internet codec will hopefully do for voice the same as text=20 >> communications + attachments work in email. >> >>> sorry if this is na=EFve >> This applies to my message as well :-) >> >> Henry >> >> On 6/16/09 3:56 PM, "Slava Borilin" wrote: >> Roni, and whole international team, >> >> I have one more question here - sorry if this is na=EFve- but still=20 >> please advice. >> >> Background: all of us do wish wish wish (vendors, customers,=20 >> end-users, etc) to have ONE IWAC (internet wideband audio codec)=20 >> for all. >> >> But assuming we (IETF) will come to the agreement which codec we=20 >> like best (existing or new one) and make RFC. >> What will then be the destiny of the that RFC? >> And who and why should be choosing the certain codec into their app? >> >> Afaik IETF, like ITU just "agree on the specs", while industry or=20 >> country-specific organizations are enforcing using or not using=20 >> certain standards, like CableLabs (Vertical market + geography). >> >> The major driver for agreeing on the standard is interop, as I see. >> Currently in the internet communications (web collaboration, voip =20 >> services, videoconferencing) - do you believe is there any force to=20 >> push interop, or everyone "plays in his own walled garden"? >> >> Should we: >> - agree on RFC and then dig into smaller (geographical or vertical=20 >> industry) communities to push them to force using this RFC (IWAC)=20 >> as part of certification to make sure they do enforce the IWAC? >> - or we should just have IWAC RFC and believe "better staff will=20 >> find its way to the market itself"? >> >> regards, >> Slava Borilin >> >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 >> Behalf Of Roni Even >> Sent: Friday, June 12, 2009 10:56 PM >> To: codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Hi, >> I would like to suggest other key topics for the BOF >> >> 1. Why should the IETF start a codec WG - why not do it as ITU / = MPEG / >> others >> >> 2. Describe the process of defining a codec in other standard bodies = - my >> view is that not everyone knows what is required to create a quality = codec. >> >> 3. Is the purpose of the WG to publish one codec or multiple=20 >> codecs based on >> different requirements. >> >> 4. If a WG will be formed there are more decision to make like, what = is the >> selection criteria if there is more than one candidate or do we=20 >> require some >> cooperation, what are the deliverable - source code, encoder = specification >> (do we require bit exactness ), how to defines the quality tests and >> evaluate the results to check if the codec addresses the = requirements. >> >> Roni Even >> >> >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On = Behalf Of >> Cullen Jennings >> Sent: Friday, June 12, 2009 8:32 PM >> To: codec@ietf.org >> Subject: [codec] Codec BOF approved, much work needed >> >> >> I have approved the CODEC BOF proposal. However, we need a bunch of >> work to get ready. Various people on IESG/IAB were not comfortable >> with the current charter and agenda so we need to work on theses >> before the meeting. >> >> A draft agenda/charter Jason provided are at >> >> Agenda: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt >> >> Charter: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt >> >> After discussion with the IESG/IAB: >> >> I'd like to remove the "as Proposed Standard" from the charter text >> for both milestones and see how the discussion goes in the BOF = before >> deciding which way this should go. >> >> I'd like to see more consideration around the issues of designing a >> codec that did a good job of mapping a real time stream onto IP >> packets. The way IP deals with packet loss and congestion has >> implications for designing a codec that works well over IP. I know >> some of the discussion I have had off list people talked about how we >> wanted a codec that supported adaptive bit rates that could change on >> the fly to be able to work well on an IP network. >> >> I will be working the folks to make sure the agenda has time to >> directly address the key topics which include (more may be coming): >> >> Will we be able to get qualified people to do and review the work? >> >> Key design goals of a new codec? >> >> Do we need a new codec or are there already ones defined that meet = the >> needs? >> >> I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. >> >> Thanks, >> >> Cullen >> >> >> >> >> >> _______________________________________________ >> 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 >> >> >> >> >> > > _______________________________________________ > 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 ------_=_NextPart_001_01C9F01C.9EC549D6 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] RE : Codec BOF approved, much work = needed

For congested = networks - I assume that the way to judge the codec is to judge the MOS over TIA-921 = network profiles (that’s what we use) which covers realistic packet loss = and congestion scenarios, and not just “average normally distributed = XX% packet loss”.

 =

However, the = reality is that while making the comparison, one will actually test the whole voice = engine, not just the codec inside it.

And normally = codec and voiceengine are separate potions of the voip = solution.

 =

It is probably = possible to test different codecs within the same voiceeenigne, to get the = comparative data.

 =

I doubt however, = that we can have a codec which does “adapt” to network itself, = without upper level (signaling, statistics, etc)

And the scope of designing the complete voiceengine and not just codec part of it, is so = much more complex that I do not believe we should even try = it.

 =

regards,

Slava Borilin

 

=

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Henry Sinnreich
Sent: Thursday, June 18, = 2009 5:34 PM
To: Dr. Christian Hoene; = Koen Vos
Cc: codec@ietf.org
Subject: Re: = [codec]RE : Codec BOF approved, much work needed

 

>MOS 3.5?

It appears MOS metrics are obsolete and inadequate for BB Internet, Telepresence (mostly for business) and Digital Living Room (mostly for consumer). The highest MOS is 5.0 aspired for 3.1 kHz telephony :-)

Also, how do you accommodate metrics for cut-offs of entire sentences, = as is the case for congested narrowband channels?

Are there better metrics?

Henry

On 6/18/09 3:34 AM, "Dr. Christian Hoene" <hoene@uni-tuebingen.de> = wrote:

In order to support a = high degree of reliability and available, I
think the audio codec should support an acceptable operation mode even =
if the bandwidth is low. If the ultra low delay music transmission is =
not possible, the codec shall degrade to 25ms delayed music
transmission and further degrade to speech quality.

Jean-Marc: What is the coding rate of CELT, if it shall transmit voice =
at a quality of about MOS 3.5?




> Quoting Henry Sinnreich:
>> As for supporting bandwidth constrained links, where congestion = can
>> occur, I believe the mobile phone industry has already done a = good
>> job that we need not duplicate.
>
> Mobile phones use codecs that are expensive and complex to license = though.
> And audio quality on mobile phones is mediocre or worse.
>
> koen.
>
>
>
>> Given the choice between designing for narrowband links and =
>> broadband Internet, let's chose therefore broadband.
>>
>> Henry
>>
>> On 6/16/09 9:41 PM, "Jean-Marc Valin" <jean-marc.valin@octasic.com> = wrote:
>>
>> For wideband (16 kHz sampling), I think speech-only (ideally =
>> without mutilating background music) is sufficient. However, = for
>> super wideband (32 kHz and up), I think it's important to start =
>> supporting music. When it comes to latency (by that I mean the =
>> codec's algorithmic delay), the lower the better. I consider =
>> anything above ~40 ms to be unacceptable (ruling out Vorbis, = MP3
>> and standard AAC), but it should ideally be lower than that. = The
>> lower the delay, the less problems you have with acoustic = echo.
>>
>>   Jean-Marc
>>
>> -------- Message d'origine--------
>> De: codec-bounces@ietf.org de la part de Henry Sinnreich
>> Date: mar. 16/06/2009 18:31
>> =C0: Sandy (Alexander) MacInnis; codec@ietf.org; Slava Borilin; Roni Even
>> Objet : Re: [codec] Codec BOF approved, much work needed
>>
>>> Are we talking here about speech, or generic audio?
>>
>> As Slava has pointed out it is about wideband speech, that is = the
>> low latency (150ms or so) still applies, but having wideband = audio
>> (8-16 kHz audio BW) and why not, stereo. All this and many = other
>> however is to be worked out in the proposed Internet Codec = WG.
>>
>> Henry
>>
>>
>> On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis"
>> <macinnis@broadcom.com> wrote:
>>
>> Are we talking here about speech, or generic audio?
>>
>> There's a difference in terms of coding (bit rate, quality, = etc.)
>> and in terms of applicability.
>>
>> Or do we want both, i.e. two codecs?
>>
>> --Sandy
>>
>>
>> ________________________________
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On
>> Behalf Of Henry Sinnreich
>> Sent: Tuesday, June 16, 2009 6:15 PM
>> To: Slava Borilin; Roni Even; codec@ietf.org
>> Subject: Re: [codec] Codec BOF approved, much work needed
>>
>> Dear Slava,
>>
>>> We are talking not about "enabling technology" to = make everyone
>>> understand each other (email case),
>>> but "enhancement" -  everyone can today = understand each other via
>>> 711 or 722, but we want to push the quality bar while = keeping the
>>> interop.
>>
>> This is an excellent point. We are talking about the Internet = here
>> in in the IETF.
>>
>> Henry
>>
>>
>> On 6/16/09 4:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
>>
>> Dear Henry,
>>
>> It is probably not the same  as with email (or maybe just = timing is
>> different).
>> We are talking not about  "enabling technology" = to make everyone
>> understand each other (email case), but =  "enhancement" -  everyone
>> can today understand each other via 711 or 722,  but we = want to
>> push the quality bar while keeping the interop.
>>
>> So  really the magic question is that once we have the = agreement on
>> "recommended"  IWAC- either one or several = (agree with Jean-Marc),
>> who is to  enforce?
>> PROBABLY the force to enforce are telecom operators?
>> As  telco, against internet companies (Cisco, Skype, MSFT, = etc), do
>> not like  walled gardens by definition:
>> - The telco landscape is not (well, not  only) Skype/cheap = IP calls
>> versus Cellular or Wireline.
>> - The  mid-term battle is between internet and its rich =
>> communication techniques (web  conferencing, social = networking) and
>>  telco's phone-only  service.
>> - Battle is not only for call $$, but for the time spent on =  the
>> media (trend is users spending more minutes on internet comms = then
>> on  phones)
>> - so carriers have to move from NGN core networks to offer =  
>> IP-based "social network-like" communication models = to subscribers,
>> therefore,  have IP-service at the last mile for the user, = and not
>> only for enterprise  IP-phones, but every consumer.
>> - And as Telco need subscribers to pay for  the service, = here comes
>> the HD(=3Dwideband + packet loss robustness), as the =  necessary step
>> to keep user satisfied with the carrier IP-service.
>> - So  actually, HD sounds to be the cornerstone for = keeping the
>> landscape of whole  Telco industry versus Internet = communications
>> (or vice versa).
>> - so for  telcos it will be really important to have IWAC = RFC and
>> telcos have the power  to enforce using it (via geo or = industry
>> forums - examples are PAL/NTSC in  geo, industry - = CableLabs), and
>> they are used to the standard/certification  process?
>>
>> Again, apart from the ambitions, what all of us (as =  vendors and as
>> users) would like to achieve, is interop.
>> And interop  should, probably, be enforced, not "recommended" via
>> some sort of  certification?
>>
>> Everyone, please  advice.
>>
>>
>> regards,
>> Slava  Borilin
>>
>>
>> ________________________________
>>
>> From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
>> Sent: Wednesday, June 17, 2009 1:33 AM
>> To: Slava Borilin;  Roni Even; codec@ietf.org
>> Subject: Re:  [codec] Codec BOF approved, much work = needed
>>
>> Hi  Slava,
>>
>>> Currently in the internet communications (web = collaboration,  voip
>>> services, videoconferencing) -
>>> do you believe is there any force  to push interop, or everyone
>>> "plays in his own walled garden"?
>>
>> IMO one  of the main the strengths of the Internet is its = global
>> reach. The user can be  anywhere and reach content from = and
>> communicate with anyone, anywhere. Just  like we are doing = here
>> with email.
>> The Internet codec will hopefully do for  voice the same = as text
>> communications + attachments work in  email.
>>
>>> sorry if this is na=EFve
>> This applies to my message as well  :-)
>>
>> Henry
>>
>> On 6/16/09 3:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
>> Roni, and  whole international team,
>>
>> I have one more question here - sorry if this  is na=EFve- = but still
>> please advice.
>>
>> Background: all of us do wish wish  wish (vendors, = customers,
>> end-users, etc) to have ONE IWAC (internet wideband  audio = codec)
>> for all.
>>
>> But assuming we (IETF) will come to the agreement  which = codec we
>> like best (existing or new one) and make RFC.
>> What will then  be the destiny of the that RFC?
>> And who and why should be choosing the  certain codec into = their app?
>>
>> Afaik IETF, like ITU just "agree on the  specs", = while industry or
>> country-specific organizations are enforcing using  or not = using
>> certain standards, like CableLabs (Vertical market + =  geography).
>>
>> The major driver for agreeing on the standard is interop, =  as I see.
>> Currently in the internet communications (web collaboration, = voip  
>> services, videoconferencing) - do you believe is there any = force to
>> push  interop, or everyone "plays in his own walled garden"?
>>
>> Should we:
>> -  agree on RFC and then dig into smaller (geographical or vertical
>> industry)  communities to push them to force using this = RFC (IWAC)
>> as part of  certification to make sure they do enforce the = IWAC?
>> - or we should just  have IWAC RFC and believe = "better staff will
>> find its way to the market  itself"?
>>
>> regards,
>> Slava Borilin
>>
>>
>> -----Original  Message-----
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On  
>> Behalf Of Roni Even
>> Sent: Friday, June 12, 2009 10:56 PM
>> To: codec@ietf.org
>> Subject: Re: [codec] Codec BOF  approved, much work = needed
>>
>> Hi,
>> I would like to suggest other key  topics for the BOF
>>
>> 1. Why should the IETF start a codec WG - why not do  it = as ITU / MPEG /
>> others
>>
>> 2. Describe the process of defining a  codec in other = standard bodies - my
>> view is that not everyone knows what is  required to = create a quality codec.
>>
>> 3. Is the purpose of the WG to  publish one codec or = multiple
>> codecs based on
>> different  requirements.
>>
>> 4. If a WG will be formed there are more decision to make =  like, what is the
>> selection criteria if there is more than one candidate or =  do we
>> require some
>> cooperation, what are the deliverable - source code, =  encoder specification
>> (do we require bit exactness ), how to defines the =  quality tests and
>> evaluate the results to check if the codec addresses the  requirements.
>>
>> Roni Even
>>
>>
>>
>> -----Original  Message-----
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On  Behalf Of
>> Cullen Jennings
>> Sent: Friday, June 12, 2009 8:32 PM
>> To: codec@ietf.org
>> Subject: [codec] Codec BOF  approved, much work needed
>>
>>
>> I have approved the CODEC BOF proposal.  However, we need = a bunch of
>> work to get ready.  Various people on  IESG/IAB were = not comfortable
>> with the current charter and agenda so we  need to work on = theses
>> before the meeting.
>>
>> A draft agenda/charter  Jason provided are at
>>
>> Agenda: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt
>>
>> Charter:  http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt
= >>
>> After  discussion with the IESG/IAB:
>>
>> I'd like to remove the "as Proposed  Standard" = from the charter text
>> for both milestones and see how the  discussion goes in = the BOF before
>> deciding which way this should  go.
>>
>> I'd like to see more consideration around the issues of = designing a
>> codec that did a good job of mapping a real time stream onto = IP
>> packets. The way IP deals with packet loss and congestion = has
>> implications for designing a codec that works well over IP. I = know
>> some of the discussion I have had off list people talked about = how we
>> wanted a codec that supported adaptive bit rates that could = change on
>> the fly to be able to work well on an IP network.
>>
>> I will be working  the folks to make sure the agenda has = time to
>> directly address the key  topics which include (more may = be coming):
>>
>> Will we be able to get  qualified people to do and review = the work?
>>
>> Key design goals of a new  codec?
>>
>> Do we need a new codec or are there already ones defined that  meet the
>> needs?
>>
>> I have asked Jason Fischl  and Jean-Marc Valin  to = co-chair this BOF.
>>
>> Thanks,
>>
>> Cullen <RAI  AD>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>>
>>
>
> _______________________________________________
> 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

------_=_NextPart_001_01C9F01C.9EC549D6-- From hsinnrei@adobe.com Thu Jun 18 07:11:56 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 3063928C125 for ; Thu, 18 Jun 2009 07:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.503 X-Spam-Level: X-Spam-Status: No, score=-4.503 tagged_above=-999 required=5 tests=[AWL=-0.660, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 Z4a7h1NmnH7D for ; Thu, 18 Jun 2009 07:11:53 -0700 (PDT) Received: from psmtp.com (exprod6ob111.obsmtp.com [64.18.1.26]) by core3.amsl.com (Postfix) with ESMTP id 7A9A23A6B19 for ; Thu, 18 Jun 2009 07:11:51 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKSjpLK0CI+gPA8iOmM+esNo84HIg3weHi@postini.com; Thu, 18 Jun 2009 07:12:05 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5IE5gao027775; Thu, 18 Jun 2009 07:05:43 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5IEBsiq022758; Thu, 18 Jun 2009 07:11:54 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Thu, 18 Jun 2009 07:11:54 -0700 From: Henry Sinnreich To: Christian Hoene , Koen Vos Date: Thu, 18 Jun 2009 07:11:51 -0700 Thread-Topic: =?iso-8859-1?Q?[codec]_RE=A0:_Codec_BOF_approved, _much_work_needed?= Thread-Index: Acnv74/EOPinVpyIRQSmEiAopWXOHwAKdFKoAAAe10AAATdL0A== Message-ID: In-Reply-To: <003901c9f01b$e8eab950$bac02bf0$@de> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C65FB5574338hsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] =?iso-8859-1?q?RE=A0=3A_Codec_BOF_approved=2C_much_work_n?= =?iso-8859-1?q?eeded?= 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, 18 Jun 2009 14:11:56 -0000 --_000_C65FB5574338hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable My sincere apology for continuing this discussion, but this I cannot let th= is pass: >We all know that the PSTN has a reliability of about 99.999%. During the major catastrophes here in the last 10 years the PSTN was out of= service for days and weeks and the only communications that worked were ov= er the Internet. During the 1st few days of the hurricane Katrina the mayor of New Orleans t= alked to the president using VoIP with WiFi access. Thanks, Henry On 6/18/09 8:51 AM, "Christian Hoene" wrote: I do have the opinion that a main design metric beside audio quality, compl= exity, costs, and delay shall be reliability. We all know that the PSTN has a reliability of about 99.999%. If designing = a reliable Audio over IP codec, we shall consider to make it as robust as p= ossible. Robust not only against packet losses but also for periods of low = bandwidth. To make a system reliability, you must make it aware of this failures and t= ry to cope smartly with them. Thus, a codec which is aware of the packet lo= ss rate, shall decrease its bit/frame rates. Also, if it operates in the pr= esence of very high packet losses it stops, it make sense to switch off the= sending of the audio stream. (The encoder might then send a busy signal) The mean availability of the audio transmissions, calculated over all users= , might be one of the metrics for assessing the performance of an Internet = audio codec. Christian From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Thursday, June 18, 2009 3:34 PM To: Dr. Christian Hoene; Koen Vos Cc: codec@ietf.org Subject: Re: [codec] RE : Codec BOF approved, much work needed >MOS 3.5? It appears MOS metrics are obsolete and inadequate for BB Internet, Telepre= sence (mostly for business) and Digital Living Room (mostly for consumer). = The highest MOS is 5.0 aspired for 3.1 kHz telephony :-) Also, how do you accommodate metrics for cut-offs of entire sentences, as i= s the case for congested narrowband channels? Are there better metrics? Henry On 6/18/09 3:34 AM, "Dr. Christian Hoene" wrote: In order to support a high degree of reliability and available, I think the audio codec should support an acceptable operation mode even if the bandwidth is low. If the ultra low delay music transmission is not possible, the codec shall degrade to 25ms delayed music transmission and further degrade to speech quality. Jean-Marc: What is the coding rate of CELT, if it shall transmit voice at a quality of about MOS 3.5? > Quoting Henry Sinnreich: >> As for supporting bandwidth constrained links, where congestion can >> occur, I believe the mobile phone industry has already done a good >> job that we need not duplicate. > > Mobile phones use codecs that are expensive and complex to license though= . > And audio quality on mobile phones is mediocre or worse. > > koen. > > > >> Given the choice between designing for narrowband links and >> broadband Internet, let's chose therefore broadband. >> >> Henry >> >> On 6/16/09 9:41 PM, "Jean-Marc Valin" wrot= e: >> >> For wideband (16 kHz sampling), I think speech-only (ideally >> without mutilating background music) is sufficient. However, for >> super wideband (32 kHz and up), I think it's important to start >> supporting music. When it comes to latency (by that I mean the >> codec's algorithmic delay), the lower the better. I consider >> anything above ~40 ms to be unacceptable (ruling out Vorbis, MP3 >> and standard AAC), but it should ideally be lower than that. The >> lower the delay, the less problems you have with acoustic echo. >> >> Jean-Marc >> >> -------- Message d'origine-------- >> De: codec-bounces@ietf.org de la part de Henry Sinnreich >> Date: mar. 16/06/2009 18:31 >> =C0: Sandy (Alexander) MacInnis; codec@ietf.org; Slava Borilin; Roni Eve= n >> Objet : Re: [codec] Codec BOF approved, much work needed >> >>> Are we talking here about speech, or generic audio? >> >> As Slava has pointed out it is about wideband speech, that is the >> low latency (150ms or so) still applies, but having wideband audio >> (8-16 kHz audio BW) and why not, stereo. All this and many other >> however is to be worked out in the proposed Internet Codec WG. >> >> Henry >> >> >> On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis" >> wrote: >> >> Are we talking here about speech, or generic audio? >> >> There's a difference in terms of coding (bit rate, quality, etc.) >> and in terms of applicability. >> >> Or do we want both, i.e. two codecs? >> >> --Sandy >> >> >> ________________________________ >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >> Behalf Of Henry Sinnreich >> Sent: Tuesday, June 16, 2009 6:15 PM >> To: Slava Borilin; Roni Even; codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Dear Slava, >> >>> We are talking not about "enabling technology" to make everyone >>> understand each other (email case), >>> but "enhancement" - everyone can today understand each other via >>> 711 or 722, but we want to push the quality bar while keeping the >>> interop. >> >> This is an excellent point. We are talking about the Internet here >> in in the IETF. >> >> Henry >> >> >> On 6/16/09 4:56 PM, "Slava Borilin" wrote: >> >> Dear Henry, >> >> It is probably not the same as with email (or maybe just timing is >> different). >> We are talking not about "enabling technology" to make everyone >> understand each other (email case), but "enhancement" - everyone >> can today understand each other via 711 or 722, but we want to >> push the quality bar while keeping the interop. >> >> So really the magic question is that once we have the agreement on >> "recommended" IWAC- either one or several (agree with Jean-Marc), >> who is to enforce? >> PROBABLY the force to enforce are telecom operators? >> As telco, against internet companies (Cisco, Skype, MSFT, etc), do >> not like walled gardens by definition: >> - The telco landscape is not (well, not only) Skype/cheap IP calls >> versus Cellular or Wireline. >> - The mid-term battle is between internet and its rich >> communication techniques (web conferencing, social networking) and >> telco's phone-only service. >> - Battle is not only for call $$, but for the time spent on the >> media (trend is users spending more minutes on internet comms then >> on phones) >> - so carriers have to move from NGN core networks to offer >> IP-based "social network-like" communication models to subscribers, >> therefore, have IP-service at the last mile for the user, and not >> only for enterprise IP-phones, but every consumer. >> - And as Telco need subscribers to pay for the service, here comes >> the HD(=3Dwideband + packet loss robustness), as the necessary step >> to keep user satisfied with the carrier IP-service. >> - So actually, HD sounds to be the cornerstone for keeping the >> landscape of whole Telco industry versus Internet communications >> (or vice versa). >> - so for telcos it will be really important to have IWAC RFC and >> telcos have the power to enforce using it (via geo or industry >> forums - examples are PAL/NTSC in geo, industry - CableLabs), and >> they are used to the standard/certification process? >> >> Again, apart from the ambitions, what all of us (as vendors and as >> users) would like to achieve, is interop. >> And interop should, probably, be enforced, not "recommended" via >> some sort of certification? >> >> Everyone, please advice. >> >> >> regards, >> Slava Borilin >> >> >> ________________________________ >> >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Sent: Wednesday, June 17, 2009 1:33 AM >> To: Slava Borilin; Roni Even; codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Hi Slava, >> >>> Currently in the internet communications (web collaboration, voip >>> services, videoconferencing) - >>> do you believe is there any force to push interop, or everyone >>> "plays in his own walled garden"? >> >> IMO one of the main the strengths of the Internet is its global >> reach. The user can be anywhere and reach content from and >> communicate with anyone, anywhere. Just like we are doing here >> with email. >> The Internet codec will hopefully do for voice the same as text >> communications + attachments work in email. >> >>> sorry if this is na=EFve >> This applies to my message as well :-) >> >> Henry >> >> On 6/16/09 3:56 PM, "Slava Borilin" wrote: >> Roni, and whole international team, >> >> I have one more question here - sorry if this is na=EFve- but still >> please advice. >> >> Background: all of us do wish wish wish (vendors, customers, >> end-users, etc) to have ONE IWAC (internet wideband audio codec) >> for all. >> >> But assuming we (IETF) will come to the agreement which codec we >> like best (existing or new one) and make RFC. >> What will then be the destiny of the that RFC? >> And who and why should be choosing the certain codec into their app? >> >> Afaik IETF, like ITU just "agree on the specs", while industry or >> country-specific organizations are enforcing using or not using >> certain standards, like CableLabs (Vertical market + geography). >> >> The major driver for agreeing on the standard is interop, as I see. >> Currently in the internet communications (web collaboration, voip >> services, videoconferencing) - do you believe is there any force to >> push interop, or everyone "plays in his own walled garden"? >> >> Should we: >> - agree on RFC and then dig into smaller (geographical or vertical >> industry) communities to push them to force using this RFC (IWAC) >> as part of certification to make sure they do enforce the IWAC? >> - or we should just have IWAC RFC and believe "better staff will >> find its way to the market itself"? >> >> regards, >> Slava Borilin >> >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >> Behalf Of Roni Even >> Sent: Friday, June 12, 2009 10:56 PM >> To: codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Hi, >> I would like to suggest other key topics for the BOF >> >> 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / >> others >> >> 2. Describe the process of defining a codec in other standard bodies - = my >> view is that not everyone knows what is required to create a quality co= dec. >> >> 3. Is the purpose of the WG to publish one codec or multiple >> codecs based on >> different requirements. >> >> 4. If a WG will be formed there are more decision to make like, what is= the >> selection criteria if there is more than one candidate or do we >> require some >> cooperation, what are the deliverable - source code, encoder specificat= ion >> (do we require bit exactness ), how to defines the quality tests and >> evaluate the results to check if the codec addresses the requirements. >> >> Roni Even >> >> >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of >> Cullen Jennings >> Sent: Friday, June 12, 2009 8:32 PM >> To: codec@ietf.org >> Subject: [codec] Codec BOF approved, much work needed >> >> >> I have approved the CODEC BOF proposal. However, we need a bunch of >> work to get ready. Various people on IESG/IAB were not comfortable >> with the current charter and agenda so we need to work on theses >> before the meeting. >> >> A draft agenda/charter Jason provided are at >> >> Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt >> >> Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.t= xt >> >> After discussion with the IESG/IAB: >> >> I'd like to remove the "as Proposed Standard" from the charter text >> for both milestones and see how the discussion goes in the BOF before >> deciding which way this should go. >> >> I'd like to see more consideration around the issues of designing a >> codec that did a good job of mapping a real time stream onto IP >> packets. The way IP deals with packet loss and congestion has >> implications for designing a codec that works well over IP. I know >> some of the discussion I have had off list people talked about how we >> wanted a codec that supported adaptive bit rates that could change on >> the fly to be able to work well on an IP network. >> >> I will be working the folks to make sure the agenda has time to >> directly address the key topics which include (more may be coming): >> >> Will we be able to get qualified people to do and review the work? >> >> Key design goals of a new codec? >> >> Do we need a new codec or are there already ones defined that meet the >> needs? >> >> I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. >> >> Thanks, >> >> Cullen >> >> >> >> >> >> _______________________________________________ >> 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 >> >> >> >> >> > > _______________________________________________ > 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_C65FB5574338hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] RE=A0: Codec BOF approved, much work needed My sincere apology for continuing this discussion, b= ut this I cannot let this pass:

>We all know that the PSTN has a reliability of about 99.999%.

During the major cat= astrophes here in the last 10 years the PSTN was out of service for days an= d weeks and the only communications that worked were over the Internet. During the 1st few days of the hurricane Katrina the mayor of New Orleans t= alked to the president using VoIP with WiFi access.

Thanks, Henry


On 6/18/09 8:51 AM, "Christian Hoene" <hoene@uni-tuebingen.de> wrote:

I = do have the opinion that a main design metric beside audio quality, complex= ity, costs, and delay shall be reliability.
 
We all know that the PSTN has a reliability of about 99.999%. If designing = a reliable Audio over IP codec, we shall consider to make it as robust as p= ossible. Robust not only against packet losses but also for periods of low = bandwidth.
 
To make a system reliability, you must make it aware of this failures and t= ry to cope smartly with them. Thus, a codec which is aware of the packet lo= ss rate, shall decrease its bit/frame rates. Also, if it operates in the pr= esence of very high packet losses it stops, it make sense to switch off the= sending of the audio stream. (The encoder might then send a busy signal)  
The mean availability of the audio transmissions, calculated over all users= , might be one of the metrics for assessing the performance of an Internet = audio codec.
 
Christian
 
 

From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Thursday, June 18, 2009 3:34 PM
To: Dr. Christian Hoene; Koen Vos
Cc: codec@ietf.org
Subject: Re: [codec] RE : Codec BOF approved, much work needed
>MOS 3.5?

It appears MOS metrics are obsolete and inadequate for BB Internet, Telepre= sence (mostly for business) and Digital Living Room (mostly for consumer). = The highest MOS is 5.0 aspired for 3.1 kHz telephony :-)

Also, how do you accommodate metrics for cut-offs of entire sentences, as i= s the case for congested narrowband channels?

Are there better metrics?

Henry

On 6/18/09 3:34 AM, "Dr. Christian Hoene" <hoene@uni-tuebingen.de> wrote:
In order to support a high degree of reliability and available, I
think the audio codec should support an acceptable operation mode even
if the bandwidth is low. If the ultra low delay music transmission is
not possible, the codec shall degrade to 25ms delayed music
transmission and further degrade to speech quality.

Jean-Marc: What is the coding rate of CELT, if it shall transmit voice
at a quality of about MOS 3.5?




> Quoting Henry Sinnreich:
>> As for supporting bandwidth constrained links, where congestion ca= n
>> occur, I believe the mobile phone industry has already done a good=
>> job that we need not duplicate.
>
> Mobile phones use codecs that are expensive and complex to license tho= ugh.
> And audio quality on mobile phones is mediocre or worse.
>
> koen.
>
>
>
>> Given the choice between designing for narrowband links and
>> broadband Internet, let's chose therefore broadband.
>>
>> Henry
>>
>> On 6/16/09 9:41 PM, "Jean-Marc Valin" <jean-marc.valin@octasic.com> wrote:
>>
>> For wideband (16 kHz sampling), I think speech-only (ideally
>> without mutilating background music) is sufficient. However, for <= BR> >> super wideband (32 kHz and up), I think it's important to start >> supporting music. When it comes to latency (by that I mean the >> codec's algorithmic delay), the lower the better. I consider
>> anything above ~40 ms to be unacceptable (ruling out Vorbis, MP3 <= BR> >> and standard AAC), but it should ideally be lower than that. The <= BR> >> lower the delay, the less problems you have with acoustic echo. >>
>>   Jean-Marc
>>
>> -------- Message d'origine--------
>> De: codec-bounces@ietf.org = de la part de Henry Sinnreich
>> Date: mar. 16/06/2009 18:31
>> À: Sandy (Alexander) MacInnis; c= odec@ietf.org; Slava Borilin; Roni Even
>> Objet : Re: [codec] Codec BOF approved, much work needed
>>
>>> Are we talking here about speech, or generic audio?
>>
>> As Slava has pointed out it is about wideband speech, that is the =
>> low latency (150ms or so) still applies, but having wideband audio=
>> (8-16 kHz audio BW) and why not, stereo. All this and many other <= BR> >> however is to be worked out in the proposed Internet Codec WG.
>>
>> Henry
>>
>>
>> On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis"
>> <macinnis@broadcom.com>= ; wrote:
>>
>> Are we talking here about speech, or generic audio?
>>
>> There's a difference in terms of coding (bit rate, quality, etc.) =
>> and in terms of applicability.
>>
>> Or do we want both, i.e. two codecs?
>>
>> --Sandy
>>
>>
>> ________________________________
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org<= /a>] On
>> Behalf Of Henry Sinnreich
>> Sent: Tuesday, June 16, 2009 6:15 PM
>> To: Slava Borilin; Roni Even; codec@iet= f.org
>> Subject: Re: [codec] Codec BOF approved, much work needed
>>
>> Dear Slava,
>>
>>> We are talking not about "enabling technology" to ma= ke everyone
>>> understand each other (email case),
>>> but "enhancement" -  everyone can today underst= and each other via
>>> 711 or 722, but we want to push the quality bar while keeping = the
>>> interop.
>>
>> This is an excellent point. We are talking about the Internet here=
>> in in the IETF.
>>
>> Henry
>>
>>
>> On 6/16/09 4:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
>>
>> Dear Henry,
>>
>> It is probably not the same  as with email (or maybe just tim= ing is
>> different).
>> We are talking not about  "enabling technology" to = make everyone
>> understand each other (email case), but  "enhancement&qu= ot; -  everyone
>> can today understand each other via 711 or 722,  but we want = to
>> push the quality bar while keeping the interop.
>>
>> So  really the magic question is that once we have the agreem= ent on
>> "recommended"  IWAC- either one or several (agree w= ith Jean-Marc),
>> who is to  enforce?
>> PROBABLY the force to enforce are telecom operators?
>> As  telco, against internet companies (Cisco, Skype, MSFT, et= c), do
>> not like  walled gardens by definition:
>> - The telco landscape is not (well, not  only) Skype/cheap IP= calls
>> versus Cellular or Wireline.
>> - The  mid-term battle is between internet and its rich
>> communication techniques (web  conferencing, social networkin= g) and
>>  telco's phone-only  service.
>> - Battle is not only for call $$, but for the time spent on  = the
>> media (trend is users spending more minutes on internet comms then=
>> on  phones)
>> - so carriers have to move from NGN core networks to offer  <= BR> >> IP-based "social network-like" communication models to s= ubscribers,
>> therefore,  have IP-service at the last mile for the user, an= d not
>> only for enterprise  IP-phones, but every consumer.
>> - And as Telco need subscribers to pay for  the service, here= comes
>> the HD(=3Dwideband + packet loss robustness), as the  necessa= ry step
>> to keep user satisfied with the carrier IP-service.
>> - So  actually, HD sounds to be the cornerstone for keeping t= he
>> landscape of whole  Telco industry versus Internet communicat= ions
>> (or vice versa).
>> - so for  telcos it will be really important to have IWAC RFC= and
>> telcos have the power  to enforce using it (via geo or indust= ry
>> forums - examples are PAL/NTSC in  geo, industry - CableLabs)= , and
>> they are used to the standard/certification  process?
>>
>> Again, apart from the ambitions, what all of us (as  vendors = and as
>> users) would like to achieve, is interop.
>> And interop  should, probably, be enforced, not "recomme= nded" via
>> some sort of  certification?
>>
>> Everyone, please  advice.
>>
>>
>> regards,
>> Slava  Borilin
>>
>>
>> ________________________________
>>
>> From: Henry Sinnreich [mailt= o:hsinnrei@adobe.com]
>> Sent: Wednesday, June 17, 2009 1:33 AM
>> To: Slava Borilin;  Roni Even; cod= ec@ietf.org
>> Subject: Re:  [codec] Codec BOF approved, much work needed >>
>> Hi  Slava,
>>
>>> Currently in the internet communications (web collaboration, &= nbsp;voip
>>> services, videoconferencing) -
>>> do you believe is there any force  to push interop, or ev= eryone
>>> "plays in his own walled garden"?
>>
>> IMO one  of the main the strengths of the Internet is its glo= bal
>> reach. The user can be  anywhere and reach content from and <= BR> >> communicate with anyone, anywhere. Just  like we are doing he= re
>> with email.
>> The Internet codec will hopefully do for  voice the same as t= ext
>> communications + attachments work in  email.
>>
>>> sorry if this is naïve
>> This applies to my message as well  :-)
>>
>> Henry
>>
>> On 6/16/09 3:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
>> Roni, and  whole international team,
>>
>> I have one more question here - sorry if this  is naïve-= but still
>> please advice.
>>
>> Background: all of us do wish wish  wish (vendors, customers,=
>> end-users, etc) to have ONE IWAC (internet wideband  audio co= dec)
>> for all.
>>
>> But assuming we (IETF) will come to the agreement  which code= c we
>> like best (existing or new one) and make RFC.
>> What will then  be the destiny of the that RFC?
>> And who and why should be choosing the  certain codec into th= eir app?
>>
>> Afaik IETF, like ITU just "agree on the  specs", wh= ile industry or
>> country-specific organizations are enforcing using  or not us= ing
>> certain standards, like CableLabs (Vertical market +  geograp= hy).
>>
>> The major driver for agreeing on the standard is interop,  as= I see.
>> Currently in the internet communications (web collaboration, voip =  
>> services, videoconferencing) - do you believe is there any force t= o
>> push  interop, or everyone "plays in his own walled gard= en"?
>>
>> Should we:
>> -  agree on RFC and then dig into smaller (geographical or ve= rtical
>> industry)  communities to push them to force using this RFC (= IWAC)
>> as part of  certification to make sure they do enforce the IW= AC?
>> - or we should just  have IWAC RFC and believe "better s= taff will
>> find its way to the market  itself"?
>>
>> regards,
>> Slava Borilin
>>
>>
>> -----Original  Message-----
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org<= /a>] On  
>> Behalf Of Roni Even
>> Sent: Friday, June 12, 2009 10:56 PM
>> To: codec@ietf.org
>> Subject: Re: [codec] Codec BOF  approved, much work needed >>
>> Hi,
>> I would like to suggest other key  topics for the BOF
>>
>> 1. Why should the IETF start a codec WG - why not do  it as I= TU / MPEG /
>> others
>>
>> 2. Describe the process of defining a  codec in other standar= d bodies - my
>> view is that not everyone knows what is  required to create a= quality codec.
>>
>> 3. Is the purpose of the WG to  publish one codec or multiple=
>> codecs based on
>> different  requirements.
>>
>> 4. If a WG will be formed there are more decision to make  li= ke, what is the
>> selection criteria if there is more than one candidate or  do= we
>> require some
>> cooperation, what are the deliverable - source code,  encoder= specification
>> (do we require bit exactness ), how to defines the  quality t= ests and
>> evaluate the results to check if the codec addresses the  req= uirements.
>>
>> Roni Even
>>
>>
>>
>> -----Original  Message-----
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org<= /a>] On  Behalf Of
>> Cullen Jennings
>> Sent: Friday, June 12, 2009 8:32 PM
>> To: codec@ietf.org
>> Subject: [codec] Codec BOF  approved, much work needed
>>
>>
>> I have approved the CODEC BOF proposal.  However, we need a b= unch of
>> work to get ready.  Various people on  IESG/IAB were not= comfortable
>> with the current charter and agenda so we  need to work on th= eses
>> before the meeting.
>>
>> A draft agenda/charter  Jason provided are at
>>
>> Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agen= da.txt
>>
>> Charter:  http://svn.resiprocate.org/rep/ietf-drafts/codec-= bof/charter.txt
>>
>> After  discussion with the IESG/IAB:
>>
>> I'd like to remove the "as Proposed  Standard" from= the charter text
>> for both milestones and see how the  discussion goes in the B= OF before
>> deciding which way this should  go.
>>
>> I'd like to see more consideration around the issues of designing = a
>> codec that did a good job of mapping a real time stream onto IP >> packets. The way IP deals with packet loss and congestion has
>> implications for designing a codec that works well over IP. I know=
>> some of the discussion I have had off list people talked about how= we
>> wanted a codec that supported adaptive bit rates that could change= on
>> the fly to be able to work well on an IP network.
>>
>> I will be working  the folks to make sure the agenda has time= to
>> directly address the key  topics which include (more may be c= oming):
>>
>> Will we be able to get  qualified people to do and review the= work?
>>
>> Key design goals of a new  codec?
>>
>> Do we need a new codec or are there already ones defined that &nbs= p;meet the
>> needs?
>>
>> I have asked Jason Fischl  and Jean-Marc Valin  to co-ch= air this BOF.
>>
>> Thanks,
>>
>> Cullen <RAI  AD>
>>
>>
>>
>>
>>
>> _______________________________________________
>> codec  mailing list
>> codec@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/codec
>>
>> _______________________________________________
>> codec  mailing list
>> codec@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/codec
>> _______________________________________________
>> codec  mailing list
>> codec@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/codec
>>
>>
>>
>>
>>
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ie= tf.org/mailman/listinfo/codec
>

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

--_000_C65FB5574338hsinnreiadobecom_-- From tme@americafree.tv Thu Jun 18 07:24:06 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 AC6BF28C316 for ; Thu, 18 Jun 2009 07:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.241 X-Spam-Level: X-Spam-Status: No, score=-1.241 tagged_above=-999 required=5 tests=[AWL=-1.397, BAYES_00=-2.599, FRT_ADOBE2=2.455, MIME_8BIT_HEADER=0.3] 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 k+JUkuRXONbo for ; Thu, 18 Jun 2009 07:24:05 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 0D7A43A6CA5 for ; Thu, 18 Jun 2009 07:23:37 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id E26B340A9A90; Thu, 18 Jun 2009 10:23:46 -0400 (EDT) Message-Id: <580FC3FB-3EC9-4845-A8CA-9C6F415D7478@americafree.tv> From: Marshall Eubanks To: Henry Sinnreich In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 18 Jun 2009 10:23:44 -0400 References: X-Mailer: Apple Mail (2.935.3) Cc: "codec@ietf.org" Subject: Re: [codec] =?iso-8859-1?q?RE=A0=3A_Codec_BOF_approved=2C_much_work_n?= =?iso-8859-1?q?eeded?= 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, 18 Jun 2009 14:24:06 -0000 On Jun 18, 2009, at 10:11 AM, Henry Sinnreich wrote: > My sincere apology for continuing this discussion, but this I cannot =20= > let this pass: > > >We all know that the PSTN has a reliability of about 99.999%. > Every time my phone service has been out in the last decade, I was =20 told that that didn't count against 99.999%, so I regard that as marketing, not engineering. Regards Marshall > During the major catastrophes here in the last 10 years the PSTN was =20= > out of service for days and weeks and the only communications that =20 > worked were over the Internet. > During the 1st few days of the hurricane Katrina the mayor of New =20 > Orleans talked to the president using VoIP with WiFi access. > > Thanks, Henry > > > On 6/18/09 8:51 AM, "Christian Hoene" wrote: > > I do have the opinion that a main design metric beside audio =20 > quality, complexity, costs, and delay shall be reliability. > > We all know that the PSTN has a reliability of about 99.999%. If =20 > designing a reliable Audio over IP codec, we shall consider to make =20= > it as robust as possible. Robust not only against packet losses but =20= > also for periods of low bandwidth. > > To make a system reliability, you must make it aware of this =20 > failures and try to cope smartly with them. Thus, a codec which is =20 > aware of the packet loss rate, shall decrease its bit/frame rates. =20 > Also, if it operates in the presence of very high packet losses it =20 > stops, it make sense to switch off the sending of the audio stream. =20= > (The encoder might then send a busy signal) > > The mean availability of the audio transmissions, calculated over =20 > all users, might be one of the metrics for assessing the performance =20= > of an Internet audio codec. > > Christian > > > > From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > Sent: Thursday, June 18, 2009 3:34 PM > To: Dr. Christian Hoene; Koen Vos > Cc: codec@ietf.org > Subject: Re: [codec] RE : Codec BOF approved, much work needed > > >MOS 3.5? > > It appears MOS metrics are obsolete and inadequate for BB Internet, =20= > Telepresence (mostly for business) and Digital Living Room (mostly =20 > for consumer). The highest MOS is 5.0 aspired for 3.1 kHz =20 > telephony :-) > > Also, how do you accommodate metrics for cut-offs of entire =20 > sentences, as is the case for congested narrowband channels? > > Are there better metrics? > > Henry > > On 6/18/09 3:34 AM, "Dr. Christian Hoene" =20 > wrote: > In order to support a high degree of reliability and available, I > think the audio codec should support an acceptable operation mode even > if the bandwidth is low. If the ultra low delay music transmission is > not possible, the codec shall degrade to 25ms delayed music > transmission and further degrade to speech quality. > > Jean-Marc: What is the coding rate of CELT, if it shall transmit voice > at a quality of about MOS 3.5? > > > > > > Quoting Henry Sinnreich: > >> As for supporting bandwidth constrained links, where congestion can > >> occur, I believe the mobile phone industry has already done a good > >> job that we need not duplicate. > > > > Mobile phones use codecs that are expensive and complex to license =20= > though. > > And audio quality on mobile phones is mediocre or worse. > > > > koen. > > > > > > > >> Given the choice between designing for narrowband links and > >> broadband Internet, let's chose therefore broadband. > >> > >> Henry > >> > >> On 6/16/09 9:41 PM, "Jean-Marc Valin" marc.valin@octasic.com> wrote: > >> > >> For wideband (16 kHz sampling), I think speech-only (ideally > >> without mutilating background music) is sufficient. However, for > >> super wideband (32 kHz and up), I think it's important to start > >> supporting music. When it comes to latency (by that I mean the > >> codec's algorithmic delay), the lower the better. I consider > >> anything above ~40 ms to be unacceptable (ruling out Vorbis, MP3 > >> and standard AAC), but it should ideally be lower than that. The > >> lower the delay, the less problems you have with acoustic echo. > >> > >> Jean-Marc > >> > >> -------- Message d'origine-------- > >> De: codec-bounces@ietf.org de la part de Henry Sinnreich > >> Date: mar. 16/06/2009 18:31 > >> =C0: Sandy (Alexander) MacInnis; codec@ietf.org; Slava Borilin; =20 > Roni Even > >> Objet : Re: [codec] Codec BOF approved, much work needed > >> > >>> Are we talking here about speech, or generic audio? > >> > >> As Slava has pointed out it is about wideband speech, that is the > >> low latency (150ms or so) still applies, but having wideband audio > >> (8-16 kHz audio BW) and why not, stereo. All this and many other > >> however is to be worked out in the proposed Internet Codec WG. > >> > >> Henry > >> > >> > >> On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis" > >> wrote: > >> > >> Are we talking here about speech, or generic audio? > >> > >> There's a difference in terms of coding (bit rate, quality, etc.) > >> and in terms of applicability. > >> > >> Or do we want both, i.e. two codecs? > >> > >> --Sandy > >> > >> > >> ________________________________ > >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > >> Behalf Of Henry Sinnreich > >> Sent: Tuesday, June 16, 2009 6:15 PM > >> To: Slava Borilin; Roni Even; codec@ietf.org > >> Subject: Re: [codec] Codec BOF approved, much work needed > >> > >> Dear Slava, > >> > >>> We are talking not about "enabling technology" to make everyone > >>> understand each other (email case), > >>> but "enhancement" - everyone can today understand each other via > >>> 711 or 722, but we want to push the quality bar while keeping the > >>> interop. > >> > >> This is an excellent point. We are talking about the Internet here > >> in in the IETF. > >> > >> Henry > >> > >> > >> On 6/16/09 4:56 PM, "Slava Borilin" wrote: > >> > >> Dear Henry, > >> > >> It is probably not the same as with email (or maybe just timing is > >> different). > >> We are talking not about "enabling technology" to make everyone > >> understand each other (email case), but "enhancement" - everyone > >> can today understand each other via 711 or 722, but we want to > >> push the quality bar while keeping the interop. > >> > >> So really the magic question is that once we have the agreement on > >> "recommended" IWAC- either one or several (agree with Jean-Marc), > >> who is to enforce? > >> PROBABLY the force to enforce are telecom operators? > >> As telco, against internet companies (Cisco, Skype, MSFT, etc), do > >> not like walled gardens by definition: > >> - The telco landscape is not (well, not only) Skype/cheap IP calls > >> versus Cellular or Wireline. > >> - The mid-term battle is between internet and its rich > >> communication techniques (web conferencing, social networking) and > >> telco's phone-only service. > >> - Battle is not only for call $$, but for the time spent on the > >> media (trend is users spending more minutes on internet comms then > >> on phones) > >> - so carriers have to move from NGN core networks to offer > >> IP-based "social network-like" communication models to subscribers, > >> therefore, have IP-service at the last mile for the user, and not > >> only for enterprise IP-phones, but every consumer. > >> - And as Telco need subscribers to pay for the service, here comes > >> the HD(=3Dwideband + packet loss robustness), as the necessary = step > >> to keep user satisfied with the carrier IP-service. > >> - So actually, HD sounds to be the cornerstone for keeping the > >> landscape of whole Telco industry versus Internet communications > >> (or vice versa). > >> - so for telcos it will be really important to have IWAC RFC and > >> telcos have the power to enforce using it (via geo or industry > >> forums - examples are PAL/NTSC in geo, industry - CableLabs), and > >> they are used to the standard/certification process? > >> > >> Again, apart from the ambitions, what all of us (as vendors and as > >> users) would like to achieve, is interop. > >> And interop should, probably, be enforced, not "recommended" via > >> some sort of certification? > >> > >> Everyone, please advice. > >> > >> > >> regards, > >> Slava Borilin > >> > >> > >> ________________________________ > >> > >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] > >> Sent: Wednesday, June 17, 2009 1:33 AM > >> To: Slava Borilin; Roni Even; codec@ietf.org > >> Subject: Re: [codec] Codec BOF approved, much work needed > >> > >> Hi Slava, > >> > >>> Currently in the internet communications (web collaboration, voip > >>> services, videoconferencing) - > >>> do you believe is there any force to push interop, or everyone > >>> "plays in his own walled garden"? > >> > >> IMO one of the main the strengths of the Internet is its global > >> reach. The user can be anywhere and reach content from and > >> communicate with anyone, anywhere. Just like we are doing here > >> with email. > >> The Internet codec will hopefully do for voice the same as text > >> communications + attachments work in email. > >> > >>> sorry if this is na=EFve > >> This applies to my message as well :-) > >> > >> Henry > >> > >> On 6/16/09 3:56 PM, "Slava Borilin" wrote: > >> Roni, and whole international team, > >> > >> I have one more question here - sorry if this is na=EFve- but = still > >> please advice. > >> > >> Background: all of us do wish wish wish (vendors, customers, > >> end-users, etc) to have ONE IWAC (internet wideband audio codec) > >> for all. > >> > >> But assuming we (IETF) will come to the agreement which codec we > >> like best (existing or new one) and make RFC. > >> What will then be the destiny of the that RFC? > >> And who and why should be choosing the certain codec into their =20= > app? > >> > >> Afaik IETF, like ITU just "agree on the specs", while industry or > >> country-specific organizations are enforcing using or not using > >> certain standards, like CableLabs (Vertical market + geography). > >> > >> The major driver for agreeing on the standard is interop, as I =20 > see. > >> Currently in the internet communications (web collaboration, voip > >> services, videoconferencing) - do you believe is there any force to > >> push interop, or everyone "plays in his own walled garden"? > >> > >> Should we: > >> - agree on RFC and then dig into smaller (geographical or vertical > >> industry) communities to push them to force using this RFC (IWAC) > >> as part of certification to make sure they do enforce the IWAC? > >> - or we should just have IWAC RFC and believe "better staff will > >> find its way to the market itself"? > >> > >> regards, > >> Slava Borilin > >> > >> > >> -----Original Message----- > >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > >> Behalf Of Roni Even > >> Sent: Friday, June 12, 2009 10:56 PM > >> To: codec@ietf.org > >> Subject: Re: [codec] Codec BOF approved, much work needed > >> > >> Hi, > >> I would like to suggest other key topics for the BOF > >> > >> 1. Why should the IETF start a codec WG - why not do it as ITU / =20= > MPEG / > >> others > >> > >> 2. Describe the process of defining a codec in other standard =20 > bodies - my > >> view is that not everyone knows what is required to create a =20 > quality codec. > >> > >> 3. Is the purpose of the WG to publish one codec or multiple > >> codecs based on > >> different requirements. > >> > >> 4. If a WG will be formed there are more decision to make like, =20= > what is the > >> selection criteria if there is more than one candidate or do we > >> require some > >> cooperation, what are the deliverable - source code, encoder =20 > specification > >> (do we require bit exactness ), how to defines the quality tests =20= > and > >> evaluate the results to check if the codec addresses the =20 > requirements. > >> > >> Roni Even > >> > >> > >> > >> -----Original Message----- > >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20= > Behalf Of > >> Cullen Jennings > >> Sent: Friday, June 12, 2009 8:32 PM > >> To: codec@ietf.org > >> Subject: [codec] Codec BOF approved, much work needed > >> > >> > >> I have approved the CODEC BOF proposal. However, we need a bunch =20= > of > >> work to get ready. Various people on IESG/IAB were not =20 > comfortable > >> with the current charter and agenda so we need to work on theses > >> before the meeting. > >> > >> A draft agenda/charter Jason provided are at > >> > >> Agenda: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > >> > >> Charter: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt > >> > >> After discussion with the IESG/IAB: > >> > >> I'd like to remove the "as Proposed Standard" from the charter =20 > text > >> for both milestones and see how the discussion goes in the BOF =20 > before > >> deciding which way this should go. > >> > >> I'd like to see more consideration around the issues of designing a > >> codec that did a good job of mapping a real time stream onto IP > >> packets. The way IP deals with packet loss and congestion has > >> implications for designing a codec that works well over IP. I know > >> some of the discussion I have had off list people talked about =20 > how we > >> wanted a codec that supported adaptive bit rates that could =20 > change on > >> the fly to be able to work well on an IP network. > >> > >> I will be working the folks to make sure the agenda has time to > >> directly address the key topics which include (more may be =20 > coming): > >> > >> Will we be able to get qualified people to do and review the work? > >> > >> Key design goals of a new codec? > >> > >> Do we need a new codec or are there already ones defined that =20 > meet the > >> needs? > >> > >> I have asked Jason Fischl and Jean-Marc Valin to co-chair this =20= > BOF. > >> > >> Thanks, > >> > >> Cullen > >> > >> > >> > >> > >> > >> _______________________________________________ > >> 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 > >> > >> > >> > >> > >> > > > > _______________________________________________ > > 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 hsinnrei@adobe.com Thu Jun 18 07:28: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 594D828C338 for ; Thu, 18 Jun 2009 07:28:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.413 X-Spam-Level: X-Spam-Status: No, score=-4.413 tagged_above=-999 required=5 tests=[AWL=-0.570, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 XUAtGmWQPJax for ; Thu, 18 Jun 2009 07:28:32 -0700 (PDT) Received: from exprod6og101.obsmtp.com (exprod6og101.obsmtp.com [64.18.1.181]) by core3.amsl.com (Postfix) with ESMTP id 2E03128C340 for ; Thu, 18 Jun 2009 07:28:31 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob101.postini.com ([64.18.5.12]) with SMTP ID DSNKSjpPEH332x3IMm+Bs1/MbH4n3OX+2lPG@postini.com; Thu, 18 Jun 2009 07:28:44 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5IESOWG013236; Thu, 18 Jun 2009 07:28:25 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5IESNiq025661; Thu, 18 Jun 2009 07:28:23 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Thu, 18 Jun 2009 07:28:23 -0700 From: Henry Sinnreich To: Slava Borilin , "Dr. Christian Hoene" , Koen Vos Date: Thu, 18 Jun 2009 07:28:20 -0700 Thread-Topic: =?iso-8859-1?Q?[codec]RE=A0:_Codec_BOF_approved, _much_work_needed?= Thread-Index: Acnv74/EOPinVpyIRQSmEiAopWXOHwAKdFKoAABiWSAAAYcokw== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C65FB9344346hsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] =?iso-8859-1?q?RE=A0=3A_Codec_BOF_approved=2C_much_work_n?= =?iso-8859-1?q?eeded?= 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, 18 Jun 2009 14:28:45 -0000 --_000_C65FB9344346hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Does it make sense to discuss the possible control channel inside the codec= ? Henry On 6/18/09 8:56 AM, "Slava Borilin" wrote: For congested networks - I assume that the way to judge the codec is to jud= ge the MOS over TIA-921 network profiles (that's what we use) which covers = realistic packet loss and congestion scenarios, and not just "average norma= lly distributed XX% packet loss". However, the reality is that while making the comparison, one will actually= test the whole voice engine, not just the codec inside it. And normally codec and voiceengine are separate potions of the voip solutio= n. It is probably possible to test different codecs within the same voiceeenig= ne, to get the comparative data. I doubt however, that we can have a codec which does "adapt" to network its= elf, without upper level (signaling, statistics, etc) And the scope of designing the complete voiceengine and not just codec part= of it, is so much more complex that I do not believe we should even try it= . regards, Slava Borilin ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of H= enry Sinnreich Sent: Thursday, June 18, 2009 5:34 PM To: Dr. Christian Hoene; Koen Vos Cc: codec@ietf.org Subject: Re: [codec]RE : Codec BOF approved, much work needed >MOS 3.5? It appears MOS metrics are obsolete and inadequate for BB Internet, Telepre= sence (mostly for business) and Digital Living Room (mostly for consumer). = The highest MOS is 5.0 aspired for 3.1 kHz telephony :-) Also, how do you accommodate metrics for cut-offs of entire sentences, as i= s the case for congested narrowband channels? Are there better metrics? Henry On 6/18/09 3:34 AM, "Dr. Christian Hoene" wrote: In order to support a high degree of reliability and available, I think the audio codec should support an acceptable operation mode even if the bandwidth is low. If the ultra low delay music transmission is not possible, the codec shall degrade to 25ms delayed music transmission and further degrade to speech quality. Jean-Marc: What is the coding rate of CELT, if it shall transmit voice at a quality of about MOS 3.5? > Quoting Henry Sinnreich: >> As for supporting bandwidth constrained links, where congestion can >> occur, I believe the mobile phone industry has already done a good >> job that we need not duplicate. > > Mobile phones use codecs that are expensive and complex to license though= . > And audio quality on mobile phones is mediocre or worse. > > koen. > > > >> Given the choice between designing for narrowband links and >> broadband Internet, let's chose therefore broadband. >> >> Henry >> >> On 6/16/09 9:41 PM, "Jean-Marc Valin" wrot= e: >> >> For wideband (16 kHz sampling), I think speech-only (ideally >> without mutilating background music) is sufficient. However, for >> super wideband (32 kHz and up), I think it's important to start >> supporting music. When it comes to latency (by that I mean the >> codec's algorithmic delay), the lower the better. I consider >> anything above ~40 ms to be unacceptable (ruling out Vorbis, MP3 >> and standard AAC), but it should ideally be lower than that. The >> lower the delay, the less problems you have with acoustic echo. >> >> Jean-Marc >> >> -------- Message d'origine-------- >> De: codec-bounces@ietf.org de la part de Henry Sinnreich >> Date: mar. 16/06/2009 18:31 >> =C0: Sandy (Alexander) MacInnis; codec@ietf.org; Slava Borilin; Roni Eve= n >> Objet : Re: [codec] Codec BOF approved, much work needed >> >>> Are we talking here about speech, or generic audio? >> >> As Slava has pointed out it is about wideband speech, that is the >> low latency (150ms or so) still applies, but having wideband audio >> (8-16 kHz audio BW) and why not, stereo. All this and many other >> however is to be worked out in the proposed Internet Codec WG. >> >> Henry >> >> >> On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis" >> wrote: >> >> Are we talking here about speech, or generic audio? >> >> There's a difference in terms of coding (bit rate, quality, etc.) >> and in terms of applicability. >> >> Or do we want both, i.e. two codecs? >> >> --Sandy >> >> >> ________________________________ >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >> Behalf Of Henry Sinnreich >> Sent: Tuesday, June 16, 2009 6:15 PM >> To: Slava Borilin; Roni Even; codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Dear Slava, >> >>> We are talking not about "enabling technology" to make everyone >>> understand each other (email case), >>> but "enhancement" - everyone can today understand each other via >>> 711 or 722, but we want to push the quality bar while keeping the >>> interop. >> >> This is an excellent point. We are talking about the Internet here >> in in the IETF. >> >> Henry >> >> >> On 6/16/09 4:56 PM, "Slava Borilin" wrote: >> >> Dear Henry, >> >> It is probably not the same as with email (or maybe just timing is >> different). >> We are talking not about "enabling technology" to make everyone >> understand each other (email case), but "enhancement" - everyone >> can today understand each other via 711 or 722, but we want to >> push the quality bar while keeping the interop. >> >> So really the magic question is that once we have the agreement on >> "recommended" IWAC- either one or several (agree with Jean-Marc), >> who is to enforce? >> PROBABLY the force to enforce are telecom operators? >> As telco, against internet companies (Cisco, Skype, MSFT, etc), do >> not like walled gardens by definition: >> - The telco landscape is not (well, not only) Skype/cheap IP calls >> versus Cellular or Wireline. >> - The mid-term battle is between internet and its rich >> communication techniques (web conferencing, social networking) and >> telco's phone-only service. >> - Battle is not only for call $$, but for the time spent on the >> media (trend is users spending more minutes on internet comms then >> on phones) >> - so carriers have to move from NGN core networks to offer >> IP-based "social network-like" communication models to subscribers, >> therefore, have IP-service at the last mile for the user, and not >> only for enterprise IP-phones, but every consumer. >> - And as Telco need subscribers to pay for the service, here comes >> the HD(=3Dwideband + packet loss robustness), as the necessary step >> to keep user satisfied with the carrier IP-service. >> - So actually, HD sounds to be the cornerstone for keeping the >> landscape of whole Telco industry versus Internet communications >> (or vice versa). >> - so for telcos it will be really important to have IWAC RFC and >> telcos have the power to enforce using it (via geo or industry >> forums - examples are PAL/NTSC in geo, industry - CableLabs), and >> they are used to the standard/certification process? >> >> Again, apart from the ambitions, what all of us (as vendors and as >> users) would like to achieve, is interop. >> And interop should, probably, be enforced, not "recommended" via >> some sort of certification? >> >> Everyone, please advice. >> >> >> regards, >> Slava Borilin >> >> >> ________________________________ >> >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Sent: Wednesday, June 17, 2009 1:33 AM >> To: Slava Borilin; Roni Even; codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Hi Slava, >> >>> Currently in the internet communications (web collaboration, voip >>> services, videoconferencing) - >>> do you believe is there any force to push interop, or everyone >>> "plays in his own walled garden"? >> >> IMO one of the main the strengths of the Internet is its global >> reach. The user can be anywhere and reach content from and >> communicate with anyone, anywhere. Just like we are doing here >> with email. >> The Internet codec will hopefully do for voice the same as text >> communications + attachments work in email. >> >>> sorry if this is na=EFve >> This applies to my message as well :-) >> >> Henry >> >> On 6/16/09 3:56 PM, "Slava Borilin" wrote: >> Roni, and whole international team, >> >> I have one more question here - sorry if this is na=EFve- but still >> please advice. >> >> Background: all of us do wish wish wish (vendors, customers, >> end-users, etc) to have ONE IWAC (internet wideband audio codec) >> for all. >> >> But assuming we (IETF) will come to the agreement which codec we >> like best (existing or new one) and make RFC. >> What will then be the destiny of the that RFC? >> And who and why should be choosing the certain codec into their app? >> >> Afaik IETF, like ITU just "agree on the specs", while industry or >> country-specific organizations are enforcing using or not using >> certain standards, like CableLabs (Vertical market + geography). >> >> The major driver for agreeing on the standard is interop, as I see. >> Currently in the internet communications (web collaboration, voip >> services, videoconferencing) - do you believe is there any force to >> push interop, or everyone "plays in his own walled garden"? >> >> Should we: >> - agree on RFC and then dig into smaller (geographical or vertical >> industry) communities to push them to force using this RFC (IWAC) >> as part of certification to make sure they do enforce the IWAC? >> - or we should just have IWAC RFC and believe "better staff will >> find its way to the market itself"? >> >> regards, >> Slava Borilin >> >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >> Behalf Of Roni Even >> Sent: Friday, June 12, 2009 10:56 PM >> To: codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Hi, >> I would like to suggest other key topics for the BOF >> >> 1. Why should the IETF start a codec WG - why not do it as ITU / MPEG / >> others >> >> 2. Describe the process of defining a codec in other standard bodies - = my >> view is that not everyone knows what is required to create a quality co= dec. >> >> 3. Is the purpose of the WG to publish one codec or multiple >> codecs based on >> different requirements. >> >> 4. If a WG will be formed there are more decision to make like, what is= the >> selection criteria if there is more than one candidate or do we >> require some >> cooperation, what are the deliverable - source code, encoder specificat= ion >> (do we require bit exactness ), how to defines the quality tests and >> evaluate the results to check if the codec addresses the requirements. >> >> Roni Even >> >> >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of >> Cullen Jennings >> Sent: Friday, June 12, 2009 8:32 PM >> To: codec@ietf.org >> Subject: [codec] Codec BOF approved, much work needed >> >> >> I have approved the CODEC BOF proposal. However, we need a bunch of >> work to get ready. Various people on IESG/IAB were not comfortable >> with the current charter and agenda so we need to work on theses >> before the meeting. >> >> A draft agenda/charter Jason provided are at >> >> Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt >> >> Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.t= xt >> >> After discussion with the IESG/IAB: >> >> I'd like to remove the "as Proposed Standard" from the charter text >> for both milestones and see how the discussion goes in the BOF before >> deciding which way this should go. >> >> I'd like to see more consideration around the issues of designing a >> codec that did a good job of mapping a real time stream onto IP >> packets. The way IP deals with packet loss and congestion has >> implications for designing a codec that works well over IP. I know >> some of the discussion I have had off list people talked about how we >> wanted a codec that supported adaptive bit rates that could change on >> the fly to be able to work well on an IP network. >> >> I will be working the folks to make sure the agenda has time to >> directly address the key topics which include (more may be coming): >> >> Will we be able to get qualified people to do and review the work? >> >> Key design goals of a new codec? >> >> Do we need a new codec or are there already ones defined that meet the >> needs? >> >> I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. >> >> Thanks, >> >> Cullen >> >> >> >> >> >> _______________________________________________ >> 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 >> >> >> >> >> > > _______________________________________________ > 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_C65FB9344346hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec]RE=A0: Codec BOF approved, much work needed Does it make sense to discuss the possible control channel inside the= codec?
Henry


On 6/18/09 8:56 AM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:

For congested networks - I assu= me that the way to judge the codec is to judge the MOS over TIA-921 network= profiles (that’s what we use) which covers realistic packet loss and= congestion scenarios, and not just “average normally distributed XX%= packet loss”.
 
However, the reality is that while making the comparison, one will actually= test the whole voice engine, not just the codec inside it.
And normally codec and voiceengine are separate potions of the voip solutio= n.
 
It is probably possible to test different codecs within the same voiceeenig= ne, to get the comparative data.
 
I doubt however, that we can have a codec which does “adapt” to= network itself, without upper level (signaling, statistics, etc)
And the scope of designing the complete voiceengine and not just codec part= of it, is so much more complex that I do not believe we should even try it= .
 

regards,
Slava Borilin

From: codec= -bounces@ietf.org [mailto:cod= ec-bounces@ietf.org] On Behalf Of Henry Sinnreich
Sent: Thursday, June 18, 2009 5:34 PM
To: Dr. Christian Hoene; Koen Vos
Cc: codec@ietf.org
Subject: Re: [codec]RE : Codec BOF approved, much work needed
>MOS 3.5?

It appears MOS metrics are obsolete and inadequate for BB Internet, Telepre= sence (mostly for business) and Digital Living Room (mostly for consumer). = The highest MOS is 5.0 aspired for 3.1 kHz telephony :-)

Also, how do you accommodate metrics for cut-offs of entire sentences, as i= s the case for congested narrowband channels?

Are there better metrics?

Henry

On 6/18/09 3:34 AM, "Dr. Christian Hoene" <hoene@uni-tuebingen.de> wrote:
In order to support a high degree of reliability and available, I
think the audio codec should support an acceptable operation mode even
if the bandwidth is low. If the ultra low delay music transmission is
not possible, the codec shall degrade to 25ms delayed music
transmission and further degrade to speech quality.

Jean-Marc: What is the coding rate of CELT, if it shall transmit voice
at a quality of about MOS 3.5?




> Quoting Henry Sinnreich:
>> As for supporting bandwidth constrained links, where congestion ca= n
>> occur, I believe the mobile phone industry has already done a good=
>> job that we need not duplicate.
>
> Mobile phones use codecs that are expensive and complex to license tho= ugh.
> And audio quality on mobile phones is mediocre or worse.
>
> koen.
>
>
>
>> Given the choice between designing for narrowband links and
>> broadband Internet, let's chose therefore broadband.
>>
>> Henry
>>
>> On 6/16/09 9:41 PM, "Jean-Marc Valin" <jean-marc.valin@octasic.com> wrote:
>>
>> For wideband (16 kHz sampling), I think speech-only (ideally
>> without mutilating background music) is sufficient. However, for <= BR> >> super wideband (32 kHz and up), I think it's important to start >> supporting music. When it comes to latency (by that I mean the >> codec's algorithmic delay), the lower the better. I consider
>> anything above ~40 ms to be unacceptable (ruling out Vorbis, MP3 <= BR> >> and standard AAC), but it should ideally be lower than that. The <= BR> >> lower the delay, the less problems you have with acoustic echo. >>
>>   Jean-Marc
>>
>> -------- Message d'origine--------
>> De: codec-bounces@ietf.org = de la part de Henry Sinnreich
>> Date: mar. 16/06/2009 18:31
>> À: Sandy (Alexander) MacInnis; c= odec@ietf.org; Slava Borilin; Roni Even
>> Objet : Re: [codec] Codec BOF approved, much work needed
>>
>>> Are we talking here about speech, or generic audio?
>>
>> As Slava has pointed out it is about wideband speech, that is the =
>> low latency (150ms or so) still applies, but having wideband audio=
>> (8-16 kHz audio BW) and why not, stereo. All this and many other <= BR> >> however is to be worked out in the proposed Internet Codec WG.
>>
>> Henry
>>
>>
>> On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis"
>> <macinnis@broadcom.com>= ; wrote:
>>
>> Are we talking here about speech, or generic audio?
>>
>> There's a difference in terms of coding (bit rate, quality, etc.) =
>> and in terms of applicability.
>>
>> Or do we want both, i.e. two codecs?
>>
>> --Sandy
>>
>>
>> ________________________________
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org<= /a>] On
>> Behalf Of Henry Sinnreich
>> Sent: Tuesday, June 16, 2009 6:15 PM
>> To: Slava Borilin; Roni Even; codec@iet= f.org
>> Subject: Re: [codec] Codec BOF approved, much work needed
>>
>> Dear Slava,
>>
>>> We are talking not about "enabling technology" to ma= ke everyone
>>> understand each other (email case),
>>> but "enhancement" -  everyone can today underst= and each other via
>>> 711 or 722, but we want to push the quality bar while keeping = the
>>> interop.
>>
>> This is an excellent point. We are talking about the Internet here=
>> in in the IETF.
>>
>> Henry
>>
>>
>> On 6/16/09 4:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
>>
>> Dear Henry,
>>
>> It is probably not the same  as with email (or maybe just tim= ing is
>> different).
>> We are talking not about  "enabling technology" to = make everyone
>> understand each other (email case), but  "enhancement&qu= ot; -  everyone
>> can today understand each other via 711 or 722,  but we want = to
>> push the quality bar while keeping the interop.
>>
>> So  really the magic question is that once we have the agreem= ent on
>> "recommended"  IWAC- either one or several (agree w= ith Jean-Marc),
>> who is to  enforce?
>> PROBABLY the force to enforce are telecom operators?
>> As  telco, against internet companies (Cisco, Skype, MSFT, et= c), do
>> not like  walled gardens by definition:
>> - The telco landscape is not (well, not  only) Skype/cheap IP= calls
>> versus Cellular or Wireline.
>> - The  mid-term battle is between internet and its rich
>> communication techniques (web  conferencing, social networkin= g) and
>>  telco's phone-only  service.
>> - Battle is not only for call $$, but for the time spent on  = the
>> media (trend is users spending more minutes on internet comms then=
>> on  phones)
>> - so carriers have to move from NGN core networks to offer  <= BR> >> IP-based "social network-like" communication models to s= ubscribers,
>> therefore,  have IP-service at the last mile for the user, an= d not
>> only for enterprise  IP-phones, but every consumer.
>> - And as Telco need subscribers to pay for  the service, here= comes
>> the HD(=3Dwideband + packet loss robustness), as the  necessa= ry step
>> to keep user satisfied with the carrier IP-service.
>> - So  actually, HD sounds to be the cornerstone for keeping t= he
>> landscape of whole  Telco industry versus Internet communicat= ions
>> (or vice versa).
>> - so for  telcos it will be really important to have IWAC RFC= and
>> telcos have the power  to enforce using it (via geo or indust= ry
>> forums - examples are PAL/NTSC in  geo, industry - CableLabs)= , and
>> they are used to the standard/certification  process?
>>
>> Again, apart from the ambitions, what all of us (as  vendors = and as
>> users) would like to achieve, is interop.
>> And interop  should, probably, be enforced, not "recomme= nded" via
>> some sort of  certification?
>>
>> Everyone, please  advice.
>>
>>
>> regards,
>> Slava  Borilin
>>
>>
>> ________________________________
>>
>> From: Henry Sinnreich [mailt= o:hsinnrei@adobe.com]
>> Sent: Wednesday, June 17, 2009 1:33 AM
>> To: Slava Borilin;  Roni Even; cod= ec@ietf.org
>> Subject: Re:  [codec] Codec BOF approved, much work needed >>
>> Hi  Slava,
>>
>>> Currently in the internet communications (web collaboration, &= nbsp;voip
>>> services, videoconferencing) -
>>> do you believe is there any force  to push interop, or ev= eryone
>>> "plays in his own walled garden"?
>>
>> IMO one  of the main the strengths of the Internet is its glo= bal
>> reach. The user can be  anywhere and reach content from and <= BR> >> communicate with anyone, anywhere. Just  like we are doing he= re
>> with email.
>> The Internet codec will hopefully do for  voice the same as t= ext
>> communications + attachments work in  email.
>>
>>> sorry if this is naïve
>> This applies to my message as well  :-)
>>
>> Henry
>>
>> On 6/16/09 3:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
>> Roni, and  whole international team,
>>
>> I have one more question here - sorry if this  is naïve-= but still
>> please advice.
>>
>> Background: all of us do wish wish  wish (vendors, customers,=
>> end-users, etc) to have ONE IWAC (internet wideband  audio co= dec)
>> for all.
>>
>> But assuming we (IETF) will come to the agreement  which code= c we
>> like best (existing or new one) and make RFC.
>> What will then  be the destiny of the that RFC?
>> And who and why should be choosing the  certain codec into th= eir app?
>>
>> Afaik IETF, like ITU just "agree on the  specs", wh= ile industry or
>> country-specific organizations are enforcing using  or not us= ing
>> certain standards, like CableLabs (Vertical market +  geograp= hy).
>>
>> The major driver for agreeing on the standard is interop,  as= I see.
>> Currently in the internet communications (web collaboration, voip =  
>> services, videoconferencing) - do you believe is there any force t= o
>> push  interop, or everyone "plays in his own walled gard= en"?
>>
>> Should we:
>> -  agree on RFC and then dig into smaller (geographical or ve= rtical
>> industry)  communities to push them to force using this RFC (= IWAC)
>> as part of  certification to make sure they do enforce the IW= AC?
>> - or we should just  have IWAC RFC and believe "better s= taff will
>> find its way to the market  itself"?
>>
>> regards,
>> Slava Borilin
>>
>>
>> -----Original  Message-----
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org<= /a>] On  
>> Behalf Of Roni Even
>> Sent: Friday, June 12, 2009 10:56 PM
>> To: codec@ietf.org
>> Subject: Re: [codec] Codec BOF  approved, much work needed >>
>> Hi,
>> I would like to suggest other key  topics for the BOF
>>
>> 1. Why should the IETF start a codec WG - why not do  it as I= TU / MPEG /
>> others
>>
>> 2. Describe the process of defining a  codec in other standar= d bodies - my
>> view is that not everyone knows what is  required to create a= quality codec.
>>
>> 3. Is the purpose of the WG to  publish one codec or multiple=
>> codecs based on
>> different  requirements.
>>
>> 4. If a WG will be formed there are more decision to make  li= ke, what is the
>> selection criteria if there is more than one candidate or  do= we
>> require some
>> cooperation, what are the deliverable - source code,  encoder= specification
>> (do we require bit exactness ), how to defines the  quality t= ests and
>> evaluate the results to check if the codec addresses the  req= uirements.
>>
>> Roni Even
>>
>>
>>
>> -----Original  Message-----
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org<= /a>] On  Behalf Of
>> Cullen Jennings
>> Sent: Friday, June 12, 2009 8:32 PM
>> To: codec@ietf.org
>> Subject: [codec] Codec BOF  approved, much work needed
>>
>>
>> I have approved the CODEC BOF proposal.  However, we need a b= unch of
>> work to get ready.  Various people on  IESG/IAB were not= comfortable
>> with the current charter and agenda so we  need to work on th= eses
>> before the meeting.
>>
>> A draft agenda/charter  Jason provided are at
>>
>> Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agen= da.txt
>>
>> Charter:  http://svn.resiprocate.org/rep/ietf-drafts/codec-= bof/charter.txt
>>
>> After  discussion with the IESG/IAB:
>>
>> I'd like to remove the "as Proposed  Standard" from= the charter text
>> for both milestones and see how the  discussion goes in the B= OF before
>> deciding which way this should  go.
>>
>> I'd like to see more consideration around the issues of designing = a
>> codec that did a good job of mapping a real time stream onto IP >> packets. The way IP deals with packet loss and congestion has
>> implications for designing a codec that works well over IP. I know=
>> some of the discussion I have had off list people talked about how= we
>> wanted a codec that supported adaptive bit rates that could change= on
>> the fly to be able to work well on an IP network.
>>
>> I will be working  the folks to make sure the agenda has time= to
>> directly address the key  topics which include (more may be c= oming):
>>
>> Will we be able to get  qualified people to do and review the= work?
>>
>> Key design goals of a new  codec?
>>
>> Do we need a new codec or are there already ones defined that &nbs= p;meet the
>> needs?
>>
>> I have asked Jason Fischl  and Jean-Marc Valin  to co-ch= air this BOF.
>>
>> Thanks,
>>
>> Cullen <RAI  AD>
>>
>>
>>
>>
>>
>> _______________________________________________
>> codec  mailing list
>> codec@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/codec
>>
>> _______________________________________________
>> codec  mailing list
>> codec@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/codec
>> _______________________________________________
>> codec  mailing list
>> codec@ietf.org
>> https://ww= w.ietf.org/mailman/listinfo/codec
>>
>>
>>
>>
>>
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ie= tf.org/mailman/listinfo/codec
>

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

--_000_C65FB9344346hsinnreiadobecom_-- From hoene@uni-tuebingen.de Thu Jun 18 08:39:47 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 CD8A928C3C2 for ; Thu, 18 Jun 2009 08:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.252 X-Spam-Level: X-Spam-Status: No, score=-4.252 tagged_above=-999 required=5 tests=[AWL=-1.378, BAYES_00=-2.599, FRT_ADOBE2=2.455, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 qF8i89E3obIF for ; Thu, 18 Jun 2009 08:39:33 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id A70193A6926 for ; Thu, 18 Jun 2009 08:39:32 -0700 (PDT) Received: from hoeneLenovoT60 ([82.113.106.154]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n5IFdOOD022450 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Jun 2009 17:39:31 +0200 From: "Christian Hoene" To: "'Henry Sinnreich'" , References: In-Reply-To: Date: Thu, 18 Jun 2009 17:39:23 +0200 Message-ID: <005901c9f02a$f94aeea0$ebe0cbe0$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_005A_01C9F03B.BCD3BEA0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnv74/EOPinVpyIRQSmEiAopWXOHwAKdFKoAABiWSAAAYcokwACJJVQ Content-language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Subject: Re: [codec] =?iso-8859-1?q?RE=A0=3A_Codec_BOF_approved=2C_much_work_n?= =?iso-8859-1?q?eeded?= 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, 18 Jun 2009 15:39:47 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_005A_01C9F03B.BCD3BEA0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It make perfectly sense. For the type of usage scenarios we have in mind (namely interactive or even simultaneous), audio is transmitted in both directions. Adding a control channel would give a real advantage to = existing codec designs.=20 =20 Adding a voice engine to the codec, it not really any big issue. It has = been describe couple of time in research literature. I bet the IETF have many experts in this field. =20 I just like to remind that the RFC 3550 suggests in chapter 10 somewhere that the RTP profile SHOULD care of rate adaptation. I am wondering why = it is constantly ignored. Of course, we shall discuss whether to include it into the RTP profile or in the CODEC specification. =20 Christian =20 =20 =20 =20 =20 From: Henry Sinnreich [mailto:hsinnrei@adobe.com]=20 Sent: Thursday, June 18, 2009 4:28 PM To: Slava Borilin; Dr. Christian Hoene; Koen Vos Cc: codec@ietf.org Subject: Re: [codec]RE : Codec BOF approved, much work needed =20 Does it make sense to discuss the possible control channel inside the = codec? Henry On 6/18/09 8:56 AM, "Slava Borilin" wrote: For congested networks - I assume that the way to judge the codec is to judge the MOS over TIA-921 network profiles (that=92s what we use) which covers realistic packet loss and congestion scenarios, and not just = =93average normally distributed XX% packet loss=94. =20 However, the reality is that while making the comparison, one will = actually test the whole voice engine, not just the codec inside it. And normally codec and voiceengine are separate potions of the voip solution. =20 It is probably possible to test different codecs within the same voiceeenigne, to get the comparative data. =20 I doubt however, that we can have a codec which does =93adapt=94 to = network itself, without upper level (signaling, statistics, etc) And the scope of designing the complete voiceengine and not just codec = part of it, is so much more complex that I do not believe we should even try = it. =20 regards, Slava Borilin _____ =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Henry Sinnreich Sent: Thursday, June 18, 2009 5:34 PM To: Dr. Christian Hoene; Koen Vos Cc: codec@ietf.org Subject: Re: [codec]RE : Codec BOF approved, much work needed >MOS 3.5? It appears MOS metrics are obsolete and inadequate for BB Internet, Telepresence (mostly for business) and Digital Living Room (mostly for consumer). The highest MOS is 5.0 aspired for 3.1 kHz telephony :-) Also, how do you accommodate metrics for cut-offs of entire sentences, = as is the case for congested narrowband channels? Are there better metrics? Henry On 6/18/09 3:34 AM, "Dr. Christian Hoene" = wrote: In order to support a high degree of reliability and available, I=20 think the audio codec should support an acceptable operation mode even=20 if the bandwidth is low. If the ultra low delay music transmission is=20 not possible, the codec shall degrade to 25ms delayed music=20 transmission and further degrade to speech quality. Jean-Marc: What is the coding rate of CELT, if it shall transmit voice=20 at a quality of about MOS 3.5? > Quoting Henry Sinnreich: >> As for supporting bandwidth constrained links, where congestion can=20 >> occur, I believe the mobile phone industry has already done a good=20 >> job that we need not duplicate. > > Mobile phones use codecs that are expensive and complex to license = though. > And audio quality on mobile phones is mediocre or worse. > > koen. > > > >> Given the choice between designing for narrowband links and=20 >> broadband Internet, let's chose therefore broadband. >> >> Henry >> >> On 6/16/09 9:41 PM, "Jean-Marc Valin" wrote: >> >> For wideband (16 kHz sampling), I think speech-only (ideally=20 >> without mutilating background music) is sufficient. However, for=20 >> super wideband (32 kHz and up), I think it's important to start=20 >> supporting music. When it comes to latency (by that I mean the=20 >> codec's algorithmic delay), the lower the better. I consider=20 >> anything above ~40 ms to be unacceptable (ruling out Vorbis, MP3=20 >> and standard AAC), but it should ideally be lower than that. The=20 >> lower the delay, the less problems you have with acoustic echo. >> >> Jean-Marc >> >> -------- Message d'origine-------- >> De: codec-bounces@ietf.org de la part de Henry Sinnreich >> Date: mar. 16/06/2009 18:31 >> =C0: Sandy (Alexander) MacInnis; codec@ietf.org; Slava Borilin; Roni = Even >> Objet : Re: [codec] Codec BOF approved, much work needed >> >>> Are we talking here about speech, or generic audio? >> >> As Slava has pointed out it is about wideband speech, that is the=20 >> low latency (150ms or so) still applies, but having wideband audio=20 >> (8-16 kHz audio BW) and why not, stereo. All this and many other=20 >> however is to be worked out in the proposed Internet Codec WG. >> >> Henry >> >> >> On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis"=20 >> wrote: >> >> Are we talking here about speech, or generic audio? >> >> There's a difference in terms of coding (bit rate, quality, etc.)=20 >> and in terms of applicability. >> >> Or do we want both, i.e. two codecs? >> >> --Sandy >> >> >> ________________________________ >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On=20 >> Behalf Of Henry Sinnreich >> Sent: Tuesday, June 16, 2009 6:15 PM >> To: Slava Borilin; Roni Even; codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Dear Slava, >> >>> We are talking not about "enabling technology" to make everyone=20 >>> understand each other (email case), >>> but "enhancement" - everyone can today understand each other via=20 >>> 711 or 722, but we want to push the quality bar while keeping the=20 >>> interop. >> >> This is an excellent point. We are talking about the Internet here=20 >> in in the IETF. >> >> Henry >> >> >> On 6/16/09 4:56 PM, "Slava Borilin" wrote: >> >> Dear Henry, >> >> It is probably not the same as with email (or maybe just timing is=20 >> different). >> We are talking not about "enabling technology" to make everyone=20 >> understand each other (email case), but "enhancement" - everyone=20 >> can today understand each other via 711 or 722, but we want to=20 >> push the quality bar while keeping the interop. >> >> So really the magic question is that once we have the agreement on=20 >> "recommended" IWAC- either one or several (agree with Jean-Marc),=20 >> who is to enforce? >> PROBABLY the force to enforce are telecom operators? >> As telco, against internet companies (Cisco, Skype, MSFT, etc), do=20 >> not like walled gardens by definition: >> - The telco landscape is not (well, not only) Skype/cheap IP calls=20 >> versus Cellular or Wireline. >> - The mid-term battle is between internet and its rich=20 >> communication techniques (web conferencing, social networking) and=20 >> telco's phone-only service. >> - Battle is not only for call $$, but for the time spent on the=20 >> media (trend is users spending more minutes on internet comms then=20 >> on phones) >> - so carriers have to move from NGN core networks to offer =20 >> IP-based "social network-like" communication models to subscribers,=20 >> therefore, have IP-service at the last mile for the user, and not=20 >> only for enterprise IP-phones, but every consumer. >> - And as Telco need subscribers to pay for the service, here comes=20 >> the HD(=3Dwideband + packet loss robustness), as the necessary step=20 >> to keep user satisfied with the carrier IP-service. >> - So actually, HD sounds to be the cornerstone for keeping the=20 >> landscape of whole Telco industry versus Internet communications=20 >> (or vice versa). >> - so for telcos it will be really important to have IWAC RFC and=20 >> telcos have the power to enforce using it (via geo or industry=20 >> forums - examples are PAL/NTSC in geo, industry - CableLabs), and=20 >> they are used to the standard/certification process? >> >> Again, apart from the ambitions, what all of us (as vendors and as=20 >> users) would like to achieve, is interop. >> And interop should, probably, be enforced, not "recommended" via=20 >> some sort of certification? >> >> Everyone, please advice. >> >> >> regards, >> Slava Borilin >> >> >> ________________________________ >> >> From: Henry Sinnreich [mailto:hsinnrei@adobe.com] >> Sent: Wednesday, June 17, 2009 1:33 AM >> To: Slava Borilin; Roni Even; codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Hi Slava, >> >>> Currently in the internet communications (web collaboration, voip=20 >>> services, videoconferencing) - >>> do you believe is there any force to push interop, or everyone=20 >>> "plays in his own walled garden"? >> >> IMO one of the main the strengths of the Internet is its global=20 >> reach. The user can be anywhere and reach content from and=20 >> communicate with anyone, anywhere. Just like we are doing here=20 >> with email. >> The Internet codec will hopefully do for voice the same as text=20 >> communications + attachments work in email. >> >>> sorry if this is na=EFve >> This applies to my message as well :-) >> >> Henry >> >> On 6/16/09 3:56 PM, "Slava Borilin" wrote: >> Roni, and whole international team, >> >> I have one more question here - sorry if this is na=EFve- but still=20 >> please advice. >> >> Background: all of us do wish wish wish (vendors, customers,=20 >> end-users, etc) to have ONE IWAC (internet wideband audio codec)=20 >> for all. >> >> But assuming we (IETF) will come to the agreement which codec we=20 >> like best (existing or new one) and make RFC. >> What will then be the destiny of the that RFC? >> And who and why should be choosing the certain codec into their app? >> >> Afaik IETF, like ITU just "agree on the specs", while industry or=20 >> country-specific organizations are enforcing using or not using=20 >> certain standards, like CableLabs (Vertical market + geography). >> >> The major driver for agreeing on the standard is interop, as I see. >> Currently in the internet communications (web collaboration, voip =20 >> services, videoconferencing) - do you believe is there any force to=20 >> push interop, or everyone "plays in his own walled garden"? >> >> Should we: >> - agree on RFC and then dig into smaller (geographical or vertical=20 >> industry) communities to push them to force using this RFC (IWAC)=20 >> as part of certification to make sure they do enforce the IWAC? >> - or we should just have IWAC RFC and believe "better staff will=20 >> find its way to the market itself"? >> >> regards, >> Slava Borilin >> >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On =20 >> Behalf Of Roni Even >> Sent: Friday, June 12, 2009 10:56 PM >> To: codec@ietf.org >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Hi, >> I would like to suggest other key topics for the BOF >> >> 1. Why should the IETF start a codec WG - why not do it as ITU / = MPEG / >> others >> >> 2. Describe the process of defining a codec in other standard bodies = - my >> view is that not everyone knows what is required to create a quality codec. >> >> 3. Is the purpose of the WG to publish one codec or multiple=20 >> codecs based on >> different requirements. >> >> 4. If a WG will be formed there are more decision to make like, what = is the >> selection criteria if there is more than one candidate or do we=20 >> require some >> cooperation, what are the deliverable - source code, encoder specification >> (do we require bit exactness ), how to defines the quality tests and >> evaluate the results to check if the codec addresses the = requirements. >> >> Roni Even >> >> >> >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On = Behalf Of >> Cullen Jennings >> Sent: Friday, June 12, 2009 8:32 PM >> To: codec@ietf.org >> Subject: [codec] Codec BOF approved, much work needed >> >> >> I have approved the CODEC BOF proposal. However, we need a bunch of >> work to get ready. Various people on IESG/IAB were not comfortable >> with the current charter and agenda so we need to work on theses >> before the meeting. >> >> A draft agenda/charter Jason provided are at >> >> Agenda: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt >> >> Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt >> >> After discussion with the IESG/IAB: >> >> I'd like to remove the "as Proposed Standard" from the charter text >> for both milestones and see how the discussion goes in the BOF = before >> deciding which way this should go. >> >> I'd like to see more consideration around the issues of designing a >> codec that did a good job of mapping a real time stream onto IP >> packets. The way IP deals with packet loss and congestion has >> implications for designing a codec that works well over IP. I know >> some of the discussion I have had off list people talked about how we >> wanted a codec that supported adaptive bit rates that could change on >> the fly to be able to work well on an IP network. >> >> I will be working the folks to make sure the agenda has time to >> directly address the key topics which include (more may be coming): >> >> Will we be able to get qualified people to do and review the work? >> >> Key design goals of a new codec? >> >> Do we need a new codec or are there already ones defined that meet = the >> needs? >> >> I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. >> >> Thanks, >> >> Cullen >> >> >> >> >> >> _______________________________________________ >> 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 >> >> >> >> >> > > _______________________________________________ > 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 ------=_NextPart_000_005A_01C9F03B.BCD3BEA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec]RE : Codec BOF approved, much work needed

It make perfectly sense. For the type of usage scenarios = we have in mind (namely interactive or even simultaneous), audio is transmitted = in both directions. Adding a control channel would give a real advantage to = existing codec designs.

 

Adding a voice engine to the codec, it not really any big = issue. It has been describe couple of time in research literature. I bet the = IETF have many experts in this field.

 

I just like to remind that the RFC 3550 suggests in = chapter 10 somewhere that the RTP profile SHOULD care of rate adaptation. I am wondering why = it is constantly ignored. Of course, we shall discuss whether to include it = into the RTP profile or in the CODEC specification.

 

Christian

 

 

 

 

 

From:= Henry Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Thursday, June 18, 2009 4:28 PM
To: Slava Borilin; Dr. Christian Hoene; Koen Vos
Cc: codec@ietf.org
Subject: Re: [codec]RE : Codec BOF approved, much work = needed

 

Does it make sense to discuss the possible control channel inside the = codec?
Henry


On 6/18/09 8:56 AM, "Slava Borilin" <Borilin@spiritdsp.com> = wrote:

For congested networks - I assume that the way to judge the = codec is to judge the MOS over TIA-921 network profiles (that’s what we = use) which covers realistic packet loss and congestion scenarios, and not = just “average normally distributed XX% packet loss”.
 
However, the reality is that while making the comparison, one will = actually test the whole voice engine, not just the codec inside it.
And normally codec and voiceengine are separate potions of the voip = solution.
 
It is probably possible to test different codecs within the same = voiceeenigne, to get the comparative data.
 
I doubt however, that we can have a codec which does “adapt” = to network itself, without upper level (signaling, statistics, etc)
And the scope of designing the complete voiceengine and not just codec = part of it, is so much more complex that I do not believe we should even try = it.
 

regards,
Slava Borilin

From:= codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On Behalf Of Henry Sinnreich
Sent: Thursday, June 18, 2009 5:34 PM
To: Dr. Christian Hoene; Koen Vos
Cc: codec@ietf.org
Subject: Re: [codec]RE : Codec BOF approved, much work needed

>MOS = 3.5?

It appears MOS metrics are obsolete and inadequate for BB Internet, Telepresence (mostly for business) and Digital Living Room (mostly for consumer). The highest MOS is 5.0 aspired for 3.1 kHz telephony :-)

Also, how do you accommodate metrics for cut-offs of entire sentences, = as is the case for congested narrowband channels?

Are there better metrics?

Henry

On 6/18/09 3:34 AM, "Dr. Christian Hoene" <hoene@uni-tuebingen.de> = wrote:
In order to support a high degree of reliability and available, I
think the audio codec should support an acceptable operation mode even =
if the bandwidth is low. If the ultra low delay music transmission is =
not possible, the codec shall degrade to 25ms delayed music
transmission and further degrade to speech quality.

Jean-Marc: What is the coding rate of CELT, if it shall transmit voice =
at a quality of about MOS 3.5?




> Quoting Henry Sinnreich:
>> As for supporting bandwidth constrained links, where congestion = can
>> occur, I believe the mobile phone industry has already done a = good
>> job that we need not duplicate.
>
> Mobile phones use codecs that are expensive and complex to license = though.
> And audio quality on mobile phones is mediocre or worse.
>
> koen.
>
>
>
>> Given the choice between designing for narrowband links and =
>> broadband Internet, let's chose therefore broadband.
>>
>> Henry
>>
>> On 6/16/09 9:41 PM, "Jean-Marc Valin" <jean-marc.valin@octasic.com> = wrote:
>>
>> For wideband (16 kHz sampling), I think speech-only (ideally =
>> without mutilating background music) is sufficient. However, = for
>> super wideband (32 kHz and up), I think it's important to start =
>> supporting music. When it comes to latency (by that I mean the =
>> codec's algorithmic delay), the lower the better. I consider =
>> anything above ~40 ms to be unacceptable (ruling out Vorbis, = MP3
>> and standard AAC), but it should ideally be lower than that. = The
>> lower the delay, the less problems you have with acoustic = echo.
>>
>>   Jean-Marc
>>
>> -------- Message d'origine--------
>> De: codec-bounces@ietf.org de la part de Henry Sinnreich
>> Date: mar. 16/06/2009 18:31
>> =C0: Sandy (Alexander) MacInnis; codec@ietf.org; Slava Borilin; Roni Even
>> Objet : Re: [codec] Codec BOF approved, much work needed
>>
>>> Are we talking here about speech, or generic audio?
>>
>> As Slava has pointed out it is about wideband speech, that is = the
>> low latency (150ms or so) still applies, but having wideband = audio
>> (8-16 kHz audio BW) and why not, stereo. All this and many = other
>> however is to be worked out in the proposed Internet Codec = WG.
>>
>> Henry
>>
>>
>> On 6/16/09 5:18 PM, "Sandy (Alexander) MacInnis"
>> <macinnis@broadcom.com> wrote:
>>
>> Are we talking here about speech, or generic audio?
>>
>> There's a difference in terms of coding (bit rate, quality, = etc.)
>> and in terms of applicability.
>>
>> Or do we want both, i.e. two codecs?
>>
>> --Sandy
>>
>>
>> ________________________________
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On
>> Behalf Of Henry Sinnreich
>> Sent: Tuesday, June 16, 2009 6:15 PM
>> To: Slava Borilin; Roni Even; codec@ietf.org
>> Subject: Re: [codec] Codec BOF approved, much work needed
>>
>> Dear Slava,
>>
>>> We are talking not about "enabling technology" to = make everyone
>>> understand each other (email case),
>>> but "enhancement" -  everyone can today = understand each other via
>>> 711 or 722, but we want to push the quality bar while = keeping the
>>> interop.
>>
>> This is an excellent point. We are talking about the Internet = here
>> in in the IETF.
>>
>> Henry
>>
>>
>> On 6/16/09 4:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
>>
>> Dear Henry,
>>
>> It is probably not the same  as with email (or maybe just = timing is
>> different).
>> We are talking not about  "enabling technology" = to make everyone
>> understand each other (email case), but =  "enhancement" -  everyone
>> can today understand each other via 711 or 722,  but we = want to
>> push the quality bar while keeping the interop.
>>
>> So  really the magic question is that once we have the = agreement on
>> "recommended"  IWAC- either one or several = (agree with Jean-Marc),
>> who is to  enforce?
>> PROBABLY the force to enforce are telecom operators?
>> As  telco, against internet companies (Cisco, Skype, MSFT, = etc), do
>> not like  walled gardens by definition:
>> - The telco landscape is not (well, not  only) Skype/cheap = IP calls
>> versus Cellular or Wireline.
>> - The  mid-term battle is between internet and its rich =
>> communication techniques (web  conferencing, social = networking) and
>>  telco's phone-only  service.
>> - Battle is not only for call $$, but for the time spent on =  the
>> media (trend is users spending more minutes on internet comms = then
>> on  phones)
>> - so carriers have to move from NGN core networks to offer =  
>> IP-based "social network-like" communication models = to subscribers,
>> therefore,  have IP-service at the last mile for the user, = and not
>> only for enterprise  IP-phones, but every consumer.
>> - And as Telco need subscribers to pay for  the service, = here comes
>> the HD(=3Dwideband + packet loss robustness), as the =  necessary step
>> to keep user satisfied with the carrier IP-service.
>> - So  actually, HD sounds to be the cornerstone for = keeping the
>> landscape of whole  Telco industry versus Internet = communications
>> (or vice versa).
>> - so for  telcos it will be really important to have IWAC = RFC and
>> telcos have the power  to enforce using it (via geo or = industry
>> forums - examples are PAL/NTSC in  geo, industry - = CableLabs), and
>> they are used to the standard/certification  process?
>>
>> Again, apart from the ambitions, what all of us (as =  vendors and as
>> users) would like to achieve, is interop.
>> And interop  should, probably, be enforced, not "recommended" via
>> some sort of  certification?
>>
>> Everyone, please  advice.
>>
>>
>> regards,
>> Slava  Borilin
>>
>>
>> ________________________________
>>
>> From: Henry Sinnreich [mailto:hsinnrei@adobe.com]
>> Sent: Wednesday, June 17, 2009 1:33 AM
>> To: Slava Borilin;  Roni Even; codec@ietf.org
>> Subject: Re:  [codec] Codec BOF approved, much work = needed
>>
>> Hi  Slava,
>>
>>> Currently in the internet communications (web = collaboration,  voip
>>> services, videoconferencing) -
>>> do you believe is there any force  to push interop, or everyone
>>> "plays in his own walled garden"?
>>
>> IMO one  of the main the strengths of the Internet is its = global
>> reach. The user can be  anywhere and reach content from = and
>> communicate with anyone, anywhere. Just  like we are doing = here
>> with email.
>> The Internet codec will hopefully do for  voice the same = as text
>> communications + attachments work in  email.
>>
>>> sorry if this is na=EFve
>> This applies to my message as well  :-)
>>
>> Henry
>>
>> On 6/16/09 3:56 PM, "Slava Borilin" <Borilin@spiritdsp.com> wrote:
>> Roni, and  whole international team,
>>
>> I have one more question here - sorry if this  is na=EFve- = but still
>> please advice.
>>
>> Background: all of us do wish wish  wish (vendors, = customers,
>> end-users, etc) to have ONE IWAC (internet wideband  audio = codec)
>> for all.
>>
>> But assuming we (IETF) will come to the agreement  which = codec we
>> like best (existing or new one) and make RFC.
>> What will then  be the destiny of the that RFC?
>> And who and why should be choosing the  certain codec into = their app?
>>
>> Afaik IETF, like ITU just "agree on the  specs", = while industry or
>> country-specific organizations are enforcing using  or not = using
>> certain standards, like CableLabs (Vertical market + =  geography).
>>
>> The major driver for agreeing on the standard is interop, =  as I see.
>> Currently in the internet communications (web collaboration, = voip  
>> services, videoconferencing) - do you believe is there any = force to
>> push  interop, or everyone "plays in his own walled garden"?
>>
>> Should we:
>> -  agree on RFC and then dig into smaller (geographical or vertical
>> industry)  communities to push them to force using this = RFC (IWAC)
>> as part of  certification to make sure they do enforce the = IWAC?
>> - or we should just  have IWAC RFC and believe = "better staff will
>> find its way to the market  itself"?
>>
>> regards,
>> Slava Borilin
>>
>>
>> -----Original  Message-----
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On  
>> Behalf Of Roni Even
>> Sent: Friday, June 12, 2009 10:56 PM
>> To: codec@ietf.org
>> Subject: Re: [codec] Codec BOF  approved, much work = needed
>>
>> Hi,
>> I would like to suggest other key  topics for the BOF
>>
>> 1. Why should the IETF start a codec WG - why not do  it = as ITU / MPEG /
>> others
>>
>> 2. Describe the process of defining a  codec in other = standard bodies - my
>> view is that not everyone knows what is  required to = create a quality codec.
>>
>> 3. Is the purpose of the WG to  publish one codec or = multiple
>> codecs based on
>> different  requirements.
>>
>> 4. If a WG will be formed there are more decision to make =  like, what is the
>> selection criteria if there is more than one candidate or =  do we
>> require some
>> cooperation, what are the deliverable - source code, =  encoder specification
>> (do we require bit exactness ), how to defines the =  quality tests and
>> evaluate the results to check if the codec addresses the  requirements.
>>
>> Roni Even
>>
>>
>>
>> -----Original  Message-----
>> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= On  Behalf Of
>> Cullen Jennings
>> Sent: Friday, June 12, 2009 8:32 PM
>> To: codec@ietf.org
>> Subject: [codec] Codec BOF  approved, much work needed
>>
>>
>> I have approved the CODEC BOF proposal.  However, we need = a bunch of
>> work to get ready.  Various people on  IESG/IAB were = not comfortable
>> with the current charter and agenda so we  need to work on = theses
>> before the meeting.
>>
>> A draft agenda/charter  Jason provided are at
>>
>> Agenda: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt
>>
>> Charter:  http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/charter.txt
= >>
>> After  discussion with the IESG/IAB:
>>
>> I'd like to remove the "as Proposed  Standard" = from the charter text
>> for both milestones and see how the  discussion goes in = the BOF before
>> deciding which way this should  go.
>>
>> I'd like to see more consideration around the issues of = designing a
>> codec that did a good job of mapping a real time stream onto = IP
>> packets. The way IP deals with packet loss and congestion = has
>> implications for designing a codec that works well over IP. I = know
>> some of the discussion I have had off list people talked about = how we
>> wanted a codec that supported adaptive bit rates that could = change on
>> the fly to be able to work well on an IP network.
>>
>> I will be working  the folks to make sure the agenda has = time to
>> directly address the key  topics which include (more may = be coming):
>>
>> Will we be able to get  qualified people to do and review = the work?
>>
>> Key design goals of a new  codec?
>>
>> Do we need a new codec or are there already ones defined that  meet the
>> needs?
>>
>> I have asked Jason Fischl  and Jean-Marc Valin  to = co-chair this BOF.
>>
>> Thanks,
>>
>> Cullen <RAI  AD>
>>
>>
>>
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>
>>
>>
>
> _______________________________________________
> 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

------=_NextPart_000_005A_01C9F03B.BCD3BEA0-- From gmaxwell@juniper.net Thu Jun 18 09:25: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 4400B28C3FB for ; Thu, 18 Jun 2009 09:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 IZXUR0Nlp2AB for ; Thu, 18 Jun 2009 09:25:34 -0700 (PDT) Received: from exprod7og120.obsmtp.com (exprod7og120.obsmtp.com [64.18.2.18]) by core3.amsl.com (Postfix) with ESMTP id ACEC928C142 for ; Thu, 18 Jun 2009 09:25:34 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob120.postini.com ([64.18.6.12]) with SMTP ID DSNKSjpqfG6GlhZodzCrl9ZanvVmqkYhQakG@postini.com; Thu, 18 Jun 2009 09:25:47 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB03-HQ.jnpr.net ([fe80::a124:1ab1:8e0b:f671%11]) with mapi; Thu, 18 Jun 2009 09:24:48 -0700 From: Gregory Maxwell To: Christian Hoene , 'Henry Sinnreich' , 'Koen Vos' Date: Thu, 18 Jun 2009 09:24:48 -0700 Thread-Topic: =?iso-8859-1?Q?[codec]=09RE=A0:_Codec_BOF_approved, _much_work_needed?= Thread-Index: Acnv74/EOPinVpyIRQSmEiAopWXOHwAKdFKoAAAe10AABDjdRg== Message-ID: References: <20090618103404.20747hsmkwbyohdo@webmail.uni-tuebingen.de> , <003901c9f01b$e8eab950$bac02bf0$@de> In-Reply-To: <003901c9f01b$e8eab950$bac02bf0$@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 Cc: "codec@ietf.org" Subject: Re: [codec] =?iso-8859-1?q?RE=A0=3A_Codec_BOF_approved=2C_much_work_n?= =?iso-8859-1?q?eeded?= 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, 18 Jun 2009 16:25:36 -0000 Christian Hoene [hoene@uni-tuebingen.de] wrote: > I do have the opinion that a main design metric beside audio quality, com= plexity, costs, and delay shall be reliability. > We all know that the PSTN has a reliability of about 99.999%. If designin= g a reliable Audio over IP codec, we shall=20 > consider to make it as robust as possible. Robust not only against packet= losses but also for periods of low bandwidth. > To make a system reliability, you must make it aware of this failures and= try to cope smartly with them. Thus, a codec > which is aware of the packet loss rate, shall decrease its bit/frame rate= s. Also, if it operates in the presence of very > high packet losses it stops, it make sense to switch off the sending of t= he audio stream. (The encoder might then send a > busy signal) The mean availability of the audio transmissions, calculated= over all users, might be one of the metrics for > assessing the performance of an Internet audio codec. I agree with this. This is why good rate adaptability for the total system= is important. I also believe that codes themselves must be adaptable, bec= ause switching among multiple codecs is difficult to negotiate and unlikely= to work well in situations of inter-operation. I have found that frames of very short temporal duration are very useful fo= r improving intelligibility in the face of random loss (Tail-drop like loss= reduces the advantage of tiny duration frames). With ~4-8ms frames you can= take sustained >30% packet loss and still deliver intelligible speech, eve= n without sophisticated packet loss concealment. For example, with 50% un= iform random loss: http://myrandomnode.dyndns.org:8080/~gmaxwell/celt/celt_= diner_64kbit_128samp_50pct_loss.wav Responding to congestion is a more complex issue than simply detecting loss= and changing bitrate/framesize. I think congestion control itself is outs= ide of the scope of this working group, but providing the mechanisms that c= ongestion control requires from the codec (i.e. bitrate/framerate adaptabil= ity) is very much on-topic and an important requirement which existing solu= tions address poorly. =20 I'm not generally in favor of achieving congestion control using a codec si= de channel because congestion should be managed for all streams concurrentl= y and because the codec will not usually have visibility to all congestion = related information, such as ECN. From hoene@uni-tuebingen.de Thu Jun 18 10:43:04 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 3345B28C436 for ; Thu, 18 Jun 2009 10:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.961 X-Spam-Level: X-Spam-Status: No, score=-3.961 tagged_above=-999 required=5 tests=[AWL=-0.291, BAYES_00=-2.599, 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 7ffA6-cIeO7V for ; Thu, 18 Jun 2009 10:43:03 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id E88F328C435 for ; Thu, 18 Jun 2009 10:43:02 -0700 (PDT) Received: from hoeneLenovoT60 ([82.113.106.151]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n5IHgukl001742 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Jun 2009 19:43:08 +0200 From: "Christian Hoene" To: "'Jean-Marc Valin'" References: <005901c9f02a$f94aeea0$ebe0cbe0$@de> <4A3A674F.9040206@octasic.com> In-Reply-To: <4A3A674F.9040206@octasic.com> Date: Thu, 18 Jun 2009 19:42:56 +0200 Message-ID: <006901c9f03c$3ef46d80$bcdd4880$@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: AcnwL4REAHg78jWYSAO2RPREAhsrnQABZYgA Content-language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] RE : Codec BOF approved, much work needed 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, 18 Jun 2009 17:43:04 -0000 Hello JM, > > It make perfectly sense. For the type of usage scenarios we have in > > mind (namely interactive or even simultaneous), audio is transmitted > > in both directions. Adding a control channel would give a real > > advantage to existing codec designs. > > > > It's generally easy to add such a "side channel" to a codec's bit-stream > and it only costs a fraction of a bit (e.g. by reserving one combination > of N bits) when you're not using it. That being said, I tend to think > there are better solutions, such as handling that communication in > SIP/SDP and later with RTP/RTCP. This allows to have mechanisms that > works for all codecs, rather than one mechanism per codec. In any case, > this is something on which the AVT people should have an input. Currently, I am not sure what kind of data we need to transmit in a side channel (some indications on congestion?). Maybe, the loss rates and delay variation given by RTCP are enough for controlling the sending rate. > > > Adding a voice engine to the codec, it not really any big issue. It > > has been describe couple of time in research literature. I bet the > > IETF have many experts in this field. > > > Not sure exactly what you mean by "voice engine", but if you mean the > jitter buffer, echo canceller, and all other algorithms you may need, > then again I don't see why we would want to include that in a codec > definition unless there is a very compelling reason. Even assuming we > add topics like jitter buffers to the new WG's charter (don't know if > it's a good idea?), any "improved jitter buffer" we would come up with > would likely also be applicable to other codecs. Similar to the classic joint-source/channel coding approach for increasing the efficiency of multimedia transmission, a rate control in the codec makes sense. In some sense, then the "Internet" is considered as the "channel". I am not sure whether to include a dejittering buffer. Again, it is a topic which has been well studied in research and that is fairly well understood. Also, it should not be many lines of code because CELT does already support loss and time concealment (as far as I remember). For example, if a packet has not been arrived, CELT start a loss concealment. After loss concealment, it might consider to still playout a packet arrived too late. In such as way. Similar, if many packets (2 or 3) have been arrived but are not played out, then CELT fastens the playout by skipping some pitch periods. If we add something like an very simple jitter buffer algorithm into the specification, we should assure that all phones using CELT have a minimal quality. Otherwise, some phones would include a sophisticated jitter buffer, others none. We should keep in mind to raise the quality of ALL internet users, not only those who can buy an extensive phone having sophisticated algorithms. > > I just like to remind that the RFC 3550 suggests in chapter 10 > > somewhere that the RTP profile SHOULD care of rate adaptation. I am > > wondering why it is constantly ignored. Of course, we shall discuss > > whether to include it into the RTP profile or in the CODEC specification. > > > > Again, I would tend to side on "include in the RTP profile". Even then, > assuming one has the loss/bandwidth statistics, I'm not sure what's even > needed in the RTP profile to allow rate adaptation. One of the main > issues I've seen seen though is that estimating the network capacity is > automatically is hard. For example, how do you know if the lost packets > you see are caused by an excessive bit-rate or if the packets would be > lost anyway (regardless of the rate). Similarly, how do you know that > you can increase the bit-rate without causing lost packets? This should not be an big issue. TCP does these decisions in every connection. We should ask the IETF expert on congestion control to give us advice. Or, we can use some simple TCP formula, which calculates the sending rate taking into account the former sending rate, the losses, the delays and the packet sizes. Cheers, Christian From koen.vos@skype.net Thu Jun 18 12:49:38 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 B984528C0FB for ; Thu, 18 Jun 2009 12:49:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.115 X-Spam-Level: X-Spam-Status: No, score=-5.115 tagged_above=-999 required=5 tests=[AWL=1.184, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 Z+AYJbg1m0Df for ; Thu, 18 Jun 2009 12:49:37 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id B910D3A69D1 for ; Thu, 18 Jun 2009 12:49:37 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 9385A2007AC57 for ; Thu, 18 Jun 2009 21:49:49 +0200 (CEST) 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=9aQVWRqpaOd/ At0JUGNxGMTfwhw=; b=PnhJwW2CrgxK6tK9mIADHhphm7YqNviGrm9JJeaITUOe VcbNtUB8oePcQiDz41z8qCMMgMu204kcdto1+rbtDAilYVP2a7pj9qEYO1LGOwlI EH8lADJVc2YfebmlAFd1lIWHM2MXZF1uDP2gwPmFfSr3gSghFxWPC8iaqsWprmw= 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=HS6W6iM38nlhXsOAWl4C SwSA/Creyn/nmfmrY7MZMiuPTXrbWfseoPRB/gSRKgTRGv2kQO1z8RzRPTPdYV5I S/nXUY6rj8lVGQ9O2UTIKVNNyv/BlnUhEBnyVe+EjXv1hJHkNCvoEd52xBWe6vnt NI6jm7RsY17VPIAladpe6O4= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 920782007AC56 for ; Thu, 18 Jun 2009 21:49:49 +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 JMy2yvgU216n for ; Thu, 18 Jun 2009 21:49:48 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id BE0432007AB58; Thu, 18 Jun 2009 21:49:48 +0200 (CEST) Received: from adsl-71-141-96-214.dsl.snfc21.pacbell.net (adsl-71-141-96-214.dsl.snfc21.pacbell.net [71.141.96.214]) by mail.skype.net (Horde Framework) with HTTP; Thu, 18 Jun 2009 12:49:48 -0700 Message-ID: <20090618124948.98715pqevh5e2rmk@mail.skype.net> Date: Thu, 18 Jun 2009 12:49:48 -0700 From: Koen Vos To: codec@ietf.org References: <005901c9f02a$f94aeea0$ebe0cbe0$@de> In-Reply-To: <005901c9f02a$f94aeea0$ebe0cbe0$@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) Subject: Re: [codec] =?iso-8859-1?q?RE=A0=3A_Codec_BOF_approved=2C_much_work_n?= =?iso-8859-1?q?eeded?= 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, 18 Jun 2009 19:49:38 -0000 Quoting Christian Hoene: > Adding a voice engine to the codec, it not really any big issue. It has been > describe couple of time in research literature. I bet the IETF have many > experts in this field. The reason for standardizing a codec is to ensure interoperability between different parties using that codec. The voice engine has no impact on interoperability, and therefore needs no standard. koen. From Borilin@spiritdsp.com Thu Jun 18 12:50:46 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 D01313A6B88 for ; Thu, 18 Jun 2009 12:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.142 X-Spam-Level: X-Spam-Status: No, score=0.142 tagged_above=-999 required=5 tests=[AWL=-1.429, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_KOI8R=0.67] 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 uLk10EZaJZkC for ; Thu, 18 Jun 2009 12:50:45 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 98A183A6B41 for ; Thu, 18 Jun 2009 12:50:45 -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 n5IJouBc090417; Thu, 18 Jun 2009 23:50:57 +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: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Date: Thu, 18 Jun 2009 23:50:49 +0400 Message-ID: In-Reply-To: <20090618124948.98715pqevh5e2rmk@mail.skype.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: =?koi8-r?Q?=5Bcodec=5D_RE=9A=3A_Codec_BOF_approved=2C_much_work_needed?= Thread-Index: AcnwTfeTtpzY1HwYSQ+ISwIhVwGaOwAABpbg References: <005901c9f02a$f94aeea0$ebe0cbe0$@de> <20090618124948.98715pqevh5e2rmk@mail.skype.net> From: "Slava Borilin" To: "Koen Vos" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: Re: [codec] =?koi8-r?b?UkWaOiBDb2RlYyBCT0YgYXBwcm92ZWQsIG11Y2ggd29y?= =?koi8-r?b?ayBuZWVkZWQ=?= 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, 18 Jun 2009 19:50:47 -0000 Absolutely. regards, Slava Borilin =20 -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Koen Vos Sent: Thursday, June 18, 2009 11:50 PM To: codec@ietf.org Subject: Re: [codec] RE=9A: Codec BOF approved, much work needed Quoting Christian Hoene: > Adding a voice engine to the codec, it not really any big issue. It = has been > describe couple of time in research literature. I bet the IETF have = many > experts in this field. The reason for standardizing a codec is to ensure interoperability =20 between different parties using that codec. The voice engine has no =20 impact on interoperability, and therefore needs no standard. koen. _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From rjesup@wgate.com Thu Jun 18 13:46:00 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 74D803A6A7F for ; Thu, 18 Jun 2009 13:46:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.433 X-Spam-Level: X-Spam-Status: No, score=-1.433 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, MIME_8BIT_HEADER=0.3, RDNS_DYNAMIC=0.1, SARE_SUB_ENC_UTF8=0.152] 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 FOS1PU0qSysI for ; Thu, 18 Jun 2009 13:45:59 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 7E6C03A68BD for ; Thu, 18 Jun 2009 13:45:59 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 18 Jun 2009 16:46:11 -0400 To: Gregory Maxwell References: <20090618103404.20747hsmkwbyohdo@webmail.uni-tuebingen.de> <003901c9f01b$e8eab950$bac02bf0$@de> From: Randell Jesup Date: Thu, 18 Jun 2009 16:46:01 -0400 In-Reply-To: (Gregory Maxwell's message of "Thu\, 18 Jun 2009 09\:24\:48 -0700") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 18 Jun 2009 20:46:11.0678 (UTC) FILETIME=[D071DFE0:01C9F055] Cc: "codec@ietf.org" Subject: Re: [codec] =?utf-8?q?RE=C2=A0=3A_Codec_BOF_approved=2C_much_work_nee?= =?utf-8?q?ded?= X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup 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, 18 Jun 2009 20:46:00 -0000 Gregory Maxwell writes: >I agree with this. This is why good rate adaptability for the total >system is important. I also believe that codes themselves must be >adaptable, because switching among multiple codecs is difficult to >negotiate and unlikely to work well in situations of inter-operation. It could work ok in theory, but in practice it's unlikely to work well, especially if done frequently. >Responding to congestion is a more complex issue than simply detecting >loss and changing bitrate/framesize. I think congestion control itself >is outside of the scope of this working group, but providing the >mechanisms that congestion control requires from the codec >(i.e. bitrate/framerate adaptability) is very much on-topic and an >important requirement which existing solutions address poorly. I think the congestion control per se is outside the perview of this group, but providing the hooks for a congestion-control mechanism to interact with the codec is quite important. For example, running this codec on a TFRC-enabled or DCCP RTP stream - TFRC and DCCP need to be able to adjust (via the application) the bitrate of the codec in order to implement congestion control, and perhaps adjust packetization periods/packet-rates. Most current voice/audio codecs have no adjustment in-call available, or at best a very coarse adjustment. >I'm not generally in favor of achieving congestion control using a >codec side channel because congestion should be managed for all streams >concurrently and because the codec will not usually have visibility to >all congestion related information, such as ECN. Right: for example, if you're sending multiple streams, then the application may have more options for how to adjust packet rates or bandwidth depending on the characteristics of each stream, and to balance the tradeoffs (for example, between audio and video streams in the same session). -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From hsinnrei@adobe.com Thu Jun 18 15:00:00 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 338C43A6AE1 for ; Thu, 18 Jun 2009 15:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.259 X-Spam-Level: X-Spam-Status: No, score=-5.259 tagged_above=-999 required=5 tests=[AWL=1.039, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, 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 IQSfeHyPbpcP for ; Thu, 18 Jun 2009 14:59:58 -0700 (PDT) Received: from psmtp.com (exprod6ob111.obsmtp.com [64.18.1.26]) by core3.amsl.com (Postfix) with ESMTP id 4E15D3A67F4 for ; Thu, 18 Jun 2009 14:59:50 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKSjq43yYnc3butQ9ELEdLFxhh5+znziBU@postini.com; Thu, 18 Jun 2009 15:00:11 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 n5ILxuWG000419; Thu, 18 Jun 2009 14:59:56 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n5ILwwYC001363; Thu, 18 Jun 2009 14:59:53 -0700 (PDT) Received: from excas03.corp.adobe.com (10.8.189.123) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 18 Jun 2009 14:59:45 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas03.corp.adobe.com ([10.8.189.123]) with mapi; Thu, 18 Jun 2009 14:59:45 -0700 From: Henry Sinnreich To: Randell Jesup , Gregory Maxwell Date: Thu, 18 Jun 2009 14:59:44 -0700 Thread-Topic: =?iso-8859-1?Q?[codec]_RE=A0:_Codec_BOF_approved, _much_work_needed?= Thread-Index: AcnwVdN8chBVlZ7sT0+37hTcq3wcJwACkLpQ Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6602300438Chsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] =?iso-8859-1?q?RE=A0=3A_Codec_BOF_approved=2C_much_work_n?= =?iso-8859-1?q?eeded?= 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, 18 Jun 2009 22:00:00 -0000 --_000_C6602300438Chsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This and previous contributions lead to a matrix, such as the following: Columns: (Place for dealing with congestion): Column 1: Application (proprietary, must eat, etc.), or Column 2: Protocol standards machinery Rows: Row 1: Codec in-band channel, Row 2: RTP machinery, Row3: Network infrastructure (routers, SBC, etc.) This gives 6 choices to evaluate. Plenty of work for the Codec WG. Henry On 6/18/09 3:46 PM, "Randell Jesup" wrote: Gregory Maxwell writes: >I agree with this. This is why good rate adaptability for the total >system is important. I also believe that codes themselves must be >adaptable, because switching among multiple codecs is difficult to >negotiate and unlikely to work well in situations of inter-operation. It could work ok in theory, but in practice it's unlikely to work well, especially if done frequently. >Responding to congestion is a more complex issue than simply detecting >loss and changing bitrate/framesize. I think congestion control itself >is outside of the scope of this working group, but providing the >mechanisms that congestion control requires from the codec >(i.e. bitrate/framerate adaptability) is very much on-topic and an >important requirement which existing solutions address poorly. I think the congestion control per se is outside the perview of this group, but providing the hooks for a congestion-control mechanism to interact with the codec is quite important. For example, running this codec on a TFRC-enabled or DCCP RTP stream - TFRC and DCCP need to be able to adjust (via the application) the bitrate of the codec in order to implement congestion control, and perhaps adjust packetization periods/packet-rates. Most current voice/audio codecs have no adjustment in-call available, or at best a very coarse adjustment. >I'm not generally in favor of achieving congestion control using a >codec side channel because congestion should be managed for all streams >concurrently and because the codec will not usually have visibility to >all congestion related information, such as ECN. Right: for example, if you're sending multiple streams, then the application may have more options for how to adjust packet rates or bandwidth depending on the characteristics of each stream, and to balance the tradeoffs (for example, between audio and video streams in the same session). -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS te= am rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the we= apons provided for defence against real, pretended, or imaginary dangers from abr= oad." - James Madison, 4th US president (1751-1836) --_000_C6602300438Chsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] RE?: Codec BOF approved, much work needed This and previous contributions lead to a matrix,  such as the f= ollowing:

Columns: (Place for dealing with congestion):
   Column 1: Application (proprietary, must eat, etc.), or    Column 2: Protocol standards machinery
Rows:
   Row 1: Codec in-band channel,
  Row 2: RTP machinery,
  Row3:  Network infrastructure (routers, SBC, etc.)

This gives 6 choices to evaluate. Plenty of work for the Codec WG.

Henry



On 6/18/09 3:46 PM, "Randell Jesup" <rjesup@wgate.com> wrote:

Gregory Maxwell <gmaxwell@juniper.net> writes:
>I agree with this.  This is why good rate adaptability for the tot= al
>system is important.  I also believe that codes themselves must be=
>adaptable, because switching among multiple codecs is difficult to
>negotiate and unlikely to work well in situations of inter-operation.
It could work ok in theory, but in practice it's unlikely to work well,
especially if done frequently.

>Responding to congestion is a more complex issue than simply detecting<= BR> >loss and changing bitrate/framesize.  I think congestion control i= tself
>is outside of the scope of this working group, but providing the
>mechanisms that congestion control requires from the codec
>(i.e. bitrate/framerate adaptability) is very much on-topic and an
>important requirement which existing solutions address poorly.  &n= bsp;

I think the congestion control per se is outside the perview of this
group, but providing the hooks for a congestion-control mechanism to
interact with the codec is quite important.  For example, running this=
codec on a TFRC-enabled or DCCP RTP stream - TFRC and DCCP need to be
able to adjust (via the application) the bitrate of the codec in order
to implement congestion control, and perhaps adjust packetization
periods/packet-rates.

Most current voice/audio codecs have no adjustment in-call available, or at best a very coarse adjustment.

>I'm not generally in favor of achieving congestion control using a
>codec side channel because congestion should be managed for all streams=
>concurrently and because the codec will not usually have visibility to<= BR> >all congestion related information, such as ECN.

Right: for example, if you're sending multiple streams, then the
application may have more options for how to adjust packet rates or
bandwidth depending on the characteristics of each stream, and to
balance the tradeoffs (for example, between audio and video streams in
the same session).

--
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS te= am
rjesup@wgate.com
"The fetters imposed on liberty at home have ever been forged out of t= he weapons
provided for defence against real, pretended, or imaginary dangers from abr= oad."
            &nb= sp;   - James Madison, 4th US president (1751-1836)

--_000_C6602300438Chsinnreiadobecom_-- From hoene@uni-tuebingen.de Thu Jun 18 15:24:33 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 15BD53A6CCD for ; Thu, 18 Jun 2009 15:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 MzrvqMZDuTTi for ; Thu, 18 Jun 2009 15:24:32 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 831023A69E7 for ; Thu, 18 Jun 2009 15:24:12 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-092-074-178-015.pools.arcor-ip.net [92.74.178.15]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n5IMOG6Y019161 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Jun 2009 00:24:23 +0200 From: "Christian Hoene" To: "'Jean-Marc Valin'" References: <005901c9f02a$f94aeea0$ebe0cbe0$@de> <4A3A674F.9040206@octasic.com> <006901c9f03c$3ef46d80$bcdd4880$@de> <4A3A902E.7020702@octasic.com> In-Reply-To: <4A3A902E.7020702@octasic.com> Date: Fri, 19 Jun 2009 00:24:14 +0200 Message-ID: <000601c9f063$873b0370$95b10a50$@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: AcnwR+MW/b5LzBm3T0qP7peN0W/STQAFzFxQ Content-Language: de x-cr-hashedpuzzle: XGI= AxnN BmOc D17X GuQk JeRl MNn7 MdHg MieL Mm5q QE2R QwjM SExo T6Qt UNBP UYlA; 2; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAagBlAGEAbgAtAG0AYQByAGMALgB2AGEAbABpAG4AQABvAGMAdABhAHMAaQBjAC4AYwBvAG0A; Sosha1_v1; 7; {A0B1036B-6CFC-459E-8C71-03654221A8BD}; aABvAGUAbgBlAEAAdQBuAGkALQB0AHUAZQBiAGkAbgBnAGUAbgAuAGQAZQA=; Thu, 18 Jun 2009 22:23:41 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAUgBFACAAOgAgAEMAbwBkAGUAYwAgAEIATwBGACAAYQBwAHAAcgBvAHYAZQBkACwAIABtAHUAYwBoACAAdwBvAHIAawAgAG4AZQBlAGQAZQBkAA== x-cr-puzzleid: {A0B1036B-6CFC-459E-8C71-03654221A8BD} 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.0.191; VDF: 7.1.4.112; host: mx05); id=14547-JnYHaI Cc: codec@ietf.org Subject: Re: [codec] RE : Codec BOF approved, much work needed 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, 18 Jun 2009 22:24:33 -0000 Dear Jean-Marc, > > If we add something like an very simple jitter buffer algorithm into the > > specification, we should assure that all phones using CELT have a minimal > > quality. Otherwise, some phones would include a sophisticated jitter buffer, > > others none. We should keep in mind to raise the quality of ALL internet > > users, not only those who can buy an extensive phone having sophisticated > > algorithms. > > > > I agree with those goals (having a good jitter buffer, optimising use of > late packets), but I don't see how specifying them in a codec helps in > any way. For example, I'm shipping a jitter buffer, an AEC and a noise > suppressor along with the Speex package, but these are still generic > algorithms that are not part of the Speex specification and that can be > used with any other codec. My belief is that when you specify a codec, > you should specify the least amount that is necessary to ensure > inter-operability. Otherwise, you end up with kitchen-sink standards > that prevent further improvements (what if you find a better jitter > buffer algorithm than the one specified in the standard?). On the other > hand, if you find an improved jitter buffer algorithm that depends on > having a certain feature in the codec, you can specify that particular > feature without specifying the whole jitter buffer. Jean-Marc, I am sorry, but I cannot understand your argumentation. Let me explain why: Dejittering buffers and PLCs are both essential components to ensure high quality. Let's compare the dejittering buffer with the packet loss concealment (PLC): The ITU, 3GPP and others have standardized PLC algorithms for many codecs. PLC is only important for the receiving side and is not required for the interoperability with the encoder. For example, an encoder using G.711 really does not care whether the receiving side implement the G.711 appendix 1 PLC. Anyhow, the PLC has been standardized. More important than the algorithm is the interface between protocol stack and decoder. If the protocol stack can indicate that a packet has not arrived, any PLC algorithm can start working. Similar, if a packet arrives too late or too early, any dejittering buffer or time concealment algorithm can try to cope with it. Thus, I would suggest to define 1. An additional interface between the RTP protocol and the decoder to indicate lost, late and early packets. 2. Some basic algorithm that conducts loss and time concealment. (Let the Skypes and SpiritDSPs provide better algorithms than those described in the standard.) > Here's a practical example of that from CELT. CELT has two types of > prediction that can use information from previous frame(s). However, the > bit-stream includes flags to turn those predictors on or off on a > frame-by-frame basis. So in good conditions, you can use the prediction, > but in bad conditions with high losses, you can turn it off and code all > frames independently (at the cost of a slightly higher bitrate). This is > the kind of feature that is useful to have in an "Internet codec", > without the need to specify exactly how the application has to use it. If a feature is not standardized, some will not implement it. If a feature is not implemented everywhere, all users will suffer because all users can call each other. > > This should not be an big issue. TCP does these decisions in every > > connection. We should ask the IETF expert on congestion control to give us > > advice. Or, we can use some simple TCP formula, which calculates the sending > > rate taking into account the former sending rate, the losses, the delays and > > the packet sizes. > > > > The rate adaptation method used by TCP is essentially "keep increasing > the rate until you start losing packets, at which point, you decrease > the rate". This is bad for VoIP for (at least) two reasons: 1) it means > you're guaranteed to end up losing packets and Instead of indicating congestion with packet loss, the ECN flag can be used. > 2) if you have losses > that are *not* caused by congestion, you end up using the lowest bitrate > available. If you have losses not caused by congestion, something is going severely wrong. Wireless links tend to be quite lossy. However, most wireless links have FEC and/or ARQ to cope with transmission errors. Best regards, Christian From jean-marc.valin@usherbrooke.ca Thu Jun 18 18:23:22 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 402D03A6A0D for ; Thu, 18 Jun 2009 18:23:22 -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 i2e2TUbOdiPW for ; Thu, 18 Jun 2009 18:23:21 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 44E9F3A67F1 for ; Thu, 18 Jun 2009 18:23:21 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 7BIT Content-type: text/plain; charset=ISO-8859-1 Received: from idefix.homelinux.org ([70.81.109.112]) by VL-MO-MR003.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KLG00KEIP791VA0@VL-MO-MR003.ip.videotron.ca> for codec@ietf.org; Thu, 18 Jun 2009 21:23:33 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by idefix.homelinux.org (Postfix) with ESMTP id 4B125509840; Thu, 18 Jun 2009 21:23:33 -0400 (EDT) Message-id: <4A3AE894.70001@usherbrooke.ca> Date: Thu, 18 Jun 2009 21:23:32 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) To: Christian Hoene X-Enigmail-Version: 0.95.2 Cc: codec@ietf.org Subject: Re: [codec] RE : Codec BOF approved, much work needed 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: Fri, 19 Jun 2009 01:23:22 -0000 Hi, (I sent a few emails today that didn't go to the list apparently due to DNS update issues, but the main one was quoted by Christian) > The ITU, 3GPP and others have standardized PLC algorithms for many codecs. > PLC is only important for the receiving side and is not required for the > interoperability with the encoder. For example, an encoder using G.711 > really does not care whether the receiving side implement the G.711 appendix > 1 PLC. Anyhow, the PLC has been standardized. I am not opposed to having a *reference implementation* of the PLC for the specified codec. In fact, this would be the only way to ensure that the codec is really robust to packet loss. However, I don't think there's any point in saying "this is how you should do the PLC" because that is likely to improve. In the case of G.711 appendix I, it turns out that most vendors are actually their own PLC algorithm to achieve better quality than G.711 A1. > More important than the > algorithm is the interface between protocol stack and decoder. If the > protocol stack can indicate that a packet has not arrived, any PLC algorithm > can start working. Similar, if a packet arrives too late or too early, any > dejittering buffer or time concealment algorithm can try to cope with it. The interface you're talking about is nothing more than the implementation's API. This does not need to be specified at all. Again, you can say "in the reference implementation, you can call do_plc() to conceal a lost packet", but nobody cares what you call the function in your implementation or what the arguments are. > So in good conditions, you can use the prediction, >> but in bad conditions with high losses, you can turn it off and code all >> frames independently (at the cost of a slightly higher bitrate). This is >> the kind of feature that is useful to have in an "Internet codec", >> without the need to specify exactly how the application has to use it. > > If a feature is not standardized, some will not implement it. If a feature > is not implemented everywhere, all users will suffer because all users can > call each other. The *codec* feature has to be standardised because you have to define that "this bit turns this feature on", so all decoders will *have* to correctly handle it. On the other hand, the sender is still free to decide whether it wants to *use* the feature. Like other people have said already, standardising a codec means specifying the meaning of each bit in the packet. There is no need to standardise things that aren't necessary for inter-operability -- no matter how important they are. You will notice that none of the ITU codecs specify how to do the jitter buffering (imaging having to support 10 jitter buffers in your application!). The only exception is the PLC because it is specific to the codec. But even then, a non-normative example is fine as far as I'm concerned. If you look at the iLBC RFC, you'll see that it includes a reference implementation of the PLC but basically states that you can implement the PLC in any way you like. Cheers, Jean-Marc From hoene@uni-tuebingen.de Fri Jun 19 01:30:29 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 3C0D63A6921 for ; Fri, 19 Jun 2009 01:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 BRMF0BfWPhF6 for ; Fri, 19 Jun 2009 01:30:28 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 0C92E3A6ABD for ; Fri, 19 Jun 2009 01:30:27 -0700 (PDT) Received: from hoeneLenovoT60 (u-172-c216.cs.uni-tuebingen.de [134.2.172.216]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n5J8UbCJ030493 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Jun 2009 10:30:37 +0200 From: "Christian Hoene" To: "'Jean-Marc Valin'" References: <4A3AE894.70001@usherbrooke.ca> In-Reply-To: <4A3AE894.70001@usherbrooke.ca> Date: Fri, 19 Jun 2009 10:30:37 +0200 Message-ID: <000401c9f0b8$3948a280$abd9e780$@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: AcnwfJVnuRKVcxzzR+OuOyCLPGAZOgAOJefw Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] RE : Codec BOF approved, much work needed 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: Fri, 19 Jun 2009 08:30:29 -0000 Good Morning JM, > > More important than the > > algorithm is the interface between protocol stack and decoder. If the > > protocol stack can indicate that a packet has not arrived, any PLC algorithm > > can start working. Similar, if a packet arrives too late or too early, any > > dejittering buffer or time concealment algorithm can try to cope with it. > > The interface you're talking about is nothing more than the > implementation's API. This does not need to be specified at all. Again, > you can say "in the reference implementation, you can call do_plc() to > conceal a lost packet", but nobody cares what you call the function in > your implementation or what the arguments are. The IETF recommendation define clearly the services the protocol layer offer. Also, the separation of functionally is clearly described. I just want to clarify, how the protocol stack will look like: Version A: Acoustics and signal processing Codec Dejittering Buffer RTP UDP IP ... Or Version B: Acoustics and signal processing Codec RTP UDP IP We do not know the exact functionality split between dejittering buffer and codec, because the times and kinds playout adjustments are depending on the content of the audio signal, on the PLC, and the decoder. > The *codec* feature has to be standardised because you have to define > that "this bit turns this feature on", so all decoders will *have* to > correctly handle it. On the other hand, the sender is still free to > decide whether it wants to *use* the feature. No, it also concludes the information on which services the codec are provides and which lower services it uses. > You will notice that none of the ITU > codecs specify how to do the jitter buffering. I follow a clean slate approach in thinking, questioning many decisions that have been made in the past. At this point I firmly believe that we shall reconsider the classic thinking on what an audio codec does and what it does not. To state it clearly: 1) It is not only about the bits in the packets, it is also about the interfaces to lower and upper layers. 2) Because the concealment of time adjustments, the loss concealment, and the decoding are highly intercorrelated, these functionallies shall be merged into one common block (Version B). 3) If we follow Version A, it should be clear on how the interface between codec and dejittering buffer has to look like in order to support playout adjustments. > If you look at the iLBC RFC, > you'll see that it includes a reference implementation of the PLC but > basically states that you can implement the PLC in any way you like. Yes, I would be perfectly fine having a dejittering buffer in the reference implementation but stating that everybody is free to implement it differently. Cheers, Christian From koen.vos@skype.net Fri Jun 19 03:28:34 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 547403A69CC for ; Fri, 19 Jun 2009 03:28:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.561 X-Spam-Level: X-Spam-Status: No, score=-5.561 tagged_above=-999 required=5 tests=[AWL=1.038, 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 pAxPvNAqV2x9 for ; Fri, 19 Jun 2009 03:28:33 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 29CB33A6930 for ; Fri, 19 Jun 2009 03:28:33 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 3D3712007AB21 for ; Fri, 19 Jun 2009 12:28:42 +0200 (CEST) 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=y6ycCF9iGP7q 0RzPnEXJrntH+PU=; b=Wyu5yrnt7K4Gwy5XL5BobpeVpmQJCi02OCARzaaJewH+ MVhRarYChRvx7AiUBBnrXCainA6uPm6PHhV/ZW9DO/NcCz9KnMZ2/r6MaguQin+n yw2o9gTmXhICJ+W24o8/JyJ9Xt1Q25yyjUFU33FZhQrhujwyrqw+P9RMHFGQTic= 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=nMdwKxuukJwTTcwL5Ka0 LtXDYwa4blE+oq5qyBI/H9ysSutQesUlYEXBNieh4aAwssZTVszngRxSHM1OT8pv IpC70efWL42xIOMZAxQW173xkFAwo64tIfBEqENyIbWEoWEWXmUxzXSrlzHwyTtk r1yp8iiHT/6tiCdOYwJjXmM= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 3BE6D2007A7F9 for ; Fri, 19 Jun 2009 12:28:42 +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 C9JsLAMzsSH2 for ; Fri, 19 Jun 2009 12:28:41 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 6AFAC2007AAD5; Fri, 19 Jun 2009 12:28:41 +0200 (CEST) Received: from adsl-71-141-96-214.dsl.snfc21.pacbell.net (adsl-71-141-96-214.dsl.snfc21.pacbell.net [71.141.96.214]) by mail.skype.net (Horde Framework) with HTTP; Fri, 19 Jun 2009 03:28:41 -0700 Message-ID: <20090619032841.2122362oqyhc3k2h@mail.skype.net> Date: Fri, 19 Jun 2009 03:28:41 -0700 From: Koen Vos To: codec@ietf.org References: <4A3AE894.70001@usherbrooke.ca> <000401c9f0b8$3948a280$abd9e780$@de> In-Reply-To: <000401c9f0b8$3948a280$abd9e780$@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) Subject: Re: [codec] RE : Codec BOF approved, much work needed 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: Fri, 19 Jun 2009 10:28:34 -0000 Quoting Christian Hoene: > Yes, I would be perfectly fine having a dejittering buffer in the reference > implementation but stating that everybody is free to implement it > differently. A jitter buffer is usually a separate module because the mutual dependencies with the decoder are simple. And also because a voice engine often contains several speech codecs but only one jitter buffer. That said, it may indeed be useful and fun to develop an open source jitter buffer - without having to standardize it. But you may want to start by looking at the existing open source jitter buffers (and voice engines). koen. From hoene@uni-tuebingen.de Fri Jun 19 04:42:19 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 B8F163A6967 for ; Fri, 19 Jun 2009 04:42:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[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 GSx9orrP5cpk for ; Fri, 19 Jun 2009 04:42:18 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 8951D3A685C for ; Fri, 19 Jun 2009 04:42:18 -0700 (PDT) Received: from hoeneLenovoT60 (vpn0263.extern.uni-tuebingen.de [134.2.165.13]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n5JBgS17026199 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 19 Jun 2009 13:42:29 +0200 From: "Christian Hoene" To: "'Koen Vos'" , References: <4A3AE894.70001@usherbrooke.ca> <000401c9f0b8$3948a280$abd9e780$@de> <20090619032841.2122362oqyhc3k2h@mail.skype.net> In-Reply-To: <20090619032841.2122362oqyhc3k2h@mail.skype.net> Date: Fri, 19 Jun 2009 13:42:28 +0200 Message-ID: <000d01c9f0d3$06b2da00$14188e00$@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: AcnwyMLafHlC1m7wRZmT8n97wWwsUAABpJUg Content-Language: de x-cr-hashedpuzzle: gq0= BQ6U BXBc F96E G39t ISAZ NyfW N0Hc OBnp P8Bu RBfZ Smpx ULQJ Udsz Ujam U1ML; 2; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAawBvAGUAbgAuAHYAbwBzAEAAcwBrAHkAcABlAC4AbgBlAHQA; Sosha1_v1; 7; {50FB5F71-32F0-4D29-BA9A-11A8DE60D7B2}; aABvAGUAbgBlAEAAdQBuAGkALQB0AHUAZQBiAGkAbgBnAGUAbgAuAGQAZQA=; Fri, 19 Jun 2009 11:41:11 GMT; SQBuAGMAbAB1AGQAZQAgAEQAZQBqAGkAdAB0AGUAcgAgAEIAdQBmAGYAZQByAD8AIABXAEEAUwAgAFIARQA6ACAAWwBjAG8AZABlAGMAXQAgAFIARQAgADoAIABDAG8AZABlAGMAIABCAE8ARgAgAGEAcABwAHIAbwB2AGUAZAAsACAAbQB1AGMAaAAgAHcAbwByAGsAIABuAGUAZQBkAGUAZAA= x-cr-puzzleid: {50FB5F71-32F0-4D29-BA9A-11A8DE60D7B2} X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Subject: [codec] Include Dejitter Buffer? WAS RE: RE : Codec BOF approved, much work needed 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: Fri, 19 Jun 2009 11:42:19 -0000 Hi Koen, > > Yes, I would be perfectly fine having a dejittering buffer in the reference > > implementation but stating that everybody is free to implement it > > differently. >=20 > A jitter buffer is usually a separate module because the mutual > dependencies with the decoder are simple. And also because a voice > engine often contains several speech codecs but only one jitter = buffer. > > That said, it may indeed be useful and fun to develop an open source > jitter buffer - without having to standardize it. But you may want to > start by looking at the existing open source jitter buffers (and voice > engines). I think we shall understand which kind of dejittering buffer we mean. I = just copied this section from my PhD thesis " 2.1.5. Playout scheduler At the receiver, protocol entities process the packets and deliver them = to the de-jittering buffer (also called playout scheduler or packet voice receiver), which temporally stores packets so that they can be played = out in a timely manner [11, 13]. They try to playout the speech time-regular = manner to conceal variations in the transmission delay also known as jitter. If packets are too delayed to be played out on time, they are usually = treated as lost. Consequently, losses as seen by the application are in fact a superposition of real losses and excessive delays, where =93excessive=94 = is used in terms of playout buffer dimensioning. As the playout buffer = contributes to the end-to-end delay it should not store packets longer than = necessary. Instead, the playout buffer should drop packets that arrive too late to = be played out at the scheduled time. The playout scheduling can be static: If packets exceed a given = transmission time they are discarded (we will refer to this scheme as fixed playout buffer ). Alternatively, adaptive playout buffers redefine the playout = time in accordance to the delay process of the network [146,173]. We refer to this kind of adaptation as rescheduling. The scheduling of playouts can = be adjusted most easily during silence periods because then it is not noticeable. Adjustments during voice activity require more sophisticated concealment algorithms [132, 135]. Some early work on the perception of playout jitter can be found in [123, 195]. References [11] G. Barberis, =93Buffer sizing of a packet-voice receiver,=94 IEEE Transactions on Communications, vol. 29, no. 2, pp. 152=96156, Feb. = 1981. [13] G. Barberis and D. Pazzaglia, =93Analysis and optimal design of a packet-voice receiver,=94 IEEE Transactions on Communications, vol. 28, = no. 2, pp. 217=96227, 1980. [123] N. Kitawaki and K. Itoh, =93Pure delay effects on speech quality = in telecommunications,=94 IEEE Journal on Selected Areas in Communications, = vol. 9, no. 4, pp. 586=96593, 1991. [132] Y. J. Liang, N. F=A8arber, and B. Girod, =93Adaptive playout = scheduling and loss concealment for voice communication over IP networks,=94 IEEE Transactions on Multimedia, vol. 5, no. 4, pp. 532=96543, Dec. 2003.=20 [135] F. Liu, J. Kim, and C.-C. J. Kuo, =93Adaptive delay concealment = for internet voice applications with packet-based time-scale = modification,=94 in IEEE International Conference on Acoustics, Speech, and Signal = Processing (ICASSP =9201), vol. 3, May 2001, pp. 1461=961464. [146] S. B. Moon, J. Kurose, and D. Towsley, =93Packet audio playout = delay adjustments: performance bounds and algorithms,=94ACM/Springer = Multimedia Systems, vol. 27, no. 3, pp. 17=9628, Jan. 1998. [173] R. Ramjee, J. F. Kurose, D. F. Towsley, and H. Schulzrinne, = =93Adaptive playout mechanisms for packetized audio applications in wide-area = networks,=94 in 13th Proceedings IEEE INFOCOM =9294, Toronto, Canada, June 1994, pp. 680=96688. [195] R. Steinmetz, =93Human perception of jitter and media = synchronization,=94 IEEE Journal on Selected Areas in Communications, vol. 14, no. 1, pp. = 61=9672, 1996." To my understanding, a modern dejittering buffer uses a similar = algorithm as described in [132] and [135] and is a) medium specific (e.g., can only be used for audio) b) might be codec-depended if its implementation shall be computational efficient. A couple of ETSI's VoIP performance tests have shown that the best VoIP phones do use time stretching and shrinking algorithms to lower the = impact of playout adjustments. With best regards, Christian From rjesup@wgate.com Fri Jun 19 07:24:06 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 45F683A6966 for ; Fri, 19 Jun 2009 07:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.629 X-Spam-Level: X-Spam-Status: No, score=-1.629 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.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 Df3pmpG+1nnu for ; Fri, 19 Jun 2009 07:24:05 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 638E23A6A27 for ; Fri, 19 Jun 2009 07:23:56 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 10:24:08 -0400 To: "Christian Hoene" References: <4A3AE894.70001@usherbrooke.ca> <000401c9f0b8$3948a280$abd9e780$@de> <20090619032841.2122362oqyhc3k2h@mail.skype.net> <000d01c9f0d3$06b2da00$14188e00$@de> From: Randell Jesup Date: Fri, 19 Jun 2009 10:24:02 -0400 In-Reply-To: <000d01c9f0d3$06b2da00$14188e00$@de> (Christian Hoene's message of "Fri\, 19 Jun 2009 13\:42\:28 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 19 Jun 2009 14:24:08.0423 (UTC) FILETIME=[9B887F70:01C9F0E9] Cc: codec@ietf.org Subject: Re: [codec] Include Dejitter Buffer? WAS RE: RE : Codec BOF approved, much work needed X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup List-Id: "Should the IETF standardize wideband Internet codec\(s\)? " List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 14:24:06 -0000 "Christian Hoene" writes: >[132] Y. J. Liang, N. F=C2=A8arber, and B. Girod, =E2=80=9CAdaptive playou= t scheduling >and loss concealment for voice communication over IP networks,=E2=80=9D IE= EE >Transactions on Multimedia, vol. 5, no. 4, pp. 532=E2=80=93543, Dec. 2003.= =20 >[135] F. Liu, J. Kim, and C.-C. J. Kuo, =E2=80=9CAdaptive delay concealmen= t for >internet voice applications with packet-based time-scale modification,=E2= =80=9D in >IEEE International Conference on Acoustics, Speech, and Signal Processing >(ICASSP =E2=80=9901), vol. 3, May 2001, pp. 1461=E2=80=931464. ... >To my understanding, a modern dejittering buffer uses a similar algorithm = as >described in [132] and [135] and is >a) medium specific (e.g., can only be used for audio) >b) might be codec-depended if its implementation shall be computational >efficient. Agreed: adaptive, media-specific. I can see knowledge of the codec being useful, though that could be parameterized -- i.e. tell the jitter buffer about the characteristics of the codec to let it adjust tradeoffs, like the tradeoff between delay and loss. For example, some codecs might be fairly insensitive to one-packet losses, and the buffer might crank down delay, while with another codec there may be less redundant information in surrounding packets, and thus you might increase delay slightly if it reduces late-packet "losses" due to jitter.=20=20 Note that much of this is a true matter of heuristic tuning, and the tradeoffs can be application-dependent as well. Those are big obstacles to embedding a jitter buffer model in a codec definition (or standardizing them at all). >A couple of ETSI's VoIP performance tests have shown that the best VoIP >phones do use time stretching and shrinking algorithms to lower the impact >of playout adjustments. That would match my understanding and experience. --=20 Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS te= am rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the we= apons provided for defence against real, pretended, or imaginary dangers from abr= oad." - James Madison, 4th US president (1751-1836) From ron.even.tlv@gmail.com Fri Jun 19 08:58:57 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 DB7D43A6981 for ; Fri, 19 Jun 2009 08:58:57 -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 EV06w2ie0dfG for ; Fri, 19 Jun 2009 08:58:56 -0700 (PDT) Received: from mail-fx0-f212.google.com (mail-fx0-f212.google.com [209.85.220.212]) by core3.amsl.com (Postfix) with ESMTP id 1C1B33A659B for ; Fri, 19 Jun 2009 08:58:55 -0700 (PDT) Received: by fxm8 with SMTP id 8so167037fxm.37 for ; Fri, 19 Jun 2009 08:59:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=Nfs3dN8JL2jmAKGlNZoeIh+08RViaX/7KXKK8OqHG0o=; b=IJbIzmKlK+FGUjNjzO3xFfxOFfEKKOJRL4IiO9c9WvFigP14PMf+/x4rmO9kPNbIwg WGfoGUVxLFnTIpsps3CMNQyrr+drvu2EnhXJ0ipp46u/zKrlbb1SClXYsb6lLEZ3MJji p4meIPdaobyhFhJ2E7+H1jbw2XIp84AXh3knc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=sESodd4bBIJAi+h8DazxQCr6zvd21f/LJXID+KVlyPcW0dv7bDOP6DrYIcd4kaEfki 9EuWfDLaBvdtflMliw0I3erNl0sQ6fO80oi5wSOrnWCEJQKFd4LJBp5SywTqh2xbdqDT n+8lxp6HSzEMoqFm6sDEOMqYQllZ3vHfzftA4= MIME-Version: 1.0 Received: by 10.86.26.11 with SMTP id 11mr3373370fgz.45.1245427144107; Fri, 19 Jun 2009 08:59:04 -0700 (PDT) Date: Fri, 19 Jun 2009 18:59:04 +0300 Message-ID: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com> From: Ron Even To: codec@ietf.org Content-Type: multipart/alternative; boundary=000e0cd286e284a7a5046cb59a55 Subject: Re: [codec] Codec BOF approved, much work needed 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: Fri, 19 Jun 2009 15:58:57 -0000 --000e0cd286e284a7a5046cb59a55 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cullen, I looked at the agenda 1. Administrative (Chairs, 5 min) - Note takers, Jabber scribes - Agenda bashing 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) 3. Proposed CODECs (TBD, 25 min) - Expect to have two or more drafts here 4. Charter Discussion (All, 40 min) 5. Decisions and HUMs (All, 5 min) 6. Conclusions and Next Steps (Chairs/ADs, 5 min) And it looks to me that it starts with assumption that we will have a new working group. I am not sure that that this was agreed and yet I see no time allocated to discuss the topic. I would expect that item 3 will be rational for doing codec at the IETF considering that this work is done also by other SDOs that the IETF is working with. Now even if there will be such a WG starting with proposed CODECS is like having a solution before the requirements. In other standard bodies requirements are not just names but they also have values. So what is the purpose of proposing codecs, do we need to select at the BOF which one will be standardize, to me it looks like this should be done later. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Cullen Jennings > Sent: Friday, June 12, 2009 8:32 PM > To: codec@ietf.org > Subject: [codec] Codec BOF approved, much work needed > > > I have approved the CODEC BOF proposal. However, we need a bunch of > work to get ready. Various people on IESG/IAB were not comfortable > with the current charter and agenda so we need to work on theses > before the meeting. > > A draft agenda/charter Jason provided are at > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- > bof/charter.txt > > After discussion with the IESG/IAB: > > I'd like to remove the "as Proposed Standard" from the charter text > for both milestones and see how the discussion goes in the BOF before > deciding which way this should go. > > I'd like to see more consideration around the issues of designing a > codec that did a good job of mapping a real time stream onto IP > packets. The way IP deals with packet loss and congestion has > implications for designing a codec that works well over IP. I know > some of the discussion I have had off list people talked about how we > wanted a codec that supported adaptive bit rates that could change on > the fly to be able to work well on an IP network. > > I will be working the folks to make sure the agenda has time to > directly address the key topics which include (more may be coming): > > Will we be able to get qualified people to do and review the work? > > Key design goals of a new codec? > > Do we need a new codec or are there already ones defined that meet the > needs? > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. > > Thanks, > > Cullen > > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --000e0cd286e284a7a5046cb59a55 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Cullen,

I looked at the agenda

=A0

1. Administrative (Chairs, 5 min)

=A0 - Note t= akers, Jabber scribes

=A0 - Agenda= bashing

=A0 <= /font>

2. Introduction and Scoping of BOF (Chairs/ADs, 15 mi= n)

=A0 <= /font>

3. Proposed CODECs (TBD, 25 min)

=A0 - Expect= to have two or more drafts here

=A0

4. Charter Discussion (All, 40 min)

=A0

5. Decisions and HUMs (All, 5 min)

=A0

6. Conclusions and Next Steps (Chairs/ADs, 5 min)=A0

=A0

=A0

And it looks to me that it starts with assumption tha= t we will have a new working group.

=A0

I am not sure that that this was agreed and yet I see= no time allocated to discuss the topic. I would expect that item 3 will be= rational for doing codec at the IETF considering that this work is done al= so by other SDOs that the IETF is working with.

=A0

Now even if there will be such a WG starting with pro= posed CODECS is like having a solution before the requirements. In other st= andard bodies requirements are not just names but they also have values. So= what is the purpose of proposing codecs, do we need to select at the BOF w= hich one will be standardize, to me it looks like this should be done later= .

=A0

Roni Even=A0

=A0

=A0 <= /font>

=A0

=A0

> -----Original Message-----

> From: = codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf

> Of Cullen Jennings

> Sent: Friday, June 12, 2009 8:32 PM

> To: codec@ietf= .org

> Subject: [codec] Codec BOF approved, much work n= eeded

>

>

> I have approved the CODEC BOF proposal. However,= we need a bunch of

> work to get ready.=A0 Various people on IESG/IAB were not comfortable

> with the current charter and agenda so we need t= o work on theses

> before the meeting.

>

> A draft agenda/charter Jason provided are at

>

> Agenda: http://svn.resiprocate.org/rep/ietf-dra= fts/codec-bof/agenda.txt

>

> Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-

> bof/charter.txt

>

> After discussion with the IESG/IAB:

>

> I'd like to remove the "as Proposed Sta= ndard" from the charter text

> for both milestones and see how the discussion g= oes in the BOF before

> deciding which way this should go.=

>

> I'd like to see more consideration around th= e issues of designing a

> codec that did a good job of mapping a real time= stream onto IP

> packets. The way IP deals with packet loss and c= ongestion has

> implications for designing a codec that works we= ll over IP. I know

> some of the discussion I have had off list peopl= e talked about how we

> wanted a codec that supported adaptive bit rates= that could change on

> the fly to be able to work well on an IP network= .

>

> I will be working the folks to make sure the age= nda has time to

> directly address the key topics which include (m= ore may be coming):

>

> Will we be able to get qualified people to do an= d review the work?

>

> Key design goals of a new codec?

>

> Do we need a new codec or are there already ones= defined that meet the

> needs?

>

> I have asked Jason Fischl=A0 and Jean-Marc Valin to co-chair this BOF.

>

> Thanks,

>

> Cullen <RAI AD>

>

>

>

>

>

> _______________________________________________<= /font>

> codec mailing list

> codec@ietf.org=

> https://www.ietf.org/mailman/listinfo/codec

--000e0cd286e284a7a5046cb59a55-- From Borilin@spiritdsp.com Fri Jun 19 09:21:57 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 7F2583A69C4 for ; Fri, 19 Jun 2009 09:21:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.633 X-Spam-Level: X-Spam-Status: No, score=-1.633 tagged_above=-999 required=5 tests=[AWL=0.514, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152] 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 qpIOdllrLU6j for ; Fri, 19 Jun 2009 09:21:56 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 388843A69B1 for ; Fri, 19 Jun 2009 09:21:56 -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 n5JGLnKM007176; Fri, 19 Jun 2009 20:21:50 +0400 (MSD) (envelope-from Borilin@spiritdsp.com) Received: from 192.168.125.5 ([192.168.125.5]) by mail-srv.spiritcorp.com ([192.168.125.3]) with Microsoft Exchange Server HTTP-DAV ; Fri, 19 Jun 2009 16:21:43 +0000 MIME-Version: 1.0 Content-class: From: "Slava Borilin" Message-ID: <001301c9f0fa$09138588$057da8c0@spiritcorp.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Jun 2009 20:21:35 +0400 Importance: normal X-Priority: 3 thread-topic: Re: [codec] Codec BOF approved, much work needed thread-index: Acnw+gkTHL2SdLtVTDiF20h8Qld27Q== X-MimeOLE: Produced By Microsoft Exchange V6.5 To: "Ron Even" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: [codec] =?utf-8?b?0J3QkDogUmU6ICBDb2RlYyBCT0YgYXBwcm92ZWQsIG11?= =?utf-8?q?ch_work_needed?= 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: Fri, 19 Jun 2009 16:21:57 -0000 Agree with Roni- reqs first. Suggest to change 3 to =C2=ABrequirements = fot codec=C2=BB. Slava Borilin=20 ----- =D0=98=D1=81=D1=85=D0=BE=D0=B4=D0=BD=D0=BE=D0=B5 = =D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0=BD=D0=B8=D0=B5 ----- =D0=9E=D1=82: Ron Even =D0=9E=D1=82=D0=BF=D1=80=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=D0=BE: 19 = =D0=B8=D1=8E=D0=BD=D1=8F 2009 =D0=B3. 19:59 =D0=9A=D0=BE=D0=BC=D1=83: codec@ietf.org =D0=A2=D0=B5=D0=BC=D0=B0: Re: [codec] Codec BOF approved, much work = needed Cullen, I looked at the agenda 1. Administrative (Chairs, 5 min) - Note takers, Jabber scribes - Agenda bashing 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) 3. Proposed CODECs (TBD, 25 min) - Expect to have two or more drafts here 4. Charter Discussion (All, 40 min) 5. Decisions and HUMs (All, 5 min) 6. Conclusions and Next Steps (Chairs/ADs, 5 min) And it looks to me that it starts with assumption that we will have a = new working group. I am not sure that that this was agreed and yet I see no time allocated = to discuss the topic. I would expect that item 3 will be rational for doing codec at the IETF considering that this work is done also by other SDOs = that the IETF is working with. Now even if there will be such a WG starting with proposed CODECS is = like having a solution before the requirements. In other standard bodies requirements are not just names but they also have values. So what is = the purpose of proposing codecs, do we need to select at the BOF which one = will be standardize, to me it looks like this should be done later. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Cullen Jennings > Sent: Friday, June 12, 2009 8:32 PM > To: codec@ietf.org > Subject: [codec] Codec BOF approved, much work needed > > > I have approved the CODEC BOF proposal. However, we need a bunch of > work to get ready. Various people on IESG/IAB were not comfortable > with the current charter and agenda so we need to work on theses > before the meeting. > > A draft agenda/charter Jason provided are at > > Agenda: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- > bof/charter.txt > > After discussion with the IESG/IAB: > > I'd like to remove the "as Proposed Standard" from the charter text > for both milestones and see how the discussion goes in the BOF before > deciding which way this should go. > > I'd like to see more consideration around the issues of designing a > codec that did a good job of mapping a real time stream onto IP > packets. The way IP deals with packet loss and congestion has > implications for designing a codec that works well over IP. I know > some of the discussion I have had off list people talked about how we > wanted a codec that supported adaptive bit rates that could change on > the fly to be able to work well on an IP network. > > I will be working the folks to make sure the agenda has time to > directly address the key topics which include (more may be coming): > > Will we be able to get qualified people to do and review the work? > > Key design goals of a new codec? > > Do we need a new codec or are there already ones defined that meet the > needs? > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. > > Thanks, > > Cullen > > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From ron.even.tlv@gmail.com Fri Jun 19 10:47:52 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 7EC633A6B8A for ; Fri, 19 Jun 2009 10:47:52 -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 yKUoithRjel4 for ; Fri, 19 Jun 2009 10:47:51 -0700 (PDT) Received: from mail-fx0-f212.google.com (mail-fx0-f212.google.com [209.85.220.212]) by core3.amsl.com (Postfix) with ESMTP id 0B3D23A6B87 for ; Fri, 19 Jun 2009 10:47:50 -0700 (PDT) Received: by fxm8 with SMTP id 8so233438fxm.37 for ; Fri, 19 Jun 2009 10:48:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=V1w9v1yzhuUApMz8uKR/BPNkDVcGfYaEWyAVZ5ukpfQ=; b=pTb17RKy+joY/VkDlHtxH2nUbCids9P35xIOFk2Bzto5oCKmbkb/vXZyg7MlXtMkGV xKr3kul8uvmdpgnts2XX1SZcgcwOK/XXft4uGyB++I/H0XDnSiH2uAZkQaWEV1Xv6JYp HgsMhl8aWm5oezxniovZo7vBIc7A/L7KUxSEo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=sPwIk/mglFDKT8+iFSxmuAeG/3x057ifFLKnIDDVqko3FkRk6fKnoqjHSbncSfdYke zg7nqlmQQhfqf1hyWqgIwGWq1QIza3DvLEKnOjHc7fejxRUMa7U+6+dL73a9Szotm/Lz arrHd39rGreLuKt+DzOOERPtD7C19xTyeayBQ= Received: by 10.103.215.15 with SMTP id s15mr2029023muq.118.1245433681793; Fri, 19 Jun 2009 10:48:01 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-78-100.red.bezeqint.net [79.179.78.100]) by mx.google.com with ESMTPS id 7sm4984273mup.24.2009.06.19.10.47.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Jun 2009 10:48:00 -0700 (PDT) From: "Roni Even" To: "'Slava Borilin'" , References: <001301c9f0fa$09138588$057da8c0@spiritcorp.com> In-Reply-To: <001301c9f0fa$09138588$057da8c0@spiritcorp.com> Date: Fri, 19 Jun 2009 20:46:50 +0300 Message-ID: <4a3bcf50.0710660a.29d4.492a@mx.google.com> 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: Acnw+gkTHL2SdLtVTDiF20h8Qld27QAC3/UQ Content-Language: en-us Subject: Re: [codec] Codec BOF approved, much work needed 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: Fri, 19 Jun 2009 17:47:52 -0000 Slava, This was not my suggestion, please read what I wrote, I suggested to = discuss the rational for doing codec work at the IETF. Anyhow codec themselves should not be presented at a BOF or maybe we can = hum on the codecs in the BOF and be done with this work Roni > -----Original Message----- > From: Slava Borilin [mailto:Borilin@spiritdsp.com] > Sent: Friday, June 19, 2009 7:22 PM > To: Ron Even; codec@ietf.org > Subject: =D0=9D=D0=90: Re: [codec] Codec BOF approved, much work = needed >=20 > Agree with Roni- reqs first. Suggest to change 3 to =C2=ABrequirements = fot > codec=C2=BB. >=20 > Slava Borilin >=20 > ----- =D0=98=D1=81=D1=85=D0=BE=D0=B4=D0=BD=D0=BE=D0=B5 = =D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0=BD=D0=B8=D0=B5 ----- > =D0=9E=D1=82: Ron Even > =D0=9E=D1=82=D0=BF=D1=80=D0=B0=D0=B2=D0=BB=D0=B5=D0=BD=D0=BE: 19 = =D0=B8=D1=8E=D0=BD=D1=8F 2009 =D0=B3. 19:59 > =D0=9A=D0=BE=D0=BC=D1=83: codec@ietf.org > =D0=A2=D0=B5=D0=BC=D0=B0: Re: [codec] Codec BOF approved, much work = needed >=20 > Cullen, >=20 > I looked at the agenda >=20 >=20 >=20 > 1. Administrative (Chairs, 5 min) >=20 > - Note takers, Jabber scribes >=20 > - Agenda bashing >=20 >=20 >=20 > 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) >=20 >=20 >=20 > 3. Proposed CODECs (TBD, 25 min) >=20 > - Expect to have two or more drafts here >=20 >=20 >=20 > 4. Charter Discussion (All, 40 min) >=20 >=20 >=20 > 5. Decisions and HUMs (All, 5 min) >=20 >=20 >=20 > 6. Conclusions and Next Steps (Chairs/ADs, 5 min) >=20 >=20 >=20 >=20 >=20 > And it looks to me that it starts with assumption that we will have a > new > working group. >=20 >=20 >=20 > I am not sure that that this was agreed and yet I see no time = allocated > to > discuss the topic. I would expect that item 3 will be rational for > doing > codec at the IETF considering that this work is done also by other = SDOs > that > the IETF is working with. >=20 >=20 >=20 > Now even if there will be such a WG starting with proposed CODECS is > like > having a solution before the requirements. In other standard bodies > requirements are not just names but they also have values. So what is > the > purpose of proposing codecs, do we need to select at the BOF which one > will > be standardize, to me it looks like this should be done later. >=20 >=20 >=20 > Roni Even >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > > -----Original Message----- >=20 > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > Behalf >=20 > > Of Cullen Jennings >=20 > > Sent: Friday, June 12, 2009 8:32 PM >=20 > > To: codec@ietf.org >=20 > > Subject: [codec] Codec BOF approved, much work needed >=20 > > >=20 > > >=20 > > I have approved the CODEC BOF proposal. However, we need a bunch of >=20 > > work to get ready. Various people on IESG/IAB were not comfortable >=20 > > with the current charter and agenda so we need to work on theses >=20 > > before the meeting. >=20 > > >=20 > > A draft agenda/charter Jason provided are at >=20 > > >=20 > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec- > bof/agenda.txt >=20 > > >=20 > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- >=20 > > bof/charter.txt >=20 > > >=20 > > After discussion with the IESG/IAB: >=20 > > >=20 > > I'd like to remove the "as Proposed Standard" from the charter text >=20 > > for both milestones and see how the discussion goes in the BOF = before >=20 > > deciding which way this should go. >=20 > > >=20 > > I'd like to see more consideration around the issues of designing a >=20 > > codec that did a good job of mapping a real time stream onto IP >=20 > > packets. The way IP deals with packet loss and congestion has >=20 > > implications for designing a codec that works well over IP. I know >=20 > > some of the discussion I have had off list people talked about how = we >=20 > > wanted a codec that supported adaptive bit rates that could change = on >=20 > > the fly to be able to work well on an IP network. >=20 > > >=20 > > I will be working the folks to make sure the agenda has time to >=20 > > directly address the key topics which include (more may be coming): >=20 > > >=20 > > Will we be able to get qualified people to do and review the work? >=20 > > >=20 > > Key design goals of a new codec? >=20 > > >=20 > > Do we need a new codec or are there already ones defined that meet > the >=20 > > needs? >=20 > > >=20 > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. >=20 > > >=20 > > Thanks, >=20 > > >=20 > > Cullen >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > > _______________________________________________ >=20 > > codec mailing list >=20 > > codec@ietf.org >=20 > > https://www.ietf.org/mailman/listinfo/codec From ron.even.tlv@gmail.com Fri Jun 19 11:42:11 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 1CD3C3A6AFF for ; Fri, 19 Jun 2009 11:42:11 -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 kIMnFv27g-Bb for ; Fri, 19 Jun 2009 11:42:10 -0700 (PDT) Received: from mail-fx0-f212.google.com (mail-fx0-f212.google.com [209.85.220.212]) by core3.amsl.com (Postfix) with ESMTP id C5D163A6981 for ; Fri, 19 Jun 2009 11:42:09 -0700 (PDT) Received: by fxm8 with SMTP id 8so261816fxm.37 for ; Fri, 19 Jun 2009 11:42:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=AOyRcUiSchHFcDUCJHD5miyxxx8QJv4MNDuNWbKIxos=; b=OnwE0/1EXPIYlGx3/4CJwFXCKOE+3fRbvmZSe09Z3qSZmEp5YLs0c3OlK7elCrKJJ3 NtvJk+NIZaSfFykHxuz/tmq2JfrjbXhDsJlLDcAfyrEyoAYGcTQmlKP52F9QgCMjHwSS ZKWuF6FiOWuCQhxhlXMch6jQlytfGGd1136OA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=uF/A4fL7Yg8jmw2l8+2lfM5w5yV1e8zqMqlord7JVZZKSbhBwmdildOHYTJ9BK4xoo OYUCTkJbUIyoUWlK93wVCj+xpV/x+bGqJNRylq5q1AwviKcXQYangnYR/8LAFJVmcwzp ysVrz20nQT2rkKY07zuZ2OusK7FVn0Q8cmxKk= Received: by 10.103.168.12 with SMTP id v12mr2072056muo.45.1245436936962; Fri, 19 Jun 2009 11:42:16 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-78-100.red.bezeqint.net [79.179.78.100]) by mx.google.com with ESMTPS id i5sm6944896mue.55.2009.06.19.11.42.15 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Jun 2009 11:42:16 -0700 (PDT) From: "Roni Even" To: References: <001301c9f0fa$09138588$057da8c0@spiritcorp.com> In-Reply-To: <001301c9f0fa$09138588$057da8c0@spiritcorp.com> Date: Fri, 19 Jun 2009 21:41:04 +0300 Message-ID: <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> 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: Acnw+gkTHL2SdLtVTDiF20h8Qld27QADaHaA Content-Language: en-us Subject: [codec] Codec BOF approved, comments on charter 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: Fri, 19 Jun 2009 18:42:11 -0000 Hi, Inline some comments (sections starting with RE) on the charter. Purpose: This new working group would be chartered with the purpose of collecting expertise within the IETF in order to review the design of audio codecs specifically for use with the Internet.=20 Unlike other SDOs, these codecs would be optimized for use on the = Internet,=20 RE: I would argue that this statement is not correct and I have not seen = any data supporting this statement, the fact is that there are numerous = codecs coming from other SDOs being used on the Internet. I would also = say that optimize for the Internet is not an application description = since it is to wide, eventually this will be reflected if you start to = discuss requirements when you will need to describe the applications = that will use this codec. and as much as possible choose technology that does not require paying = patent royalties. RE: Is this a selection criteria for selecting a codec. The Internet Low Bit Rate Codec (iLBC) work was done in AVT but it was = felt that subsequent work should not be done in the AVT working group.=20 RE: to say done is overstating what was done in AVT comparing to other = bodies. Furthermore it is not the same to publish a codec done by some = company as an Informational and specifying requirements and selecting = one codec from multiple proposal based on quality criteria This new working group will have as its primary purpose the = standardization of a multi-purpose audio codec that can be used in various situations on the Internet. Some of the proposed Internet-specific requirements include: * scalable and adaptive bit rate; * various sampling rate profiles from narrow-band to super-wideband; RE: Just to clarify do you mean 3.5Khz, 7Khz and 14 Khz? * scalable complexity; * low latency; and=20 * resilience to packet loss. RE: I think that the first stage is to describe the use scenarios before = giving requirements. For the current text I can add multiple other = requirements for example: Support for hands free operation (open mic), speech and music, multiple = languages support, fax, stereo, 5+1, layered codec ......... There are a number of wide-band capable codecs defined by other SDOs. = For instance, G.722 is seeing adoption in Enterprise applications since it = is relatively simple and low-cost to deploy. However, it has a high, fixed bitrate and is not appropriate for mobile applications where spectrum efficiency is important or in consumer applications where available bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been = adopted by the 3GPP as a wideband standard for mobile applications. G.722.2 is relatively high cost due to patent royalties and is seeing minimal deployments outside of mobile handsets making it challenging to create wideband experiences on Internet-capable mobile devices when extending beyond the mobile network. In other cases, proprietary codecs are being adopted which further create islands with no interoperability unless widespread transcoding is performed. Transcoding leads to higher costs = and lower quality. RE: Basing your discussion on G.722 and G.722.2 is not correct (G.722 is = 7Khz) the latest codecs technology will be AMR-WB+, MPEG4 AAC-LD or = scalable, eAAC+, G.729 with the new enhancement layers for wide band, = G.718. Note that the ITU is working on embedded variable bit rates codec = technology. =20 The goal of this working group is to define a single codec with multiple profiles which can be made available on a wide variety of = Internet-capable devices including low-power, mobile devices as well as devices capable = of utilizing high quality, high bitrate audio. RE: What is multiple profiles is it embedded variable rate (layered = codec) or is it different modes (like G.722.1 and G.722.1C) using the = same codec technology. Proposed Deliverables: 1) Requirements for wideband, Internet audio codec(s). 2) Algorithm description for wideband, Internet audio codec(s) as = Proposed Standard.=20 3) Specification of payload format(s) for defined codecs as Proposed Standard RE: Other deliverables - testing procedure and metrics. Codec selection = criteria - which requirements are more important. I am also not sure = what is algorithm description means, I would except a fixed point source = reference if we want to have bit exactness between multiple = implementations.=20 The deliverables should include quality test results from independent = test labs to enable selection. I also thought from the above text that we are talking about super = wideband and not wide band codec. Thanks Roni Even From ron.even.tlv@gmail.com Fri Jun 19 12:05:34 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 A6CA43A6A02 for ; Fri, 19 Jun 2009 12:05:34 -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=[AWL=-0.000, 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 wWubJnOfDio5 for ; Fri, 19 Jun 2009 12:05:33 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 8EA883A69A9 for ; Fri, 19 Jun 2009 12:05:33 -0700 (PDT) Received: by bwz9 with SMTP id 9so1954278bwz.37 for ; Fri, 19 Jun 2009 12:05:43 -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:thread-index:content-language; bh=cBBq2U3IN8QRGwKz8AgCNht2LeWp3uogQ0V1zP3A3u4=; b=dGM+pOFM3UlysOUP0G5hy63HkaqDtplVhLdgdfC1cn6UJqpJfiOHni0AwE0pN9xNyl /XNXOJxgBcfwmfwVWvuA0PUCPFh+Ld/b5esAtEDpcxdJ+82OKGvdWGyfAWodyG3PIMOG 9r/Psa1fZwQZ3Ft1yQv5wygoSG5vObWc6AbA4= 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 :thread-index:content-language; b=SKWqw/Jj5JYK11KwY1EOlV139UwceqJYjseW9JLo7pJeqRBOgFIyvWQf3hbq7s57DA Sgu5ZcMuWzNi4RY7t1kO3TMs+oR27CRi0RFMrtzIrseJ41MJbIpONeAZawaaqjN4THlg fqRvMddTT2pYVcbSNNQz4IhKLRfJUVhwQsd8o= Received: by 10.103.176.20 with SMTP id d20mr2062435mup.27.1245438343664; Fri, 19 Jun 2009 12:05:43 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-78-100.red.bezeqint.net [79.179.78.100]) by mx.google.com with ESMTPS id j10sm12528816muh.45.2009.06.19.12.05.42 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Jun 2009 12:05:43 -0700 (PDT) From: "Roni Even" To: "'Jean-Marc Valin'" References: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com> <4A3BDE42.3090508@octasic.com> In-Reply-To: <4A3BDE42.3090508@octasic.com> Date: Fri, 19 Jun 2009 22:04:33 +0300 Message-ID: <4a3be187.0aec660a.691c.ffffdf99@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnxDvZAgHcCPS5OQqmNkcGiazTLqQAAMaQQ Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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: Fri, 19 Jun 2009 19:05:34 -0000 Jaen-Marc, Charter does not constitute the requirements from the codec or do you think that what is in the charter are the requirements. I am also not sure what you mean when you are saying that presenting codecs will prevent what you call kitchen sink/wish list requirements. Are the codecs to be presented the only codecs allowed for the WG and if not then why present them, better spend the BOF time on deciding if this work should be done and if there is a consensus try to discuss how the WG will define requirements and select a codec. I think that even for these topics the BOF time will be too short Roni Even > -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] > Sent: Friday, June 19, 2009 9:52 PM > To: Ron Even > Cc: codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > Ron Even wrote: > > > > Now even if there will be such a WG starting with proposed CODECS is > > like having a solution before the requirements. In other standard > > bodies requirements are not just names but they also have values. So > > what is the purpose of proposing codecs, do we need to select at the > > BOF which one will be standardize, to me it looks like this should be > > done later. > > > > I agree that discussing the requirements is very important, I just > assumed that is was part of the "Charter Discussion" item. Regarding > codec proposals, I think it's still a good idea to have that as a way > to > better focus the discussions. We don't have to choose any or the > proposed codecs and if we do, it doesn't have to be in the form they > have been submitted. What this does however is: > 1) It gives us a base for discussion to avoid defining kitchen- > sink/wish > list requirements > 2) It shows us some technology we have available right now, so that we > can adapt it rather than starting from scratch > > Cheers, > > Jean-Marc From koen.vos@skype.net Fri Jun 19 13:19: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 DD3983A69A9 for ; Fri, 19 Jun 2009 13:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.769 X-Spam-Level: X-Spam-Status: No, score=-5.769 tagged_above=-999 required=5 tests=[AWL=0.830, 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 Y+VijnTQIZC2 for ; Fri, 19 Jun 2009 13:19:35 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 518973A6840 for ; Fri, 19 Jun 2009 13:19:35 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 702D92007A95F for ; Fri, 19 Jun 2009 22:19:47 +0200 (CEST) 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=rupIYpxWWHXa cq1TcKmHk+uZCHc=; b=fplG+HYdOr9bRBsdsvZo2GcGwR3RMn6FdPZSmOLYP2HQ 1qqanIGFPSy6y17ZD8AtXqq278EUejhNyvrdnkF0HIz2iYrhzBK51rGyIAKVTI6o Ee7GX0uOtO+V/oMqLKkYh/YCwVjsLQjoXQl8IZvcJuOpkEsVryEAitM+8a3vmoY= 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=T2r+his3lTU6aPoRSYsm j5vB97CLbNryrdAp0KYTloCjz6LB6zexXvjNyLGXk4MkPpTTIHYNq2TNaoNzlEmV VNk3Fq0ulz+R5X1AEJq/j9R/xKRVO/V93yYtXwgjrttdWPS5704obCiBG7WQ18FO fVb0cG1aon53f2byTkkiJeA= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 6EAC72007A798 for ; Fri, 19 Jun 2009 22:19:47 +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 xAjnpZMf027m for ; Fri, 19 Jun 2009 22:19:37 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 7D0CD2007C15F; Fri, 19 Jun 2009 22:19:37 +0200 (CEST) Received: from adsl-71-141-96-214.dsl.snfc21.pacbell.net (adsl-71-141-96-214.dsl.snfc21.pacbell.net [71.141.96.214]) by mail.skype.net (Horde Framework) with HTTP; Fri, 19 Jun 2009 13:19:37 -0700 Message-ID: <20090619131937.60923aczat3opjh5@mail.skype.net> Date: Fri, 19 Jun 2009 13:19:37 -0700 From: Koen Vos To: codec@ietf.org References: <001301c9f0fa$09138588$057da8c0@spiritcorp.com> <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> In-Reply-To: <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> 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] Codec BOF approved, comments on charter 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: Fri, 19 Jun 2009 20:19:37 -0000 Quoting Roni Even: > For the current text I can add multiple other requirements for example: > Support for hands free operation (open mic), You mean built-in echo cancellation and noise suppression? Or are you just specifying a test requirement? > speech and music, stereo People on this list seem to think - efficient speech codec at low bitrates - high quality for music/stereo at higher rates > multiple languages support, Most codec standards are in C. Or are you again talking test specs? > fax, Fax has problems with any VoIP codec. Why not stick with T.38? > 5+1 Not sure how important 5+1 is for real-time communications. > layered codec The use case is limited to certain multi-party calls, but it's a valid point to discuss. The alternative is transcoding. best, koen. Quoting Roni Even: > Hi, > Inline some comments (sections starting with RE) on the charter. > > Purpose: > > This new working group would be chartered with the purpose of collecting > expertise within the IETF in order to review the design of audio codecs > specifically for use with the Internet. > > Unlike other SDOs, these codecs would be optimized for use on the Internet, > > RE: I would argue that this statement is not correct and I have not > seen any data supporting this statement, the fact is that there are > numerous codecs coming from other SDOs being used on the Internet. I > would also say that optimize for the Internet is not an application > description since it is to wide, eventually this will be reflected > if you start to discuss requirements when you will need to describe > the applications that will use this codec. > > > and as much as possible choose technology that does not require > paying patent royalties. > > RE: Is this a selection criteria for selecting a codec. > > > The Internet Low Bit Rate Codec (iLBC) work was done in AVT but it was felt > that subsequent work should not be done in the AVT working group. > > RE: to say done is overstating what was done in AVT comparing to > other bodies. Furthermore it is not the same to publish a codec done > by some company as an Informational and specifying requirements and > selecting one codec from multiple proposal based on quality criteria > > This new working group will have as its primary purpose the > standardization of a > multi-purpose audio codec that can be used in various situations on the > Internet. Some of the proposed Internet-specific requirements include: > * scalable and adaptive bit rate; > * various sampling rate profiles from narrow-band to super-wideband; > > RE: Just to clarify do you mean 3.5Khz, 7Khz and 14 Khz? > > * scalable complexity; > * low latency; and > * resilience to packet loss. > > RE: I think that the first stage is to describe the use scenarios > before giving requirements. For the current text I can add multiple > other requirements for example: > Support for hands free operation (open mic), speech and music, > multiple languages support, fax, stereo, 5+1, layered codec ......... > > > There are a number of wide-band capable codecs defined by other SDOs. For > instance, G.722 is seeing adoption in Enterprise applications since it is > relatively simple and low-cost to deploy. However, it has a high, fixed > bitrate and is not appropriate for mobile applications where spectrum > efficiency is important or in consumer applications where available > bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been adopted > by the 3GPP as a wideband standard for mobile applications. G.722.2 is > relatively high cost due to patent royalties and is seeing minimal > deployments outside of mobile handsets making it challenging to create > wideband experiences on Internet-capable mobile devices when extending > beyond the mobile network. In other cases, proprietary codecs are being > adopted which further create islands with no interoperability unless > widespread transcoding is performed. Transcoding leads to higher costs and > lower quality. > > RE: Basing your discussion on G.722 and G.722.2 is not correct > (G.722 is 7Khz) the latest codecs technology will be AMR-WB+, MPEG4 > AAC-LD or scalable, eAAC+, G.729 with the new enhancement layers for > wide band, G.718. Note that the ITU is working on embedded variable > bit rates codec technology. > > > The goal of this working group is to define a single codec with multiple > profiles which can be made available on a wide variety of Internet-capable > devices including low-power, mobile devices as well as devices capable of > utilizing high quality, high bitrate audio. > > RE: What is multiple profiles is it embedded variable rate (layered > codec) or is it different modes (like G.722.1 and G.722.1C) using > the same codec technology. > > > Proposed Deliverables: > > 1) Requirements for wideband, Internet audio codec(s). > 2) Algorithm description for wideband, Internet audio codec(s) as Proposed > Standard. > 3) Specification of payload format(s) for defined codecs as Proposed > Standard > > RE: Other deliverables - testing procedure and metrics. Codec > selection criteria - which requirements are more important. I am > also not sure what is algorithm description means, I would except a > fixed point source reference if we want to have bit exactness > between multiple implementations. > The deliverables should include quality test results from > independent test labs to enable selection. > I also thought from the above text that we are talking about super > wideband and not wide band codec. > > Thanks > Roni Even > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From Jean-Marc.Valin@USherbrooke.ca Fri Jun 19 13:38:51 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 A035D3A68C3 for ; Fri, 19 Jun 2009 13:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.359 X-Spam-Level: X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 TSzPZ+HzZDRr for ; Fri, 19 Jun 2009 13:38:50 -0700 (PDT) Received: from smtpi6.usherbrooke.ca (smtpi6.usherbrooke.ca [132.210.236.2]) by core3.amsl.com (Postfix) with ESMTP id AE4983A68B1 for ; Fri, 19 Jun 2009 13:38:50 -0700 (PDT) Received: from localhost (www05.USherbrooke.ca [132.210.244.140]) by smtpi6.usherbrooke.ca (8.13.8/8.13.8) with ESMTP id n5JKcxH5012808; Fri, 19 Jun 2009 16:38:59 -0400 Received: from 70.54.254.106 ([70.54.254.106]) by www.usherbrooke.ca (IMP) with HTTP for ; Fri, 19 Jun 2009 16:38:59 -0400 Message-ID: <1245443939.4a3bf76372390@www.usherbrooke.ca> Date: Fri, 19 Jun 2009 16:38:59 -0400 From: Jean-Marc Valin To: Roni Even References: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com> <4A3BDE42.3090508@octasic.com> <4a3be187.0aec660a.691c.ffffdf99@mx.google.com> In-Reply-To: <4a3be187.0aec660a.691c.ffffdf99@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 70.54.254.106 X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-MailScanner-ID: n5JKcxH5012808 X-UdeS-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-7.499, requis 5, autolearn=not spam, BAYES_00 -2.60, RDNS_NONE 0.10, UDES_MONBUREAU03 -5.00) X-UdeS-MailScanner-From: jean-marc.valin@usherbrooke.ca Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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: Fri, 19 Jun 2009 20:38:51 -0000 Hi, (again, see my original email in the quote below because the list didn't accept it) Quoting Roni Even : > I am also not sure what you mean when you are saying that presenting codecs > will prevent what you call kitchen sink/wish list requirements. I want to avoid ending up with a list of requirements that looks like: "high-quality music at 8 kbit/s" or "support bit-rates from 2 to 512 kbit/s". It helps to have a reference of what's technologically achievable (even the ITU codecs can serve for that), but it's also useful to have a reference of what we could have in the relatively short term. For example, one way to proceed would be to look at some actual proposals and ask "what more (or less) do we need compared to this?". No, this is not exactly the way the ITU works, but if we wanted everything to work like it does at the ITU, we wouldn't be discussing a new WG. Having actual proposals is also a good way to address the "there is no codec expertise" argument against forming this new WG. Cheers, Jean-Marc > > -----Original Message----- > > From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] > > Sent: Friday, June 19, 2009 9:52 PM > > To: Ron Even > > Cc: codec@ietf.org > > Subject: Re: [codec] Codec BOF approved, much work needed > > > > Ron Even wrote: > > > > > > Now even if there will be such a WG starting with proposed CODECS is > > > like having a solution before the requirements. In other standard > > > bodies requirements are not just names but they also have values. So > > > what is the purpose of proposing codecs, do we need to select at the > > > BOF which one will be standardize, to me it looks like this should be > > > done later. > > > > > > > I agree that discussing the requirements is very important, I just > > assumed that is was part of the "Charter Discussion" item. Regarding > > codec proposals, I think it's still a good idea to have that as a way > > to > > better focus the discussions. We don't have to choose any or the > > proposed codecs and if we do, it doesn't have to be in the form they > > have been submitted. What this does however is: > > 1) It gives us a base for discussion to avoid defining kitchen- > > sink/wish > > list requirements > > 2) It shows us some technology we have available right now, so that we > > can adapt it rather than starting from scratch > > > > Cheers, > > > > Jean-Marc > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > From ron.even.tlv@gmail.com Fri Jun 19 13:39:29 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 DE6FE3A68B1 for ; Fri, 19 Jun 2009 13:39:29 -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 lHTQrYANxWDm for ; Fri, 19 Jun 2009 13:39:28 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id D3EB43A6840 for ; Fri, 19 Jun 2009 13:39:27 -0700 (PDT) Received: by bwz9 with SMTP id 9so1997352bwz.37 for ; Fri, 19 Jun 2009 13:39:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=nzSRBaUe8QYxzPyjOabo/NZxXBxWbHqS0C4B7/doEyw=; b=NESj+K5/gmL1XSAXa787f8VuvTcvnv9S4cwL99yMwH27P8gimwuDSCU5wu0g7/iZsK 0f9lp8HIyF0jv2Qq3B7Fe6DlC4gnEBj2/TbgGiA40vo/HGOdxjByj7+E7X+bi04XdA+G 0fOtZ+C+ENFqAhc/vFlzn3hpEPfuxUDFp6UJw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=mkX/TiXPmmXwhL7HIZkiE6lAvE2IjAK4D0YnjXr89x7Ok9KTvoOds1EY0B8UaS/OqQ MG9Eih6VxhSOUvNm9NccdkPqbACP9coToi9Rf5chisUll6UefH89VbzGPf/mkafLtD61 52wjc+NuIMkrO0uMiwARpdbhb2yUiP/z/aFqQ= Received: by 10.103.223.2 with SMTP id a2mr2127211mur.4.1245443978905; Fri, 19 Jun 2009 13:39:38 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-78-100.red.bezeqint.net [79.179.78.100]) by mx.google.com with ESMTPS id y6sm12766010mug.10.2009.06.19.13.39.37 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Jun 2009 13:39:38 -0700 (PDT) From: "Roni Even" To: "'Koen Vos'" , References: <001301c9f0fa$09138588$057da8c0@spiritcorp.com> <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> <20090619131937.60923aczat3opjh5@mail.skype.net> In-Reply-To: <20090619131937.60923aczat3opjh5@mail.skype.net> Date: Fri, 19 Jun 2009 23:38:28 +0300 Message-ID: <4a3bf78a.06e2660a.605f.ffffef7c@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnxG08VASL65CpdTc+aixF5tRDl4gAAcq9w Content-Language: en-us Subject: Re: [codec] Codec BOF approved, comments on charter 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: Fri, 19 Jun 2009 20:39:30 -0000 Inline > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Koen Vos > Sent: Friday, June 19, 2009 11:20 PM > To: codec@ietf.org > Subject: Re: [codec] Codec BOF approved, comments on charter > > Quoting Roni Even: > > For the current text I can add multiple other requirements for > example: > > Support for hands free operation (open mic), > > You mean built-in echo cancellation and noise suppression? Or are you > just specifying a test requirement? This are codec requirements. Solution and tests are the next step > > > > speech and music, stereo > > People on this list seem to think > - efficient speech codec at low bitrates > - high quality for music/stereo at higher rates This is a requirement that need numbers not words > > > > multiple languages support, > > Most codec standards are in C. Or are you again talking test specs? Requirements, speech quality not only for English language, that will be reflected in the test requirements > > > > fax, > > Fax has problems with any VoIP codec. Why not stick with T.38? Need to specify the requirement, I can live without > > > > 5+1 > > Not sure how important 5+1 is for real-time communications. Music!!!!! > > > > layered codec > > The use case is limited to certain multi-party calls, but it's a valid > point to discuss. The alternative is transcoding. This is not multiparty it will be layering to support the multi rate at different quality. Narrow band lower layer with enhancement layers for wide band and super wideband like G.729 and G.718 > > best, > koen. > > > > Quoting Roni Even: > > Hi, > > Inline some comments (sections starting with RE) on the charter. > > > > Purpose: > > > > This new working group would be chartered with the purpose of > collecting > > expertise within the IETF in order to review the design of audio > codecs > > specifically for use with the Internet. > > > > Unlike other SDOs, these codecs would be optimized for use on the > Internet, > > > > RE: I would argue that this statement is not correct and I have not > > seen any data supporting this statement, the fact is that there are > > numerous codecs coming from other SDOs being used on the Internet. I > > would also say that optimize for the Internet is not an application > > description since it is to wide, eventually this will be reflected > > if you start to discuss requirements when you will need to describe > > the applications that will use this codec. > > > > > > and as much as possible choose technology that does not require > > paying patent royalties. > > > > RE: Is this a selection criteria for selecting a codec. > > > > > > The Internet Low Bit Rate Codec (iLBC) work was done in AVT but it > was felt > > that subsequent work should not be done in the AVT working group. > > > > RE: to say done is overstating what was done in AVT comparing to > > other bodies. Furthermore it is not the same to publish a codec done > > by some company as an Informational and specifying requirements and > > selecting one codec from multiple proposal based on quality criteria > > > > This new working group will have as its primary purpose the > > standardization of a > > multi-purpose audio codec that can be used in various situations on > the > > Internet. Some of the proposed Internet-specific requirements > include: > > * scalable and adaptive bit rate; > > * various sampling rate profiles from narrow-band to super-wideband; > > > > RE: Just to clarify do you mean 3.5Khz, 7Khz and 14 Khz? > > > > * scalable complexity; > > * low latency; and > > * resilience to packet loss. > > > > RE: I think that the first stage is to describe the use scenarios > > before giving requirements. For the current text I can add multiple > > other requirements for example: > > Support for hands free operation (open mic), speech and music, > > multiple languages support, fax, stereo, 5+1, layered codec ......... > > > > > > There are a number of wide-band capable codecs defined by other SDOs. > For > > instance, G.722 is seeing adoption in Enterprise applications since > it is > > relatively simple and low-cost to deploy. However, it has a high, > fixed > > bitrate and is not appropriate for mobile applications where spectrum > > efficiency is important or in consumer applications where available > > bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been > adopted > > by the 3GPP as a wideband standard for mobile applications. G.722.2 > is > > relatively high cost due to patent royalties and is seeing minimal > > deployments outside of mobile handsets making it challenging to > create > > wideband experiences on Internet-capable mobile devices when > extending > > beyond the mobile network. In other cases, proprietary codecs are > being > > adopted which further create islands with no interoperability unless > > widespread transcoding is performed. Transcoding leads to higher > costs and > > lower quality. > > > > RE: Basing your discussion on G.722 and G.722.2 is not correct > > (G.722 is 7Khz) the latest codecs technology will be AMR-WB+, MPEG4 > > AAC-LD or scalable, eAAC+, G.729 with the new enhancement layers for > > wide band, G.718. Note that the ITU is working on embedded variable > > bit rates codec technology. > > > > > > The goal of this working group is to define a single codec with > multiple > > profiles which can be made available on a wide variety of Internet- > capable > > devices including low-power, mobile devices as well as devices > capable of > > utilizing high quality, high bitrate audio. > > > > RE: What is multiple profiles is it embedded variable rate (layered > > codec) or is it different modes (like G.722.1 and G.722.1C) using > > the same codec technology. > > > > > > Proposed Deliverables: > > > > 1) Requirements for wideband, Internet audio codec(s). > > 2) Algorithm description for wideband, Internet audio codec(s) as > Proposed > > Standard. > > 3) Specification of payload format(s) for defined codecs as Proposed > > Standard > > > > RE: Other deliverables - testing procedure and metrics. Codec > > selection criteria - which requirements are more important. I am > > also not sure what is algorithm description means, I would except a > > fixed point source reference if we want to have bit exactness > > between multiple implementations. > > The deliverables should include quality test results from > > independent test labs to enable selection. > > I also thought from the above text that we are talking about super > > wideband and not wide band codec. > > > > Thanks > > Roni Even > > > > > > _______________________________________________ > > 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 Borilin@spiritdsp.com Fri Jun 19 13:44:15 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 BB81D3A68B1 for ; Fri, 19 Jun 2009 13:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.662 X-Spam-Level: X-Spam-Status: No, score=-0.662 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] 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 xlsIzfDTTqaT for ; Fri, 19 Jun 2009 13:44:14 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id E06ED3A6840 for ; Fri, 19 Jun 2009 13:44:13 -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 n5JKiPKi011001; Sat, 20 Jun 2009 00:44:25 +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: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Date: Sat, 20 Jun 2009 00:42:59 +0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec BOF approved, comments on charter Thread-Index: AcnxG1NTsewJxSz5Qa2T0w+JLlEi7gAAzTEK References: <001301c9f0fa$09138588$057da8c0@spiritcorp.com><4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> <20090619131937.60923aczat3opjh5@mail.skype.net> From: "Slava Borilin" To: "Koen Vos" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: [codec] HA: Codec BOF approved, comments on charter 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: Fri, 19 Jun 2009 20:44:15 -0000 I beleive by "languages" Roni meant english, russian spanish etc. 5.1 is not inportant (yet), but stereo (2) is also quite interesting for = conferencing. ________________________________ =EF=D4: codec-bounces@ietf.org =CF=D4 =C9=CD=C5=CE=C9 Koen Vos =EF=D4=D0=D2=C1=D7=CC=C5=CE=CF: =F3=C2, 20.06.2009 0:19 =EB=CF=CD=D5: codec@ietf.org =F4=C5=CD=C1: Re: [codec] Codec BOF approved, comments on charter Quoting Roni Even: > For the current text I can add multiple other requirements for = example: > Support for hands free operation (open mic), You mean built-in echo cancellation and noise suppression? Or are you=20 just specifying a test requirement? > speech and music, stereo People on this list seem to think - efficient speech codec at low bitrates - high quality for music/stereo at higher rates > multiple languages support, Most codec standards are in C. Or are you again talking test specs? > fax, Fax has problems with any VoIP codec. Why not stick with T.38? > 5+1 Not sure how important 5+1 is for real-time communications. > layered codec The use case is limited to certain multi-party calls, but it's a valid=20 point to discuss. The alternative is transcoding. best, koen. Quoting Roni Even: > Hi, > Inline some comments (sections starting with RE) on the charter. > > Purpose: > > This new working group would be chartered with the purpose of = collecting > expertise within the IETF in order to review the design of audio = codecs > specifically for use with the Internet. > > Unlike other SDOs, these codecs would be optimized for use on the = Internet, > > RE: I would argue that this statement is not correct and I have not=20 > seen any data supporting this statement, the fact is that there are=20 > numerous codecs coming from other SDOs being used on the Internet. I=20 > would also say that optimize for the Internet is not an application=20 > description since it is to wide, eventually this will be reflected=20 > if you start to discuss requirements when you will need to describe=20 > the applications that will use this codec. > > > and as much as possible choose technology that does not require=20 > paying patent royalties. > > RE: Is this a selection criteria for selecting a codec. > > > The Internet Low Bit Rate Codec (iLBC) work was done in AVT but it = was felt > that subsequent work should not be done in the AVT working group. > > RE: to say done is overstating what was done in AVT comparing to=20 > other bodies. Furthermore it is not the same to publish a codec done=20 > by some company as an Informational and specifying requirements and=20 > selecting one codec from multiple proposal based on quality criteria > > This new working group will have as its primary purpose the=20 > standardization of a > multi-purpose audio codec that can be used in various situations on = the > Internet. Some of the proposed Internet-specific requirements include: > * scalable and adaptive bit rate; > * various sampling rate profiles from narrow-band to super-wideband; > > RE: Just to clarify do you mean 3.5Khz, 7Khz and 14 Khz? > > * scalable complexity; > * low latency; and > * resilience to packet loss. > > RE: I think that the first stage is to describe the use scenarios=20 > before giving requirements. For the current text I can add multiple=20 > other requirements for example: > Support for hands free operation (open mic), speech and music,=20 > multiple languages support, fax, stereo, 5+1, layered codec ......... > > > There are a number of wide-band capable codecs defined by other SDOs. = For > instance, G.722 is seeing adoption in Enterprise applications since it = is > relatively simple and low-cost to deploy. However, it has a high, = fixed > bitrate and is not appropriate for mobile applications where spectrum > efficiency is important or in consumer applications where available > bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been = adopted > by the 3GPP as a wideband standard for mobile applications. G.722.2 is > relatively high cost due to patent royalties and is seeing minimal > deployments outside of mobile handsets making it challenging to create > wideband experiences on Internet-capable mobile devices when extending > beyond the mobile network. In other cases, proprietary codecs are = being > adopted which further create islands with no interoperability unless > widespread transcoding is performed. Transcoding leads to higher costs = and > lower quality. > > RE: Basing your discussion on G.722 and G.722.2 is not correct=20 > (G.722 is 7Khz) the latest codecs technology will be AMR-WB+, MPEG4=20 > AAC-LD or scalable, eAAC+, G.729 with the new enhancement layers for=20 > wide band, G.718. Note that the ITU is working on embedded variable=20 > bit rates codec technology. > > > The goal of this working group is to define a single codec with = multiple > profiles which can be made available on a wide variety of = Internet-capable > devices including low-power, mobile devices as well as devices capable = of > utilizing high quality, high bitrate audio. > > RE: What is multiple profiles is it embedded variable rate (layered=20 > codec) or is it different modes (like G.722.1 and G.722.1C) using=20 > the same codec technology. > > > Proposed Deliverables: > > 1) Requirements for wideband, Internet audio codec(s). > 2) Algorithm description for wideband, Internet audio codec(s) as = Proposed > Standard. > 3) Specification of payload format(s) for defined codecs as Proposed > Standard > > RE: Other deliverables - testing procedure and metrics. Codec=20 > selection criteria - which requirements are more important. I am=20 > also not sure what is algorithm description means, I would except a=20 > fixed point source reference if we want to have bit exactness=20 > between multiple implementations. > The deliverables should include quality test results from=20 > independent test labs to enable selection. > I also thought from the above text that we are talking about super=20 > wideband and not wide band codec. > > Thanks > Roni Even > > > _______________________________________________ > 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 ron.even.tlv@gmail.com Fri Jun 19 13:51:22 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 4A6FE3A6AE3 for ; Fri, 19 Jun 2009 13:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.36 X-Spam-Level: X-Spam-Status: No, score=-1.36 tagged_above=-999 required=5 tests=[AWL=-0.620, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, SARE_LWSHORTT=1.24] 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 tonCmvTrP829 for ; Fri, 19 Jun 2009 13:51:21 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id F0A023A68D6 for ; Fri, 19 Jun 2009 13:51:20 -0700 (PDT) Received: by bwz9 with SMTP id 9so2002390bwz.37 for ; Fri, 19 Jun 2009 13:51:31 -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:thread-index:content-language; bh=VqUN8PxtjWJKEY9N7rIqX50uouMiAQekKYJnP9S7txc=; b=dQpsjatPwjBuJZ8yRny5ejlSHKlStE9fOlRk0yetTVQB7/mSjysfiNembxa4zSHWUA 7Gu1t2H777DK01V2AJrFxUQSTFN7mwrIxqG3vIuU/haWpW9Bws3ZSuaUF04O8utNXUEt SuPlGipS1fT/ZefMbmppN9LMGvuBu/Wdyzc+g= 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 :thread-index:content-language; b=dSRW6Tf5mg3aRuuK2wFbHT11WWos1qivuDeqkL4y/H6HGU0NZzFeJVKeVmCy9rJFXi Wnk44Xc/eDoOyh5XcrUth019XDLH4G8Xy0KvrZrFsZ7LEdqLRyEUCrQ/m/G7Tw8SnetE ZYzHd2LdWHrIiX9YdKHfA1toyfS4nQfEv4Pxg= Received: by 10.204.122.74 with SMTP id k10mr2849346bkr.129.1245444690802; Fri, 19 Jun 2009 13:51:30 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-78-100.red.bezeqint.net [79.179.78.100]) by mx.google.com with ESMTPS id g28sm6690051fkg.45.2009.06.19.13.51.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Jun 2009 13:51:30 -0700 (PDT) From: "Roni Even" To: "'Jean-Marc Valin'" References: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com> <4A3BDE42.3090508@octasic.com> <4a3be187.0aec660a.691c.ffffdf99@mx.google.com> <1245443939.4a3bf76372390@www.usherbrooke.ca> In-Reply-To: <1245443939.4a3bf76372390@www.usherbrooke.ca> Date: Fri, 19 Jun 2009 23:50:20 +0300 Message-ID: <4a3bfa52.1c215e0a.09cf.ffffdff7@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnxHfvxnSWGaa57RoqhKJZFnftkAAAAF4ew Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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: Fri, 19 Jun 2009 20:51:22 -0000 Hi, I think you are using more than one email address and this is why the mailing list do not accept all your posting. As for you response, If you do not have any real requirements, and I mean ones that start with the application and gives quality values so how will the IETF decide to approve some offering without knowing that it is better suited than currently available codecs and recommend such a codec. This looks more like rubber stamping some existing codec, I hope this is not what the IETF does. If you want to publish existing codecs ASAP like was done with iLBC, than do informational RFCs and I am not sure why you need a WG for that. Roni Even > -----Original Message----- > From: Jean-Marc Valin [mailto:Jean-Marc.Valin@USherbrooke.ca] > Sent: Friday, June 19, 2009 11:39 PM > To: Roni Even > Cc: 'Jean-Marc Valin'; codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > Hi, > > (again, see my original email in the quote below because the list > didn't accept > it) > > Quoting Roni Even : > > I am also not sure what you mean when you are saying that presenting > codecs > > will prevent what you call kitchen sink/wish list requirements. > > I want to avoid ending up with a list of requirements that looks like: > "high-quality music at 8 kbit/s" or "support bit-rates from 2 to 512 > kbit/s". > It helps to have a reference of what's technologically achievable (even > the ITU > codecs can serve for that), but it's also useful to have a reference of > what we > could have in the relatively short term. For example, one way to > proceed would > be to look at some actual proposals and ask "what more (or less) do we > need > compared to this?". No, this is not exactly the way the ITU works, but > if we > wanted everything to work like it does at the ITU, we wouldn't be > discussing a > new WG. > > Having actual proposals is also a good way to address the "there is no > codec > expertise" argument against forming this new WG. > > Cheers, > > Jean-Marc > > > > -----Original Message----- > > > From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] > > > Sent: Friday, June 19, 2009 9:52 PM > > > To: Ron Even > > > Cc: codec@ietf.org > > > Subject: Re: [codec] Codec BOF approved, much work needed > > > > > > Ron Even wrote: > > > > > > > > Now even if there will be such a WG starting with proposed CODECS > is > > > > like having a solution before the requirements. In other standard > > > > bodies requirements are not just names but they also have values. > So > > > > what is the purpose of proposing codecs, do we need to select at > the > > > > BOF which one will be standardize, to me it looks like this > should be > > > > done later. > > > > > > > > > > I agree that discussing the requirements is very important, I just > > > assumed that is was part of the "Charter Discussion" item. > Regarding > > > codec proposals, I think it's still a good idea to have that as a > way > > > to > > > better focus the discussions. We don't have to choose any or the > > > proposed codecs and if we do, it doesn't have to be in the form > they > > > have been submitted. What this does however is: > > > 1) It gives us a base for discussion to avoid defining kitchen- > > > sink/wish > > > list requirements > > > 2) It shows us some technology we have available right now, so that > we > > > can adapt it rather than starting from scratch > > > > > > Cheers, > > > > > > Jean-Marc > > > > _______________________________________________ > > codec mailing list > > codec@ietf.org > > https://www.ietf.org/mailman/listinfo/codec > > > > > From Borilin@spiritdsp.com Fri Jun 19 13:52:32 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 5F4FE3A6AE3 for ; Fri, 19 Jun 2009 13:52:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.635 X-Spam-Level: X-Spam-Status: No, score=-0.635 tagged_above=-999 required=5 tests=[AWL=-0.486, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45] 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 poRMWOAThIUJ for ; Fri, 19 Jun 2009 13:52:31 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id B97B73A68D6 for ; Fri, 19 Jun 2009 13:52:30 -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 n5JKqgWL011097; Sat, 20 Jun 2009 00:52:42 +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: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable Date: Sat, 20 Jun 2009 00:52:36 +0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec BOF approved, comments on charter Thread-Index: AcnxG08VASL65CpdTc+aixF5tRDl4gAAcq9wAABwh3o= References: <001301c9f0fa$09138588$057da8c0@spiritcorp.com> <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> <20090619131937.60923aczat3opjh5@mail.skype.net> <4a3bf78a.06e2660a.605f.ffffef7c@mx.google.com> From: "Slava Borilin" To: "Roni Even" , "Koen Vos" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: [codec] HA: Codec BOF approved, comments on charter 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: Fri, 19 Jun 2009 20:52:32 -0000 This is not multiparty it will be layering to support the multi rate at different quality. Narrow band lower layer with enhancement layers for = wide band and super wideband like G.729 and G.718 ' it is not necessarily to be multy-layer from the bitstreampoint of view = - it can be multiple encoding runs to cover several parts of spectrum, = but still can be sent out to network as "solid" stream.. scalably really means ability to "strip out" automatically 'extra = layers', which, first of all, make sense in the conferencing enviroment = (as such stripping should be done at the server, after encoding).=20 it is similar to H.264SVC. =20 example - SPIRIT developed scalable voice codec many yeasr ago (it was = done even before G.729.1 was started). so the most benefits are in the conferencing space - comparing = non-scalable codec @MGW handling 400 chalnnels, and with scalable = (=3Dtranscoding free) codec it goes to 8000 channels on the same = hardware. =20 for p2p PLC you do not need scalability much- as most codecs now are = VBR, its ehough already to adapt codec (at the source) to the bandwidth. but without scalability, you can't change the bitrate later (on GW or = conferencing server). =20 Slava Borilin =20 ________________________________ =EF=D4: codec-bounces@ietf.org =CF=D4 =C9=CD=C5=CE=C9 Roni Even =EF=D4=D0=D2=C1=D7=CC=C5=CE=CF: =F3=C2, 20.06.2009 0:38 =EB=CF=CD=D5: 'Koen Vos'; codec@ietf.org =F4=C5=CD=C1: Re: [codec] Codec BOF approved, comments on charter Inline > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Koen Vos > Sent: Friday, June 19, 2009 11:20 PM > To: codec@ietf.org > Subject: Re: [codec] Codec BOF approved, comments on charter > > Quoting Roni Even: > > For the current text I can add multiple other requirements for > example: > > Support for hands free operation (open mic), > > You mean built-in echo cancellation and noise suppression? Or are you > just specifying a test requirement? This are codec requirements. Solution and tests are the next step > > > > speech and music, stereo > > People on this list seem to think > - efficient speech codec at low bitrates > - high quality for music/stereo at higher rates This is a requirement that need numbers not words > > > > multiple languages support, > > Most codec standards are in C. Or are you again talking test specs? Requirements, speech quality not only for English language, that will be reflected in the test requirements > > > > fax, > > Fax has problems with any VoIP codec. Why not stick with T.38? Need to specify the requirement, I can live without > > > > 5+1 > > Not sure how important 5+1 is for real-time communications. Music!!!!! > > > > layered codec > > The use case is limited to certain multi-party calls, but it's a valid > point to discuss. The alternative is transcoding. This is not multiparty it will be layering to support the multi rate at different quality. Narrow band lower layer with enhancement layers for = wide band and super wideband like G.729 and G.718 > > best, > koen. > > > > Quoting Roni Even: > > Hi, > > Inline some comments (sections starting with RE) on the charter. > > > > Purpose: > > > > This new working group would be chartered with the purpose of > collecting > > expertise within the IETF in order to review the design of audio > codecs > > specifically for use with the Internet. > > > > Unlike other SDOs, these codecs would be optimized for use on the > Internet, > > > > RE: I would argue that this statement is not correct and I have not > > seen any data supporting this statement, the fact is that there are > > numerous codecs coming from other SDOs being used on the Internet. I > > would also say that optimize for the Internet is not an application > > description since it is to wide, eventually this will be reflected > > if you start to discuss requirements when you will need to describe > > the applications that will use this codec. > > > > > > and as much as possible choose technology that does not require > > paying patent royalties. > > > > RE: Is this a selection criteria for selecting a codec. > > > > > > The Internet Low Bit Rate Codec (iLBC) work was done in AVT but it > was felt > > that subsequent work should not be done in the AVT working group. > > > > RE: to say done is overstating what was done in AVT comparing to > > other bodies. Furthermore it is not the same to publish a codec done > > by some company as an Informational and specifying requirements and > > selecting one codec from multiple proposal based on quality criteria > > > > This new working group will have as its primary purpose the > > standardization of a > > multi-purpose audio codec that can be used in various situations on > the > > Internet. Some of the proposed Internet-specific requirements > include: > > * scalable and adaptive bit rate; > > * various sampling rate profiles from narrow-band to super-wideband; > > > > RE: Just to clarify do you mean 3.5Khz, 7Khz and 14 Khz? > > > > * scalable complexity; > > * low latency; and > > * resilience to packet loss. > > > > RE: I think that the first stage is to describe the use scenarios > > before giving requirements. For the current text I can add multiple > > other requirements for example: > > Support for hands free operation (open mic), speech and music, > > multiple languages support, fax, stereo, 5+1, layered codec = ......... > > > > > > There are a number of wide-band capable codecs defined by other = SDOs. > For > > instance, G.722 is seeing adoption in Enterprise applications since > it is > > relatively simple and low-cost to deploy. However, it has a high, > fixed > > bitrate and is not appropriate for mobile applications where = spectrum > > efficiency is important or in consumer applications where available > > bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been > adopted > > by the 3GPP as a wideband standard for mobile applications. G.722.2 > is > > relatively high cost due to patent royalties and is seeing minimal > > deployments outside of mobile handsets making it challenging to > create > > wideband experiences on Internet-capable mobile devices when > extending > > beyond the mobile network. In other cases, proprietary codecs are > being > > adopted which further create islands with no interoperability unless > > widespread transcoding is performed. Transcoding leads to higher > costs and > > lower quality. > > > > RE: Basing your discussion on G.722 and G.722.2 is not correct > > (G.722 is 7Khz) the latest codecs technology will be AMR-WB+, MPEG4 > > AAC-LD or scalable, eAAC+, G.729 with the new enhancement layers for > > wide band, G.718. Note that the ITU is working on embedded variable > > bit rates codec technology. > > > > > > The goal of this working group is to define a single codec with > multiple > > profiles which can be made available on a wide variety of Internet- > capable > > devices including low-power, mobile devices as well as devices > capable of > > utilizing high quality, high bitrate audio. > > > > RE: What is multiple profiles is it embedded variable rate (layered > > codec) or is it different modes (like G.722.1 and G.722.1C) using > > the same codec technology. > > > > > > Proposed Deliverables: > > > > 1) Requirements for wideband, Internet audio codec(s). > > 2) Algorithm description for wideband, Internet audio codec(s) as > Proposed > > Standard. > > 3) Specification of payload format(s) for defined codecs as Proposed > > Standard > > > > RE: Other deliverables - testing procedure and metrics. Codec > > selection criteria - which requirements are more important. I am > > also not sure what is algorithm description means, I would except a > > fixed point source reference if we want to have bit exactness > > between multiple implementations. > > The deliverables should include quality test results from > > independent test labs to enable selection. > > I also thought from the above text that we are talking about super > > wideband and not wide band codec. > > > > Thanks > > Roni Even > > > > > > _______________________________________________ > > 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 Jean-Marc.Valin@USherbrooke.ca Fri Jun 19 13:59:55 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 F04173A6BA9 for ; Fri, 19 Jun 2009 13:59:55 -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=[AWL=0.620, 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 yPwkRlNSMcKX for ; Fri, 19 Jun 2009 13:59:55 -0700 (PDT) Received: from smtpi6.usherbrooke.ca (smtpi6.usherbrooke.ca [132.210.236.2]) by core3.amsl.com (Postfix) with ESMTP id 0B9603A68C3 for ; Fri, 19 Jun 2009 13:59:54 -0700 (PDT) Received: from localhost (www05.USherbrooke.ca [132.210.244.140]) by smtpi6.usherbrooke.ca (8.13.8/8.13.8) with ESMTP id n5JL04PL018300; Fri, 19 Jun 2009 17:00:04 -0400 Received: from 70.54.254.106 ([70.54.254.106]) by www.usherbrooke.ca (IMP) with HTTP for ; Fri, 19 Jun 2009 17:00:04 -0400 Message-ID: <1245445204.4a3bfc5434b08@www.usherbrooke.ca> Date: Fri, 19 Jun 2009 17:00:04 -0400 From: Jean-Marc Valin To: Roni Even References: <001301c9f0fa$09138588$057da8c0@spiritcorp.com> <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> In-Reply-To: <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 70.54.254.106 X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-MailScanner-ID: n5JL04PL018300 X-UdeS-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-7.499, requis 5, autolearn=not spam, BAYES_00 -2.60, RDNS_NONE 0.10, UDES_MONBUREAU03 -5.00) X-UdeS-MailScanner-From: jean-marc.valin@usherbrooke.ca Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, comments on charter 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: Fri, 19 Jun 2009 20:59:56 -0000 Hi, My thoughts on the requirements. Quoting Roni Even : > * various sampling rate profiles from narrow-band to super-wideband; > > RE: Just to clarify do you mean 3.5Khz, 7Khz and 14 Khz? Obviously 8 kHz (sampling rate) can be useful for PSTN compatibility. Otherwise, we probably want from 16 kHz, all the way up to 48 kHz or so. > Support for hands free operation (open mic), I assume that by that you mean "robustness to background noise and reverberation". I agree that this is important, although not too hard to achieve once we target higher bit-rates anyway (it's mainly tough on <8 kbit/s codecs). > speech and music Definitely important -- at least for the higher sampling rates and bit-rates. > multiple languages support That's important, although in practice I've never seen a codec that would work on English, but not on German. Obviously, at low bit-rate you want to be careful to preserve the pitch in tonal languages, but I don't think we'll have much problem with languages. > fax T.38 > stereo, 5+1 Stereo is definitely useful. 5.1 is worth supporting, but that would most likely be through multiple independent channels/pairs, so that's probably not that much of an issue. > layered codec ......... That one we can debate, but my initial thought is that I'm not sure it's worth the trouble in this case. I.e. is it worth sacrificing efficiency for the ability to cut bits in the middle of the path (rather than just tell the encoder to reduce its rate). Cheers, Jean-Marc From Jean-Marc.Valin@USherbrooke.ca Fri Jun 19 14:29:08 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 61C933A6BEE for ; Fri, 19 Jun 2009 14:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.669 X-Spam-Level: X-Spam-Status: No, score=-1.669 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 DF004SXg+37u for ; Fri, 19 Jun 2009 14:29:07 -0700 (PDT) Received: from smtpi5.usherbrooke.ca (smtpi5.usherbrooke.ca [132.210.236.1]) by core3.amsl.com (Postfix) with ESMTP id DF3AA3A6C41 for ; Fri, 19 Jun 2009 14:28:55 -0700 (PDT) Received: from localhost (www03.USherbrooke.ca [132.210.244.10]) by smtpi5.usherbrooke.ca (8.13.8/8.13.8) with ESMTP id n5JLT5fG002073; Fri, 19 Jun 2009 17:29:05 -0400 Received: from 70.54.254.106 ([70.54.254.106]) by www.usherbrooke.ca (IMP) with HTTP for ; Fri, 19 Jun 2009 17:29:05 -0400 Message-ID: <1245446945.4a3c032106f5f@www.usherbrooke.ca> Date: Fri, 19 Jun 2009 17:29:05 -0400 From: Jean-Marc Valin To: Roni Even References: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com> <4A3BDE42.3090508@octasic.com> <4a3be187.0aec660a.691c.ffffdf99@mx.google.com> <1245443939.4a3bf76372390@www.usherbrooke.ca> <4a3bfa52.1c215e0a.09cf.ffffdff7@mx.google.com> In-Reply-To: <4a3bfa52.1c215e0a.09cf.ffffdff7@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 70.54.254.106 X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-MailScanner-ID: n5JLT5fG002073 X-UdeS-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-7.499, requis 5, autolearn=not spam, BAYES_00 -2.60, RDNS_NONE 0.10, UDES_MONBUREAU01 -5.00) X-UdeS-MailScanner-From: jean-marc.valin@usherbrooke.ca Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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: Fri, 19 Jun 2009 21:29:08 -0000 Quoting Roni Even : > I think you are using more than one email address and this is why the > mailing list do not accept all your posting. Both addresses are subscribed. It's just an issue with the ietf mail server rejecting email because a recent DNS update hasn't fully propagated. > As for you response, If you do not have any real requirements I am not suggesting that we shouldn't have requirements. > and I mean > ones that start with the application and gives quality values so how will > the IETF decide to approve some offering without knowing that it is better > suited than currently available codecs and recommend such a codec. One of the issues that is fundamental here is that most of the "currently available codecs" are simply not an option for Internet use at the moment. There is a large range of applications that require clients to be downloadable freely (either as open source, or just "free of charge"). Codecs such as G.729.x, AMR-*, and G.718 are simply not an option, no matter what their technical merits are. Just look at a few high-profile software such as Skype, Adobe Flash, Google Talk, X-Lite, and many less known ones. None of these support G.729 or AMR and as far as I know they can't add support without paying royalties every time someone downloads the software. The codecs you'll see being used are G.711, Speex, iLBC... or even GSM-FR. These are the "currently available codecs" for most Internet applications. This is the real reference on which we need to improve (not to say that we can't make something better for Internal apps than the ITU codecs). > This > looks more like rubber stamping some existing codec, I hope this is not what > the IETF does. > If you want to publish existing codecs ASAP like was done with iLBC, than do > informational RFCs and I am not sure why you need a WG for that. I am not suggesting rubber-stamping a codec. I am merely stating that it's easier to start from something that's already available and possibly adapt it to suit our needs. Time isn't everything, but it also counts. It can be weighted in like other requirements: "how much delay is feature X worth?" Cheers, Jean-Marc > Roni Even > > > -----Original Message----- > > From: Jean-Marc Valin [mailto:Jean-Marc.Valin@USherbrooke.ca] > > Sent: Friday, June 19, 2009 11:39 PM > > To: Roni Even > > Cc: 'Jean-Marc Valin'; codec@ietf.org > > Subject: Re: [codec] Codec BOF approved, much work needed > > > > Hi, > > > > (again, see my original email in the quote below because the list > > didn't accept > > it) > > > > Quoting Roni Even : > > > I am also not sure what you mean when you are saying that presenting > > codecs > > > will prevent what you call kitchen sink/wish list requirements. > > > > I want to avoid ending up with a list of requirements that looks like: > > "high-quality music at 8 kbit/s" or "support bit-rates from 2 to 512 > > kbit/s". > > It helps to have a reference of what's technologically achievable (even > > the ITU > > codecs can serve for that), but it's also useful to have a reference of > > what we > > could have in the relatively short term. For example, one way to > > proceed would > > be to look at some actual proposals and ask "what more (or less) do we > > need > > compared to this?". No, this is not exactly the way the ITU works, but > > if we > > wanted everything to work like it does at the ITU, we wouldn't be > > discussing a > > new WG. > > > > Having actual proposals is also a good way to address the "there is no > > codec > > expertise" argument against forming this new WG. > > > > Cheers, > > > > Jean-Marc > > > > > > -----Original Message----- > > > > From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] > > > > Sent: Friday, June 19, 2009 9:52 PM > > > > To: Ron Even > > > > Cc: codec@ietf.org > > > > Subject: Re: [codec] Codec BOF approved, much work needed > > > > > > > > Ron Even wrote: > > > > > > > > > > Now even if there will be such a WG starting with proposed CODECS > > is > > > > > like having a solution before the requirements. In other standard > > > > > bodies requirements are not just names but they also have values. > > So > > > > > what is the purpose of proposing codecs, do we need to select at > > the > > > > > BOF which one will be standardize, to me it looks like this > > should be > > > > > done later. > > > > > > > > > > > > > I agree that discussing the requirements is very important, I just > > > > assumed that is was part of the "Charter Discussion" item. > > Regarding > > > > codec proposals, I think it's still a good idea to have that as a > > way > > > > to > > > > better focus the discussions. We don't have to choose any or the > > > > proposed codecs and if we do, it doesn't have to be in the form > > they > > > > have been submitted. What this does however is: > > > > 1) It gives us a base for discussion to avoid defining kitchen- > > > > sink/wish > > > > list requirements > > > > 2) It shows us some technology we have available right now, so that > > we > > > > can adapt it rather than starting from scratch > > > > > > > > Cheers, > > > > > > > > Jean-Marc > > > > > > _______________________________________________ > > > codec mailing list > > > codec@ietf.org > > > https://www.ietf.org/mailman/listinfo/codec > > > > > > > > > > > > From koen.vos@skype.net Fri Jun 19 17:30:29 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 47B383A6BAA for ; Fri, 19 Jun 2009 17:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.907 X-Spam-Level: X-Spam-Status: No, score=-5.907 tagged_above=-999 required=5 tests=[AWL=0.692, 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 YKKYsHYlxP3U for ; Fri, 19 Jun 2009 17:30:28 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 0E14E3A6BC8 for ; Fri, 19 Jun 2009 17:30:27 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 807572007AB5C for ; Sat, 20 Jun 2009 02:30:40 +0200 (CEST) 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=kEf+VKmMzYos cyC6T9r+zaadW1I=; b=hgDxVQdBa6jPTzpsz+D338oTHh3YhpC9g+EENZI5rdM3 X3jWks7wkx4w1XRhrwDS0ZnRX4a2s6lPH/2e5jrBTl4tUa/v1Tf5jCzhGFwkc5bF NrL2NLIQB5RcZ8E1bS4FZ5pu7w9EowgrGMDQvzTKmNaRhyQ6gc51zY/NzsE5pAE= 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=vgz9BrUQavGUcNT1vDk0 nGtWcgLo5nq8dWDSjK8gjFheRVxiACcw45WuEkbyZ/BgetNz4oiUHeqlU+1APIe7 8r0wyinprgaLnpwpv/nEAcZgGZa75N5a59d0iUp05GyU/2yL1jsgIgJNc4tHD3o5 jsaCEWxpzH11mz+BFSIuehg= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 7EF0E2007AB3F for ; Sat, 20 Jun 2009 02:30:40 +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 on6f-8GF7GlA for ; Sat, 20 Jun 2009 02:30:39 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 3421A2007AB03; Sat, 20 Jun 2009 02:30:27 +0200 (CEST) Received: from adsl-71-141-96-214.dsl.snfc21.pacbell.net (adsl-71-141-96-214.dsl.snfc21.pacbell.net [71.141.96.214]) by mail.skype.net (Horde Framework) with HTTP; Fri, 19 Jun 2009 17:30:27 -0700 Message-ID: <20090619173027.12351gnvi8g8xnkz@mail.skype.net> Date: Fri, 19 Jun 2009 17:30:27 -0700 From: Koen Vos To: codec@ietf.org References: <001301c9f0fa$09138588$057da8c0@spiritcorp.com> <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> <20090619131937.60923aczat3opjh5@mail.skype.net> <4a3bf78a.06e2660a.605f.ffffef7c@mx.google.com> In-Reply-To: <4a3bf78a.06e2660a.605f.ffffef7c@mx.google.com> 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] Codec BOF approved, comments on charter 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, 20 Jun 2009 00:30:29 -0000 Quoting Roni Even: >> Not sure how important 5+1 is for real-time communications. > > Music!!!!! Most music is streamed and has no hard real-time requirements, and codecs like AAC or Vorbis are good choices for this. I'm fine with having my music-on-hold in mere stereo ;) >> > layered codec >> >> The use case is limited to certain multi-party calls, but it's a valid >> point to discuss. The alternative is transcoding. > > This is not multiparty it will be layering to support the multi rate at > different quality. Narrow band lower layer with enhancement layers for wide > band and super wideband like G.729 and G.718 In a one-to-one call, an encoder should not transmit higher-quality layers if these layers are then stripped off in the channel. The codec and (initial) bitrate are negotiated during call setup, and we've already established the requirement of a control mechanism to set the bitrate in case of network congestion. So the encoder will just send whatever the other side wants to, and can, receive. koen. From jean-marc.valin@usherbrooke.ca Fri Jun 19 18:30:16 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 C24923A6BE6 for ; Fri, 19 Jun 2009 18:30:16 -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 3kmU2ny+5Coi for ; Fri, 19 Jun 2009 18:30:14 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id BFBAC3A6B59 for ; Fri, 19 Jun 2009 18:30:14 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1 Received: from idefix.homelinux.org ([70.81.109.112]) by VL-MO-MR002.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KLI00JLBK6RRDF0@VL-MO-MR002.ip.videotron.ca> for codec@ietf.org; Fri, 19 Jun 2009 21:30:27 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by idefix.homelinux.org (Postfix) with ESMTP id 8DC26509840; Fri, 19 Jun 2009 21:30:27 -0400 (EDT) Message-id: <4A3C3BB3.2060807@usherbrooke.ca> Date: Fri, 19 Jun 2009 21:30:27 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) To: Koen Vos References: <001301c9f0fa$09138588$057da8c0@spiritcorp.com> <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> <20090619131937.60923aczat3opjh5@mail.skype.net> <4a3bf78a.06e2660a.605f.ffffef7c@mx.google.com> <20090619173027.12351gnvi8g8xnkz@mail.skype.net> In-reply-to: <20090619173027.12351gnvi8g8xnkz@mail.skype.net> X-Enigmail-Version: 0.95.2 Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, comments on charter 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, 20 Jun 2009 01:30:16 -0000 Koen Vos a écrit : > Quoting Roni Even: >>> Not sure how important 5+1 is for real-time communications. >> >> Music!!!!! > > Most music is streamed and has no hard real-time requirements, and > codecs like AAC or Vorbis are good choices for this. I'm fine with > having my music-on-hold in mere stereo ;) Actually, there *are* music applications with real-time requirements. Some examples are: - Live network music performances (e.g. http://www.soundjack.eu/) - Wi-fi audio equipment (you want sound in sync with your TV) - Network sound servers (e.g. netjack http://www.jackaudio.org/) Also, it turns out that once you when you want really high quality, the speech coding techniques (based on LPC with pitch) tend to saturate and you end up with transform codecs that perform well on music. So at this point, you get music for free. > In a one-to-one call, an encoder should not transmit higher-quality > layers if these layers are then stripped off in the channel. > > The codec and (initial) bitrate are negotiated during call setup, and > we've already established the requirement of a control mechanism to set > the bitrate in case of network congestion. So the encoder will just send > whatever the other side wants to, and can, receive. I totally agree here. Jean-Marc From rjesup@wgate.com Fri Jun 19 19:35:54 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 B07C03A68E2 for ; Fri, 19 Jun 2009 19:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.646 X-Spam-Level: X-Spam-Status: No, score=-1.646 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.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 Ka4wH+iB9M46 for ; Fri, 19 Jun 2009 19:35:53 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id B8BD43A67DD for ; Fri, 19 Jun 2009 19:35:53 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 22:36:07 -0400 To: Jean-Marc Valin References: <001301c9f0fa$09138588$057da8c0@spiritcorp.com> <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> <20090619131937.60923aczat3opjh5@mail.skype.net> <4a3bf78a.06e2660a.605f.ffffef7c@mx.google.com> <20090619173027.12351gnvi8g8xnkz@mail.skype.net> <4A3C3BB3.2060807@usherbrooke.ca> From: Randell Jesup Date: Fri, 19 Jun 2009 22:36:04 -0400 In-Reply-To: <4A3C3BB3.2060807@usherbrooke.ca> (Jean-Marc Valin's message of "Fri\, 19 Jun 2009 21\:30\:27 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 20 Jun 2009 02:36:07.0010 (UTC) FILETIME=[DD0D0C20:01C9F14F] Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, comments on charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup 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, 20 Jun 2009 02:35:54 -0000 Jean-Marc Valin writes: >> Most music is streamed and has no hard real-time requirements, and >> codecs like AAC or Vorbis are good choices for this. I'm fine with >> having my music-on-hold in mere stereo ;) > >Actually, there *are* music applications with real-time requirements. >Some examples are: >- Live network music performances (e.g. http://www.soundjack.eu/) >- Wi-fi audio equipment (you want sound in sync with your TV) >- Network sound servers (e.g. netjack http://www.jackaudio.org/) Two of those do NOT have hard-real-time requirements. WiFi audio may not be hard-real-time either, though the example you give might be the only hard-real-time case here, since it has to try to sync to an external device. This is not "internet" audio though, it's LAN audio. Might be addressable or happen to be covered, but I wouldn't make this a primary goal. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From jean-marc.valin@usherbrooke.ca Fri Jun 19 20:18: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 75F793A6C2C for ; Fri, 19 Jun 2009 20:18:24 -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 REftw+qgq5Ip for ; Fri, 19 Jun 2009 20:18:23 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id A6F6828C12F for ; Fri, 19 Jun 2009 20:18:23 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1 Received: from idefix.homelinux.org ([70.81.109.112]) by VL-MO-MR004.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KLI00KOOP719U30@VL-MO-MR004.ip.videotron.ca> for codec@ietf.org; Fri, 19 Jun 2009 23:18:37 -0400 (EDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by idefix.homelinux.org (Postfix) with ESMTP id EDA5D509840; Fri, 19 Jun 2009 23:18:36 -0400 (EDT) Message-id: <4A3C550C.80903@usherbrooke.ca> Date: Fri, 19 Jun 2009 23:18:36 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) To: Randell Jesup References: <001301c9f0fa$09138588$057da8c0@spiritcorp.com> <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> <20090619131937.60923aczat3opjh5@mail.skype.net> <4a3bf78a.06e2660a.605f.ffffef7c@mx.google.com> <20090619173027.12351gnvi8g8xnkz@mail.skype.net> <4A3C3BB3.2060807@usherbrooke.ca> In-reply-to: X-Enigmail-Version: 0.95.2 Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, comments on charter 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, 20 Jun 2009 03:18:24 -0000 Randell Jesup a écrit : > Jean-Marc Valin writes: >>> Most music is streamed and has no hard real-time requirements, and >>> codecs like AAC or Vorbis are good choices for this. I'm fine with >>> having my music-on-hold in mere stereo ;) >> Actually, there *are* music applications with real-time requirements. >> Some examples are: >> - Live network music performances (e.g. http://www.soundjack.eu/) >> - Wi-fi audio equipment (you want sound in sync with your TV) >> - Network sound servers (e.g. netjack http://www.jackaudio.org/) > > Two of those do NOT have hard-real-time requirements. Then I think you misunderstood what I wrote: - Live network music performances: I'm in Montreal playing guitar and you're in New York singing. We can synchronise each other as long as the one-way delay is less than about 25 ms. If you remove the network delay, that leaves only a few ms delay for the codec. But it *is* possible (and it's been done with CELT already). - Network sound servers: The idea is to log on to a remote machine and run multimedia applications. For this to work well, the sound has to arrive with as little delay as possible, otherwise there is a perceived lag. Cheers, Jean-Marc From ron.even.tlv@gmail.com Fri Jun 19 22:41:25 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 9A0603A6920 for ; Fri, 19 Jun 2009 22:41:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.257 X-Spam-Level: X-Spam-Status: No, score=-1.257 tagged_above=-999 required=5 tests=[AWL=-0.517, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, SARE_LWSHORTT=1.24] 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 Xz8MHVyamSMx for ; Fri, 19 Jun 2009 22:41:24 -0700 (PDT) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.154]) by core3.amsl.com (Postfix) with ESMTP id 18F6E3A683A for ; Fri, 19 Jun 2009 22:41:23 -0700 (PDT) Received: by fg-out-1718.google.com with SMTP id d23so197460fga.18 for ; Fri, 19 Jun 2009 22:41:35 -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:thread-index:content-language; bh=YBQJlpG9RVD3zUGKLpc/i+PYUORnKoBj17742Hjxi2c=; b=GAlqrEi7obgdTXnD5P0m/hEBDPNxLKcVxpHvczL0t1C6yY7MaLSZFoWhDUod6BUVUH wjIVIM2GtUBuuZj0BjYZ+y9xtOVA/TJ20eKhLTgYsmuIPKMDS2JjUWulmkQ+RYaNl2tc uBWVv5TsAbbbZZABgRyD4b+ldVmdluO3R/bD8= 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 :thread-index:content-language; b=wq9v1N6ccAY4jgzgqyNtO8RxZJsYo+ByGBNWQQ7UqWEXB/WXYdpy/lOVWZEGIhsnJM pUZNiBkmXWwxbEHj7LTo5aZkPvVcUZ7bhXQ7PN9bHTlYZUbi5TZlKgUVNmu51uv29ayE 76xP9WznAy1iNpu9Rgbk98SPqz0tNCL8j13LU= Received: by 10.86.36.11 with SMTP id j11mr3906094fgj.56.1245476495000; Fri, 19 Jun 2009 22:41:35 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-78-100.red.bezeqint.net [79.179.78.100]) by mx.google.com with ESMTPS id 12sm1221821fgg.10.2009.06.19.22.41.33 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Jun 2009 22:41:34 -0700 (PDT) From: "Roni Even" To: "'Jean-Marc Valin'" References: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com> <4A3BDE42.3090508@octasic.com> <4a3be187.0aec660a.691c.ffffdf99@mx.google.com> <1245443939.4a3bf76372390@www.usherbrooke.ca> <4a3bfa52.1c215e0a.09cf.ffffdff7@mx.google.com> <1245446945.4a3c032106f5f@www.usherbrooke.ca> In-Reply-To: <1245446945.4a3c032106f5f@www.usherbrooke.ca> Date: Sat, 20 Jun 2009 08:40:23 +0300 Message-ID: <4a3c768e.0c07560a.062b.ffffe257@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnxJPsPK3LT0DKNROug/Keh6ArniAAQ9kDw Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 20 Jun 2009 05:41:25 -0000 Jean-Marc, I think this will cause a discussion , you are saying "Just look at a few high-profile software such as Skype, Adobe Flash, Google Talk, X-Lite," As far as I understand these high-profile software clients are using proprietary signaling so they can continue to use proprietary codecs. Why should the IETF help solutions that are not interoperable, and do not show any interest with supporting free interoperability by publishing their specifications with royalty free licenses. Roni Even > -----Original Message----- > From: Jean-Marc Valin [mailto:Jean-Marc.Valin@USherbrooke.ca] > Sent: Saturday, June 20, 2009 12:29 AM > To: Roni Even > Cc: 'Jean-Marc Valin'; codec@ietf.org > Subject: RE: [codec] Codec BOF approved, much work needed > > Quoting Roni Even : > > I think you are using more than one email address and this is why the > > mailing list do not accept all your posting. > > Both addresses are subscribed. It's just an issue with the ietf mail > server > rejecting email because a recent DNS update hasn't fully propagated. > > > As for you response, If you do not have any real requirements > > I am not suggesting that we shouldn't have requirements. > > > and I mean > > ones that start with the application and gives quality values so how > will > > the IETF decide to approve some offering without knowing that it is > better > > suited than currently available codecs and recommend such a codec. > > One of the issues that is fundamental here is that most of the > "currently > available codecs" are simply not an option for Internet use at the > moment. > There is a large range of applications that require clients to be > downloadable > freely (either as open source, or just "free of charge"). Codecs such > as > G.729.x, AMR-*, and G.718 are simply not an option, no matter what > their > technical merits are. Just look at a few high-profile software such as > Skype, > Adobe Flash, Google Talk, X-Lite, and many less known ones. None of > these > support G.729 or AMR and as far as I know they can't add support > without paying > royalties every time someone downloads the software. The codecs you'll > see > being used are G.711, Speex, iLBC... or even GSM-FR. These are the > "currently > available codecs" for most Internet applications. This is the real > reference on > which we need to improve (not to say that we can't make something > better for > Internal apps than the ITU codecs). > > > This > > looks more like rubber stamping some existing codec, I hope this is > not what > > the IETF does. > > If you want to publish existing codecs ASAP like was done with iLBC, > than do > > informational RFCs and I am not sure why you need a WG for that. > > I am not suggesting rubber-stamping a codec. I am merely stating that > it's > easier to start from something that's already available and possibly > adapt it > to suit our needs. Time isn't everything, but it also counts. It can be > weighted in like other requirements: "how much delay is feature X > worth?" > > Cheers, > > Jean-Marc > > > > Roni Even > > > > > -----Original Message----- > > > From: Jean-Marc Valin [mailto:Jean-Marc.Valin@USherbrooke.ca] > > > Sent: Friday, June 19, 2009 11:39 PM > > > To: Roni Even > > > Cc: 'Jean-Marc Valin'; codec@ietf.org > > > Subject: Re: [codec] Codec BOF approved, much work needed > > > > > > Hi, > > > > > > (again, see my original email in the quote below because the list > > > didn't accept > > > it) > > > > > > Quoting Roni Even : > > > > I am also not sure what you mean when you are saying that > presenting > > > codecs > > > > will prevent what you call kitchen sink/wish list requirements. > > > > > > I want to avoid ending up with a list of requirements that looks > like: > > > "high-quality music at 8 kbit/s" or "support bit-rates from 2 to > 512 > > > kbit/s". > > > It helps to have a reference of what's technologically achievable > (even > > > the ITU > > > codecs can serve for that), but it's also useful to have a > reference of > > > what we > > > could have in the relatively short term. For example, one way to > > > proceed would > > > be to look at some actual proposals and ask "what more (or less) do > we > > > need > > > compared to this?". No, this is not exactly the way the ITU works, > but > > > if we > > > wanted everything to work like it does at the ITU, we wouldn't be > > > discussing a > > > new WG. > > > > > > Having actual proposals is also a good way to address the "there is > no > > > codec > > > expertise" argument against forming this new WG. > > > > > > Cheers, > > > > > > Jean-Marc > > > > > > > > -----Original Message----- > > > > > From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] > > > > > Sent: Friday, June 19, 2009 9:52 PM > > > > > To: Ron Even > > > > > Cc: codec@ietf.org > > > > > Subject: Re: [codec] Codec BOF approved, much work needed > > > > > > > > > > Ron Even wrote: > > > > > > > > > > > > Now even if there will be such a WG starting with proposed > CODECS > > > is > > > > > > like having a solution before the requirements. In other > standard > > > > > > bodies requirements are not just names but they also have > values. > > > So > > > > > > what is the purpose of proposing codecs, do we need to select > at > > > the > > > > > > BOF which one will be standardize, to me it looks like this > > > should be > > > > > > done later. > > > > > > > > > > > > > > > > I agree that discussing the requirements is very important, I > just > > > > > assumed that is was part of the "Charter Discussion" item. > > > Regarding > > > > > codec proposals, I think it's still a good idea to have that as > a > > > way > > > > > to > > > > > better focus the discussions. We don't have to choose any or > the > > > > > proposed codecs and if we do, it doesn't have to be in the form > > > they > > > > > have been submitted. What this does however is: > > > > > 1) It gives us a base for discussion to avoid defining kitchen- > > > > > sink/wish > > > > > list requirements > > > > > 2) It shows us some technology we have available right now, so > that > > > we > > > > > can adapt it rather than starting from scratch > > > > > > > > > > Cheers, > > > > > > > > > > Jean-Marc > > > > > > > > _______________________________________________ > > > > codec mailing list > > > > codec@ietf.org > > > > https://www.ietf.org/mailman/listinfo/codec > > > > > > > > > > > > > > > > > > > > From rjesup@wgate.com Fri Jun 19 23:37: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 CF0173A67A4 for ; Fri, 19 Jun 2009 23:37:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.659 X-Spam-Level: X-Spam-Status: No, score=-1.659 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.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 Z1b2oY08npwv for ; Fri, 19 Jun 2009 23:37:05 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 09FE73A63EC for ; Fri, 19 Jun 2009 23:37:04 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 20 Jun 2009 02:37:18 -0400 To: "Roni Even" References: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com> <4A3BDE42.3090508@octasic.com> <4a3be187.0aec660a.691c.ffffdf99@mx.google.com> <1245443939.4a3bf76372390@www.usherbrooke.ca> <4a3bfa52.1c215e0a.09cf.ffffdff7@mx.google.com> <1245446945.4a3c032106f5f@www.usherbrooke.ca> <4a3c768e.0c07560a.062b.ffffe257@mx.google.com> From: Randell Jesup Date: Sat, 20 Jun 2009 02:37:17 -0400 In-Reply-To: <4a3c768e.0c07560a.062b.ffffe257@mx.google.com> (Roni Even's message of "Sat\, 20 Jun 2009 08\:40\:23 +0300") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 20 Jun 2009 06:37:18.0463 (UTC) FILETIME=[8EB588F0:01C9F171] Cc: codec@ietf.org, 'Jean-Marc Valin' Subject: Re: [codec] Codec BOF approved, much work needed X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup 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, 20 Jun 2009 06:37:05 -0000 "Roni Even" writes: >I think this will cause a discussion , you are saying >"Just look at a few high-profile software such as Skype, Adobe Flash, Google >Talk, X-Lite," > >As far as I understand these high-profile software clients are using >proprietary signaling so they can continue to use proprietary codecs. >Why should the IETF help solutions that are not interoperable, and do not >show any interest with supporting free interoperability by publishing their >specifications with royalty free licenses. X-lite is a standards-based SIP softclient. Skype *says* they're going to open up their new "Silk" codec; however the available info in scant, and there's something in what little is available that tends to imply they'll only provide you with a (Windows) binary library, though they don't say so outright. I filled out the form months ago for access; not even an acknowledgement. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From rjesup@wgate.com Fri Jun 19 23:43:01 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 491DD3A67A4 for ; Fri, 19 Jun 2009 23:43:01 -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.066, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.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 jMk7K5uiD6jw for ; Fri, 19 Jun 2009 23:43:00 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 4823A3A63EC for ; Fri, 19 Jun 2009 23:43:00 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 20 Jun 2009 02:43:11 -0400 To: Jean-Marc Valin References: <001301c9f0fa$09138588$057da8c0@spiritcorp.com> <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> <20090619131937.60923aczat3opjh5@mail.skype.net> <4a3bf78a.06e2660a.605f.ffffef7c@mx.google.com> <20090619173027.12351gnvi8g8xnkz@mail.skype.net> <4A3C3BB3.2060807@usherbrooke.ca> <4A3C550C.80903@usherbrooke.ca> From: Randell Jesup Date: Sat, 20 Jun 2009 02:43:10 -0400 In-Reply-To: <4A3C550C.80903@usherbrooke.ca> (Jean-Marc Valin's message of "Fri\, 19 Jun 2009 23\:18\:36 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 20 Jun 2009 06:43:11.0088 (UTC) FILETIME=[60E3D700:01C9F172] Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, comments on charter X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup 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, 20 Jun 2009 06:43:01 -0000 Jean-Marc Valin writes: >>> Actually, there *are* music applications with real-time requirements. >>> Some examples are: >>> - Live network music performances (e.g. http://www.soundjack.eu/) >>> - Wi-fi audio equipment (you want sound in sync with your TV) >>> - Network sound servers (e.g. netjack http://www.jackaudio.org/) >> >> Two of those do NOT have hard-real-time requirements. > >Then I think you misunderstood what I wrote: > >- Live network music performances: I'm in Montreal playing guitar and >you're in New York singing. We can synchronise each other as long as the >one-way delay is less than about 25 ms. If you remove the network delay, >that leaves only a few ms delay for the codec. But it *is* possible (and >it's been done with CELT already). > >- Network sound servers: The idea is to log on to a remote machine and >run multimedia applications. For this to work well, the sound has to >arrive with as little delay as possible, otherwise there is a perceived lag. You're correct, I mis-understood. I thought you meant "broadcast" of live performances, and a stored audio streaming server. Perhaps "live musical collaberation", and "Remote PC access with multimedia". That last one, though, isn't as delay-sensitive (though it should be low delay) - the issue is more one of audio-video sync. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From jean-marc.valin@usherbrooke.ca Sat Jun 20 06:29:17 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 A527F3A6B44 for ; Sat, 20 Jun 2009 06:29:17 -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=[AWL=-0.620, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 R9VFWCXkQdEh for ; Sat, 20 Jun 2009 06:29:16 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 7B43B3A6B65 for ; Sat, 20 Jun 2009 06:29:16 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.10] ([70.81.109.112]) by VL-MH-MR001.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KLJ00FHRHH5MY70@VL-MH-MR001.ip.videotron.ca> for codec@ietf.org; Sat, 20 Jun 2009 09:29:30 -0400 (EDT) Message-id: <4A3CE439.9000508@usherbrooke.ca> Date: Sat, 20 Jun 2009 09:29:29 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) To: Roni Even References: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com> <4A3BDE42.3090508@octasic.com> <4a3be187.0aec660a.691c.ffffdf99@mx.google.com> <1245443939.4a3bf76372390@www.usherbrooke.ca> <4a3bfa52.1c215e0a.09cf.ffffdff7@mx.google.com> <1245446945.4a3c032106f5f@www.usherbrooke.ca> <4a3c768e.0c07560a.062b.ffffe257@mx.google.com> In-reply-to: <4a3c768e.0c07560a.062b.ffffe257@mx.google.com> X-Enigmail-Version: 0.95.2 Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 20 Jun 2009 13:29:17 -0000 Hi, Roni Even a écrit : > I think this will cause a discussion , you are saying > "Just look at a few high-profile software such as Skype, Adobe Flash, Google > Talk, X-Lite," > > As far as I understand these high-profile software clients are using > proprietary signaling so they can continue to use proprietary codecs. > Why should the IETF help solutions that are not interoperable, and do not > show any interest with supporting free interoperability by publishing their > specifications with royalty free licenses. As far as I know, X-Lite uses SIP, while Google talk supports SIP and XMPP. I'm not sure about Flash, but as far as I know you can use it Speex API to do pretty much what you want (including a SIP phone). As far as I know, Skype is the only app not to use open signalling protocols. I still included it because the fact that it has a proprietary protocol is pretty much orthogonal to the argument I am making: for most Internet applications (open, proprietary), the standard ITU codecs are simply not an option at all. If even these (presumably deep pocket) high profile companies cannot use G.729 or AMR-* in their clients, I don't see how smaller companies and open source projects would be able to. Jean-Marc > Roni Even > >> -----Original Message----- >> From: Jean-Marc Valin [mailto:Jean-Marc.Valin@USherbrooke.ca] >> Sent: Saturday, June 20, 2009 12:29 AM >> To: Roni Even >> Cc: 'Jean-Marc Valin'; codec@ietf.org >> Subject: RE: [codec] Codec BOF approved, much work needed >> >> Quoting Roni Even : >>> I think you are using more than one email address and this is why the >>> mailing list do not accept all your posting. >> Both addresses are subscribed. It's just an issue with the ietf mail >> server >> rejecting email because a recent DNS update hasn't fully propagated. >> >>> As for you response, If you do not have any real requirements >> I am not suggesting that we shouldn't have requirements. >> >>> and I mean >>> ones that start with the application and gives quality values so how >> will >>> the IETF decide to approve some offering without knowing that it is >> better >>> suited than currently available codecs and recommend such a codec. >> One of the issues that is fundamental here is that most of the >> "currently >> available codecs" are simply not an option for Internet use at the >> moment. >> There is a large range of applications that require clients to be >> downloadable >> freely (either as open source, or just "free of charge"). Codecs such >> as >> G.729.x, AMR-*, and G.718 are simply not an option, no matter what >> their >> technical merits are. Just look at a few high-profile software such as >> Skype, >> Adobe Flash, Google Talk, X-Lite, and many less known ones. None of >> these >> support G.729 or AMR and as far as I know they can't add support >> without paying >> royalties every time someone downloads the software. The codecs you'll >> see >> being used are G.711, Speex, iLBC... or even GSM-FR. These are the >> "currently >> available codecs" for most Internet applications. This is the real >> reference on >> which we need to improve (not to say that we can't make something >> better for >> Internal apps than the ITU codecs). >> >>> This >>> looks more like rubber stamping some existing codec, I hope this is >> not what >>> the IETF does. >>> If you want to publish existing codecs ASAP like was done with iLBC, >> than do >>> informational RFCs and I am not sure why you need a WG for that. >> I am not suggesting rubber-stamping a codec. I am merely stating that >> it's >> easier to start from something that's already available and possibly >> adapt it >> to suit our needs. Time isn't everything, but it also counts. It can be >> weighted in like other requirements: "how much delay is feature X >> worth?" >> >> Cheers, >> >> Jean-Marc >> >> >>> Roni Even >>> >>>> -----Original Message----- >>>> From: Jean-Marc Valin [mailto:Jean-Marc.Valin@USherbrooke.ca] >>>> Sent: Friday, June 19, 2009 11:39 PM >>>> To: Roni Even >>>> Cc: 'Jean-Marc Valin'; codec@ietf.org >>>> Subject: Re: [codec] Codec BOF approved, much work needed >>>> >>>> Hi, >>>> >>>> (again, see my original email in the quote below because the list >>>> didn't accept >>>> it) >>>> >>>> Quoting Roni Even : >>>>> I am also not sure what you mean when you are saying that >> presenting >>>> codecs >>>>> will prevent what you call kitchen sink/wish list requirements. >>>> I want to avoid ending up with a list of requirements that looks >> like: >>>> "high-quality music at 8 kbit/s" or "support bit-rates from 2 to >> 512 >>>> kbit/s". >>>> It helps to have a reference of what's technologically achievable >> (even >>>> the ITU >>>> codecs can serve for that), but it's also useful to have a >> reference of >>>> what we >>>> could have in the relatively short term. For example, one way to >>>> proceed would >>>> be to look at some actual proposals and ask "what more (or less) do >> we >>>> need >>>> compared to this?". No, this is not exactly the way the ITU works, >> but >>>> if we >>>> wanted everything to work like it does at the ITU, we wouldn't be >>>> discussing a >>>> new WG. >>>> >>>> Having actual proposals is also a good way to address the "there is >> no >>>> codec >>>> expertise" argument against forming this new WG. >>>> >>>> Cheers, >>>> >>>> Jean-Marc >>>> >>>>>> -----Original Message----- >>>>>> From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] >>>>>> Sent: Friday, June 19, 2009 9:52 PM >>>>>> To: Ron Even >>>>>> Cc: codec@ietf.org >>>>>> Subject: Re: [codec] Codec BOF approved, much work needed >>>>>> >>>>>> Ron Even wrote: >>>>>>> Now even if there will be such a WG starting with proposed >> CODECS >>>> is >>>>>>> like having a solution before the requirements. In other >> standard >>>>>>> bodies requirements are not just names but they also have >> values. >>>> So >>>>>>> what is the purpose of proposing codecs, do we need to select >> at >>>> the >>>>>>> BOF which one will be standardize, to me it looks like this >>>> should be >>>>>>> done later. >>>>>>> >>>>>> I agree that discussing the requirements is very important, I >> just >>>>>> assumed that is was part of the "Charter Discussion" item. >>>> Regarding >>>>>> codec proposals, I think it's still a good idea to have that as >> a >>>> way >>>>>> to >>>>>> better focus the discussions. We don't have to choose any or >> the >>>>>> proposed codecs and if we do, it doesn't have to be in the form >>>> they >>>>>> have been submitted. What this does however is: >>>>>> 1) It gives us a base for discussion to avoid defining kitchen- >>>>>> sink/wish >>>>>> list requirements >>>>>> 2) It shows us some technology we have available right now, so >> that >>>> we >>>>>> can adapt it rather than starting from scratch >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Jean-Marc >>>>> _______________________________________________ >>>>> codec mailing list >>>>> codec@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/codec >>>>> >>>>> >>> >>> >>> > > > > From ron.even.tlv@gmail.com Sat Jun 20 07:14:13 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 AF6643A69A4 for ; Sat, 20 Jun 2009 07:14:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.183 X-Spam-Level: X-Spam-Status: No, score=-1.183 tagged_above=-999 required=5 tests=[AWL=-0.443, BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, SARE_LWSHORTT=1.24] 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 O7Ald+khVjmK for ; Sat, 20 Jun 2009 07:14:12 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id D70BF3A696D for ; Sat, 20 Jun 2009 07:14:11 -0700 (PDT) Received: by bwz9 with SMTP id 9so2259067bwz.37 for ; Sat, 20 Jun 2009 07:14:23 -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:thread-index:content-language; bh=CRZWvsMFAFrB6JcWuq+e9O1IzLpFbiiVoSbXkg9XcFY=; b=oYDaCjBA7kew+WmAuu3JFdR0A4bOfQXGA+5p0Ab/un5UaqH+bnOr4T431Y8KAtxdV+ Q6gAzWEsF8pPiw7hBjT04LLJOSGJhdFV/4CAQXAN8t/JWaFvNoNypPSKrjLruSzW552d FUz/mXu7RDYAMGEC4fGst2eM/ev2IXp/oemWs= 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 :thread-index:content-language; b=hnczP55qXIlskqI/HaxkzjXM+Ta+ceX7BzcpUZ5Ioa6SRO8ZaiFKKVcmZRQ61r3wi9 dp/qcan0VMFSOeocF/5K0qEJABCiMLXLaxLvvxF6842WophgQ/PB26AF1iujFNOYxg4Z 4ahcw3K4vGbCRQHy08QznFLxXwDkCP4x8jKkQ= Received: by 10.204.112.205 with SMTP id x13mr3791695bkp.213.1245507263435; Sat, 20 Jun 2009 07:14:23 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-78-100.red.bezeqint.net [79.179.78.100]) by mx.google.com with ESMTPS id 19sm8054830fkr.55.2009.06.20.07.14.22 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Jun 2009 07:14:23 -0700 (PDT) From: "Roni Even" To: "'Jean-Marc Valin'" References: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com> <4A3BDE42.3090508@octasic.com> <4a3be187.0aec660a.691c.ffffdf99@mx.google.com> <1245443939.4a3bf76372390@www.usherbrooke.ca> <4a3bfa52.1c215e0a.09cf.ffffdff7@mx.google.com> <1245446945.4a3c032106f5f@www.usherbrooke.ca> <4a3c768e.0c07560a.062b.ffffe257@mx.google.com> <4A3CE439.9000508@usherbrooke.ca> In-Reply-To: <4A3CE439.9000508@usherbrooke.ca> Date: Sat, 20 Jun 2009 17:13:13 +0300 Message-ID: <4a3ceebf.13125e0a.6b81.ffff96b6@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 Thread-Index: AcnxqyRzwVTLZ+KqRwqtj8fv2kDaOwABRQ/Q Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 20 Jun 2009 14:14:13 -0000 Jean-Marc, I think you are missing the point. A reason for a standard codec like = for standard signaling is to achieve interoperability between products = coming from different implementation giving the customer a choice. If the = products you list do not interoperate and do not try to address open = interoperability why do you need a standard codec. Get any free license codec available = and use it in those products, each can use a different one if they do not interoperate on the signaling part. Making one of them a standard does = not buy the industry any value in this case. Roni=20 > -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@usherbrooke.ca] > Sent: Saturday, June 20, 2009 4:29 PM > To: Roni Even > Cc: 'Jean-Marc Valin'; codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed >=20 > Hi, >=20 > Roni Even a =E9crit : > > I think this will cause a discussion , you are saying > > "Just look at a few high-profile software such as Skype, Adobe = Flash, > Google > > Talk, X-Lite," > > > > As far as I understand these high-profile software clients are using > > proprietary signaling so they can continue to use proprietary = codecs. > > Why should the IETF help solutions that are not interoperable, and = do > not > > show any interest with supporting free interoperability by = publishing > their > > specifications with royalty free licenses. >=20 > As far as I know, X-Lite uses SIP, while Google talk supports SIP and > XMPP. I'm not sure about Flash, but as far as I know you can use it > Speex API to do pretty much what you want (including a SIP phone). As > far as I know, Skype is the only app not to use open signalling > protocols. I still included it because the fact that it has a > proprietary protocol is pretty much orthogonal to the argument I am > making: for most Internet applications (open, proprietary), the > standard > ITU codecs are simply not an option at all. If even these (presumably > deep pocket) high profile companies cannot use G.729 or AMR-* in their > clients, I don't see how smaller companies and open source projects > would be able to. >=20 > Jean-Marc >=20 > > Roni Even > > > >> -----Original Message----- > >> From: Jean-Marc Valin [mailto:Jean-Marc.Valin@USherbrooke.ca] > >> Sent: Saturday, June 20, 2009 12:29 AM > >> To: Roni Even > >> Cc: 'Jean-Marc Valin'; codec@ietf.org > >> Subject: RE: [codec] Codec BOF approved, much work needed > >> > >> Quoting Roni Even : > >>> I think you are using more than one email address and this is why > the > >>> mailing list do not accept all your posting. > >> Both addresses are subscribed. It's just an issue with the ietf = mail > >> server > >> rejecting email because a recent DNS update hasn't fully = propagated. > >> > >>> As for you response, If you do not have any real requirements > >> I am not suggesting that we shouldn't have requirements. > >> > >>> and I mean > >>> ones that start with the application and gives quality values so > how > >> will > >>> the IETF decide to approve some offering without knowing that it = is > >> better > >>> suited than currently available codecs and recommend such a codec. > >> One of the issues that is fundamental here is that most of the > >> "currently > >> available codecs" are simply not an option for Internet use at the > >> moment. > >> There is a large range of applications that require clients to be > >> downloadable > >> freely (either as open source, or just "free of charge"). Codecs > such > >> as > >> G.729.x, AMR-*, and G.718 are simply not an option, no matter what > >> their > >> technical merits are. Just look at a few high-profile software such > as > >> Skype, > >> Adobe Flash, Google Talk, X-Lite, and many less known ones. None of > >> these > >> support G.729 or AMR and as far as I know they can't add support > >> without paying > >> royalties every time someone downloads the software. The codecs > you'll > >> see > >> being used are G.711, Speex, iLBC... or even GSM-FR. These are the > >> "currently > >> available codecs" for most Internet applications. This is the real > >> reference on > >> which we need to improve (not to say that we can't make something > >> better for > >> Internal apps than the ITU codecs). > >> > >>> This > >>> looks more like rubber stamping some existing codec, I hope this = is > >> not what > >>> the IETF does. > >>> If you want to publish existing codecs ASAP like was done with > iLBC, > >> than do > >>> informational RFCs and I am not sure why you need a WG for that. > >> I am not suggesting rubber-stamping a codec. I am merely stating > that > >> it's > >> easier to start from something that's already available and = possibly > >> adapt it > >> to suit our needs. Time isn't everything, but it also counts. It = can > be > >> weighted in like other requirements: "how much delay is feature X > >> worth?" > >> > >> Cheers, > >> > >> Jean-Marc > >> > >> > >>> Roni Even > >>> > >>>> -----Original Message----- > >>>> From: Jean-Marc Valin [mailto:Jean-Marc.Valin@USherbrooke.ca] > >>>> Sent: Friday, June 19, 2009 11:39 PM > >>>> To: Roni Even > >>>> Cc: 'Jean-Marc Valin'; codec@ietf.org > >>>> Subject: Re: [codec] Codec BOF approved, much work needed > >>>> > >>>> Hi, > >>>> > >>>> (again, see my original email in the quote below because the list > >>>> didn't accept > >>>> it) > >>>> > >>>> Quoting Roni Even : > >>>>> I am also not sure what you mean when you are saying that > >> presenting > >>>> codecs > >>>>> will prevent what you call kitchen sink/wish list requirements. > >>>> I want to avoid ending up with a list of requirements that looks > >> like: > >>>> "high-quality music at 8 kbit/s" or "support bit-rates from 2 to > >> 512 > >>>> kbit/s". > >>>> It helps to have a reference of what's technologically achievable > >> (even > >>>> the ITU > >>>> codecs can serve for that), but it's also useful to have a > >> reference of > >>>> what we > >>>> could have in the relatively short term. For example, one way to > >>>> proceed would > >>>> be to look at some actual proposals and ask "what more (or less) > do > >> we > >>>> need > >>>> compared to this?". No, this is not exactly the way the ITU = works, > >> but > >>>> if we > >>>> wanted everything to work like it does at the ITU, we wouldn't be > >>>> discussing a > >>>> new WG. > >>>> > >>>> Having actual proposals is also a good way to address the "there > is > >> no > >>>> codec > >>>> expertise" argument against forming this new WG. > >>>> > >>>> Cheers, > >>>> > >>>> Jean-Marc > >>>> > >>>>>> -----Original Message----- > >>>>>> From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com] > >>>>>> Sent: Friday, June 19, 2009 9:52 PM > >>>>>> To: Ron Even > >>>>>> Cc: codec@ietf.org > >>>>>> Subject: Re: [codec] Codec BOF approved, much work needed > >>>>>> > >>>>>> Ron Even wrote: > >>>>>>> Now even if there will be such a WG starting with proposed > >> CODECS > >>>> is > >>>>>>> like having a solution before the requirements. In other > >> standard > >>>>>>> bodies requirements are not just names but they also have > >> values. > >>>> So > >>>>>>> what is the purpose of proposing codecs, do we need to select > >> at > >>>> the > >>>>>>> BOF which one will be standardize, to me it looks like this > >>>> should be > >>>>>>> done later. > >>>>>>> > >>>>>> I agree that discussing the requirements is very important, I > >> just > >>>>>> assumed that is was part of the "Charter Discussion" item. > >>>> Regarding > >>>>>> codec proposals, I think it's still a good idea to have that as > >> a > >>>> way > >>>>>> to > >>>>>> better focus the discussions. We don't have to choose any or > >> the > >>>>>> proposed codecs and if we do, it doesn't have to be in the form > >>>> they > >>>>>> have been submitted. What this does however is: > >>>>>> 1) It gives us a base for discussion to avoid defining kitchen- > >>>>>> sink/wish > >>>>>> list requirements > >>>>>> 2) It shows us some technology we have available right now, so > >> that > >>>> we > >>>>>> can adapt it rather than starting from scratch > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> Jean-Marc > >>>>> _______________________________________________ > >>>>> codec mailing list > >>>>> codec@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/codec > >>>>> > >>>>> > >>> > >>> > >>> > > > > > > > > From xiphmont@gmail.com Sat Jun 20 08:30:40 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 3239D3A696A for ; Sat, 20 Jun 2009 08:30:40 -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.107, 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 ooqfy9dbltQX for ; Sat, 20 Jun 2009 08:30:39 -0700 (PDT) Received: from mail-yx0-f183.google.com (mail-yx0-f183.google.com [209.85.210.183]) by core3.amsl.com (Postfix) with ESMTP id 5D08D3A6821 for ; Sat, 20 Jun 2009 08:30:39 -0700 (PDT) Received: by yxe13 with SMTP id 13so68844yxe.32 for ; Sat, 20 Jun 2009 08:30:51 -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 :content-transfer-encoding; bh=IdOaFKOnB+ihybGTlCX1o4LHv6YxHdhvs8crFmIIkTg=; b=Q6phOexsBHBu8OW+JJ43M/qun+SGW2aJ+vrAVAgEA/ZCXA9C8+eWQitl8iVRzQO3+/ riuuW8SYL963Ekt+akOvkbVh3Wy+ClEbIohHwopd2ofZhJ2KrwRIRes5H3pCYV/xgO7l iyMhH2LFYJWcn5/35dAoIdevQDyx9lWUHYrgQ= 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:content-transfer-encoding; b=uI0QgukT2lbh++Nk7dJW2/AMEp7sjPJ21IjulZyOK8UPC4/i+G9fP0c5LRF1UMgY3n pgwkDciKDSh8jQP5HXFe8oyW6mtgRJ2MTY8B4hu1T84qVinrE+npzMdRSplItX08GVCY IV8HCQaX3Ih2G/CfXStbiapW0Dsy5xatkLiXA= MIME-Version: 1.0 Received: by 10.231.11.1 with SMTP id r1mr1336069ibr.23.1245511851095; Sat, 20 Jun 2009 08:30:51 -0700 (PDT) In-Reply-To: <4a3ceebf.13125e0a.6b81.ffff96b6@mx.google.com> References: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com> <4A3BDE42.3090508@octasic.com> <4a3be187.0aec660a.691c.ffffdf99@mx.google.com> <1245443939.4a3bf76372390@www.usherbrooke.ca> <4a3bfa52.1c215e0a.09cf.ffffdff7@mx.google.com> <1245446945.4a3c032106f5f@www.usherbrooke.ca> <4a3c768e.0c07560a.062b.ffffe257@mx.google.com> <4A3CE439.9000508@usherbrooke.ca> <4a3ceebf.13125e0a.6b81.ffff96b6@mx.google.com> Date: Sat, 20 Jun 2009 11:30:51 -0400 Message-ID: <806dafc20906200830x45e03ae8ie5077b12f9610c3c@mail.gmail.com> From: Christopher Montgomery To: Roni Even Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org, Jean-Marc Valin Subject: Re: [codec] Codec BOF approved, much work needed 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, 20 Jun 2009 15:30:40 -0000 On Sat, Jun 20, 2009 at 10:13 AM, Roni Even wrote: > Jean-Marc, > I think you are missing the point. A reason for a standard codec like for > standard signaling is to achieve interoperability between products coming > from different implementation giving the customer a choice. That is a relevant point. > If the products > you list do not interoperate and do not try to address open interoperability > why do you need a standard codec. This seems like an argument to be discussing this all within AVT--- which you also oppose. As far as I can tell, your position can be boiled down to "I don't want the IETF to be involved in royalty-free codecs or open transport in any way." Your position is noted. Others disagree; to me it seems like a wholesale abdication of interest in what will soon be the supermajority of all traffic on the internet (if it is not already). That would be everybody's loss. [Hello from the Open Video Conference, BTW! :-] > Making one of them a standard does not > buy the industry any value in this case. It is important to point out that our responsibility is to more than immediate business interests ('the industry'). Of course, the long view benefits industry as well. Monty From xiphmont@gmail.com Sat Jun 20 08:51:39 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 80A7A3A6949 for ; Sat, 20 Jun 2009 08:51:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.163 X-Spam-Level: X-Spam-Status: No, score=-2.163 tagged_above=-999 required=5 tests=[AWL=-0.264, BAYES_00=-2.599, SARE_BIZOP=0.7] 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 7Vv05m1SI5ZN for ; Sat, 20 Jun 2009 08:51:38 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.251]) by core3.amsl.com (Postfix) with ESMTP id 6E8503A68A5 for ; Sat, 20 Jun 2009 08:51:38 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c3so981281ana.4 for ; Sat, 20 Jun 2009 08:51:50 -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 :content-transfer-encoding; bh=QQb0ATj9hf3Cm271WQk5vtHTASbrVZALxZUVCyu3/nU=; b=uKiLc+HG+5NLr5WY0365kjQ8pVK8btyx0vXKgyUwbVNra83Sp/JnbmZjXddBKAzusm OJUqyLe69GPzFcVoGmxgHc+r0+5KFkVlUtciPX1K41n7EMlWKCtoYar3GR3mLwuJ/+Yn XYJW6gVRZlbBcq/y3E/vt+QCwFfiRNrXlkiec= 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:content-transfer-encoding; b=Qe73N5pCVOFoOePWW3/UvZtPSs9LXz3i6kBYcVWQHvhnfwezS3AyjV04tEUVSjt9Qk zrthdiIVpVdt1TZpm1yo0MnlLL/6HwMPewRJr7LqmxVyMQhqd/ZbAvdS8SSDgryr2CLz Doz037Zj9ijMv5tPXJnp/WbyMGePkAit4Pc84= MIME-Version: 1.0 Received: by 10.231.15.7 with SMTP id i7mr1286444iba.43.1245513110202; Sat, 20 Jun 2009 08:51:50 -0700 (PDT) In-Reply-To: <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> References: <001301c9f0fa$09138588$057da8c0@spiritcorp.com> <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> Date: Sat, 20 Jun 2009 11:51:50 -0400 Message-ID: <806dafc20906200851r6a1fa78dx59da39abcd40b694@mail.gmail.com> From: Christopher Montgomery To: Roni Even Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, comments on charter 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, 20 Jun 2009 15:51:39 -0000 > Unlike other SDOs, these codecs would be optimized for use on the Internet, > > RE: I would argue that this statement is not correct and I have not seen any data supporting this statement OK, 'unlike _many_ SDOs'. We are interested in switched-packet networks and variable transmission rates, not fixed-bandwidth broadcast channels. Perhaps it should be stated in the positive (what we are) instead of the negative (unlike what we are not). But let's not bikeshed this too thoroughly. > The fact is that there are numerous codecs coming from other SDOs being used on the Internet. Because they are well suited, or because they're what was available at the moment someone saw an immediate short-term business opportunity? We need to think past ad-hoc deployment. > I would also say that optimize for the Internet is not an application description since it is to wide "Variable-bandwidth and switched-packet networks" and "non-linear / interactive use" might be a better starting point. 'Optimized for the internet' is not itself meaningless, merely imprecise. > and as much as possible choose technology that does not require paying patent royalties. > > RE: Is this a selection criteria for selecting a codec. yes. YES. Please get us away from nickel-and-dime IPR attached to every bit transmitted on the Internet. The physical transport itself costs enough. Please end the need to regularly re-up permissions from multiple licensing bodies to use even 'free' (as in beer) codecs before being allowed to ship a single line of code. This 'permission to breathe' model prevents entire swaths of possible applications and tries to milk 'value' out of something that, at the beginning, has none. Codecs are not rocket science. They are well understood. The math and engineering are both commodities. I'm tired of smothering every baby in the cradle with royalties as a way of offsetting the costs of infant formula. There will never be a single clear winner in any codec space that mandates licensing costs or 'permission' to use. The only reason mp3 ever got as far as it was was the incorrect perception for many years that MPEG was not enforcing patent claims. > RE: Just to clarify do you mean 3.5Khz, 7Khz and 14 Khz? No, I think that is overly fixating on voice-only. Even voice codecs don't limit to 14kHz today. > RE: Basing your discussion on G.722 and G.722.2 is not correct (G.722 is 7Khz) the latest codecs technology > will be AMR-WB+, MPEG4 AAC-LD or scalable, eAAC+, G.729 with the new enhancement layers for wide band, > G.718. Note that the ITU is working on embedded variable bit rates codec technology. I realize you're responding to a slightly different point, but it's worth reiterating: Anything that requires a license, even a free license, or patent royalties is a non-starter, full-stop. If a ten year old student programmer in Indonesia has to read a legal document or consult a lawyer to figure out if he's allowed to use a codec, then it's failed the first and most important test. We need not even bring these codecs up or list them. > RE: What is multiple profiles is it embedded variable rate (layered codec) or is it different modes > (like G.722.1 and G.722.1C) using the same codec technology. Either. Both. Whichever works. Both fit the current usage of the word. We have a next generation of codec technology just now gelling, just now at the stage of benefitting greatly from the eyes and minds of experience. > Proposed Deliverables: > > 1) Requirements for wideband, Internet audio codec(s). > 2) Algorithm description for wideband, Internet audio codec(s) as Proposed > Standard. > 3) Specification of payload format(s) for defined codecs as Proposed > Standard > > RE: Other deliverables - testing procedure and metrics Tournament development with extensive listening tests. May the best ideas win. > Codec selection criteria - which requirements are more important. > I am also not sure what is algorithm description means Plain english* description of spec. Like a text that explains how a mathemetician arrived at a proof. Monty (* turn of phrase, not literally mandating English) From ron.even.tlv@gmail.com Sat Jun 20 08:54:48 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 F1C1A3A693F for ; Sat, 20 Jun 2009 08:54:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.748 X-Spam-Level: X-Spam-Status: No, score=-1.748 tagged_above=-999 required=5 tests=[AWL=0.233, 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 6XiD7+ZPSA-Q for ; Sat, 20 Jun 2009 08:54:47 -0700 (PDT) Received: from mail-fx0-f214.google.com (mail-fx0-f214.google.com [209.85.220.214]) by core3.amsl.com (Postfix) with ESMTP id CF4963A68A5 for ; Sat, 20 Jun 2009 08:54:46 -0700 (PDT) Received: by fxm10 with SMTP id 10so195257fxm.37 for ; Sat, 20 Jun 2009 08:54:57 -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:thread-index:content-language; bh=YbkMudk8y+MbzZEtaE4vliBvE2KFdgdMsF1M+Ql8ejU=; b=Od/mWFdtPbxaKshVvSgCMAYg0UXLJftJxuBw8UHlfjjfLJZTyfaDLtKRvqsemLtGHs S0+8qh9jiXuvtxBVKcS389/OKz81B4treys1RjVGpt0xWQ3hhkGEbhmqPL69BIvwQ0dc vy4DbhnMVISxZkvPBuxM4Pv9A/3OJoFjpioig= 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 :thread-index:content-language; b=it0m/7B3duY4pmgI0WqEQFjswGmamg4OVZ8kSzZvFJR0AvB8ZWwUFO+WTznIvbOldk U6WJUUIaAoo6Jizk/Kv8aJ0POuGVEkXULFN85eOJ5dHl5VgboVA8Lxx/fQ3eSmvmrm9d 3DFmncVVHNfPmFmVq8Ipoi1Kmjn3xiQmGAqec= Received: by 10.86.98.7 with SMTP id v7mr4379180fgb.58.1245513297825; Sat, 20 Jun 2009 08:54:57 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-78-100.red.bezeqint.net [79.179.78.100]) by mx.google.com with ESMTPS id d6sm2415052fga.14.2009.06.20.08.54.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Jun 2009 08:54:56 -0700 (PDT) From: "Roni Even" To: "'Christopher Montgomery'" References: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com> <4A3BDE42.3090508@octasic.com> <4a3be187.0aec660a.691c.ffffdf99@mx.google.com> <1245443939.4a3bf76372390@www.usherbrooke.ca> <4a3bfa52.1c215e0a.09cf.ffffdff7@mx.google.com> <1245446945.4a3c032106f5f@www.usherbrooke.ca> <4a3c768e.0c07560a.062b.ffffe257@mx.google.com> <4A3CE439.9000508@usherbrooke.ca> <4a3ceebf.13125e0a.6b81.ffff96b6@mx.google.com> <806dafc20906200830x45e03ae8ie5077b12f9610c3c@mail.gmail.com> In-Reply-To: <806dafc20906200830x45e03ae8ie5077b12f9610c3c@mail.gmail.com> Date: Sat, 20 Jun 2009 18:53:35 +0300 Message-ID: <4a3d0650.0637560a.2413.6788@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcnxvBerZXVfv6XIRP2xREAOEdEndgAAeL7Q Content-Language: en-us Cc: codec@ietf.org, 'Jean-Marc Valin' Subject: Re: [codec] Codec BOF approved, much work needed 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, 20 Jun 2009 15:54:48 -0000 Monty, I am not sure why you are saying that my position is " I don't want the IETF to be involved in royalty-free codecs or open transport in any way". This is not what I anm saying What I am saying is that people coming to the IETF asking for royalty free and open transport should support it with their technology before asking others to provide it for their use. Roni Even > -----Original Message----- > From: Christopher Montgomery [mailto:xiphmont@gmail.com] > Sent: Saturday, June 20, 2009 6:31 PM > To: Roni Even > Cc: Jean-Marc Valin; codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > On Sat, Jun 20, 2009 at 10:13 AM, Roni Even > wrote: > > Jean-Marc, > > I think you are missing the point. A reason for a standard codec like > for > > standard signaling is to achieve interoperability between products > coming > > from different implementation giving the customer a choice. > > That is a relevant point. > > > If the products > > you list do not interoperate and do not try to address open > interoperability > > why do you need a standard codec. > > This seems like an argument to be discussing this all within AVT--- > which you also oppose. > > As far as I can tell, your position can be boiled down to "I don't > want the IETF to be involved in royalty-free codecs or open transport > in any way." Your position is noted. Others disagree; to me it seems > like a wholesale abdication of interest in what will soon be the > supermajority of all traffic on the internet (if it is not already). > That would be everybody's loss. > > [Hello from the Open Video Conference, BTW! :-] > > > Making one of them a standard does not > > buy the industry any value in this case. > > It is important to point out that our responsibility is to more than > immediate business interests ('the industry'). Of course, the long > view benefits industry as well. > > Monty From hsinnrei@adobe.com Sat Jun 20 09:17: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 6019C3A6BC5 for ; Sat, 20 Jun 2009 09:17:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.807 X-Spam-Level: X-Spam-Status: No, score=-5.807 tagged_above=-999 required=5 tests=[AWL=0.791, BAYES_00=-2.599, 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 sAfEZwHnW1bE for ; Sat, 20 Jun 2009 09:17:34 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by core3.amsl.com (Postfix) with ESMTP id B01623A6D34 for ; Sat, 20 Jun 2009 09:17:32 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKSj0LqpiDXLcvVlrYZRSDge/BFhloTTsF@postini.com; Sat, 20 Jun 2009 09:17:48 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5KGBWao008133; Sat, 20 Jun 2009 09:11:32 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5KGHjiq005213; Sat, 20 Jun 2009 09:17:45 -0700 (PDT) Received: from excas02.corp.adobe.com (10.8.188.212) by nahub02.corp.adobe.com (10.8.189.98) with Microsoft SMTP Server (TLS) id 8.1.340.0; Sat, 20 Jun 2009 09:17:45 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas02.corp.adobe.com ([10.8.188.212]) with mapi; Sat, 20 Jun 2009 09:17:44 -0700 From: Henry Sinnreich To: Ron Even , "codec@ietf.org" Date: Sat, 20 Jun 2009 09:17:42 -0700 Thread-Topic: Agenda: Avoiding the waterfall/requirements pitfall Thread-Index: Acnw9uZf333YnsO5SEOpg0JsCmEhnAAy7zKF Message-ID: In-Reply-To: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.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_C66275D643F1hsinnreiadobecom_" MIME-Version: 1.0 Subject: [codec] Agenda: Avoiding the waterfall/requirements pitfall 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, 20 Jun 2009 16:17:41 -0000 --_000_C66275D643F1hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable (subject changed) Roni, >In other standard bodies requirements are not just names but they also hav= e values. This may be a reason why the Darwinian Web is taking over :-) "... details only become known to us as we progress in the [system's] imple= mentation. Some of the things that we learn invalidate our design and we must backtrac= k." See for example http://en.wikipedia.org/wiki/Waterfall_model#Criticism Avoiding the waterfall model is the main reason to explore existing codec p= roposals and new design options. Requirements documents are useful as part of a continuing trial and error p= rocess, but are very damaging when dictated from the beginning. Henry On 6/19/09 10:59 AM, "Ron Even" wrote: Cullen, I looked at the agenda 1. Administrative (Chairs, 5 min) - Note takers, Jabber scribes - Agenda bashing 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) 3. Proposed CODECs (TBD, 25 min) - Expect to have two or more drafts here 4. Charter Discussion (All, 40 min) 5. Decisions and HUMs (All, 5 min) 6. Conclusions and Next Steps (Chairs/ADs, 5 min) And it looks to me that it starts with assumption that we will have a new w= orking group. I am not sure that that this was agreed and yet I see no time allocated to = discuss the topic. I would expect that item 3 will be rational for doing co= dec at the IETF considering that this work is done also by other SDOs that = the IETF is working with. Now even if there will be such a WG starting with proposed CODECS is like h= aving a solution before the requirements. In other standard bodies requirem= ents are not just names but they also have values. So what is the purpose o= f proposing codecs, do we need to select at the BOF which one will be stand= ardize, to me it looks like this should be done later. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Cullen Jennings > Sent: Friday, June 12, 2009 8:32 PM > To: codec@ietf.org > Subject: [codec] Codec BOF approved, much work needed > > > I have approved the CODEC BOF proposal. However, we need a bunch of > work to get ready. Various people on IESG/IAB were not comfortable > with the current charter and agenda so we need to work on theses > before the meeting. > > A draft agenda/charter Jason provided are at > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- > bof/charter.txt > > After discussion with the IESG/IAB: > > I'd like to remove the "as Proposed Standard" from the charter text > for both milestones and see how the discussion goes in the BOF before > deciding which way this should go. > > I'd like to see more consideration around the issues of designing a > codec that did a good job of mapping a real time stream onto IP > packets. The way IP deals with packet loss and congestion has > implications for designing a codec that works well over IP. I know > some of the discussion I have had off list people talked about how we > wanted a codec that supported adaptive bit rates that could change on > the fly to be able to work well on an IP network. > > I will be working the folks to make sure the agenda has time to > directly address the key topics which include (more may be coming): > > Will we be able to get qualified people to do and review the work? > > Key design goals of a new codec? > > Do we need a new codec or are there already ones defined that meet the > needs? > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. > > Thanks, > > Cullen > > > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --_000_C66275D643F1hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Agenda: Avoiding the waterfall/requirements pitfall (su= bject changed)

Roni,

>In other standard bodies requirements are not just names but they also = have values.

This may be a reason why the Darwinian Web is taking over :-)

“... details only become known to us as we progress in the [system's]= implementation.
Some of the things that we learn invalidate our design and we must backtrac= k.”
See for example http://en.wikipedia.org/wiki/Waterfall_model#Criticism

Avoiding the waterfall model is the main reason to explore existing codec p= roposals and new design options.

Requirements documents are useful as part of a continuing trial and error p= rocess, but are very damaging when dictated from the beginning.

Henry


On 6/19/09 10:59 AM, "Ron Even" <ron.even.tlv@gmail.com> wrote:

Cullen,
I looked at the agenda
=A0
1. Administrative (Chairs, 5 min)
=A0 - Note takers, Jabber scribes
=A0 - Agenda bashing
=A0
2. Introduction and Scoping of BOF (Chairs/ADs, 15 min)
=A0
3. Proposed CODECs (TBD, 25 min)
=A0 - Expect to have two or mo= re drafts here
=A0
4. Charter Discussion (All, 40 min)
=A0
5. Decisions and HUMs (All, 5 min)
=A0
6. Conclusions and Next Steps (Chairs/ADs, 5 min)=A0
=A0
=A0
And it looks to me that it starts with assumption that we will have a new w= orking group.
=A0
I am not sure that that this was agreed and yet I see no time allocated to = discuss the topic. I would expect that item 3 will be rational for doing co= dec at the IETF considering that this work is done also by other SDOs that = the IETF is working with.
=A0
Now even if there will be such a WG starting with proposed CODECS is like h= aving a solution before the requirements. In other standard bodies requirem= ents are not just names but they also have values. So what is the purpose o= f proposing codecs, do we need to select at the BOF which one will be stand= ardize, to me it looks like this should be done later.
=A0
Roni Even=A0
=A0
=A0
=A0
=A0
> -----Original Message-----
> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf
> Of Cullen Jenni= ngs
> Sent: Friday, June 12, 2009 8:32 PM
> To: codec@ietf.org
> Subject: [codec] Codec BOF approved, much work needed
>
>
> I have approved the CODEC BOF proposal. However, we need a bunch of > work to get ready.=A0 Var= ious people on IESG/IAB were not comfortable
> with the curren= t charter and agenda so we need to work on theses
> before the meeting.
>
> A draft agenda/charter Jason provided are at
>
> Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.t= xt
>
> Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-
> bof/charter.txt
>
> After discussion with the IESG/IAB:
>
> I'd like to remove the "as Proposed Standard" from the chart= er text
> for both milestones and see how the discussion goes in the BOF before<= BR> > deciding which way this should go.
>
> I'd like to see more consideration around the issues of designing a > codec that did a good job of mapping a real time stream onto IP
> packets. The way IP deals with packet loss and congestion has
> implications for designing a codec that works well over IP. I know
> some of the discussion I have had off list people talked about how we<= BR> > wanted a codec that supported adaptive bit rates that could change on<= BR> > the fly to be able to work well on an IP network.
>
> I will be working the folks to make sure the agenda has time to
> directly address the key topics which include (more may be coming): >
> Will we be able to get qualified people to do and review the work?
>
> Key design goals of a new codec?
>
> Do we need a new codec or are there already ones defined that meet the=
> needs?
>
> I have asked Jason Fischl=A0 and Jean-Marc Valin to co-chair this BOF.
>
> Thanks,
>
> Cullen <RAI AD>
>
>
>
>
>
> _______________________________________________
> codec mailing list
> codec@ietf.org
> https://www.ie= tf.org/mailman/listinfo/codec

--_000_C66275D643F1hsinnreiadobecom_-- From hsinnrei@adobe.com Sat Jun 20 09:18: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 32F913A6D38 for ; Sat, 20 Jun 2009 09:18:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.856 X-Spam-Level: X-Spam-Status: No, score=-5.856 tagged_above=-999 required=5 tests=[AWL=0.742, BAYES_00=-2.599, 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 FNF87EdLstAJ for ; Sat, 20 Jun 2009 09:18:15 -0700 (PDT) Received: from psmtp.com (exprod6ob109.obsmtp.com [64.18.1.22]) by core3.amsl.com (Postfix) with ESMTP id 068313A6BC5 for ; Sat, 20 Jun 2009 09:18:14 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKSj0L015dJR0t8oFo3PaXEc0y2r698+My@postini.com; Sat, 20 Jun 2009 09:18:29 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5KGIOWG022505; Sat, 20 Jun 2009 09:18:25 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5KGIOiq005296; Sat, 20 Jun 2009 09:18:24 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Sat, 20 Jun 2009 09:18:23 -0700 From: Henry Sinnreich To: Roni Even , "codec@ietf.org" Date: Sat, 20 Jun 2009 09:18:21 -0700 Thread-Topic: Royalty free is top motivation Thread-Index: Acnw+gkTHL2SdLtVTDiF20h8Qld27QADaHaAAC7D3rE= Message-ID: In-Reply-To: <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.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_C66275FD43F1hsinnreiadobecom_" MIME-Version: 1.0 Subject: [codec] Royalty free is top motivation 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, 20 Jun 2009 16:18:24 -0000 --_000_C66275FD43F1hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Roni, (Topic changed for focus) Roni, Just to make it clear, royalty free was one of the top motivations and shou= ld probably be the main requirement for the Internet codec. Interoperability with existing codecs is nice, but IMHO a secondary order r= equirement, given that most interactive communications are already on the I= nternet and will be so even more in the future. Vendors and operators are a= lways free to include some other codecs and let SIP do the codec negotiatio= n - that's what it is for in SIP. Henry On 6/19/09 1:41 PM, "Roni Even" wrote: Hi, Inline some comments (sections starting with RE) on the charter. Purpose: This new working group would be chartered with the purpose of collecting expertise within the IETF in order to review the design of audio codecs specifically for use with the Internet. Unlike other SDOs, these codecs would be optimized for use on the Internet, RE: I would argue that this statement is not correct and I have not seen an= y data supporting this statement, the fact is that there are numerous codec= s coming from other SDOs being used on the Internet. I would also say that = optimize for the Internet is not an application description since it is to = wide, eventually this will be reflected if you start to discuss requirement= s when you will need to describe the applications that will use this codec. and as much as possible choose technology that does not require paying pate= nt royalties. RE: Is this a selection criteria for selecting a codec. The Internet Low Bit Rate Codec (iLBC) work was done in AVT but it was fel= t that subsequent work should not be done in the AVT working group. RE: to say done is overstating what was done in AVT comparing to other bodi= es. Furthermore it is not the same to publish a codec done by some company = as an Informational and specifying requirements and selecting one codec fro= m multiple proposal based on quality criteria This new working group will have as its primary purpose the standardization= of a multi-purpose audio codec that can be used in various situations on the Internet. Some of the proposed Internet-specific requirements include: * scalable and adaptive bit rate; * various sampling rate profiles from narrow-band to super-wideband; RE: Just to clarify do you mean 3.5Khz, 7Khz and 14 Khz? * scalable complexity; * low latency; and * resilience to packet loss. RE: I think that the first stage is to describe the use scenarios before gi= ving requirements. For the current text I can add multiple other requiremen= ts for example: Support for hands free operation (open mic), speech and music, multiple lan= guages support, fax, stereo, 5+1, layered codec ......... There are a number of wide-band capable codecs defined by other SDOs. For instance, G.722 is seeing adoption in Enterprise applications since it is relatively simple and low-cost to deploy. However, it has a high, fixed bitrate and is not appropriate for mobile applications where spectrum efficiency is important or in consumer applications where available bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been adopte= d by the 3GPP as a wideband standard for mobile applications. G.722.2 is relatively high cost due to patent royalties and is seeing minimal deployments outside of mobile handsets making it challenging to create wideband experiences on Internet-capable mobile devices when extending beyond the mobile network. In other cases, proprietary codecs are being adopted which further create islands with no interoperability unless widespread transcoding is performed. Transcoding leads to higher costs and lower quality. RE: Basing your discussion on G.722 and G.722.2 is not correct (G.722 is 7K= hz) the latest codecs technology will be AMR-WB+, MPEG4 AAC-LD or scalable,= eAAC+, G.729 with the new enhancement layers for wide band, G.718. Note th= at the ITU is working on embedded variable bit rates codec technology. The goal of this working group is to define a single codec with multiple profiles which can be made available on a wide variety of Internet-capable devices including low-power, mobile devices as well as devices capable of utilizing high quality, high bitrate audio. RE: What is multiple profiles is it embedded variable rate (layered codec) = or is it different modes (like G.722.1 and G.722.1C) using the same codec t= echnology. Proposed Deliverables: 1) Requirements for wideband, Internet audio codec(s). 2) Algorithm description for wideband, Internet audio codec(s) as Proposed Standard. 3) Specification of payload format(s) for defined codecs as Proposed Standard RE: Other deliverables - testing procedure and metrics. Codec selection cri= teria - which requirements are more important. I am also not sure what is a= lgorithm description means, I would except a fixed point source reference i= f we want to have bit exactness between multiple implementations. The deliverables should include quality test results from independent test = labs to enable selection. I also thought from the above text that we are talking about super wideband= and not wide band codec. Thanks Roni Even _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C66275FD43F1hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Royalty free is top motivation Roni,
(Topic changed for focus)

Roni,

Just to make it clear, royalty free was one of the top motivations and shou= ld probably be the main requirement for the Internet codec.

Interoperability with existing codecs is nice, but IMHO a secondary order r= equirement, given that most interactive communications are already on the I= nternet and will be so even more in the future. Vendors and operators are a= lways free to include some other codecs and let SIP do the codec negotiatio= n – that’s what it is for in SIP.

Henry

On 6/19/09 1:41 PM, "Roni Even" <ron.even.tlv@gmail.com> wrote:

Hi,
Inline some comments (sections starting with RE) on the charter.

Purpose:

This new working group would be chartered with the purpose of collecting expertise within the IETF in order to review the design of audio codecs
specifically for use with the Internet.

Unlike other SDOs, these codecs would be optimized for use on the Internet,=

RE: I would argue that this statement is not correct and I have not seen an= y data supporting this statement, the fact is that there are numerous codec= s coming from other SDOs being used on the Internet. I would also say that = optimize for the Internet is not an application description since it is to = wide, eventually this will be reflected if you start to discuss requirement= s when you will need to describe the applications that will use this codec.=


and as much as possible choose technology that does not require paying pate= nt royalties.

RE: Is this a selection criteria for selecting a codec.


The Internet Low Bit Rate Codec (iLBC)  work was done in AVT but it wa= s felt
that subsequent work should not be done in the AVT working group.

RE: to say done is overstating what was done in AVT comparing to other bodi= es. Furthermore it is not the same to publish a codec done by some company = as an Informational and specifying requirements and selecting one codec fro= m multiple proposal based on quality criteria

This new working group will have as its primary purpose the standardization= of a
multi-purpose audio codec that can be used in various situations on the
Internet. Some of the proposed Internet-specific requirements include:
* scalable and adaptive bit rate;
* various sampling rate profiles from narrow-band to super-wideband;

RE: Just to clarify do you mean 3.5Khz, 7Khz and 14 Khz?

* scalable complexity;
* low latency; and
* resilience to packet loss.

RE: I think that the first stage is to describe the use scenarios before gi= ving requirements. For the current text I can add multiple other requiremen= ts for example:
Support for hands free operation (open mic), speech and music, multiple lan= guages support, fax, stereo, 5+1, layered codec .........


There are a number of wide-band capable codecs defined by other SDOs. For instance, G.722 is seeing adoption in Enterprise applications since it is relatively simple and low-cost to deploy. However, it has a high, fixed
bitrate and is not appropriate for mobile applications where spectrum
efficiency is important or in consumer applications where available
bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been adopte= d
by the 3GPP as a wideband standard for mobile applications. G.722.2 is
relatively high cost due to patent royalties and is seeing minimal
deployments outside of mobile handsets making it challenging to create
wideband experiences on Internet-capable mobile devices when extending
beyond the mobile network. In other cases, proprietary codecs are being
adopted which further create islands with no interoperability unless
widespread transcoding is performed. Transcoding leads to higher costs and<= BR> lower quality.

RE: Basing your discussion on G.722 and G.722.2 is not correct (G.722 is 7K= hz) the latest codecs technology will be AMR-WB+, MPEG4 AAC-LD or scalable,= eAAC+, G.729 with the new enhancement layers for wide band, G.718. Note th= at the ITU is working on embedded variable bit rates codec technology.


The goal of this working group is to define a single codec with multiple profiles which can be made available on a wide variety of Internet-capable<= BR> devices including low-power, mobile devices as well as devices capable of utilizing high quality, high bitrate audio.

RE: What is multiple profiles is it embedded variable rate (layered codec) = or is it different modes (like G.722.1 and G.722.1C) using the same codec t= echnology.


Proposed Deliverables:

1) Requirements for wideband, Internet audio codec(s).
2) Algorithm description for wideband, Internet audio codec(s) as Proposed<= BR> Standard.
3) Specification of payload format(s) for defined codecs as Proposed
Standard

RE: Other deliverables - testing procedure and metrics. Codec selection cri= teria - which requirements are more important. I am also not sure what is a= lgorithm description means, I would except a fixed point source reference i= f we want to have bit exactness between multiple implementations.
The deliverables should include quality test results from independent test = labs to enable selection.
I also thought from the above text that we are talking about super wideband= and not wide band codec.

Thanks
Roni Even


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

--_000_C66275FD43F1hsinnreiadobecom_-- From ron.even.tlv@gmail.com Sat Jun 20 09:48: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 8D60D3A6905 for ; Sat, 20 Jun 2009 09:48:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.545 X-Spam-Level: X-Spam-Status: No, score=-0.545 tagged_above=-999 required=5 tests=[AWL=-1.021, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 lBN8I2ocYvIp for ; Sat, 20 Jun 2009 09:47:56 -0700 (PDT) Received: from mail-fx0-f214.google.com (mail-fx0-f214.google.com [209.85.220.214]) by core3.amsl.com (Postfix) with ESMTP id 48C413A6D36 for ; Sat, 20 Jun 2009 09:47:55 -0700 (PDT) Received: by fxm10 with SMTP id 10so211574fxm.37 for ; Sat, 20 Jun 2009 09:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :x-mailer:thread-index:content-language; bh=GBWMnIueDGIs5NwcJ0GNuivaMEVLu1Avdd1upn7DQVs=; b=VTrhlm6rvUvICRwBzOd2+HF4+kaMMrdc4ofrsjuG9DulC9U61FaJYWodFTKXUXxLTg 71EuBBlDmlAZp3CHV/KawxIdjK8QgLSA7nsptibyVNENzpmfW6qNv+8DZWdh7XO8FvXQ qYd9WHUjQQuqNm63O/BBD+qlRnn21jOiXaAGI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; b=tIDD6ANHqrr7JO+FVGoguj4qhmGIMeaQ6eUaei3Qti9jPz0HzizcEYqve1ZixagxkJ tE01slM5z+mdlJRBgbqdEee5QhcP9ylp0tH1VaUAt/f/QgapUz/GeMwNjC/LwvS3eDdn qTtfSNm30aqObJ9PF+cH50emjvZ8qQvy+3xho= Received: by 10.204.77.78 with SMTP id f14mr3947512bkk.76.1245516486517; Sat, 20 Jun 2009 09:48:06 -0700 (PDT) Received: from windows8d787f9 (bzq-79-179-78-100.red.bezeqint.net [79.179.78.100]) by mx.google.com with ESMTPS id 28sm8466857fkx.24.2009.06.20.09.48.05 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 20 Jun 2009 09:48:06 -0700 (PDT) From: "Roni Even" To: "'Henry Sinnreich'" , References: <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> In-Reply-To: Date: Sat, 20 Jun 2009 19:46:55 +0300 Message-ID: <4a3d12c6.1c185e0a.0903.ffffc61f@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0405_01C9F1DF.DEA5D220" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnw+gkTHL2SdLtVTDiF20h8Qld27QADaHaAAC7D3rEAAHVH8A== Content-Language: en-us Subject: Re: [codec] Royalty free is top motivation 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, 20 Jun 2009 16:48:05 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0405_01C9F1DF.DEA5D220 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Henry, I fully agree that royalty free is a good requirement. I just expect that people who ask for it will come in good faith and provide interoperable royalty free technology and solutions. Having two products that run the same "royalty free" codec on the Internet but who cannot connect to each other and do not offer any such option to other developers to provide it is bad. >From knowing your views, I would expect that you will share my view that having to install on my computer multiple communication clients is not what we all want as end users. I would prefer to have one client that will be able to talk with other clients. Some of the requirements for this work so far is coming from people who want to continue to provide non-interoperable products using royalty free technology done by others. Telecommunication does not work if there is no interoperability and if the signaling interoperability will continue to be through PSTN gateways there is no need for wideband codecs. Roni From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Saturday, June 20, 2009 7:18 PM To: Roni Even; codec@ietf.org Subject: Royalty free is top motivation Roni, (Topic changed for focus) Roni, Just to make it clear, royalty free was one of the top motivations and should probably be the main requirement for the Internet codec. Interoperability with existing codecs is nice, but IMHO a secondary order requirement, given that most interactive communications are already on the Internet and will be so even more in the future. Vendors and operators are always free to include some other codecs and let SIP do the codec negotiation - that's what it is for in SIP. Henry On 6/19/09 1:41 PM, "Roni Even" wrote: Hi, Inline some comments (sections starting with RE) on the charter. Purpose: This new working group would be chartered with the purpose of collecting expertise within the IETF in order to review the design of audio codecs specifically for use with the Internet. Unlike other SDOs, these codecs would be optimized for use on the Internet, RE: I would argue that this statement is not correct and I have not seen any data supporting this statement, the fact is that there are numerous codecs coming from other SDOs being used on the Internet. I would also say that optimize for the Internet is not an application description since it is to wide, eventually this will be reflected if you start to discuss requirements when you will need to describe the applications that will use this codec. and as much as possible choose technology that does not require paying patent royalties. RE: Is this a selection criteria for selecting a codec. The Internet Low Bit Rate Codec (iLBC) work was done in AVT but it was felt that subsequent work should not be done in the AVT working group. RE: to say done is overstating what was done in AVT comparing to other bodies. Furthermore it is not the same to publish a codec done by some company as an Informational and specifying requirements and selecting one codec from multiple proposal based on quality criteria This new working group will have as its primary purpose the standardization of a multi-purpose audio codec that can be used in various situations on the Internet. Some of the proposed Internet-specific requirements include: * scalable and adaptive bit rate; * various sampling rate profiles from narrow-band to super-wideband; RE: Just to clarify do you mean 3.5Khz, 7Khz and 14 Khz? * scalable complexity; * low latency; and * resilience to packet loss. RE: I think that the first stage is to describe the use scenarios before giving requirements. For the current text I can add multiple other requirements for example: Support for hands free operation (open mic), speech and music, multiple languages support, fax, stereo, 5+1, layered codec ......... There are a number of wide-band capable codecs defined by other SDOs. For instance, G.722 is seeing adoption in Enterprise applications since it is relatively simple and low-cost to deploy. However, it has a high, fixed bitrate and is not appropriate for mobile applications where spectrum efficiency is important or in consumer applications where available bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been adopted by the 3GPP as a wideband standard for mobile applications. G.722.2 is relatively high cost due to patent royalties and is seeing minimal deployments outside of mobile handsets making it challenging to create wideband experiences on Internet-capable mobile devices when extending beyond the mobile network. In other cases, proprietary codecs are being adopted which further create islands with no interoperability unless widespread transcoding is performed. Transcoding leads to higher costs and lower quality. RE: Basing your discussion on G.722 and G.722.2 is not correct (G.722 is 7Khz) the latest codecs technology will be AMR-WB+, MPEG4 AAC-LD or scalable, eAAC+, G.729 with the new enhancement layers for wide band, G.718. Note that the ITU is working on embedded variable bit rates codec technology. The goal of this working group is to define a single codec with multiple profiles which can be made available on a wide variety of Internet-capable devices including low-power, mobile devices as well as devices capable of utilizing high quality, high bitrate audio. RE: What is multiple profiles is it embedded variable rate (layered codec) or is it different modes (like G.722.1 and G.722.1C) using the same codec technology. Proposed Deliverables: 1) Requirements for wideband, Internet audio codec(s). 2) Algorithm description for wideband, Internet audio codec(s) as Proposed Standard. 3) Specification of payload format(s) for defined codecs as Proposed Standard RE: Other deliverables - testing procedure and metrics. Codec selection criteria - which requirements are more important. I am also not sure what is algorithm description means, I would except a fixed point source reference if we want to have bit exactness between multiple implementations. The deliverables should include quality test results from independent test labs to enable selection. I also thought from the above text that we are talking about super wideband and not wide band codec. Thanks Roni Even _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec ------=_NextPart_000_0405_01C9F1DF.DEA5D220 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Royalty free is top motivation

Henry,

I fully agree that royalty free is a good requirement. I = just expect that people who ask for it will come in good faith and provide interoperable royalty free technology and solutions. Having two products = that run the same "royalty free" codec on the Internet but who = cannot connect to each other and do not offer any such option to other = developers to provide it is  bad.

 

From knowing your views, I would expect that you will = share my view that having to install on my computer multiple communication = clients is not what we all want as end users. I would prefer to have one client = that will be able to talk with other clients. Some of the requirements for this = work  so far is coming from people who want to continue to provide = non-interoperable products using royalty free technology done by others. =  

 

Telecommunication does not work if there is no = interoperability and if the signaling interoperability will continue to be through PSTN = gateways there is no need for wideband codecs.

 

 

Roni

 

From:= Henry = Sinnreich [mailto:hsinnrei@adobe.com]
Sent: Saturday, June 20, 2009 7:18 PM
To: Roni Even; codec@ietf.org
Subject: Royalty free is top motivation

 

Roni,
(Topic changed for focus)

Roni,

Just to make it clear, royalty free was one of the top motivations and = should probably be the main requirement for the Internet codec.

Interoperability with existing codecs is nice, but IMHO a secondary = order requirement, given that most interactive communications are already on = the Internet and will be so even more in the future. Vendors and operators = are always free to include some other codecs and let SIP do the codec negotiation = – that’s what it is for in SIP.

Henry

On 6/19/09 1:41 PM, "Roni Even" <ron.even.tlv@gmail.com> wrote:

Hi,
Inline some comments (sections starting with RE) on the charter.

Purpose:

This new working group would be chartered with the purpose of = collecting
expertise within the IETF in order to review the design of audio = codecs
specifically for use with the Internet.

Unlike other SDOs, these codecs would be optimized for use on the = Internet,

RE: I would argue that this statement is not correct and I have not seen = any data supporting this statement, the fact is that there are numerous = codecs coming from other SDOs being used on the Internet. I would also say that optimize for the Internet is not an application description since it is = to wide, eventually this will be reflected if you start to discuss = requirements when you will need to describe the applications that will use this = codec.


and as much as possible choose technology that does not require paying = patent royalties.

RE: Is this a selection criteria for selecting a codec.


The Internet Low Bit Rate Codec (iLBC)  work was done in AVT but it = was felt
that subsequent work should not be done in the AVT working group.

RE: to say done is overstating what was done in AVT comparing to other = bodies. Furthermore it is not the same to publish a codec done by some company = as an Informational and specifying requirements and selecting one codec from = multiple proposal based on quality criteria

This new working group will have as its primary purpose the = standardization of a
multi-purpose audio codec that can be used in various situations on = the
Internet. Some of the proposed Internet-specific requirements = include:
* scalable and adaptive bit rate;
* various sampling rate profiles from narrow-band to super-wideband;

RE: Just to clarify do you mean 3.5Khz, 7Khz and 14 Khz?

* scalable complexity;
* low latency; and
* resilience to packet loss.

RE: I think that the first stage is to describe the use scenarios before = giving requirements. For the current text I can add multiple other requirements = for example:
Support for hands free operation (open mic), speech and music, multiple languages support, fax, stereo, 5+1, layered codec .........


There are a number of wide-band capable codecs defined by other SDOs. = For
instance, G.722 is seeing adoption in Enterprise applications since it = is
relatively simple and low-cost to deploy. However, it has a high, = fixed
bitrate and is not appropriate for mobile applications where = spectrum
efficiency is important or in consumer applications where available
bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been = adopted
by the 3GPP as a wideband standard for mobile applications. G.722.2 = is
relatively high cost due to patent royalties and is seeing minimal
deployments outside of mobile handsets making it challenging to = create
wideband experiences on Internet-capable mobile devices when = extending
beyond the mobile network. In other cases, proprietary codecs are = being
adopted which further create islands with no interoperability unless
widespread transcoding is performed. Transcoding leads to higher costs = and
lower quality.

RE: Basing your discussion on G.722 and G.722.2 is not correct (G.722 is = 7Khz) the latest codecs technology will be AMR-WB+, MPEG4 AAC-LD or scalable, = eAAC+, G.729 with the new enhancement layers for wide band, G.718. Note that = the ITU is working on embedded variable bit rates codec technology.


The goal of this working group is to define a single codec with = multiple
profiles which can be made available on a wide variety of = Internet-capable
devices including low-power, mobile devices as well as devices capable = of
utilizing high quality, high bitrate audio.

RE: What is multiple profiles is it embedded variable rate (layered = codec) or is it different modes (like G.722.1 and G.722.1C) using the same codec technology.


Proposed Deliverables:

1) Requirements for wideband, Internet audio codec(s).
2) Algorithm description for wideband, Internet audio codec(s) as = Proposed
Standard.
3) Specification of payload format(s) for defined codecs as Proposed
Standard

RE: Other deliverables - testing procedure and metrics. Codec selection criteria - which requirements are more important. I am also not sure = what is algorithm description means, I would except a fixed point source = reference if we want to have bit exactness between multiple implementations.
The deliverables should include quality test results from independent = test labs to enable selection.
I also thought from the above text that we are talking about super = wideband and not wide band codec.

Thanks
Roni Even


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

------=_NextPart_000_0405_01C9F1DF.DEA5D220-- From macinnis@broadcom.com Sat Jun 20 09:53:29 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 9DD463A6AE5 for ; Sat, 20 Jun 2009 09:53:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.189 X-Spam-Level: X-Spam-Status: No, score=-2.189 tagged_above=-999 required=5 tests=[AWL=0.409, 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 m5VL1US7lEx1 for ; Sat, 20 Jun 2009 09:53:23 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id 2CC883A6905 for ; Sat, 20 Jun 2009 09:53:23 -0700 (PDT) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Sat, 20 Jun 2009 09:53:27 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Sat, 20 Jun 2009 09:53:26 -0700 From: "Sandy (Alexander) MacInnis" To: "codec@ietf.org" Date: Sat, 20 Jun 2009 09:52:15 -0700 Thread-Topic: Royalty free is top motivation Thread-Index: Acnw+gkTHL2SdLtVTDiF20h8Qld27QADaHaAAC7D3rEAAEzEwA== Message-ID: <568A92CB079CCF43BA5C8D7B08BCB4AE8150B554D6@SJEXCHCCR02.corp.ad.broadcom.com> References: <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> 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: 6623CB8D38416128777-01-01 Content-Type: multipart/alternative; boundary=_000_568A92CB079CCF43BA5C8D7B08BCB4AE8150B554D6SJEXCHCCR02co_ Subject: Re: [codec] Royalty free is top motivation 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, 20 Jun 2009 16:53:29 -0000 --_000_568A92CB079CCF43BA5C8D7B08BCB4AE8150B554D6SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable That sounds great. I'd like to point a few things that may or may not be obvious to everyone h= ere. I'm not a lawyer; this is an engineer's description (mine), so don't t= ake this a legal advice. I'm pretty familiar with patents, however. A potentially major problem with trying to make something royalty-free with= certainty, is the possibility of existing patents that may be infringed by= the "free" technology. There are lots of patents out there. Even if someone sat all by him/herself and created a codec from scratch, wi= th or without referring to any textbooks, journal articles, or openly avail= able source code, and the publishes the codec and declares that it's free t= o the world, that does not mean that it does not infringe on anyone's paten= ts. This is true whether or not the creator of the codec files any patent a= pplications on the work. If such a codec is published and used, a holder of a patent may wait until = there is widespread use of the codec, and then sue whoever they want. A dee= p-pockets company may make an attractive target. That could be a significan= t problem. For that reason, something that is thought to be royalty-free may turn out = not to be royalty free after all. It could go from seemingly free to quite = expensive rather quickly, or it could even be dropped by major companies, o= r even opposed by them in advance. It's difficult, but not quite impossible, to avoid this problem. Some standards groups try to avoid this problem by asking contributors to d= eclare what they know about any existing or planned patent coverage that ma= y cover their submission, and ask contributors who have their own patents t= o indicate on what terms they will license the patents. That may help a lot= , but it may not solve the problem. For one thing, contributors may not kno= w about patents that their method might infringe - often they don't know. T= here might also be some legal wrangling over the final terms for royalty-fr= ee licensing of patents held by contributors. Another way is to study very carefully all the patents that could possibly = be infringed, for each one, either work around it or see that the patent ha= s already expired. This is very hard to do, but it can be done. This does not mean that everyone wanting to implement a codec that's said t= o be royalty free has to read contracts. It would help however if someone h= ad done some diligence on sorting this out before the codec is published. W= ith suitable public licenses, it should be possible for all the world's use= rs to be confident that a codec is royalty-free, while also being high qual= ity, interoperable, open source, and a published standard. --Sandy ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of H= enry Sinnreich Sent: Saturday, June 20, 2009 12:18 PM To: Roni Even; codec@ietf.org Subject: [codec] Royalty free is top motivation Roni, (Topic changed for focus) Roni, Just to make it clear, royalty free was one of the top motivations and shou= ld probably be the main requirement for the Internet codec. Interoperability with existing codecs is nice, but IMHO a secondary order r= equirement, given that most interactive communications are already on the I= nternet and will be so even more in the future. Vendors and operators are a= lways free to include some other codecs and let SIP do the codec negotiatio= n - that's what it is for in SIP. Henry [... remainder of thread deleted for brevity...] --_000_568A92CB079CCF43BA5C8D7B08BCB4AE8150B554D6SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Royalty free is top motivation
That sounds great.
 
I'd like to point a few things that may or may n= ot be=20 obvious to everyone here. I'm not a lawyer; this is an engineer's descripti= on=20 (mine), so don't take this a legal advice. I'm pretty fami= liar with=20 patents, however.
 
A potentially major problem with trying to make= =20 something royalty-free with certainty, is the possibility of existing paten= ts=20 that may be infringed by the "free" technology. There are lots of patents o= ut=20 there.
 
Even if someone sat all by him/herself and creat= ed a=20 codec from scratch, with or without referring to any textbooks, journal=20 articles, or openly available source code, and the publishes the codec and= =20 declares that it's free to the world, that does not mean that it does not=20 infringe on anyone's patents. This is true whether or not the creator of th= e=20 codec files any patent applications on the work.
 
If such a codec is published and used, a holder = of a=20 patent may wait until there is widespread use of the codec, and then s= ue=20 whoever they want. A deep-pockets company may make an attractive target. That could be a=20 significant problem.
 
For=20 that reason, something that is thought to be royalty-free may turn out not = to be=20 royalty free after all. It could go from seemingly free to quite expensive= =20 rather quickly, or it could even be dropped by major companies, or even opp= osed=20 by them in advance.
 
It's=20 difficult, but not quite impossible, to avoid this problem. <= /DIV>
 
Some=20 standards groups try to avoid this problem by asking contributors to declar= e=20 what they know about any existing or planned patent coverage that may cover= =20 their submission, and ask contributors who have their own patents to indica= te on=20 what terms they will license the patents. That may help a lot, but it may n= ot=20 solve the problem. For one thing, contributors may not know about patents t= hat=20 their method might infringe - often they don't know. There might also be so= me=20 legal wrangling over the final terms for royalty-free licensing of patents = held=20 by contributors.
 
Another way is to study very carefully all the p= atents=20 that could possibly be infringed, for each one, either work around it or se= e=20 that the patent has already expired. This is very hard to do, but it can be= =20 done.
 
This=20 does not mean that everyone wanting to implement a codec that's said to be= =20 royalty free has to read contracts. It would help however if someone had do= ne=20 some diligence on sorting this out before the codec is published. With suit= able=20 public licenses, it should be possible for all the world's users to be conf= ident=20 that a codec is royalty-free, while also being high quality, interoperable,= open=20 source, and a published standard.
 
--Sandy
 

From: codec-bounces@ietf.org=20 [mailto:codec-bounces@ietf.org] On Behalf Of Henry=20 Sinnreich
Sent: Saturday, June 20, 2009 12:18 PM
To: Ro= ni=20 Even; codec@ietf.org
Subject: [codec] Royalty free is top=20 motivation

Roni,
(Topic changed for=20 focus)

Roni,

Just to make it clear, royalty free was one of t= he=20 top motivations and should probably be the main requirement for the Interne= t=20 codec.

Interoperability with existing codecs is nice, but IMHO a=20 secondary order requirement, given that most interactive communications are= =20 already on the Internet and will be so even more in the future. Vendors and= =20 operators are always free to include some other codecs and let SIP do the c= odec=20 negotiation – that’s what it is for in SIP.

Henry
[... remainder of thread deleted for=20 brevity...] 
--_000_568A92CB079CCF43BA5C8D7B08BCB4AE8150B554D6SJEXCHCCR02co_-- From hsinnrei@adobe.com Sat Jun 20 10:03:16 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 14DA33A6BA8 for ; Sat, 20 Jun 2009 10:03:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.528 X-Spam-Level: X-Spam-Status: No, score=-4.528 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 AqTwIfZGsCRV for ; Sat, 20 Jun 2009 10:03:05 -0700 (PDT) Received: from exprod6og116.obsmtp.com (exprod6og116.obsmtp.com [64.18.1.37]) by core3.amsl.com (Postfix) with ESMTP id 403683A6C04 for ; Sat, 20 Jun 2009 10:03:05 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob116.postini.com ([64.18.5.12]) with SMTP ID DSNKSj0WVcAMLmgM+Ru1Qwn0wi88/MIjhswW@postini.com; Sat, 20 Jun 2009 10:03:19 PDT Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5KGv3ao010690; Sat, 20 Jun 2009 09:57:04 -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 n5KH3DY2028671; Sat, 20 Jun 2009 10:03:14 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Sat, 20 Jun 2009 10:03:13 -0700 From: Henry Sinnreich To: Roni Even , "codec@ietf.org" Date: Sat, 20 Jun 2009 10:03:10 -0700 Thread-Topic: Royalty free is top motivation Thread-Index: Acnw+gkTHL2SdLtVTDiF20h8Qld27QADaHaAAC7D3rEAAHVH8AABG2vp Message-ID: In-Reply-To: <4a3d12c6.1c185e0a.0903.ffffc61f@mx.google.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_C662807E43FFhsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] Royalty free is top motivation 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, 20 Jun 2009 17:03:16 -0000 --_000_C662807E43FFhsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Roni, >From knowing your views, I would expect that you will share my view that h= aving to install on my computer multiple communication clients is not what = we all want as end users. I fully agree. As far as SIP goes however, all SIP phones and PC UAs have m= ultiple codecs already. I understand Skype had more then one codec as well, but am not sure. Maybe our colleagues from Skype can share with us. Henry On 6/20/09 11:46 AM, "Roni Even" wrote: Henry, I fully agree that royalty free is a good requirement. I just expect that p= eople who ask for it will come in good faith and provide interoperable roya= lty free technology and solutions. Having two products that run the same "r= oyalty free" codec on the Internet but who cannot connect to each other and= do not offer any such option to other developers to provide it is bad. >From knowing your views, I would expect that you will share my view that ha= ving to install on my computer multiple communication clients is not what w= e all want as end users. I would prefer to have one client that will be abl= e to talk with other clients. Some of the requirements for this work so fa= r is coming from people who want to continue to provide non-interoperable p= roducts using royalty free technology done by others. Telecommunication does not work if there is no interoperability and if the = signaling interoperability will continue to be through PSTN gateways there = is no need for wideband codecs. Roni From: Henry Sinnreich [mailto:hsinnrei@adobe.com] Sent: Saturday, June 20, 2009 7:18 PM To: Roni Even; codec@ietf.org Subject: Royalty free is top motivation Roni, (Topic changed for focus) Roni, Just to make it clear, royalty free was one of the top motivations and shou= ld probably be the main requirement for the Internet codec. Interoperability with existing codecs is nice, but IMHO a secondary order r= equirement, given that most interactive communications are already on the I= nternet and will be so even more in the future. Vendors and operators are a= lways free to include some other codecs and let SIP do the codec negotiatio= n - that's what it is for in SIP. Henry On 6/19/09 1:41 PM, "Roni Even" wrote: Hi, Inline some comments (sections starting with RE) on the charter. Purpose: This new working group would be chartered with the purpose of collecting expertise within the IETF in order to review the design of audio codecs specifically for use with the Internet. Unlike other SDOs, these codecs would be optimized for use on the Internet, RE: I would argue that this statement is not correct and I have not seen an= y data supporting this statement, the fact is that there are numerous codec= s coming from other SDOs being used on the Internet. I would also say that = optimize for the Internet is not an application description since it is to = wide, eventually this will be reflected if you start to discuss requirement= s when you will need to describe the applications that will use this codec. and as much as possible choose technology that does not require paying pate= nt royalties. RE: Is this a selection criteria for selecting a codec. The Internet Low Bit Rate Codec (iLBC) work was done in AVT but it was fel= t that subsequent work should not be done in the AVT working group. RE: to say done is overstating what was done in AVT comparing to other bodi= es. Furthermore it is not the same to publish a codec done by some company = as an Informational and specifying requirements and selecting one codec fro= m multiple proposal based on quality criteria This new working group will have as its primary purpose the standardization= of a multi-purpose audio codec that can be used in various situations on the Internet. Some of the proposed Internet-specific requirements include: * scalable and adaptive bit rate; * various sampling rate profiles from narrow-band to super-wideband; RE: Just to clarify do you mean 3.5Khz, 7Khz and 14 Khz? * scalable complexity; * low latency; and * resilience to packet loss. RE: I think that the first stage is to describe the use scenarios before gi= ving requirements. For the current text I can add multiple other requiremen= ts for example: Support for hands free operation (open mic), speech and music, multiple lan= guages support, fax, stereo, 5+1, layered codec ......... There are a number of wide-band capable codecs defined by other SDOs. For instance, G.722 is seeing adoption in Enterprise applications since it is relatively simple and low-cost to deploy. However, it has a high, fixed bitrate and is not appropriate for mobile applications where spectrum efficiency is important or in consumer applications where available bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been adopte= d by the 3GPP as a wideband standard for mobile applications. G.722.2 is relatively high cost due to patent royalties and is seeing minimal deployments outside of mobile handsets making it challenging to create wideband experiences on Internet-capable mobile devices when extending beyond the mobile network. In other cases, proprietary codecs are being adopted which further create islands with no interoperability unless widespread transcoding is performed. Transcoding leads to higher costs and lower quality. RE: Basing your discussion on G.722 and G.722.2 is not correct (G.722 is 7K= hz) the latest codecs technology will be AMR-WB+, MPEG4 AAC-LD or scalable,= eAAC+, G.729 with the new enhancement layers for wide band, G.718. Note th= at the ITU is working on embedded variable bit rates codec technology. The goal of this working group is to define a single codec with multiple profiles which can be made available on a wide variety of Internet-capable devices including low-power, mobile devices as well as devices capable of utilizing high quality, high bitrate audio. RE: What is multiple profiles is it embedded variable rate (layered codec) = or is it different modes (like G.722.1 and G.722.1C) using the same codec t= echnology. Proposed Deliverables: 1) Requirements for wideband, Internet audio codec(s). 2) Algorithm description for wideband, Internet audio codec(s) as Proposed Standard. 3) Specification of payload format(s) for defined codecs as Proposed Standard RE: Other deliverables - testing procedure and metrics. Codec selection cri= teria - which requirements are more important. I am also not sure what is a= lgorithm description means, I would except a fixed point source reference i= f we want to have bit exactness between multiple implementations. The deliverables should include quality test results from independent test = labs to enable selection. I also thought from the above text that we are talking about super wideband= and not wide band codec. Thanks Roni Even _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C662807E43FFhsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: Royalty free is top motivation Roni,

>From knowing your views, I would expect that you will share my view tha= t having to install on my computer multiple communication clients is not wh= at we all want as end users.

I fully agree. As far as SIP goes however, all SIP phones and PC UAs have m= ultiple codecs already.
I understand Skype had more then one codec as well, but am not sure.
Maybe our colleagues from Skype can share with us.

Henry



On 6/20/09 11:46 AM, "Roni Even" <ron.even.tlv@gmail.com> wrote:

Henry,
I fully agree that royalty free is a good requirement. I just expect that p= eople who ask for it will come in good faith and provide interoperable roya= lty free technology and solutions. Having two products that run the same &q= uot;royalty free" codec on the Internet but who cannot connect to each= other and do not offer any such option to other developers to provide it i= s  bad.
 
>From knowing your views, I would expect that you will share my view that ha= ving to install on my computer multiple communication clients is not what w= e all want as end users. I would prefer to have one client that will be abl= e to talk with other clients. Some of the requirements for this work  = so far is coming from people who want to continue to provide non-interopera= ble products using royalty free technology done by others.  
 
Telecommunication does not work if there is no interoperability and if the = signaling interoperability will continue to be through PSTN gateways there = is no need for wideband codecs.
 
 
Roni
 

From: Henry S= innreich [mailto:hsinnrei@adobe.com]
Sent: Saturday, June 20, 2009 7:18 PM
To: Roni Even; codec@ietf.org
Subject: Royalty free is top motivation
Roni,
(Topic changed for focus)

Roni,

Just to make it clear, royalty free was one of the top motivations and shou= ld probably be the main requirement for the Internet codec.

Interoperability with existing codecs is nice, but IMHO a secondary order r= equirement, given that most interactive communications are already on the I= nternet and will be so even more in the future. Vendors and operators are a= lways free to include some other codecs and let SIP do the codec negotiatio= n – that’s what it is for in SIP.

Henry

On 6/19/09 1:41 PM, "Roni Even" <ron.even.tlv@gmail.com> wrote:
Hi,
Inline some comments (sections starting with RE) on the charter.

Purpose:

This new working group would be chartered with the purpose of collecting expertise within the IETF in order to review the design of audio codecs
specifically for use with the Internet.

Unlike other SDOs, these codecs would be optimized for use on the Internet,=

RE: I would argue that this statement is not correct and I have not seen an= y data supporting this statement, the fact is that there are numerous codec= s coming from other SDOs being used on the Internet. I would also say that = optimize for the Internet is not an application description since it is to = wide, eventually this will be reflected if you start to discuss requirement= s when you will need to describe the applications that will use this codec.=


and as much as possible choose technology that does not require paying pate= nt royalties.

RE: Is this a selection criteria for selecting a codec.


The Internet Low Bit Rate Codec (iLBC)  work was done in AVT but it wa= s felt
that subsequent work should not be done in the AVT working group.

RE: to say done is overstating what was done in AVT comparing to other bodi= es. Furthermore it is not the same to publish a codec done by some company = as an Informational and specifying requirements and selecting one codec fro= m multiple proposal based on quality criteria

This new working group will have as its primary purpose the standardization= of a
multi-purpose audio codec that can be used in various situations on the
Internet. Some of the proposed Internet-specific requirements include:
* scalable and adaptive bit rate;
* various sampling rate profiles from narrow-band to super-wideband;

RE: Just to clarify do you mean 3.5Khz, 7Khz and 14 Khz?

* scalable complexity;
* low latency; and
* resilience to packet loss.

RE: I think that the first stage is to describe the use scenarios before gi= ving requirements. For the current text I can add multiple other requiremen= ts for example:
Support for hands free operation (open mic), speech and music, multiple lan= guages support, fax, stereo, 5+1, layered codec .........


There are a number of wide-band capable codecs defined by other SDOs. For instance, G.722 is seeing adoption in Enterprise applications since it is relatively simple and low-cost to deploy. However, it has a high, fixed
bitrate and is not appropriate for mobile applications where spectrum
efficiency is important or in consumer applications where available
bandwidth is fluctuating or limited. G.722.2 (AMR-wideband) has been adopte= d
by the 3GPP as a wideband standard for mobile applications. G.722.2 is
relatively high cost due to patent royalties and is seeing minimal
deployments outside of mobile handsets making it challenging to create
wideband experiences on Internet-capable mobile devices when extending
beyond the mobile network. In other cases, proprietary codecs are being
adopted which further create islands with no interoperability unless
widespread transcoding is performed. Transcoding leads to higher costs and<= BR> lower quality.

RE: Basing your discussion on G.722 and G.722.2 is not correct (G.722 is 7K= hz) the latest codecs technology will be AMR-WB+, MPEG4 AAC-LD or scalable,= eAAC+, G.729 with the new enhancement layers for wide band, G.718. Note th= at the ITU is working on embedded variable bit rates codec technology.


The goal of this working group is to define a single codec with multiple profiles which can be made available on a wide variety of Internet-capable<= BR> devices including low-power, mobile devices as well as devices capable of utilizing high quality, high bitrate audio.

RE: What is multiple profiles is it embedded variable rate (layered codec) = or is it different modes (like G.722.1 and G.722.1C) using the same codec t= echnology.


Proposed Deliverables:

1) Requirements for wideband, Internet audio codec(s).
2) Algorithm description for wideband, Internet audio codec(s) as Proposed<= BR> Standard.
3) Specification of payload format(s) for defined codecs as Proposed
Standard

RE: Other deliverables - testing procedure and metrics. Codec selection cri= teria - which requirements are more important. I am also not sure what is a= lgorithm description means, I would except a fixed point source reference i= f we want to have bit exactness between multiple implementations.
The deliverables should include quality test results from independent test = labs to enable selection.
I also thought from the above text that we are talking about super wideband= and not wide band codec.

Thanks
Roni Even


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

--_000_C662807E43FFhsinnreiadobecom_-- From hsinnrei@adobe.com Sat Jun 20 10:10:54 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 780FA28C12C for ; Sat, 20 Jun 2009 10:10:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.659 X-Spam-Level: X-Spam-Status: No, score=-5.659 tagged_above=-999 required=5 tests=[AWL=0.939, BAYES_00=-2.599, 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 Iv29v9+hneFx for ; Sat, 20 Jun 2009 10:10:51 -0700 (PDT) Received: from psmtp.com (exprod6ob113.obsmtp.com [64.18.1.30]) by core3.amsl.com (Postfix) with ESMTP id D660128C0FE for ; Sat, 20 Jun 2009 10:10:49 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKSj0YJ6JPV1rsxAdwDOehZYfSo0WdZCTE@postini.com; Sat, 20 Jun 2009 10:11:05 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 n5KHB1WG025512; Sat, 20 Jun 2009 10:11:01 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n5KHAxY2028960; Sat, 20 Jun 2009 10:11:00 -0700 (PDT) Received: from excas03.corp.adobe.com (10.8.189.123) by nacas02.corp.adobe.com (10.8.189.100) with Microsoft SMTP Server (TLS) id 8.1.340.0; Sat, 20 Jun 2009 10:10:59 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by excas03.corp.adobe.com ([10.8.189.123]) with mapi; Sat, 20 Jun 2009 10:10:58 -0700 From: Henry Sinnreich To: "Sandy (Alexander) MacInnis" , "codec@ietf.org" Date: Sat, 20 Jun 2009 10:10:57 -0700 Thread-Topic: [codec] Royalty free is top motivation Thread-Index: Acnw+gkTHL2SdLtVTDiF20h8Qld27QADaHaAAC7D3rEAAEzEwAABiYRm Message-ID: In-Reply-To: <568A92CB079CCF43BA5C8D7B08BCB4AE8150B554D6@SJEXCHCCR02.corp.ad.broadcom.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_C66282514402hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] Royalty free is top motivation 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, 20 Jun 2009 17:10:54 -0000 --_000_C66282514402hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable This are excellent points. For what it's worth, going by the IETF policy is netter than nothing. All we have to do is to disregard in the proposed IETF Codec WG existing co= decs known to have royalty claims. [Timber !!! :-) ] Henry On 6/20/09 11:52 AM, "Sandy (Alexander) MacInnis" w= rote: Some standards groups try to avoid this problem by asking contributors to d= eclare what they know about any existing or planned patent coverage that ma= y cover their submission, and ask contributors who have their own patents t= o indicate on what terms they will license the patents. That may help a lot= , but it may not solve the problem. --_000_C66282514402hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Royalty free is top motivation This are excellent points.
For what it’s worth, going by the IETF policy is netter than nothing.=
All we have to do is to disregard in the proposed IETF Codec WG existing co= decs known to have royalty claims.
[Timber !!!  :-)  ]

Henry


On 6/20/09 11:52 AM, "Sandy (Alexander) MacInnis" <macinnis@broadcom.com> wrote:

Some standards groups try to avoid this problem = by asking contributors to declare what they know about any existing or plan= ned patent coverage that may cover their submission, and ask contributors w= ho have their own patents to indicate on what terms they will license the p= atents. That may help a lot, but it may not solve the problem.
--_000_C66282514402hsinnreiadobecom_-- From jean-marc.valin@usherbrooke.ca Sat Jun 20 10:38: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 1C1AF3A6D3C for ; Sat, 20 Jun 2009 10:38:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.824 X-Spam-Level: X-Spam-Status: No, score=-1.824 tagged_above=-999 required=5 tests=[AWL=-0.465, BAYES_00=-2.599, SARE_LWSHORTT=1.24] 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 ElXVzhQn2H3Q for ; Sat, 20 Jun 2009 10:38:25 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 367193A6C31 for ; Sat, 20 Jun 2009 10:38:25 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=UTF-8 Received: from [192.168.1.10] ([70.81.109.112]) by VL-MH-MR002.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KLJ00A6LT0EZV40@VL-MH-MR002.ip.videotron.ca> for codec@ietf.org; Sat, 20 Jun 2009 13:38:39 -0400 (EDT) Message-id: <4A3D1E9E.2030601@usherbrooke.ca> Date: Sat, 20 Jun 2009 13:38:38 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) To: "Sandy (Alexander) MacInnis" References: <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> <568A92CB079CCF43BA5C8D7B08BCB4AE8150B554D6@SJEXCHCCR02.corp.ad.broadcom.com> In-reply-to: <568A92CB079CCF43BA5C8D7B08BCB4AE8150B554D6@SJEXCHCCR02.corp.ad.broadcom.com> X-Enigmail-Version: 0.95.2 Cc: "codec@ietf.org" Subject: Re: [codec] Royalty free is top motivation 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, 20 Jun 2009 17:38:26 -0000 Sandy (Alexander) MacInnis a écrit : > A potentially major problem with trying to make something royalty-free > with certainty, is the possibility of existing patents that may be > infringed by the "free" technology. There are lots of patents out there. Yes, I'm aware of that and it has been a consideration throughout the development of Speex and (now) CELT. > If such a codec is published and used, a holder of a patent may wait > until there is widespread use of the codec, and then sue whoever they > want. A deep-pockets company may make an attractive target. That could > be a significant problem. > > For that reason, something that is thought to be royalty-free may turn > out not to be royalty free after all. It could go from seemingly free to > quite expensive rather quickly, or it could even be dropped by major > companies, or even opposed by them in advance. Unfortunately, this is the sad state of the current patent system, which we cannot change in the short term. In fact, this is not only a problem for codecs, but for all software (and possibly other areas, but I won't go into that). As it is, the only way to be absolutely sure not to infringe on a patent is not to create anything. Obviously, that is not a very worthwhile option. Some people make it sound like only free software is affected, though but that's not the case. You could have a company claiming that any of the ITU or MPEG codecs infringe on their patent. Fortunately, many patents in the audio coding world are written specifically for a certain codec. The claims of these patents are usually very strong (hard to defeat by prior art), but at the same time very narrow so that accidental infringement is not too likely. It is the broader patents that are more dangerous, but they are usually better known, so easier to protect against. > Another way is to study very carefully all the patents that could > possibly be infringed, for each one, either work around it or see that > the patent has already expired. This is very hard to do, but it can be done. Yes, it can be done. And it is best done in a collaborative way, with as many people as possible using their knowledge to examine possible patent issues. I believe the IETF is a good place to do that. Cheers, Jean-Marc From xiphmont@gmail.com Sat Jun 20 10:49:06 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 54FC53A6B37 for ; Sat, 20 Jun 2009 10:49:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 EAM9kTm7v4Ey for ; Sat, 20 Jun 2009 10:49:05 -0700 (PDT) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id EABEE3A6857 for ; Sat, 20 Jun 2009 10:48:53 -0700 (PDT) Received: by gxk10 with SMTP id 10so3962531gxk.13 for ; Sat, 20 Jun 2009 10:49: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:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=sUbduEQ8Yoy/bbBtBBXUNB9zheCS4QBTbw1rDV3Ut1E=; b=Af4jt+2Wz42Pw88Xnz3cQY/YWdyIJ6YwuP6QU6sZeudd4nbiw++GG+XkrHbnl7Qhr+ NCnPsvM5HK768XHZK6i7f2kvkC4NYYGdlLZzQryIGu2bklQYa5LY/eMhq/MxUypKwpBC wl8EBB60YPGrpAHneMSAAzLKyzkByMCdKdSgQ= 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:content-transfer-encoding; b=E3jO1kGB5uo/Y4NoDRsZS1lfaezb4C5N0/hj9cUUctsmxbjz3P3KK00E8xUrMi4ZkL VxchiKu8cOeO01iwtH9wLw4RwO8o6hAmOetkVDlDH7Pi8s5OzfB4mVjoecFeM7Txc7ul gqCfYxdIo5KiB6M6bQaCwv6aJ5XKq0WpLmEag= MIME-Version: 1.0 Received: by 10.231.15.131 with SMTP id k3mr1320744iba.47.1245520145967; Sat, 20 Jun 2009 10:49:05 -0700 (PDT) In-Reply-To: <4a3d0650.0637560a.2413.6788@mx.google.com> References: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com> <4a3be187.0aec660a.691c.ffffdf99@mx.google.com> <1245443939.4a3bf76372390@www.usherbrooke.ca> <4a3bfa52.1c215e0a.09cf.ffffdff7@mx.google.com> <1245446945.4a3c032106f5f@www.usherbrooke.ca> <4a3c768e.0c07560a.062b.ffffe257@mx.google.com> <4A3CE439.9000508@usherbrooke.ca> <4a3ceebf.13125e0a.6b81.ffff96b6@mx.google.com> <806dafc20906200830x45e03ae8ie5077b12f9610c3c@mail.gmail.com> <4a3d0650.0637560a.2413.6788@mx.google.com> Date: Sat, 20 Jun 2009 13:49:05 -0400 Message-ID: <806dafc20906201049p1546e7e6q6ce67d59afed16ab@mail.gmail.com> From: Christopher Montgomery To: Roni Even Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: codec@ietf.org, Jean-Marc Valin Subject: Re: [codec] Codec BOF approved, much work needed 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, 20 Jun 2009 17:49:06 -0000 On Sat, Jun 20, 2009 at 11:53 AM, Roni Even wrote: > Monty, > I am not sure why you are saying that my position =A0is " I don't want th= e > IETF to be involved in royalty-free codecs or open transport in any way". > This is not what I anm saying I apologize; I know only what I've read on the list and from the IETF list archives. It's been hard to escape the conclusion that you're not and have not been particularly supportive of the idea in general. > What I am saying is that people coming to the IETF asking for royalty fre= e > and open transport should support it with their technology before asking > others to provide it for their use. We (Xiph) are able and willing to do this. I believe others are also able and becoming more willing. What I wanted to avoid doing was pushing our specific codecs and transports as the only possible solution as they're not. We also have a next generation with the first new codec ready to 'pop', and now is a wonderful time for it to see wide, detailed review. We're certainly adding everything we have to the basket. Monty From hoene@uni-tuebingen.de Sat Jun 20 11:41:48 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 C15F63A6A49 for ; Sat, 20 Jun 2009 11:41:48 -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 dzOcrj+iV71D for ; Sat, 20 Jun 2009 11:41:48 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id C34643A68CD for ; Sat, 20 Jun 2009 11:41:47 -0700 (PDT) Received: from wm01.uni-tuebingen.de (wm01.uni-tuebingen.de [134.2.3.20]) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n5KIg03B024359 for ; Sat, 20 Jun 2009 20:42:00 +0200 Received: by wm01.uni-tuebingen.de (Postfix, from userid 30) id DFB637241C4; Sat, 20 Jun 2009 20:41:59 +0200 (CEST) Received: from dslb-094-217-122-024.pools.arcor-ip.net (dslb-094-217-122-024.pools.arcor-ip.net [94.217.122.24]) by webmail.uni-tuebingen.de (Horde Framework) with HTTP; Sat, 20 Jun 2009 20:41:59 +0200 Message-ID: <20090620204159.87026mp5rx692p9z@webmail.uni-tuebingen.de> Date: Sat, 20 Jun 2009 20:41:59 +0200 From: "Dr. Christian Hoene" To: codec@ietf.org References: In-Reply-To: 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) 4.3.3 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.0.193; VDF: 7.1.4.118; host: mx05); id=14547-Vd8DBk Subject: Re: [codec] Royalty free is top motivation 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, 20 Jun 2009 18:41:48 -0000 > Just to make it clear, royalty free was one of the top motivations > and should probably be the main requirement for the Internet codec. Isn't "royalty free" just a means to an end? Are Jean-Marc (and hopefully many others) not motivated to provide all users telephony at superb quality no mather whether the users can afford to pay for IPRs or for a lot of bandwidth? Or do I get it wrong? Cheers, Christian From stefan.sayer@iptego.com Sat Jun 20 14:34:25 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 1F84E3A6D4F for ; Sat, 20 Jun 2009 14:34:25 -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 O3qlG+5iljLL for ; Sat, 20 Jun 2009 14:34:24 -0700 (PDT) Received: from mail.iptego.net (home2.iptego.net [78.46.32.212]) by core3.amsl.com (Postfix) with ESMTP id 91A053A6D4B for ; Sat, 20 Jun 2009 14:34:11 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.iptego.net (Postfix) with ESMTP id 354841154094; Sat, 20 Jun 2009 23:34:24 +0200 (CEST) Received: from mail.iptego.net ([127.0.0.1]) by localhost (home2.iptego.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1uiRiKiU4ifG; Sat, 20 Jun 2009 23:34:24 +0200 (CEST) Received: from [192.168.10.100] (91-64-178-44-dynip.superkabel.de [91.64.178.44]) by mail.iptego.net (Postfix) with ESMTPSA id E270B1154038; Sat, 20 Jun 2009 23:34:23 +0200 (CEST) Message-ID: <4A3D55E0.6050509@iptego.com> Date: Sat, 20 Jun 2009 23:34:24 +0200 From: Stefan Sayer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090302 Lightning/0.9 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Randell Jesup References: <4A3AE894.70001@usherbrooke.ca> <000401c9f0b8$3948a280$abd9e780$@de> <20090619032841.2122362oqyhc3k2h@mail.skype.net> <000d01c9f0d3$06b2da00$14188e00$@de> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] Include Dejitter Buffer? WAS RE: RE : Codec BOF approved, much work needed 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, 20 Jun 2009 21:34:25 -0000 o Randell Jesup [06/19/09 16:24]: > "Christian Hoene" writes: >> [132] Y. J. Liang, N. F¨arber, and B. Girod, “Adaptive playout scheduling >> and loss concealment for voice communication over IP networks,†IEEE >> Transactions on Multimedia, vol. 5, no. 4, pp. 532–543, Dec. 2003. >> [135] F. Liu, J. Kim, and C.-C. J. Kuo, “Adaptive delay concealment for >> internet voice applications with packet-based time-scale modification,†in >> IEEE International Conference on Acoustics, Speech, and Signal Processing >> (ICASSP ’01), vol. 3, May 2001, pp. 1461–1464. > ... >> To my understanding, a modern dejittering buffer uses a similar algorithm as >> described in [132] and [135] and is >> a) medium specific (e.g., can only be used for audio) >> b) might be codec-depended if its implementation shall be computational >> efficient. > > Agreed: adaptive, media-specific. I can see knowledge of the codec > being useful, though that could be parameterized -- i.e. tell the jitter > buffer about the characteristics of the codec to let it adjust > tradeoffs, like the tradeoff between delay and loss. For example, some > codecs might be fairly insensitive to one-packet losses, and the buffer > might crank down delay, while with another codec there may be less > redundant information in surrounding packets, and thus you might > increase delay slightly if it reduces late-packet "losses" due tosilence > jitter. What you mention is not the only reason why dejittering and decoding is not independent. Like with PLC, it may be possible to stretch and compress the audio much more efficiently in the decoder than in an independent (even if parametrized) dejitter buffer working on the decoded audio: first, if the codec already uses and transmits voice activity information, the time point to stretch/compress may be chosen much more efficiently, and second, by using and modifying the filter coefficients the actual stretch/compress operations may be done more efficiently. So, it is not sufficient to have information about the codec. The decoding engine is optimally involved directly in the dejitter process. Best Regards Stefan > > Note that much of this is a true matter of heuristic tuning, and the > tradeoffs can be application-dependent as well. Those are big obstacles > to embedding a jitter buffer model in a codec definition (or > standardizing them at all). > >> A couple of ETSI's VoIP performance tests have shown that the best VoIP >> phones do use time stretching and shrinking algorithms to lower the impact >> of playout adjustments. > > That would match my understanding and experience. > From koen.vos@skype.net Sat Jun 20 16:08:52 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 298D43A67B2 for ; Sat, 20 Jun 2009 16:08:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.006 X-Spam-Level: X-Spam-Status: No, score=-6.006 tagged_above=-999 required=5 tests=[AWL=0.593, 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 65RgVVv26nzY for ; Sat, 20 Jun 2009 16:08:51 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id E40543A6C54 for ; Sat, 20 Jun 2009 16:08:50 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 7F0FF2007AAA9 for ; Sun, 21 Jun 2009 01:09:03 +0200 (CEST) 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=OfdzQ9Lze5/S LWvwckcBkm5RtXM=; b=JmvjC/9OMRhq5j1VMRmQpdNNT4FAsfy8eZGzc9YrF4xD cxwIn4665Hti/pA6KND+T4/fC0B5ultA4vndtXrXRBSBtQCoXdDg7OvZU1hyFnfN oYr5ZzQai+62vnMChedzCZZjG0dNDxWG74+FiBAyPJNgTuY//lHhJoE/bBIA4tY= 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=P3Nin1+ogEDGzZkd982q oV+EzSUFglG6gImtPCjbSNHzKMXThvcfs6tpXI9OWKHMoP2PGzt1BvCLaso7TF80 0eEm13JmuBFnIArKeEyhhJexk8qLOJETaOwGu2sC05bq+MC+RYOEEZZ5itLEt7nE Ahev/UK1ncm0qlcy1YPxnQ8= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 7DA082007A56F for ; Sun, 21 Jun 2009 01:09:03 +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 hWJ+dWlTdHvX for ; Sun, 21 Jun 2009 01:09:02 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 9A1C42007A7EE; Sun, 21 Jun 2009 01:09:02 +0200 (CEST) Received: from adsl-71-141-96-214.dsl.snfc21.pacbell.net (adsl-71-141-96-214.dsl.snfc21.pacbell.net [71.141.96.214]) by mail.skype.net (Horde Framework) with HTTP; Sat, 20 Jun 2009 16:09:02 -0700 Message-ID: <20090620160902.70384ir39ldbo4jy@mail.skype.net> Date: Sat, 20 Jun 2009 16:09:02 -0700 From: Koen Vos To: codec@ietf.org References: <4A3AE894.70001@usherbrooke.ca> <000401c9f0b8$3948a280$abd9e780$@de> <20090619032841.2122362oqyhc3k2h@mail.skype.net> <000d01c9f0d3$06b2da00$14188e00$@de> <4A3D55E0.6050509@iptego.com> In-Reply-To: <4A3D55E0.6050509@iptego.com> 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.4) Subject: Re: [codec] Include Dejitter Buffer? WAS RE: RE : Codec BOF approved, much work needed 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, 20 Jun 2009 23:08:52 -0000 Quoting Stefan Sayer: > What you mention is not the only reason why dejittering and decoding > is not independent. Like with PLC, it may be possible to stretch and > compress the audio much more efficiently in the decoder than in an > independent (even if parametrized) dejitter buffer working on the > decoded audio: first, if the codec already uses and transmits voice > activity information, the time point to stretch/compress may be > chosen much more efficiently, Absolutely, that's common practice. But easily parametrized between the jitter buffer module and the decoder + Packet Loss Concealment. The decoder could for example inform the jitter buffer of the voice activity in the last decoded payload. > and second, by using and modifying the filter coefficients the > actual stretch/compress operations may be done more efficiently. Sure, but that's just PLC-internal, not related to the jitter buffer. Fundamentally, the PLC deals with the signal, and the jitter buffer deals with packets. The PLC is optimized towards the codec, the jitter buffer towards the application/platform/protocol/network. koen. From stephane.proust@orange-ftgroup.com Mon Jun 22 11:22:47 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 5867628C24F for ; Mon, 22 Jun 2009 11:22:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_55=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 rZnY0G8zrcfM for ; Mon, 22 Jun 2009 11:22:46 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id C1DE128C24C for ; Mon, 22 Jun 2009 11:22:45 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Mon, 22 Jun 2009 20:22:59 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 22 Jun 2009 20:22:57 +0200 Message-ID: <4D1AA2A55522044480C9B9CF97A93409243A73@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acnw9wvlJSthJC2UQvuyq5f4XSrVjwCWQx8A References: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com> From: To: , X-OriginalArrivalTime: 22 Jun 2009 18:22:59.0890 (UTC) FILETIME=[78FE1120:01C9F366] Subject: Re: [codec] Codec BOF approved, much work needed 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, 22 Jun 2009 18:22:47 -0000 Hello Roni, All =20 ITU-T and 3GPP have already specified a wide portfolio of speech & audio = codecs including Royalty Free codecs (for narrowband, wideband, = superwideband...) with purpose to answer the needs of all conversational = services (including new multimedia services over IP) and ensure end to = end interoperability. Many of these codecs are already deployed and = successfully used to answer the requirements of most of all voice = services all over the world (over Circuit Switched, IP and Internet = networks...). New extensions of these codecs have been or are being = standardized to extend the quality towards very high fullband/stereo = quality. With respect to the end to end interoperability issue, this codec = portfolio is even already too large considering the need to reduce = networks additional costs and quality degradations due to transcoding = operations. Adding new IETF standardized codecs to this (with probably little or no = coordination with other SDOs) would make no sense: those codecs would = obviously compete with the ones from ITU-T or 3GPP and any other legacy = codecs already widely deployed which would confuse the market, degrade = the overall end to end voice&audio interoperability and quality and = increase the transcoding costs in networks.=20 Furthermore, IETF is not the place where sufficient codec expertise is = gathered to standardize state of the art codecs (as in Technical Groups = SA4 of 3GPP or WP3/SG16 of ITU-T) and duplicating the works within = multiple Standard Bodies would not help with creating quality codecs; = this concerns not only the expertise and works needed for codec design = but also all what is related to voice & audio quality assessment. Best regards St=E9phane Proust ________________________________ De : codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] De la part = de Ron Even Envoy=E9 : vendredi 19 juin 2009 17:59 =C0 : codec@ietf.org Objet : Re: [codec] Codec BOF approved, much work needed Cullen, I looked at the agenda =20 1. Administrative (Chairs, 5 min)=20 - Note takers, Jabber scribes - Agenda bashing =20 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min)=20 =20 3. Proposed CODECs (TBD, 25 min)=20 - Expect to have two or more drafts here=20 =20 4. Charter Discussion (All, 40 min)=20 =20 5. Decisions and HUMs (All, 5 min) =20 6. Conclusions and Next Steps (Chairs/ADs, 5 min) =20 =20 =20 And it looks to me that it starts with assumption that we will have a = new working group. =20 I am not sure that that this was agreed and yet I see no time allocated = to discuss the topic. I would expect that item 3 will be rational for = doing codec at the IETF considering that this work is done also by other = SDOs that the IETF is working with. =20 Now even if there will be such a WG starting with proposed CODECS is = like having a solution before the requirements. In other standard bodies = requirements are not just names but they also have values. So what is = the purpose of proposing codecs, do we need to select at the BOF which = one will be standardize, to me it looks like this should be done later. =20 Roni Even=20 =20 =20 =20 =20 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Cullen Jennings > Sent: Friday, June 12, 2009 8:32 PM > To: codec@ietf.org > Subject: [codec] Codec BOF approved, much work needed >=20 >=20 > I have approved the CODEC BOF proposal. However, we need a bunch of > work to get ready. Various people on IESG/IAB were not comfortable > with the current charter and agenda so we need to work on theses > before the meeting. >=20 > A draft agenda/charter Jason provided are at >=20 > Agenda: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt >=20 > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- > bof/charter.txt >=20 > After discussion with the IESG/IAB: >=20 > I'd like to remove the "as Proposed Standard" from the charter text > for both milestones and see how the discussion goes in the BOF before > deciding which way this should go. >=20 > I'd like to see more consideration around the issues of designing a > codec that did a good job of mapping a real time stream onto IP > packets. The way IP deals with packet loss and congestion has > implications for designing a codec that works well over IP. I know > some of the discussion I have had off list people talked about how we > wanted a codec that supported adaptive bit rates that could change on > the fly to be able to work well on an IP network. >=20 > I will be working the folks to make sure the agenda has time to > directly address the key topics which include (more may be coming): >=20 > Will we be able to get qualified people to do and review the work? >=20 > Key design goals of a new codec? >=20 > Do we need a new codec or are there already ones defined that meet the > needs? >=20 > I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. >=20 > Thanks, >=20 > Cullen >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From hsinnrei@adobe.com Mon Jun 22 11:46:32 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 7FA323A6E17 for ; Mon, 22 Jun 2009 11:46:32 -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.398, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=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 3kttEvF9OIUH for ; Mon, 22 Jun 2009 11:46:30 -0700 (PDT) Received: from exprod6og106.obsmtp.com (exprod6og106.obsmtp.com [64.18.1.191]) by core3.amsl.com (Postfix) with ESMTP id EA15D3A6E0F for ; Mon, 22 Jun 2009 11:46:29 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob106.postini.com ([64.18.5.12]) with SMTP ID DSNKSj/RkjX40BSP+rcL39HkW2aDU9bRlMIA@postini.com; Mon, 22 Jun 2009 11:46:46 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5MIeSao004610; Mon, 22 Jun 2009 11:40:28 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5MIcUvZ011080; Mon, 22 Jun 2009 11:46:40 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Mon, 22 Jun 2009 11:46:23 -0700 From: Henry Sinnreich To: "stephane.proust@orange-ftgroup.com" , "ron.even.tlv@gmail.com" , "codec@ietf.org" Date: Mon, 22 Jun 2009 11:46:21 -0700 Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acnw9wvlJSthJC2UQvuyq5f4XSrVjwCWQx8AAAZo778= Message-ID: In-Reply-To: <4D1AA2A55522044480C9B9CF97A93409243A73@ftrdmel0.rd.francetelecom.fr> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C6653BAD4449hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] Codec BOF approved, much work needed 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, 22 Jun 2009 18:46:32 -0000 --_000_C6653BAD4449hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi St=E9phane, I am not sure how much you have followed the list, but did you notice the p= osts regarding one of the top requirements to be royalty free, to our bes= t knowledge (IETF Note Well)? Also this has been discussed at length; and credible and willing experts fo= und wrote: Hello Roni, All ITU-T and 3GPP have already specified a wide portfolio of speech & audio co= decs including Royalty Free codecs (for narrowband, wideband, superwideband= ...) with purpose to answer the needs of all conversational services (inclu= ding new multimedia services over IP) and ensure end to end interoperabilit= y. Many of these codecs are already deployed and successfully used to answe= r the requirements of most of all voice services all over the world (over C= ircuit Switched, IP and Internet networks...). New extensions of these code= cs have been or are being standardized to extend the quality towards very h= igh fullband/stereo quality. With respect to the end to end interoperability issue, this codec portfolio= is even already too large considering the need to reduce networks addition= al costs and quality degradations due to transcoding operations. Adding new IETF standardized codecs to this (with probably little or no coo= rdination with other SDOs) would make no sense: those codecs would obviousl= y compete with the ones from ITU-T or 3GPP and any other legacy codecs alre= ady widely deployed which would confuse the market, degrade the overall end= to end voice&audio interoperability and quality and increase the transcodi= ng costs in networks. Furthermore, IETF is not the place where sufficient codec expertise is gath= ered to standardize state of the art codecs (as in Technical Groups SA4 of = 3GPP or WP3/SG16 of ITU-T) and duplicating the works within multiple Standa= rd Bodies would not help with creating quality codecs; this concerns not on= ly the expertise and works needed for codec design but also all what is rel= ated to voice & audio quality assessment. Best regards St=E9phane Proust ________________________________ De : codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] De la part de R= on Even Envoy=E9 : vendredi 19 juin 2009 17:59 =C0 : codec@ietf.org Objet : Re: [codec] Codec BOF approved, much work needed Cullen, I looked at the agenda 1. Administrative (Chairs, 5 min) - Note takers, Jabber scribes - Agenda bashing 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) 3. Proposed CODECs (TBD, 25 min) - Expect to have two or more drafts here 4. Charter Discussion (All, 40 min) 5. Decisions and HUMs (All, 5 min) 6. Conclusions and Next Steps (Chairs/ADs, 5 min) And it looks to me that it starts with assumption that we will have a new w= orking group. I am not sure that that this was agreed and yet I see no time allocated to = discuss the topic. I would expect that item 3 will be rational for doing co= dec at the IETF considering that this work is done also by other SDOs that = the IETF is working with. Now even if there will be such a WG starting with proposed CODECS is like h= aving a solution before the requirements. In other standard bodies requirem= ents are not just names but they also have values. So what is the purpose o= f proposing codecs, do we need to select at the BOF which one will be stand= ardize, to me it looks like this should be done later. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Cullen Jennings > Sent: Friday, June 12, 2009 8:32 PM > To: codec@ietf.org > Subject: [codec] Codec BOF approved, much work needed > > > I have approved the CODEC BOF proposal. However, we need a bunch of > work to get ready. Various people on IESG/IAB were not comfortable > with the current charter and agenda so we need to work on theses > before the meeting. > > A draft agenda/charter Jason provided are at > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- > bof/charter.txt > > After discussion with the IESG/IAB: > > I'd like to remove the "as Proposed Standard" from the charter text > for both milestones and see how the discussion goes in the BOF before > deciding which way this should go. > > I'd like to see more consideration around the issues of designing a > codec that did a good job of mapping a real time stream onto IP > packets. The way IP deals with packet loss and congestion has > implications for designing a codec that works well over IP. I know > some of the discussion I have had off list people talked about how we > wanted a codec that supported adaptive bit rates that could change on > the fly to be able to work well on an IP network. > > I will be working the folks to make sure the agenda has time to > directly address the key topics which include (more may be coming): > > Will we be able to get qualified people to do and review the work? > > Key design goals of a new codec? > > Do we need a new codec or are there already ones defined that meet the > needs? > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. > > Thanks, > > Cullen > > > > > > _______________________________________________ > 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_C6653BAD4449hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Codec BOF approved, much work needed Hi Stéphane,

I am not sure how much you have followed the list, but did you notice the p= osts regarding one  of the top requirements to be royalty free,  = to our best knowledge (IETF Note Well)?

Also this has been discussed at length; and credible and willing experts fo= und
<IETF is not the place where sufficient codec expertise is gathered to s= tandardize state of the art codecs...

Do we need to recap all these discussions?
The proposed BOF will definitely be very productive in the eyes of its prop= onents.
Strictly IMO, innovation cannot be suppressed on the Internet and it is for= tunate when it can happen in the IETF.

Thanks, Henry


On 6/22/09 1:22 PM, "st= ephane.proust@orange-ftgroup.com" <stephane.proust@orange-ftgroup.com> wrote:

Hello Roni, All

ITU-T and 3GPP have already specified a wide portfolio of speech & audi= o codecs including Royalty Free codecs (for narrowband, wideband, superwide= band...) with purpose to answer the needs of all conversational services (i= ncluding new multimedia services over IP) and ensure end to end interoperab= ility. Many of these codecs are already deployed and successfully used to a= nswer the requirements of most of all voice services all over the world (ov= er Circuit Switched, IP and Internet networks...). New extensions of these = codecs have been or are being standardized to extend the quality towards ve= ry high fullband/stereo quality.

With respect to the end to end interoperability issue, this codec portfolio= is even already too large considering the need to reduce networks addition= al costs and quality degradations due to transcoding operations.

Adding new IETF standardized codecs to this (with probably little or no coo= rdination with other SDOs) would make no sense: those codecs would obviousl= y compete with the ones from ITU-T or 3GPP and any other legacy codecs alre= ady widely deployed which would confuse the market, degrade the overall end= to end voice&audio interoperability and quality and increase the trans= coding costs in networks.

Furthermore, IETF is not the place where sufficient codec expertise is gath= ered to standardize state of the art codecs (as in Technical Groups SA4 of = 3GPP or WP3/SG16 of ITU-T) and duplicating the works within multiple Standa= rd Bodies would not help with creating quality codecs; this concerns not on= ly the expertise and works needed for codec design but also all what is rel= ated to voice & audio quality assessment.

Best regards

Stéphane Proust

________________________________

De : codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] De la= part de Ron Even
Envoyé : vendredi 19 juin 2009 17:59
À : codec@ietf.org
Objet : Re: [codec] Codec BOF approved, much work needed



Cullen,

I looked at the agenda



1. Administrative (Chairs, 5 min)

  - Note takers, Jabber scribes

  - Agenda bashing

 

2. Introduction and Scoping of BOF (Chairs/ADs, 15 min)

 

3. Proposed CODECs (TBD, 25 min)

  - Expect to have two or more drafts here



4. Charter Discussion (All, 40 min)



5. Decisions and HUMs (All, 5 min)



6. Conclusions and Next Steps (Chairs/ADs, 5 min)





And it looks to me that it starts with assumption that we will have a new w= orking group.



I am not sure that that this was agreed and yet I see no time allocated to = discuss the topic. I would expect that item 3 will be rational for doing co= dec at the IETF considering that this work is done also by other SDOs that = the IETF is working with.



Now even if there will be such a WG starting with proposed CODECS is like h= aving a solution before the requirements. In other standard bodies requirem= ents are not just names but they also have values. So what is the purpose o= f proposing codecs, do we need to select at the BOF which one will be stand= ardize, to me it looks like this should be done later.



Roni Even



 





> -----Original Message-----

> From: codec-bounces@ietf.org [<= a href=3D"mailto:codec-bounces@ietf.org">mailto:codec-bounces@ietf.org]= On Behalf

> Of Cullen Jennings

> Sent: Friday, June 12, 2009 8:32 PM

> To: codec@ietf.org

> Subject: [codec] Codec BOF approved, much work needed

>

>

> I have approved the CODEC BOF proposal. However, we need a bunch of
> work to get ready.  Various people on IESG/IAB were not comfortab= le

> with the current charter and agenda so we need to work on theses

> before the meeting.

>

> A draft agenda/charter Jason provided are at

>

> Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.t= xt

>

> Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-

> bof/charter.txt

>

> After discussion with the IESG/IAB:

>

> I'd like to remove the "as Proposed Standard" from the chart= er text

> for both milestones and see how the discussion goes in the BOF before<= BR>
> deciding which way this should go.

>

> I'd like to see more consideration around the issues of designing a
> codec that did a good job of mapping a real time stream onto IP

> packets. The way IP deals with packet loss and congestion has

> implications for designing a codec that works well over IP. I know

> some of the discussion I have had off list people talked about how we<= BR>
> wanted a codec that supported adaptive bit rates that could change on<= BR>
> the fly to be able to work well on an IP network.

>

> I will be working the folks to make sure the agenda has time to

> directly address the key topics which include (more may be coming):
>

> Will we be able to get qualified people to do and review the work?

>

> Key design goals of a new codec?

>

> Do we need a new codec or are there already ones defined that meet the=

> needs?

>

> I have asked Jason Fischl  and Jean-Marc Valin to co-chair this B= OF.

>

> Thanks,

>

> Cullen <RAI AD>

>

>

>

>

>

> _______________________________________________

> codec mailing list

> codec@ietf.org

> https://www.ie= tf.org/mailman/listinfo/codec

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

--_000_C6653BAD4449hsinnreiadobecom_-- From Jean-Marc.Valin@USherbrooke.ca Mon Jun 22 13:02:44 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 131F13A6966 for ; Mon, 22 Jun 2009 13:02:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.186 X-Spam-Level: X-Spam-Status: No, score=-2.186 tagged_above=-999 required=5 tests=[AWL=0.413, 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 uANX5tfsDQtk for ; Mon, 22 Jun 2009 13:02:43 -0700 (PDT) Received: from smtpi5.usherbrooke.ca (smtpi5.usherbrooke.ca [132.210.236.1]) by core3.amsl.com (Postfix) with ESMTP id 3D64D3A68A4 for ; Mon, 22 Jun 2009 13:02:40 -0700 (PDT) Received: from localhost (www03.USherbrooke.ca [132.210.244.10]) by smtpi5.usherbrooke.ca (8.13.8/8.13.8) with ESMTP id n5MK2npL031997; Mon, 22 Jun 2009 16:02:49 -0400 Received: from 70.54.254.106 ([70.54.254.106]) by www.usherbrooke.ca (IMP) with HTTP for ; Mon, 22 Jun 2009 16:02:49 -0400 Message-ID: <1245700969.4a3fe369c54a1@www.usherbrooke.ca> Date: Mon, 22 Jun 2009 16:02:49 -0400 From: Jean-Marc Valin To: stephane.proust@orange-ftgroup.com References: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com> <4D1AA2A55522044480C9B9CF97A93409243A73@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4D1AA2A55522044480C9B9CF97A93409243A73@ftrdmel0.rd.francetelecom.fr> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 70.54.254.106 X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-MailScanner-ID: n5MK2npL031997 X-UdeS-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-7.499, requis 5, autolearn=not spam, BAYES_00 -2.60, RDNS_NONE 0.10, UDES_MONBUREAU01 -5.00) X-UdeS-MailScanner-From: jean-marc.valin@usherbrooke.ca Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 22 Jun 2009 20:02:44 -0000 Hi Stephane, Quoting stephane.proust@orange-ftgroup.com: > ITU-T and 3GPP have already specified a wide portfolio of speech & audio > codecs including Royalty Free codecs (for narrowband, wideband, > superwideband...) Actually, I'm not aware of any codec standardised by the ITU-T and 3GPP in the last 10 years and that doesn't require the licensing of several patents. This is one of the main problems we're trying to address here as patent-encumbered codecs are seriously harming interoperability on the Internet. > Furthermore, IETF is not the place where sufficient codec expertise is > gathered to standardize state of the art codecs (as in Technical Groups SA4 > of 3GPP or WP3/SG16 of ITU-T) As it is, we *already* have several people involved that have sufficient coding expertise and that have already written at least 6 audio codecs (that I know of -- possibly more). > and duplicating the works within multiple > Standard Bodies would not help with creating quality codecs; this concerns > not only the expertise and works needed for codec design but also all what is > related to voice & audio quality assessment. Right now, all these nice ITU codecs are just not available for use in most "Internet-based" applications. Can you find a single free VoIP client that supports AMR-WB or G.729? Any Java applet that uses these codecs? Any browser plugin? We need codecs that can be used without restriction. This is the problem that we are trying to address with this new WG proposal. Cheers, Jean-Marc From herve.taddei@huawei.com Mon Jun 22 13:07:27 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 7E08C3A6AF4 for ; Mon, 22 Jun 2009 13:07:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_55=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 AcvZ0ehTlL2O for ; Mon, 22 Jun 2009 13:07:25 -0700 (PDT) Received: from mailgw2.teleservice.net (mailgw2.teleservice.net [85.30.129.52]) by core3.amsl.com (Postfix) with ESMTP id 307AE3A6966 for ; Mon, 22 Jun 2009 13:07:25 -0700 (PDT) Received: from PCHERVE (host-85-30-163-14.sydskane.nu [85.30.163.14]) by mailgw2.teleservice.net (Postfix) with ESMTP id 93A161AF4C5; Mon, 22 Jun 2009 22:07:39 +0200 (CEST) From: "Herve Taddei" To: "'Henry Sinnreich'" , , , References: <4D1AA2A55522044480C9B9CF97A93409243A73@ftrdmel0.rd.francetelecom.fr> Date: Mon, 22 Jun 2009 22:07:32 +0200 Message-ID: <001c01c9f375$13b8c850$0ea31e55@china.huawei.com> MIME-Version: 1.0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 11 In-reply-to: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-index: Acnw9wvlJSthJC2UQvuyq5f4XSrVjwCWQx8AAAZo778AAcmCcA== Subject: Re: [codec] Codec BOF approved, much work needed 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, 22 Jun 2009 20:07:27 -0000 Dear Henry, > I am not sure how much you have followed the list, but did you notice = the posts=20 > regarding one =A0of the top requirements to be royalty free, =A0to our = best knowledge > (IETF Note Well)? I imagine he did and that is why he is pointing out to: "ITU-T and 3GPP have already specified a wide portfolio of speech & = audio codecs including Royalty Free codecs (for narrowband, wideband, superwideband...)" > Do we need to recap all these discussions?=20 > The proposed BOF will definitely be very productive in the eyes of its proponents. > Strictly IMO, innovation cannot be suppressed on the Internet and it = is fortunate=20 > when it can happen in the IETF. I think one topic to discuss during the BOF meeting should be to = understand why the decision to not standardize audio/speech codecs in IETF taken a = few years ago should be changed. Here is part of the AVT charter: "The group continues to be precluded from work on codecs themselves because of = overlap with the other standards bodies, and because the IETF does not have the ability to effectively review new codecs." Did this situation change?=20 > Strictly IMO, innovation cannot be suppressed on the Internet and it = is fortunate=20 > when it can happen in the IETF. Innovation exists and not only in IETF. I think many codecs from other = SDOs have a lot innovation. Best regards Herve Thanks, Henry On 6/22/09 1:22 PM, "stephane.proust@orange-ftgroup.com" wrote: Hello Roni, All ITU-T and 3GPP have already specified a wide portfolio of speech & audio codecs including Royalty Free codecs (for narrowband, wideband, superwideband...) with purpose to answer the needs of all conversational services (including new multimedia services over IP) and ensure end to = end interoperability. Many of these codecs are already deployed and = successfully used to answer the requirements of most of all voice services all over = the world (over Circuit Switched, IP and Internet networks...). New = extensions of these codecs have been or are being standardized to extend the = quality towards very high fullband/stereo quality. With respect to the end to end interoperability issue, this codec = portfolio is even already too large considering the need to reduce networks = additional costs and quality degradations due to transcoding operations. Adding new IETF standardized codecs to this (with probably little or no coordination with other SDOs) would make no sense: those codecs would obviously compete with the ones from ITU-T or 3GPP and any other legacy codecs already widely deployed which would confuse the market, degrade = the overall end to end voice&audio interoperability and quality and increase = the transcoding costs in networks. Furthermore, IETF is not the place where sufficient codec expertise is gathered to standardize state of the art codecs (as in Technical Groups = SA4 of 3GPP or WP3/SG16 of ITU-T) and duplicating the works within multiple Standard Bodies would not help with creating quality codecs; this = concerns not only the expertise and works needed for codec design but also all = what is related to voice & audio quality assessment. Best regards St=E9phane Proust ________________________________ De : codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] De la part = de Ron Even Envoy=E9 : vendredi 19 juin 2009 17:59 =C0 : codec@ietf.org Objet : Re: [codec] Codec BOF approved, much work needed Cullen, I looked at the agenda 1. Administrative (Chairs, 5 min) =A0=A0- Note takers, Jabber scribes =A0=A0- Agenda bashing =A0 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) =A0 3. Proposed CODECs (TBD, 25 min) =A0=A0- Expect to have two or more drafts here 4. Charter Discussion (All, 40 min) 5. Decisions and HUMs (All, 5 min) 6. Conclusions and Next Steps (Chairs/ADs, 5 min)=20 And it looks to me that it starts with assumption that we will have a = new working group. I am not sure that that this was agreed and yet I see no time allocated = to discuss the topic. I would expect that item 3 will be rational for doing codec at the IETF considering that this work is done also by other SDOs = that the IETF is working with. Now even if there will be such a WG starting with proposed CODECS is = like having a solution before the requirements. In other standard bodies requirements are not just names but they also have values. So what is = the purpose of proposing codecs, do we need to select at the BOF which one = will be standardize, to me it looks like this should be done later. Roni Even =A0 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Cullen Jennings > Sent: Friday, June 12, 2009 8:32 PM > To: codec@ietf.org > Subject: [codec] Codec BOF approved, much work needed > > > I have approved the CODEC BOF proposal. However, we need a bunch of > work to get ready. =A0Various people on IESG/IAB were not comfortable > with the current charter and agenda so we need to work on theses > before the meeting. > > A draft agenda/charter Jason provided are at > > Agenda: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- > bof/charter.txt > > After discussion with the IESG/IAB: > > I'd like to remove the "as Proposed Standard" from the charter text > for both milestones and see how the discussion goes in the BOF before > deciding which way this should go. > > I'd like to see more consideration around the issues of designing a > codec that did a good job of mapping a real time stream onto IP > packets. The way IP deals with packet loss and congestion has > implications for designing a codec that works well over IP. I know > some of the discussion I have had off list people talked about how we > wanted a codec that supported adaptive bit rates that could change on > the fly to be able to work well on an IP network. > > I will be working the folks to make sure the agenda has time to > directly address the key topics which include (more may be coming): > > Will we be able to get qualified people to do and review the work? > > Key design goals of a new codec? > > Do we need a new codec or are there already ones defined that meet the > needs? > > I have asked Jason Fischl =A0and Jean-Marc Valin to co-chair this BOF. > > Thanks, > > Cullen > > > > > > _______________________________________________ > 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 stefan.sayer@iptego.com Mon Jun 22 16:44:43 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 C40A63A6969 for ; Mon, 22 Jun 2009 16:44:43 -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 RUE+IJFPOYi4 for ; Mon, 22 Jun 2009 16:44:42 -0700 (PDT) Received: from mail.iptego.net (home2.iptego.net [78.46.32.212]) by core3.amsl.com (Postfix) with ESMTP id 896883A689B for ; Mon, 22 Jun 2009 16:44:42 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mail.iptego.net (Postfix) with ESMTP id 215651154090; Tue, 23 Jun 2009 01:44:57 +0200 (CEST) Received: from mail.iptego.net ([127.0.0.1]) by localhost (home2.iptego.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a+9TYJyt5gph; Tue, 23 Jun 2009 01:44:57 +0200 (CEST) Received: from [192.168.5.106] (91-64-178-44-dynip.superkabel.de [91.64.178.44]) by mail.iptego.net (Postfix) with ESMTPSA id DC310115407D; Tue, 23 Jun 2009 01:44:56 +0200 (CEST) Message-ID: <4A40177A.1060602@iptego.com> Date: Tue, 23 Jun 2009 01:44:58 +0200 From: Stefan Sayer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090302 Lightning/0.9 Thunderbird/2.0.0.21 Mnenhy/0.7.6.666 MIME-Version: 1.0 To: Koen Vos References: <4A3AE894.70001@usherbrooke.ca> <000401c9f0b8$3948a280$abd9e780$@de> <20090619032841.2122362oqyhc3k2h@mail.skype.net> <000d01c9f0d3$06b2da00$14188e00$@de> <4A3D55E0.6050509@iptego.com> <20090620160902.70384ir39ldbo4jy@mail.skype.net> In-Reply-To: <20090620160902.70384ir39ldbo4jy@mail.skype.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: codec@ietf.org Subject: Re: [codec] Include Dejitter Buffer? WAS RE: RE : Codec BOF approved, much work needed 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, 22 Jun 2009 23:44:43 -0000 o Koen Vos [06/21/09 01:09]: > Quoting Stefan Sayer: >> What you mention is not the only reason why dejittering and decoding >> is not independent. Like with PLC, it may be possible to stretch and >> compress the audio much more efficiently in the decoder than in an >> independent (even if parametrized) dejitter buffer working on the >> decoded audio: first, if the codec already uses and transmits voice >> activity information, the time point to stretch/compress may be chosen >> much more efficiently, > > Absolutely, that's common practice. But easily parametrized between the > jitter buffer module and the decoder + Packet Loss Concealment. The > decoder could for example inform the jitter buffer of the voice activity > in the last decoded payload. > > >> and second, by using and modifying the filter coefficients the actual >> stretch/compress operations may be done more efficiently. > > Sure, but that's just PLC-internal, not related to the jitter buffer. > > Fundamentally, the PLC deals with the signal, and the jitter buffer > deals with packets. The PLC is optimized towards the codec, the jitter > buffer towards the application/platform/protocol/network. so you are saying that the same mechanism which is used for PLC is to be used for time-scale modification of the voice (stretching/compressing) for adaptive playout scheduling like what is used with the method described in the mentioned [135]/[132] ? In my opinion this is only possible if you feed the information about desired length of decoded voice into the decoder (so it can e.g. leave out or add one or more pitch periods), keep a 'backup' decoder state of the previous frame, or add one more frame length of decoding latency - otherwise you can not compress the voice of the previous packet and for stretching its suboptimal. Anyway, this requirement would have to be taken into account for the decoder, and it is a requirement specific to packet switched networks. I f I understood him correctly it is this why Mr. Hoene wants to include the dejitter buffer in. Stefan [132] Y. J. Liang, N. F¨arber, and B. Girod, “Adaptive playout scheduling and loss concealment for voice communication over IP networks,” IEEE Transactions on Multimedia, vol. 5, no. 4, pp. 532–543, Dec. 2003. [135] F. Liu, J. Kim, and C.-C. J. Kuo, “Adaptive delay concealment for internet voice applications with packet-based time-scale modification,” in IEEE International Conference on Acoustics, Speech, and Signal Processing (ICASSP ’01), vol. 3, May 2001, pp. 1461–1464. > > koen. > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec -- Stefan Sayer VoIP Services stefan.sayer@iptego.com www.iptego.com IPTEGO GmbH Wittenbergplatz 1 10789 Berlin Germany Amtsgericht Charlottenburg, HRB 101010 Geschaeftsfuehrer: Alexander Hoffmann From hsinnrei@adobe.com Mon Jun 22 19:01:43 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 F2E403A68AD for ; Mon, 22 Jun 2009 19:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.622 X-Spam-Level: X-Spam-Status: No, score=-5.622 tagged_above=-999 required=5 tests=[AWL=0.376, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=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 X8cQzuShCtqc for ; Mon, 22 Jun 2009 19:01:41 -0700 (PDT) Received: from psmtp.com (exprod6ob114.obsmtp.com [64.18.1.32]) by core3.amsl.com (Postfix) with ESMTP id CFD6E3A6849 for ; Mon, 22 Jun 2009 19:01:40 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob114.postini.com ([64.18.5.12]) with SMTP ID DSNKSkA3lAUzBYLaN94v8xLh4zsxuNckGRuL@postini.com; Mon, 22 Jun 2009 19:01:57 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5N1tfao007207 for ; Mon, 22 Jun 2009 18:55:42 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5N21tiq001293 for ; Mon, 22 Jun 2009 19:01:55 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Mon, 22 Jun 2009 19:01:55 -0700 From: Henry Sinnreich To: "codec@ietf.org" Date: Mon, 22 Jun 2009 19:01:52 -0700 Thread-Topic: [AVT] RFC 5574 on RTP Payload Format for the Speex Codec Thread-Index: Acnzlx2AupiQhwLfS7+8oIyFA1upgAAD3XpS Message-ID: In-Reply-To: <20090623000920.AFDB52D6515@bosco.isi.edu> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C665A1C0446Ehsinnreiadobecom_" MIME-Version: 1.0 Subject: [codec] FW: [AVT] RFC 5574 on RTP Payload Format for the Speex Codec 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, 23 Jun 2009 02:01:43 -0000 --_000_C665A1C0446Ehsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable ------ Forwarded Message From: Date: Mon, 22 Jun 2009 17:09:20 -0700 To: , Cc: , Subject: [AVT] RFC 5574 on RTP Payload Format for the Speex Codec A new Request for Comments is now available in online RFC libraries. RFC 5574 Title: RTP Payload Format for the Speex Codec Author: G. Herlein, J. Valin, A. Heggestad, A. Moizard Status: Standards Track Date: June 2009 Mailbox: gherlein@herlein.com, jean-marc.valin@usherbrooke.ca, aeh@db.org, jack@atosc.org Pages: 14 Characters: 27995 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-rtp-speex-07.txt URL: http://www.rfc-editor.org/rfc/rfc5574.txt Speex is an open-source voice codec suitable for use in VoIP (Voice over IP) type applications. This document describes the payload format for Speex-generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP). [STANDARDS TRACK] This document is a product of the Audio/Video Transport Working Group of th= e IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt ------ End of Forwarded Message --_000_C665A1C0446Ehsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: [AVT] RFC 5574 on RTP Payload Format for the Speex Codec
------ Forwarded Message
From: <rfc-editor@rfc-edito= r.org>
Date: Mon, 22 Jun 2009 17:09:20 -0700
To: <ietf-announce@ietf.org>, <rfc-dist@rfc-editor.org&= gt;
Cc: <avt@ietf.org>, <rfc-editor@rfc-editor.org>
Subject: [AVT] RFC 5574 on RTP Payload Format for the Speex Codec


A new Request for Comments is now available in online RFC libraries.

       
        RFC 5574

        Title:    &n= bsp; RTP Payload Format for the
            &nb= sp;       Speex Codec
        Author:    &= nbsp;G. Herlein, J. Valin,
            &nb= sp;       A. Heggestad, A. Moizard
        Status:    &= nbsp;Standards Track
        Date:    &nb= sp;  June 2009
        Mailbox:    = gherlein@herlein.com,
            &nb= sp;       jean-marc.valin@usherbrooke.ca,
            &nb= sp;       aeh@db.= org, jack@atosc.org
        Pages:    &n= bsp; 14
        Characters: 27995
        Updates/Obsoletes/SeeAlso: =   None

        I-D Tag:    = draft-ietf-avt-rtp-speex-07.txt

        URL:    &nbs= p;   h= ttp://www.rfc-editor.org/rfc/rfc5574.txt

Speex is an open-source voice codec suitable for use in VoIP (Voice
over IP) type applications.  This document describes the payload
format for Speex-generated bit streams within an RTP packet.  Also
included here are the necessary details for the use of Speex with the
Session Description Protocol (SDP).  [STANDARDS TRACK]

This document is a product of the Audio/Video Transport Working Group of th= e IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions=
for improvements.  Please refer to the current edition of the Internet=
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  = http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see ht= tp://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to = rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/= mailman/listinfo/avt


------ End of Forwarded Message
 --_000_C665A1C0446Ehsinnreiadobecom_-- From hoene@uni-tuebingen.de Tue Jun 23 00:00: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 E9EED3A684C for ; Tue, 23 Jun 2009 00:00:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, J_CHICKENPOX_55=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 1cbrf7g3opAT for ; Tue, 23 Jun 2009 00:00: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 55A713A68ED for ; Tue, 23 Jun 2009 00:00:47 -0700 (PDT) Received: from hoeneLenovoT60 (u-172-c216.cs.uni-tuebingen.de [134.2.172.216]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n5N70t33016477 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Jun 2009 09:00:56 +0200 From: "Christian Hoene" To: "'Henry Sinnreich'" , , , References: <4D1AA2A55522044480C9B9CF97A93409243A73@ftrdmel0.rd.francetelecom.fr> In-Reply-To: Date: Tue, 23 Jun 2009 09:00:55 +0200 Message-ID: <002c01c9f3d0$5b9af980$12d0ec80$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C9F3E1.1F23C980" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnw9wvlJSthJC2UQvuyq5f4XSrVjwCWQx8AAAZo778AGBXz4A== 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.0.193; VDF: 7.1.4.126; host: mx05); id=19719-cYV3cu Subject: Re: [codec] Codec BOF approved, much work needed 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, 23 Jun 2009 07:01:00 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C9F3E1.1F23C980 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, =20 if you plan to do something innovative and to develop a disruptive technology, it is better to give it a new name. May be the naming of = this working group should be reconsidered.=20 If it would not be named =93codec=94 but something else like audio layer = or xyz protocol framework, we will have some advantages =20 First, we would not end up doing the old codec standardization and its = old traditions but try to think on how to achieve a superb interactive audio transmission for all Internet users. We would get more freedom in going = new ways and need to fall into the trap that the traditional coding experts = say: =93If you want to make a codec, you have it to do it like that=85=94 =20 Second, the 3GPP and ITU codec guys would not worry as much. We could = say, =93No we are not doing just a codec, we are developing the Internet=92s = audio layer. It=92s something different.=94=20 =20 If this WG will then end up in rubberstamping CELT, adding some = congestion control or even a dejittering buffer, or following an entirely new, = clean slate design of a codec, is anyhow up to its proponents. =20 With best regards, =20 Christan =20 =20 =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Henry Sinnreich Sent: Monday, June 22, 2009 8:46 PM To: stephane.proust@orange-ftgroup.com; ron.even.tlv@gmail.com; codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed =20 Hi St=E9phane, I am not sure how much you have followed the list, but did you notice = the posts regarding one of the top requirements to be royalty free, to our best knowledge (IETF Note Well)? Also this has been discussed at length; and credible and willing experts found wrote: Hello Roni, All ITU-T and 3GPP have already specified a wide portfolio of speech & audio codecs including Royalty Free codecs (for narrowband, wideband, superwideband...) with purpose to answer the needs of all conversational services (including new multimedia services over IP) and ensure end to = end interoperability. Many of these codecs are already deployed and = successfully used to answer the requirements of most of all voice services all over = the world (over Circuit Switched, IP and Internet networks...). New = extensions of these codecs have been or are being standardized to extend the = quality towards very high fullband/stereo quality. With respect to the end to end interoperability issue, this codec = portfolio is even already too large considering the need to reduce networks = additional costs and quality degradations due to transcoding operations. Adding new IETF standardized codecs to this (with probably little or no coordination with other SDOs) would make no sense: those codecs would obviously compete with the ones from ITU-T or 3GPP and any other legacy codecs already widely deployed which would confuse the market, degrade = the overall end to end voice&audio interoperability and quality and increase = the transcoding costs in networks. Furthermore, IETF is not the place where sufficient codec expertise is gathered to standardize state of the art codecs (as in Technical Groups = SA4 of 3GPP or WP3/SG16 of ITU-T) and duplicating the works within multiple Standard Bodies would not help with creating quality codecs; this = concerns not only the expertise and works needed for codec design but also all = what is related to voice & audio quality assessment. Best regards St=E9phane Proust ________________________________ De : codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] De la part = de Ron Even Envoy=E9 : vendredi 19 juin 2009 17:59 =C0 : codec@ietf.org Objet : Re: [codec] Codec BOF approved, much work needed Cullen, I looked at the agenda 1. Administrative (Chairs, 5 min) - Note takers, Jabber scribes - Agenda bashing =20 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) =20 3. Proposed CODECs (TBD, 25 min) - Expect to have two or more drafts here 4. Charter Discussion (All, 40 min) 5. Decisions and HUMs (All, 5 min) 6. Conclusions and Next Steps (Chairs/ADs, 5 min)=20 And it looks to me that it starts with assumption that we will have a = new working group. I am not sure that that this was agreed and yet I see no time allocated = to discuss the topic. I would expect that item 3 will be rational for doing codec at the IETF considering that this work is done also by other SDOs = that the IETF is working with. Now even if there will be such a WG starting with proposed CODECS is = like having a solution before the requirements. In other standard bodies requirements are not just names but they also have values. So what is = the purpose of proposing codecs, do we need to select at the BOF which one = will be standardize, to me it looks like this should be done later. Roni Even =20 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Cullen Jennings > Sent: Friday, June 12, 2009 8:32 PM > To: codec@ietf.org > Subject: [codec] Codec BOF approved, much work needed > > > I have approved the CODEC BOF proposal. However, we need a bunch of > work to get ready. Various people on IESG/IAB were not comfortable > with the current charter and agenda so we need to work on theses > before the meeting. > > A draft agenda/charter Jason provided are at > > Agenda: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- > bof/charter.txt > > After discussion with the IESG/IAB: > > I'd like to remove the "as Proposed Standard" from the charter text > for both milestones and see how the discussion goes in the BOF before > deciding which way this should go. > > I'd like to see more consideration around the issues of designing a > codec that did a good job of mapping a real time stream onto IP > packets. The way IP deals with packet loss and congestion has > implications for designing a codec that works well over IP. I know > some of the discussion I have had off list people talked about how we > wanted a codec that supported adaptive bit rates that could change on > the fly to be able to work well on an IP network. > > I will be working the folks to make sure the agenda has time to > directly address the key topics which include (more may be coming): > > Will we be able to get qualified people to do and review the work? > > Key design goals of a new codec? > > Do we need a new codec or are there already ones defined that meet the > needs? > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. > > Thanks, > > Cullen > > > > > > _______________________________________________ > 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 ------=_NextPart_000_002D_01C9F3E1.1F23C980 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Codec BOF approved, much work needed

Hi all,

 

if you plan to do something innovative and to develop a = disruptive technology, it is better to give it a new name. May be the naming of = this working group should be reconsidered.

If it would not be named “codec” but = something else like audio layer or xyz protocol framework, we will have some = advantages

 

First, we would not end up doing the old codec = standardization and its old traditions but try to think on how to achieve a superb = interactive audio transmission for all Internet users. We would get more freedom in = going new ways and need to fall into the trap that the traditional coding = experts say: “If you want to make a codec, you have it to do it like = that…”

 

Second, the 3GPP and ITU codec guys would not worry as = much. We could say, “No we are not doing just a codec, we are developing = the Internet’s audio layer. It’s something different.” =

 

If this WG will then end up in rubberstamping CELT, = adding some congestion control or even a dejittering buffer, or following an = entirely new, clean slate design of a codec, is anyhow up to its = proponents.

 

With best regards,

 

=A0Christan

 

 

 

From:= codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Henry Sinnreich
Sent: Monday, June 22, 2009 8:46 PM
To: stephane.proust@orange-ftgroup.com; ron.even.tlv@gmail.com; codec@ietf.org
Subject: Re: [codec] Codec BOF approved, much work = needed

 

Hi St=E9phane,

I am not sure how much you have followed the list, but did you notice = the posts regarding one  of the top requirements to be royalty free,  to = our best knowledge (IETF Note Well)?

Also this has been discussed at length; and credible and willing experts = found
<IETF is not the place where sufficient codec expertise is gathered = to standardize state of the art codecs...

Do we need to recap all these discussions?
The proposed BOF will definitely be very productive in the eyes of its proponents.
Strictly IMO, innovation cannot be suppressed on the Internet and it is fortunate when it can happen in the IETF.

Thanks, Henry


On 6/22/09 1:22 PM, "stephane.proust@orange-ftgrou= p.com" <stephane.proust@orange-ftgrou= p.com> wrote:

Hello Roni, All

ITU-T and 3GPP have already specified a wide portfolio of speech & = audio codecs including Royalty Free codecs (for narrowband, wideband, superwideband...) with purpose to answer the needs of all conversational services (including new multimedia services over IP) and ensure end to = end interoperability. Many of these codecs are already deployed and = successfully used to answer the requirements of most of all voice services all over = the world (over Circuit Switched, IP and Internet networks...). New = extensions of these codecs have been or are being standardized to extend the quality = towards very high fullband/stereo quality.

With respect to the end to end interoperability issue, this codec = portfolio is even already too large considering the need to reduce networks = additional costs and quality degradations due to transcoding operations.

Adding new IETF standardized codecs to this (with probably little or no coordination with other SDOs) would make no sense: those codecs would = obviously compete with the ones from ITU-T or 3GPP and any other legacy codecs = already widely deployed which would confuse the market, degrade the overall end = to end voice&audio interoperability and quality and increase the = transcoding costs in networks.

Furthermore, IETF is not the place where sufficient codec expertise is = gathered to standardize state of the art codecs (as in Technical Groups SA4 of = 3GPP or WP3/SG16 of ITU-T) and duplicating the works within multiple Standard = Bodies would not help with creating quality codecs; this concerns not only the expertise and works needed for codec design but also all what is related = to voice & audio quality assessment.

Best regards

St=E9phane Proust

________________________________

De : codec-bounces@ietf.org [mailto:codec-bounces@ietf.org]= De la part de Ron Even
Envoy=E9 : vendredi 19 juin 2009 17:59
=C0 : codec@ietf.org
Objet : Re: [codec] Codec BOF approved, much work needed



Cullen,

I looked at the agenda



1. Administrative (Chairs, 5 min)

  - Note takers, Jabber scribes

  - Agenda bashing

 

2. Introduction and Scoping of BOF (Chairs/ADs, 15 min)

 

3. Proposed CODECs (TBD, 25 min)

  - Expect to have two or more drafts here



4. Charter Discussion (All, 40 min)



5. Decisions and HUMs (All, 5 min)



6. Conclusions and Next Steps (Chairs/ADs, 5 min)





And it looks to me that it starts with assumption that we will have a = new working group.



I am not sure that that this was agreed and yet I see no time allocated = to discuss the topic. I would expect that item 3 will be rational for doing = codec at the IETF considering that this work is done also by other SDOs that = the IETF is working with.



Now even if there will be such a WG starting with proposed CODECS is = like having a solution before the requirements. In other standard bodies requirements are not just names but they also have values. So what is = the purpose of proposing codecs, do we need to select at the BOF which one = will be standardize, to me it looks like this should be done later.



Roni Even



 





> -----Original Message-----

> From: codec-bounces@ietf.org = [mailto:codec-bounces@ietf.org]= On Behalf

> Of Cullen Jennings

> Sent: Friday, June 12, 2009 8:32 PM

> To: codec@ietf.org

> Subject: [codec] Codec BOF approved, much work needed

>

>

> I have approved the CODEC BOF proposal. However, we need a bunch = of

> work to get ready.  Various people on IESG/IAB were not = comfortable

> with the current charter and agenda so we need to work on = theses

> before the meeting.

>

> A draft agenda/charter Jason provided are at

>

> Agenda: = http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt

>

> Charter: http://svn.res= iprocate.org/rep/ietf-drafts/codec-

> bof/charter.txt

>

> After discussion with the IESG/IAB:

>

> I'd like to remove the "as Proposed Standard" from the = charter text

> for both milestones and see how the discussion goes in the BOF = before

> deciding which way this should go.

>

> I'd like to see more consideration around the issues of designing = a

> codec that did a good job of mapping a real time stream onto IP

> packets. The way IP deals with packet loss and congestion has

> implications for designing a codec that works well over IP. I = know

> some of the discussion I have had off list people talked about how = we

> wanted a codec that supported adaptive bit rates that could change = on

> the fly to be able to work well on an IP network.

>

> I will be working the folks to make sure the agenda has time to

> directly address the key topics which include (more may be = coming):

>

> Will we be able to get qualified people to do and review the = work?

>

> Key design goals of a new codec?

>

> Do we need a new codec or are there already ones defined that meet = the

> needs?

>

> I have asked Jason Fischl  and Jean-Marc Valin to co-chair = this BOF.

>

> Thanks,

>

> Cullen <RAI AD>

>

>

>

>

>

> _______________________________________________

> 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

------=_NextPart_000_002D_01C9F3E1.1F23C980-- From koen.vos@skype.net Tue Jun 23 01:55:47 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 3D7663A6B98 for ; Tue, 23 Jun 2009 01:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.08 X-Spam-Level: X-Spam-Status: No, score=-6.08 tagged_above=-999 required=5 tests=[AWL=0.519, 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 sTkdtymvJ5-g for ; Tue, 23 Jun 2009 01:55:46 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id D09883A6B1F for ; Tue, 23 Jun 2009 01:55:45 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 07D3F2007A78E for ; Tue, 23 Jun 2009 10:56:00 +0200 (CEST) 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=YF6g8DYyYMLT w35t2qJ52vxB0Ak=; b=YgRBQ0TBDYkRFgOCtenHxkYE1sNWAI1kx0adR7pXgGmO cIYyCHIb8oatiU9/7S7KfP4JEtfz8A2eANeds3+uOYSUIDWbRebYlEZaEslT5Eha 41MRpAvZ1Kkn6JpgrOU41Y2cH0cyMuE7cHxAUM23YTEXc1xEbx5v8PBv3pjZbBI= 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=l1QbtPsikvm9EH9q4JGO wm6EA/rRXK7gZkU9xvOq1UEgj2a5wbIKcG4fj9p34tQvLt3VStL2IxPXx0+KSxt/ oPuEIHDP3Fjw7stkU2TLEd5t9crIUtNp9LUm5hKH/2313+QE9vxZl7UX0M+4wQP7 puXCbxeDhtiYwm9oeOhfD60= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 0648C20075BD5 for ; Tue, 23 Jun 2009 10:56:00 +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 PMPxNYjcym0c for ; Tue, 23 Jun 2009 10:55:59 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 2C10C2007A79F; Tue, 23 Jun 2009 10:55:59 +0200 (CEST) Received: from adsl-71-141-96-214.dsl.snfc21.pacbell.net (adsl-71-141-96-214.dsl.snfc21.pacbell.net [71.141.96.214]) by mail.skype.net (Horde Framework) with HTTP; Tue, 23 Jun 2009 01:55:59 -0700 Message-ID: <20090623015559.110317ifa41qvxcv@mail.skype.net> Date: Tue, 23 Jun 2009 01:55:59 -0700 From: Koen Vos To: codec@ietf.org References: <4A3AE894.70001@usherbrooke.ca> <000401c9f0b8$3948a280$abd9e780$@de> <20090619032841.2122362oqyhc3k2h@mail.skype.net> <000d01c9f0d3$06b2da00$14188e00$@de> <4A3D55E0.6050509@iptego.com> <20090620160902.70384ir39ldbo4jy@mail.skype.net> <4A40177A.1060602@iptego.com> In-Reply-To: <4A40177A.1060602@iptego.com> 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.4) Subject: Re: [codec] Include Dejitter Buffer? WAS RE: RE : Codec BOF approved, much work needed 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, 23 Jun 2009 08:55:47 -0000 Quoting Stefan Sayer: > so you are saying that the same mechanism which is used for PLC is > to be used for time-scale modification of the voice > (stretching/compressing) for adaptive playout scheduling like what > is used with the method described in the mentioned [135]/[132] ? The kind of operations going on in a PLC are similar to those used for time stretching/compression. But perhaps Loss and Jitter Concealment (LJC) would be a better name for such a module. In any case, I agree that such time scaling, at least in a basic form, should be a requirement for the decoder specification. It makes the codec more suitable for packet networks with unreliable delivery times. It's a shame that, despite the rigorous standardization process, ITU standards lack such functionality. > Anyway, this requirement would have to be taken into account for the > decoder, and it is a requirement specific to packet switched > networks. I f I understood him correctly it is this why Mr. Hoene > wants to include the dejitter buffer in. Right, seems like we're just talking about terminology: besides an LJC there is a need for a packet buffer and control mechanism that decides when to conceal, stretch or compress. This functionality does not belong in a codec or its specification, in my opinion. best, koen. From hoene@uni-tuebingen.de Tue Jun 23 04:08:01 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 4A47B3A67A6 for ; Tue, 23 Jun 2009 04:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.148 X-Spam-Level: X-Spam-Status: No, score=-6.148 tagged_above=-999 required=5 tests=[AWL=0.100, 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 gkn1skjNHeHT for ; Tue, 23 Jun 2009 04:07:53 -0700 (PDT) Received: from mx05.uni-tuebingen.de (mx05.uni-tuebingen.de [134.2.3.4]) by core3.amsl.com (Postfix) with ESMTP id 139593A6B85 for ; Tue, 23 Jun 2009 04:07:52 -0700 (PDT) Received: from hoeneLenovoT60 (u-172-c216.cs.uni-tuebingen.de [134.2.172.216]) (authenticated bits=0) by mx05.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n5NB832F003676 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Jun 2009 13:08:03 +0200 From: "Christian Hoene" To: "'Sandy \(Alexander\) MacInnis'" , References: <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> <568A92CB079CCF43BA5C8D7B08BCB4AE8150B554D6@SJEXCHCCR02.corp.ad.broadcom.com> In-Reply-To: <568A92CB079CCF43BA5C8D7B08BCB4AE8150B554D6@SJEXCHCCR02.corp.ad.broadcom.com> Date: Tue, 23 Jun 2009 13:08:03 +0200 Message-ID: <006701c9f3f2$e177a680$a466f380$@de> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0068_01C9F403.A5007680" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnw+gkTHL2SdLtVTDiF20h8Qld27QADaHaAAC7D3rEAAEzEwACLWUhA 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.0.193; VDF: 7.1.4.127; host: mx05); id=19719-JlSaod Subject: [codec] Procedure on how to deal with "submarine" patents? 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, 23 Jun 2009 11:08:01 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0068_01C9F403.A5007680 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear Sandy, what do you think? How large is probability, that CELT is covered by patents, what we are not aware of? I just remember the patent struggle with the GIF file format (http://en.wikipedia.org/wiki/Graphics_Interchange_Format), for which Unisys requested license fees after the format was spread widely (refer also to http://en.wikipedia.org/wiki/Submarine_patent) Should a procedure be considered and described in the standard, on how to act if the assumed to be royalty free codec is not free anymore? I am just thinking of some kind of updating the codec software that MUST be supported. Regards, Christian From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Sandy (Alexander) MacInnis Sent: Saturday, June 20, 2009 6:52 PM To: codec@ietf.org Subject: Re: [codec] Royalty free is top motivation That sounds great. I'd like to point a few things that may or may not be obvious to everyone here. I'm not a lawyer; this is an engineer's description (mine), so don't take this a legal advice. I'm pretty familiar with patents, however. A potentially major problem with trying to make something royalty-free with certainty, is the possibility of existing patents that may be infringed by the "free" technology. There are lots of patents out there. Even if someone sat all by him/herself and created a codec from scratch, with or without referring to any textbooks, journal articles, or openly available source code, and the publishes the codec and declares that it's free to the world, that does not mean that it does not infringe on anyone's patents. This is true whether or not the creator of the codec files any patent applications on the work. If such a codec is published and used, a holder of a patent may wait until there is widespread use of the codec, and then sue whoever they want. A deep-pockets company may make an attractive target. That could be a significant problem. For that reason, something that is thought to be royalty-free may turn out not to be royalty free after all. It could go from seemingly free to quite expensive rather quickly, or it could even be dropped by major companies, or even opposed by them in advance. It's difficult, but not quite impossible, to avoid this problem. Some standards groups try to avoid this problem by asking contributors to declare what they know about any existing or planned patent coverage that may cover their submission, and ask contributors who have their own patents to indicate on what terms they will license the patents. That may help a lot, but it may not solve the problem. For one thing, contributors may not know about patents that their method might infringe - often they don't know. There might also be some legal wrangling over the final terms for royalty-free licensing of patents held by contributors. Another way is to study very carefully all the patents that could possibly be infringed, for each one, either work around it or see that the patent has already expired. This is very hard to do, but it can be done. This does not mean that everyone wanting to implement a codec that's said to be royalty free has to read contracts. It would help however if someone had done some diligence on sorting this out before the codec is published. With suitable public licenses, it should be possible for all the world's users to be confident that a codec is royalty-free, while also being high quality, interoperable, open source, and a published standard. --Sandy _____ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Henry Sinnreich Sent: Saturday, June 20, 2009 12:18 PM To: Roni Even; codec@ietf.org Subject: [codec] Royalty free is top motivation Roni, (Topic changed for focus) Roni, Just to make it clear, royalty free was one of the top motivations and should probably be the main requirement for the Internet codec. Interoperability with existing codecs is nice, but IMHO a secondary order requirement, given that most interactive communications are already on the Internet and will be so even more in the future. Vendors and operators are always free to include some other codecs and let SIP do the codec negotiation - that's what it is for in SIP. Henry [... remainder of thread deleted for brevity...] ------=_NextPart_000_0068_01C9F403.A5007680 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Royalty free is top motivation

Dear Sandy,

 

what do you think? How large is probability, that CELT is = covered by patents, what we are not aware of?

 

I just remember the patent struggle with the GIF file = format (http://= en.wikipedia.org/wiki/Graphics_Interchange_Format), for which Unisys requested license fees after the format was spread = widely (refer also to = http://en.wikipedia.org/wiki/Submarine_patent)

 

Should a procedure be considered and described in the = standard, on how to act if the assumed to be royalty free codec is not free = anymore?

 

I am just thinking of some kind of updating the codec = software that MUST be supported…

 

Regards,

 

 Christian

 

 

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Sandy (Alexander) = MacInnis
Sent: Saturday, June 20, 2009 6:52 PM
To: codec@ietf.org
Subject: Re: [codec] Royalty free is top = motivation

 

That sounds great.

 

I'd like to point a few things that may or may not be = obvious to everyone here. I'm not a lawyer; this is an engineer's description = (mine), so don't take this a legal advice. I'm pretty familiar with patents, = however.

 

A potentially major problem with trying to make something royalty-free with certainty, is the possibility of existing patents that = may be infringed by the "free" technology. There are lots of patents = out there.

 

Even if someone sat all by him/herself and created a codec = from scratch, with or without referring to any textbooks, journal articles, = or openly available source code, and the publishes the codec and declares = that it's free to the world, that does not mean that it does not infringe on anyone's patents. This is true whether or not the creator of the codec = files any patent applications on the work.

 

If such a codec is published and used, a holder of a patent = may wait until there is widespread use of the codec, and then sue = whoever they want. A deep-pockets company may make an attractive target. = That could be a significant problem.

 

For that reason, something that is thought to be = royalty-free may turn out not to be royalty free after all. It could go from seemingly = free to quite expensive rather quickly, or it could even be dropped by major = companies, or even opposed by them in advance.

 

It's difficult, but not quite impossible, to avoid this = problem.

 

Some standards groups try to avoid this problem by asking contributors to declare what they know about any existing or planned = patent coverage that may cover their submission, and ask contributors who have = their own patents to indicate on what terms they will license the patents. = That may help a lot, but it may not solve the problem. For one thing, = contributors may not know about patents that their method might infringe - often they = don't know. There might also be some legal wrangling over the final terms for royalty-free licensing of patents held by = contributors.

 

Another way is to study very carefully all the patents that = could possibly be infringed, for each one, either work around it or see that = the patent has already expired. This is very hard to do, but it can be = done.

 

This does not mean that everyone wanting to implement a = codec that's said to be royalty free has to read contracts. It would help = however if someone had done some diligence on sorting this out before the codec is published. With suitable public licenses, it should be possible for all = the world's users to be confident that a codec is royalty-free, while also = being high quality, interoperable, open source, and a published = standard.

 

--Sandy

 

 

From:= codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Henry Sinnreich
Sent: Saturday, June 20, 2009 12:18 PM
To: Roni Even; codec@ietf.org
Subject: [codec] Royalty free is top motivation

Roni,
(Topic changed for focus)

Roni,

Just to make it clear, royalty free was one of the top motivations and = should probably be the main requirement for the Internet codec.

Interoperability with existing codecs is nice, but IMHO a secondary = order requirement, given that most interactive communications are already on the Internet = and will be so even more in the future. Vendors and operators are always free to = include some other codecs and let SIP do the codec negotiation – = that’s what it is for in SIP.

Henry

[... remainder of thread deleted for = brevity...] 

------=_NextPart_000_0068_01C9F403.A5007680-- From stephen.botzko@gmail.com Tue Jun 23 07:18:22 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 482673A6CED for ; Tue, 23 Jun 2009 07:18:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.409 X-Spam-Level: X-Spam-Status: No, score=-1.409 tagged_above=-999 required=5 tests=[AWL=1.189, 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 aRseJG3XC2b5 for ; Tue, 23 Jun 2009 07:18:21 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 304F03A6CE7 for ; Tue, 23 Jun 2009 07:18:21 -0700 (PDT) Received: by fxm9 with SMTP id 9so99558fxm.37 for ; Tue, 23 Jun 2009 07:18:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:content-type; bh=p7petoNul6xhPMNNCaPQAh++IQ5AKTv17ko2POZQU/Q=; b=uEfo3RqXUkQ0xXETUCbwxIhqJAbAYGf6OxrAaXNaY1HYwH4gt1UHQp46/sf0FdV1Lm Hai75fxHR84E7cRpKsxQLawBJZQJUorZpAxfZpnlwIenfyERsbeIh/hzyr2Sbp9o+MNv hGB4e0QTpdlLu2QtO2olq38KHDhZf7n1jBlHA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=blGSlvMPlmWE2F9NXtHgvvQAzDC2uQ2Z0jCKWUdXHBTWOTgGCklAMa+DZ3pIdsvuHR HBDErfyMRwtRGYGZ+HJ8uaESrqbXdkaNRJ3XKjewhNDFsw7dVUlmKG5OM5jy4kG6Ds4D nAV4teiZZtq/xyKWr9crbLg0nP2Sk4isExZCU= MIME-Version: 1.0 Received: by 10.103.226.10 with SMTP id d10mr40023mur.84.1245766714460; Tue, 23 Jun 2009 07:18:34 -0700 (PDT) Date: Tue, 23 Jun 2009 10:18:34 -0400 Message-ID: <6e9223710906230718p2b5cbdaekd98e6aa31ad32874@mail.gmail.com> From: stephen botzko To: codec@ietf.org Content-Type: multipart/alternative; boundary=0016e6dd96a07d0a1a046d04aaf2 Subject: Re: [codec] Codec BOF approved, much work needed 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, 23 Jun 2009 14:18:22 -0000 --0016e6dd96a07d0a1a046d04aaf2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >>> Actually, I'm not aware of any codec standardised by the ITU-T and 3GPP in the last 10 years and that doesn't require the licensing of several patents. This is one of the main problems we're trying to address here as patent-encumbered codecs are seriously harming interoperability on the Internet. >>> G.722.1 is one ITU-T codec is that is available royalty-free, and actually it is quite suitable for use over the internet. G.722.1 is a licensed royalty-free ITU-T standard audio codec providing high quality, moderate bit rate (24 and 32 kbit/s) wideband (50 Hz - 7 kHz audio bandwidth, 16 ksps) audio coding. It is an implementation of Polycom's SIREN7 codec. . G.722.1 Annex C provides twice the audio bandwidth, 14kHz Both were standardized over the past 10 years - G722.1 itself was standardized in September, 1999, and Annex C was standardized in May of 2005. All modes of G.722.1 can be carried over RTP. The fact is that it is *absolutely possible* to standardize royalty-free codecs in the ITU-T through their existing procedures. Polycom has done so twice over the past 10 years. Regards Stephen Botzko Polycom --0016e6dd96a07d0a1a046d04aaf2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
Actually, I'm not aware of any codec standardised by th= e ITU-T and 3GPP in the=20 last 10 years and that doesn't require the licensing of several patents= . This is=20 one of the main problems we're trying to address here as patent-encumbe= red=20 codecs are seriously harming interoperability on the Internet.
>>&= gt;

G.722.1 is one ITU-T codec is that is available royalty-free, an= d actually it is quite suitable for use over the internet.

G.722.1 i= s a licensed royalty-free ITU-T standard audio codec providing high=20 quality, moderate bit rate (24 and 32 kbit/s) wideband (50 Hz - 7 kHz audio= =20 bandwidth, 16 ksps) audio coding. It is an implementation of Polycom's = SIREN7=20 codec. . G.722.1 Annex C=A0 provides twice the audio=20 bandwidth, 14kHz=A0 Both were standardized over the past 10 years - G722.1 = itself was standardized in September, 1999, and Annex C was standardized in= May of 2005.=A0 All modes of G.722.1 can be carried over RTP.

The f= act is that it is absolutely possible to standardize royalty-free co= decs in the ITU-T through their existing procedures.=A0 Polycom has done so= twice over the past 10 years.

Regards
Stephen Botzko
Polycom
--0016e6dd96a07d0a1a046d04aaf2-- From ingemar.s.johansson@ericsson.com Tue Jun 23 10:02:40 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 B953B28C3D9 for ; Tue, 23 Jun 2009 10:02:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.649 X-Spam-Level: X-Spam-Status: No, score=-5.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_55=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 FnZCqHf+1jDY for ; Tue, 23 Jun 2009 10:02:39 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 5D47528C3C2 for ; Tue, 23 Jun 2009 10:02:39 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba8ae0000072d6-ae-4a410abddc2d Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 00.BD.29398.DBA014A4; Tue, 23 Jun 2009 19:02:54 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 23 Jun 2009 19:02:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Jun 2009 19:02:51 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Re: [codec] Codec BOF approved, much work needed Thread-Index: Acn0JHFCFYq9SnTDQ1GiZn+A+p1ozA== From: "Ingemar Johansson S" To: X-OriginalArrivalTime: 23 Jun 2009 17:02:53.0833 (UTC) FILETIME=[72C5B790:01C9F424] X-Brightmail-Tracker: AAAAAA== Cc: Ingemar Johansson S , ron.even@gmail.com Subject: Re: [codec] Codec BOF approved, much work needed 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, 23 Jun 2009 17:02:40 -0000 Hi I support Stephanes opinion on this matter, I fail to see how this WG = (if formed) would add any substantial value. The proposed work clearly = overlaps with already existing work in other SDOs and I see a big risk = with this. Is the IETF willing to take the risk of stepping into other = SDOs areas?, I see this not only as a RAI issue. This should be = discussed at the BoF. Also, I see that the main driver behind this WG is the strive for a = royalty free codec. Reality has however shown that this is much more = complicated to achive than what is believed in the beginning, the BoF = should discuss this issue as well.=20 I would like the BoF chair(s) to provide with ample time to discuss if = this WG should actually be formed, to be honest I don't really see a = need to discuss codec alternatives at the BoF. We should formulate the = problem first, a solution comes later (if needed). Regards Ingemar Johansson =20 >ITU-T and 3GPP have already specified a wide portfolio of speech & = audio codecs including Royalty Free codecs >(for narrowband, wideband, = superwideband...) with purpose to answer the needs of all conversational = services >(including new multimedia services over IP) and ensure end to = end interoperability. Many of these codecs are=20 >already deployed and successfully used to answer the requirements of = most of all voice services all over the=20 >world (over Circuit Switched, IP and Internet networks...). New = extensions of these codecs have been or are=20 >being standardized to extend the quality towards very high = fullband/stereo quality. >With respect to the end to end interoperability issue, this codec = portfolio is even already too large=20 >considering the need to reduce networks additional costs and quality = degradations due to transcoding=20 >operations. >Adding new IETF standardized codecs to this (with probably little or no = coordination with other SDOs) would=20 >make no sense: those codecs would obviously compete with the ones from = ITU-T or 3GPP and any other legacy=20 >codecs already widely deployed which would confuse the market, degrade = the overall end to end voice&audio=20 >interoperability and quality and increase the transcoding costs in = networks.=20 >Furthermore, IETF is not the place where sufficient codec expertise is = gathered to standardize state of the=20 >art codecs (as in Technical Groups SA4 of 3GPP or WP3/SG16 of ITU-T) = and duplicating the works within multiple >Standard Bodies would not = help with creating quality codecs; this concerns not only the expertise = and works=20 >needed for codec design but also all what is related to voice & audio = quality assessment. >Best regards >St=E9phane Proust From hsinnrei@adobe.com Tue Jun 23 10:23:18 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 6B75528C3BC for ; Tue, 23 Jun 2009 10:23:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.642 X-Spam-Level: X-Spam-Status: No, score=-5.642 tagged_above=-999 required=5 tests=[AWL=0.356, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_55=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 5x0ybkttYaOF for ; Tue, 23 Jun 2009 10:23:17 -0700 (PDT) Received: from exprod6og102.obsmtp.com (exprod6og102.obsmtp.com [64.18.1.183]) by core3.amsl.com (Postfix) with ESMTP id DE26A28C3A9 for ; Tue, 23 Jun 2009 10:23:15 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob102.postini.com ([64.18.5.12]) with SMTP ID DSNKSkEPkTzenUSrmCbab4kSI6fKEgTGdnfV@postini.com; Tue, 23 Jun 2009 10:23:33 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5NHHCao020150; Tue, 23 Jun 2009 10:17:12 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5NHNSiP029971; Tue, 23 Jun 2009 10:23:28 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Tue, 23 Jun 2009 10:23:28 -0700 From: Henry Sinnreich To: Ingemar Johansson S , "codec@ietf.org" Date: Tue, 23 Jun 2009 10:23:24 -0700 Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acn0JHFCFYq9SnTDQ1GiZn+A+p1ozAAAt7Dn Message-ID: In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C66679BC449Ehsinnreiadobecom_" MIME-Version: 1.0 Cc: "ron.even@gmail.com" Subject: Re: [codec] Codec BOF approved, much work needed 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, 23 Jun 2009 17:23:18 -0000 --_000_C66679BC449Ehsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sorry to confess, it is now over 10 years when we had similar discussions a= bout forming a SIP WG. H.323 was doing good and the ITU-T took care of multimedia communications. Henry On 6/23/09 12:02 PM, "Ingemar Johansson S" wrote: Hi I support Stephanes opinion on this matter, I fail to see how this WG (if f= ormed) would add any substantial value. The proposed work clearly overlaps = with already existing work in other SDOs and I see a big risk with this. Is= the IETF willing to take the risk of stepping into other SDOs areas?, I se= e this not only as a RAI issue. This should be discussed at the BoF. Also, I see that the main driver behind this WG is the strive for a royalty= free codec. Reality has however shown that this is much more complicated t= o achive than what is believed in the beginning, the BoF should discuss thi= s issue as well. I would like the BoF chair(s) to provide with ample time to discuss if this= WG should actually be formed, to be honest I don't really see a need to di= scuss codec alternatives at the BoF. We should formulate the problem first,= a solution comes later (if needed). Regards Ingemar Johansson >ITU-T and 3GPP have already specified a wide portfolio of speech & audio c= odecs including Royalty Free codecs >(for narrowband, wideband, superwideba= nd...) with purpose to answer the needs of all conversational services >(in= cluding new multimedia services over IP) and ensure end to end interoperabi= lity. Many of these codecs are >already deployed and successfully used to answer the requirements of most = of all voice services all over the >world (over Circuit Switched, IP and Internet networks...). New extensions= of these codecs have been or are >being standardized to extend the quality towards very high fullband/stereo= quality. >With respect to the end to end interoperability issue, this codec portfoli= o is even already too large >considering the need to reduce networks additional costs and quality degra= dations due to transcoding >operations. >Adding new IETF standardized codecs to this (with probably little or no co= ordination with other SDOs) would >make no sense: those codecs would obviously compete with the ones from ITU= -T or 3GPP and any other legacy >codecs already widely deployed which would confuse the market, degrade the= overall end to end voice&audio >interoperability and quality and increase the transcoding costs in network= s. >Furthermore, IETF is not the place where sufficient codec expertise is gat= hered to standardize state of the >art codecs (as in Technical Groups SA4 of 3GPP or WP3/SG16 of ITU-T) and d= uplicating the works within multiple >Standard Bodies would not help with c= reating quality codecs; this concerns not only the expertise and works >needed for codec design but also all what is related to voice & audio qual= ity assessment. >Best regards >St=E9phane Proust _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C66679BC449Ehsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Codec BOF approved, much work needed Sorry to confess, it is now over 10 years when we had similar discuss= ions about forming a SIP WG.
H.323 was doing good and the ITU-T took care of multimedia communications.<= BR>
Henry


On 6/23/09 12:02 PM, "Ingemar Johansson S" <ingemar.s.johansson@ericsson.com> wrote:<= BR>
Hi

I support Stephanes opinion on this matter, I fail to see how this WG (if f= ormed) would add any substantial value. The proposed work clearly overlaps = with already existing work in other SDOs and I see a big risk with this. Is= the IETF willing to take the risk of stepping into other SDOs areas?, I se= e this not only as a RAI issue. This should be discussed at the BoF.
Also, I see that the main driver behind this WG is the strive for a royalty= free codec. Reality has however shown that this is much more complicated t= o achive than what is believed in the beginning, the BoF should discuss thi= s issue as well.
I would like the BoF chair(s) to provide with ample time to discuss if this= WG should actually be formed, to be honest I don't really see a need to di= scuss codec alternatives at the BoF. We should formulate the problem first,= a solution comes later (if needed).

Regards
Ingemar Johansson

>ITU-T and 3GPP have already specified a wide portfolio of speech & = audio codecs including Royalty Free codecs >(for narrowband, wideband, s= uperwideband...) with purpose to answer the needs of all conversational ser= vices >(including new multimedia services over IP) and ensure end to end= interoperability. Many of these codecs are
>already deployed and successfully used to answer the requirements of mo= st of all voice services all over the
>world (over Circuit Switched, IP and Internet networks...). New extensi= ons of these codecs have been or are
>being standardized to extend the quality towards very high fullband/ste= reo quality.

>With respect to the end to end interoperability issue, this codec portf= olio is even already too large
>considering the need to reduce networks additional costs and quality de= gradations due to transcoding
>operations.

>Adding new IETF standardized codecs to this (with probably little or no= coordination with other SDOs) would
>make no sense: those codecs would obviously compete with the ones from = ITU-T or 3GPP and any other legacy
>codecs already widely deployed which would confuse the market, degrade = the overall end to end voice&audio
>interoperability and quality and increase the transcoding costs in netw= orks.

>Furthermore, IETF is not the place where sufficient codec expertise is = gathered to standardize state of the
>art codecs (as in Technical Groups SA4 of 3GPP or WP3/SG16 of ITU-T) an= d duplicating the works within multiple >Standard Bodies would not help = with creating quality codecs; this concerns not only the expertise and work= s
>needed for codec design but also all what is related to voice & aud= io quality assessment.

>Best regards

>Stéphane Proust

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

--_000_C66679BC449Ehsinnreiadobecom_-- From Jean-Marc.Valin@USherbrooke.ca Tue Jun 23 10:53:21 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 4DE0C28C3F4 for ; Tue, 23 Jun 2009 10:53:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 EualGdK20QbY for ; Tue, 23 Jun 2009 10:53:20 -0700 (PDT) Received: from smtpi6.usherbrooke.ca (smtpi6.USherbrooke.ca [132.210.236.2]) by core3.amsl.com (Postfix) with ESMTP id 48F1428C3F3 for ; Tue, 23 Jun 2009 10:53:20 -0700 (PDT) Received: from localhost (www03.USherbrooke.ca [132.210.244.10]) by smtpi6.usherbrooke.ca (8.13.8/8.13.8) with ESMTP id n5NHrX85008836; Tue, 23 Jun 2009 13:53:33 -0400 Received: from mail.octasic.com (mail.octasic.com [70.54.254.106]) by www.usherbrooke.ca (IMP) with HTTP for ; Tue, 23 Jun 2009 13:53:33 -0400 Message-ID: <1245779613.4a41169d272bb@www.usherbrooke.ca> Date: Tue, 23 Jun 2009 13:53:33 -0400 From: Jean-Marc Valin To: stephen botzko References: <6e9223710906230718p2b5cbdaekd98e6aa31ad32874@mail.gmail.com> In-Reply-To: <6e9223710906230718p2b5cbdaekd98e6aa31ad32874@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 70.54.254.106 X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-MailScanner-ID: n5NHrX85008836 X-UdeS-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-7.499, requis 5, autolearn=not spam, BAYES_00 -2.60, RDNS_NONE 0.10, UDES_MONBUREAU01 -5.00) X-UdeS-MailScanner-From: jean-marc.valin@usherbrooke.ca Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 23 Jun 2009 17:53:21 -0000 Quoting stephen botzko : > >>> > Actually, I'm not aware of any codec standardised by the ITU-T and 3GPP in > the last 10 years and that doesn't require the licensing of several patents. > This is one of the main problems we're trying to address here as > patent-encumbered codecs are seriously harming interoperability on the > Internet. > >>> > > G.722.1 is one ITU-T codec is that is available royalty-free, and actually > it is quite suitable for use over the internet. The thing with G.722.1/G.722.1C licensing is that you still have to obtain a license from Polycom under terms that (AFAIK) prevent licensing under any open source license. Excluding all open source license is not very nice, even if the terms are less restrictive than other ITU-T codecs. > G.722.1 is a licensed royalty-free ITU-T standard audio codec providing high > quality, moderate bit rate (24 and 32 kbit/s) wideband (50 Hz - 7 kHz audio > bandwidth, 16 ksps) audio coding. It is an implementation of Polycom's > SIREN7 codec. I don't think G.722.1 is really well suited for an "Internet codec". I consider G.722.1 to really belong to an older generation of codecs and it isn't very competitive for wideband speech. It can do music better than other codecs, but then people looking for music codecs generally want more than 16 kHz sampling rate anyway. > G.722.1 Annex C provides twice the audio bandwidth, 14kHz > Both were standardized over the past 10 years - G722.1 itself was > standardized in September, 1999, and Annex C was standardized in May of > 2005. All modes of G.722.1 can be carried over RTP. G.722.1C is already more interesting, but I see several limitations with it. Even at its highest rate of 48 kbps, it is still far from being transparent on music (and even speech) and it cannot cover the full audio bandwidth. On top of that, 40 ms algorithmic delay is rather large when you want to have really good overall quality. Two of these issues (sampling rate, bitrate) are addressed by G.719, but as far as I know, there is no free (gratis) patent license, much less one that is open-source compatible. > The fact is that it is *absolutely possible* to standardize royalty-free > codecs in the ITU-T through their existing procedures. Polycom has done so > twice over the past 10 years. ...and it has recently failed for G.719 because Ericsson managed to have its codec pass the qualification phase, meaning that Ericsson technology (and the correspondig patent) had to be included in the final codec. I think this is the best illustration of why trying to standardise an unencumbered codec at the ITU is not a good idea. Not only would you have to come up with the best codec, but you would also have to be the only one to qualify a codec. Cheers, Jean-Marc > Regards > Stephen Botzko > Polycom > From jean-marc.valin@octasic.com Tue Jun 23 11:26:44 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 8A89B28C3F6 for ; Tue, 23 Jun 2009 11:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=0.421, 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 nELAAbVMK4M7 for ; Tue, 23 Jun 2009 11:26:43 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 62B5828C3E8 for ; Tue, 23 Jun 2009 11:26:43 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Jun 2009 14:26:58 -0400 Message-ID: <4A411E98.5080903@octasic.com> Date: Tue, 23 Jun 2009 14:27:36 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Ingemar Johansson S References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jun 2009 18:26:58.0715 (UTC) FILETIME=[31C19EB0:01C9F430] Cc: ron.even@gmail.com, codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 23 Jun 2009 18:26:44 -0000 Hi, Ingemar Johansson S wrote: > I support Stephanes opinion on this matter, I fail to see how this WG > (if formed) would add any substantial value. The proposed work clearly > overlaps with already existing work in other SDOs and I see a big risk > with this. Is the IETF willing to take the risk of stepping into other > SDOs areas?, Care to elaborate on the risks involved in stepping into other SDO areas? I wrote Speex in 2002 and have yet to see the ITU police knocking on my door ;-) Seriously, we would be standardising something different from what the ITU-T and MPEG currently standardise. > I see this not only as a RAI issue. This should be > discussed at the BoF. Also, I see that the main driver behind this WG is > the strive for a royalty free codec. > Reality has however shown that this > is much more complicated to achive than what is believed in the > beginning, Again, I'd be interested if you could elaborate on this. The CELT codec is Xiph.Org's 5th codec (4th audio codec) and it has worked well so far. It's not a trivial task to do, but then patents are a reality for all software, not just codecs. Cheers, Jean-Marc From stephen.botzko@gmail.com Tue Jun 23 11:27:10 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 0C3B628C406 for ; Tue, 23 Jun 2009 11:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.647 X-Spam-Level: X-Spam-Status: No, score=-1.647 tagged_above=-999 required=5 tests=[AWL=0.951, 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 vACIM9o2iigi for ; Tue, 23 Jun 2009 11:27:05 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id CB02528C405 for ; Tue, 23 Jun 2009 11:27:02 -0700 (PDT) Received: by fxm9 with SMTP id 9so268562fxm.37 for ; Tue, 23 Jun 2009 11:27: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:message-id:subject:from:to:cc:content-type; bh=olHJ62Zzdsp2YayYFMmmR3YTDW/088Xw2WEQJTs5778=; b=aDs0ch1Pq1nMnrGv48Tv3l8oVOoxtWkrEgT4D2ktUVpdLH796qxzUzARRRmFFql8ib ggA8ecFxZ62Q/UpniIl/thLgw9ipKisUkfFJMCWtPrIRh11WvmmUbHn/8eFwib6NqGrZ ZdUZy3muyR6ekcO0sgDVf2wSDqVYcOwAKSF1A= 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=n9EvXKLcnUuA4S5EQTTCg0nZDEsEIH0ug68zLpSvkTmzwjgLUYLuM2WlFfhqZvfKf3 nrrN1cjog9NRRtPSuEUzifP0bRZfzIdBH4J3EwgfkKNmCgUBRW/ThYR4cacQ8CHX4l7h eRV0jtOag2dbpZLFrXGRE2PQ15X1qlSMmpb5E= MIME-Version: 1.0 Received: by 10.103.107.1 with SMTP id j1mr164953mum.99.1245781635171; Tue, 23 Jun 2009 11:27:15 -0700 (PDT) In-Reply-To: <1245779613.4a41169d272bb@www.usherbrooke.ca> References: <6e9223710906230718p2b5cbdaekd98e6aa31ad32874@mail.gmail.com> <1245779613.4a41169d272bb@www.usherbrooke.ca> Date: Tue, 23 Jun 2009 14:27:15 -0400 Message-ID: <6e9223710906231127w2a215e9bpcb0e0f29a4f164d@mail.gmail.com> From: stephen botzko To: Jean-Marc Valin Content-Type: multipart/alternative; boundary=001636416cf7d50638046d0823ba Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 23 Jun 2009 18:27:10 -0000 --001636416cf7d50638046d0823ba Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >>> ...and it has recently failed for G.719 because Ericsson managed to have its codec pass the qualification phase, meaning that Ericsson technology (and the correspondig patent) had to be included in the final codec. I think this is the best illustration of why trying to standardise an unencumbered codec at the ITU is not a good idea. Not only would you have to come up with the best codec, but you would also have to be the only one to qualify a codec >>> This is *not* correct. After the qualification phase, there is a * competitive* selection phase. This does not require merging of technologies. With G.719, Polycom and Ericsson chose to colloborate and submit a joint candidate. If we had not done so, then there would have been two candidate codecs, only one of which would have been selected - based on which one had the best test results against the terms of reference. The company with the winning codec would have had full control over the licensing terms. There is no obligation to partner at all, and you have full control over who you partner with. If a consortium of companies agree to offer a royalty-free candidate, they can keep it that way. It is true that in order to be selected the royalty-free candidate has to win the selection process. Are you saying that you don't think royalty-free technology is good enough to win in a competitive process? --001636416cf7d50638046d0823ba Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
...and it has recently failed for G.719 because Ericsson managed to have it= s
codec pass the qualification phase, meaning that Ericsson technology (and t= he
correspondig patent) had to be included in the final codec. I think this is= the
best illustration of why trying to standardise an unencumbered codec at the= ITU
is not a good idea. Not only would you have to come up with the best codec,= but
you would also have to be the only one to qualify a codec
>>>

This is not correct. After the qualification phase, there is a co= mpetitive selection phase. This does not require merging of technologie= s.

With G.719, Polycom and Ericsson chose to colloborate and submit = a joint candidate.=A0

If we had not done so, then there would have been two candidate codecs, only one of which would have been selected - based on which one had the best test results against the terms of reference. The company with the winn= ing codec would have had full control over the licensing terms.

There is no obligation to partner at all, and=A0 you have full control over= who you partner with.=A0 If a consortium of companies agree to offer a royalty-free candidate, they can keep it that way.=A0

It is true that in order to be selected the royalty-fr= ee candidate has to win the selection process.=A0 Are you saying that you d= on't think royalty-free technology is good enough to win in a competiti= ve process?


--001636416cf7d50638046d0823ba-- From hsinnrei@adobe.com Tue Jun 23 11:35:46 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 A95463A6C04 for ; Tue, 23 Jun 2009 11:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.847 X-Spam-Level: X-Spam-Status: No, score=-5.847 tagged_above=-999 required=5 tests=[AWL=0.751, BAYES_00=-2.599, 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 WbUpcRJO8WrR for ; Tue, 23 Jun 2009 11:35:42 -0700 (PDT) Received: from psmtp.com (exprod6ob113.obsmtp.com [64.18.1.30]) by core3.amsl.com (Postfix) with ESMTP id 6FA443A6B48 for ; Tue, 23 Jun 2009 11:35:41 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob113.postini.com ([64.18.5.12]) with SMTP ID DSNKSkEggNTprG6OIOyYrPfkQjpe62cuSQji@postini.com; Tue, 23 Jun 2009 11:35:58 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 n5NIZgWG024594; Tue, 23 Jun 2009 11:35:42 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-3.eur.adobe.com (8.12.10/8.12.9) with ESMTP id n5NIZcY3017880; Tue, 23 Jun 2009 11:35:40 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Tue, 23 Jun 2009 11:35:39 -0700 From: Henry Sinnreich To: stephen botzko , Jean-Marc Valin Date: Tue, 23 Jun 2009 11:35:37 -0700 Thread-Topic: Codec BOF non-agenda-topics Thread-Index: Acn0MEd56pS3PIpUTSKozPBOAjynGwAAR81q Message-ID: In-Reply-To: <6e9223710906231127w2a215e9bpcb0e0f29a4f164d@mail.gmail.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_C6668AA944AChsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: [codec] Codec BOF non-agenda-topics 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, 23 Jun 2009 18:35:46 -0000 --_000_C6668AA944AChsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I suggest that all reasons to kill codec development in the IETF should be = a non-agenda item. Also on this list. Let's see what the the codec solutions/options are and figure out how to pr= oceed from there. Or does one really think existing codec standards have a chance to immortal= ity? :-) Thanks, Henry On 6/23/09 1:27 PM, "stephen botzko" wrote: >>> ...and it has recently failed for G.719 because Ericsson managed to have it= s codec pass the qualification phase, meaning that Ericsson technology (and t= he correspondig patent) had to be included in the final codec. I think this is= the best illustration of why trying to standardise an unencumbered codec at the= ITU is not a good idea. Not only would you have to come up with the best codec,= but you would also have to be the only one to qualify a codec >>> This is not correct. After the qualification phase, there is a competitive = selection phase. This does not require merging of technologies. With G.719, Polycom and Ericsson chose to colloborate and submit a joint ca= ndidate. If we had not done so, then there would have been two candidate codecs, onl= y one of which would have been selected - based on which one had the best t= est results against the terms of reference. The company with the winning co= dec would have had full control over the licensing terms. There is no obligation to partner at all, and you have full control over w= ho you partner with. If a consortium of companies agree to offer a royalty= -free candidate, they can keep it that way. It is true that in order to be selected the royalty-free candidate has to w= in the selection process. Are you saying that you don't think royalty-free= technology is good enough to win in a competitive process? --_000_C6668AA944AChsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Codec BOF non-agenda-topics I suggest that all reasons to kill codec development in the IETF shou= ld be a non-agenda item.
Also on this list.

Let’s see what the the codec solutions/options are and figure out how= to proceed from there.
Or does one really think existing codec standards have a chance to immortal= ity?   :-)

Thanks, Henry


On 6/23/09 1:27 PM, "stephen botzko" <stephen.botzko@gmail.com> wrote:

>>>
...and it has recently failed for G.719 because Ericsson managed to have it= s
codec pass the qualification phase, meaning that Ericsson technology (and t= he
correspondig patent) had to be included in the final codec. I think this is= the
best illustration of why trying to standardise an unencumbered codec at the= ITU
is not a good idea. Not only would you have to come up with the best codec,= but
you would also have to be the only one to qualify a codec
>>>

This is not correct. After the qualification phase, there is a co= mpetitive selection phase. This does not require merging of technologie= s.

With G.719, Polycom and Ericsson chose to colloborate and submit a joint ca= ndidate.=A0

If we had not done so, then there would have been two candidate codecs, onl= y one of which would have been selected - based on which one had the best t= est results against the terms of reference. The company with the winning co= dec would have had full control over the licensing terms.

There is no obligation to partner at all, and=A0 you have full control over= who you partner with.=A0 If a consortium of companies agree to offer a roy= alty-free candidate, they can keep it that way.=A0

It is true that in order to be selected the royalty-free candidate has to w= in the selection process.=A0 Are you saying that you don't think royalty-fr= ee technology is good enough to win in a competitive process?



--_000_C6668AA944AChsinnreiadobecom_-- From jean-marc.valin@octasic.com Tue Jun 23 11:51:08 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 D1F4B3A68CD for ; Tue, 23 Jun 2009 11:51:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.231 X-Spam-Level: X-Spam-Status: No, score=-2.231 tagged_above=-999 required=5 tests=[AWL=0.368, 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 7InkiYQ1fwlc for ; Tue, 23 Jun 2009 11:51:07 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 47A4E28C2E1 for ; Tue, 23 Jun 2009 11:51:07 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Jun 2009 14:51:10 -0400 Message-ID: <4A412444.9010007@octasic.com> Date: Tue, 23 Jun 2009 14:51:48 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: stephen botzko References: <6e9223710906230718p2b5cbdaekd98e6aa31ad32874@mail.gmail.com> <1245779613.4a41169d272bb@www.usherbrooke.ca> <6e9223710906231127w2a215e9bpcb0e0f29a4f164d@mail.gmail.com> In-Reply-To: <6e9223710906231127w2a215e9bpcb0e0f29a4f164d@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jun 2009 18:51:10.0203 (UTC) FILETIME=[92E91CB0:01C9F433] Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 23 Jun 2009 18:51:09 -0000 > It is true that in order to be selected the royalty-free candidate has > to win the selection process. Are you saying that you don't think > royalty-free technology is good enough to win in a competitive process? What I am saying is that given any unencumbered codec (or even encumbered ones, it doesn't matter), it's almost always possible to add one or two minor tweaks -- which you can patent -- and that will have some sort of improvement. Also, if technical superiority of the resulting codec was the only goal of ITU standards, how do you explain the strong correlation between the owners of the patents in an ITU codec and the companies that proposed the codec? I understand that the companies involved in the ITU (mainly carriers as far as I know) may be willing to pay licensing fees for those minor improvements. However, when it comes to most Internet applications, being able to legally use the codec is the most important "feature". Cheers, Jean-Marc From xiphmont@gmail.com Tue Jun 23 12:00:06 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 001A53A6BA9 for ; Tue, 23 Jun 2009 12:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 nx7rzWoloUI4 for ; Tue, 23 Jun 2009 12:00:05 -0700 (PDT) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id 551503A6EAC for ; Tue, 23 Jun 2009 12:00:04 -0700 (PDT) Received: by gxk10 with SMTP id 10so469071gxk.13 for ; Tue, 23 Jun 2009 12:00:18 -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 :content-transfer-encoding; bh=rbRTLgBr6nOx58WVw6OdySSggvRwuPzPuT7XOidBgYE=; b=vz9OKGoUtgbzBLc9a8xNt+2HGhAMWt6Vh+o8nKixR2u/1dGoVfWxLDayLQwuoeFuRg tFAH5HwtOY1kNUd7OE6FlMB5wLS4TPvS1WGiTXVgsshls6EwlgfZRMthwEIH5TGySRyI rJjP3Nuwxow3qN4MgNx81Klz3lkjFjZZagFfI= 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:content-transfer-encoding; b=lyHh3tK1gJhAIk9fBs1mPFKqeLDZyFLTbzJZRzTGEzKj3pPoVJ0lZqe165sg91qlhO Yk7gG/cZyw5oWbkaqGa1qcXDYv2MuXs4vP1hn7GDvz89E4/7KUHh0QZIACAC+bNvILuR tL5nNyBXPE82SUs0qBQlBRlWK9OMH3YzSMGNw= MIME-Version: 1.0 Received: by 10.231.38.76 with SMTP id a12mr145324ibe.50.1245783618466; Tue, 23 Jun 2009 12:00:18 -0700 (PDT) In-Reply-To: <4A412444.9010007@octasic.com> References: <6e9223710906230718p2b5cbdaekd98e6aa31ad32874@mail.gmail.com> <1245779613.4a41169d272bb@www.usherbrooke.ca> <6e9223710906231127w2a215e9bpcb0e0f29a4f164d@mail.gmail.com> <4A412444.9010007@octasic.com> Date: Tue, 23 Jun 2009 15:00:18 -0400 Message-ID: <806dafc20906231200u765e3ea2u9a232f1b8dbb04a8@mail.gmail.com> From: Christopher Montgomery To: Jean-Marc Valin Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org, stephen botzko Subject: Re: [codec] Codec BOF approved, much work needed 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, 23 Jun 2009 19:00:06 -0000 > I understand that the companies involved in the ITU (mainly carriers as far > as I know) may be willing to pay licensing fees for those minor > improvements. However, when it comes to most Internet applications, being > able to legally use the codec is the most important "feature". ...and to not let this be lost in the haggling about cost and payments, the important point is not what a codec is worth, but the control that licensing implies. It is just as important to avoid a royalty-free but still license-encumbered codec, as it is a codec that has an attached royalty structure. The issue is not [as much] money, it is about control and permission. That is part of why I assert the IETF is the correct place to have this discussion, even if it is not the usual historical venue. Monty From stewe@stewe.org Tue Jun 23 12:24: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 D1C4A28C179 for ; Tue, 23 Jun 2009 12:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.253 X-Spam-Level: * X-Spam-Status: No, score=1.253 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 Uu6kPn1aSo8u for ; Tue, 23 Jun 2009 12:24:06 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 0DEC73A6EAC for ; Tue, 23 Jun 2009 12:23:46 -0700 (PDT) Received: from [192.168.1.7] (unverified [68.197.227.183]) by stewe.org (SurgeMail 3.9e) with ESMTP id 313163-1743317 for multiple; Tue, 23 Jun 2009 21:24:02 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 23 Jun 2009 15:23:05 -0400 From: Stephan Wenger To: Henry Sinnreich , stephen botzko , Jean-Marc Valin Message-ID: Thread-Topic: [codec] Codec BOF non-agenda-topics Thread-Index: Acn0MEd56pS3PIpUTSKozPBOAjynGwAAR81qAAGoYks= In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3328615389_1939408" X-Originating-IP: 68.197.227.183 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (68.197.227.183) was found in the spamhaus database. http://www.spamhaus.net Cc: "codec@ietf.org" Subject: Re: [codec] Codec BOF non-agenda-topics 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, 23 Jun 2009 19:24:12 -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_3328615389_1939408 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable On 6/23/09 2:35 PM, "Henry Sinnreich" wrote: > I suggest that all reasons to kill codec development in the IETF should b= e a > non-agenda item. Also on this list.=20 Huh??? Why that? I think that this list, and the BOF, are actually the ONLY places where we should discuss whether the IETF should venture once more into the codec standardization space. I further believe that this, rather strategic, discussion, should come to a conclusion first, before we entertaining actua= l proposals and (much worse) their claimed IPR properties. It is my impression that the vast majority of codec standardization expert= s are not IETF regulars, and many of those I know would have a hard time to adapt to the IETF=B9s mode of working. Worse, in the current economic climate, few companies appear to be eager to send their experts to yet another SDO for projects which they already handle elsewhere. Many of thes= e companies are the powerhouses of speech and audio codec standardization. I= n the end, we could easily end up with inferior technology (due to lack of participation of a large percentage of codec standardization experts) that may be encumbered by patents without any obligation of licensing (RF or otherwise) by the patent holders---since these patent holders may not Participate (in the sense of the note well and RFC3979) in the standardization process and, therefore, have not even disclosure, let alone licensing obligations. This whole codec-in-the-IETF business smells to me like venue-shopping, based at least partly on a misconception of the IETF=B9s IPR policy, the options available in other SDOs, and that=B9s not what I consider a good idea= . Regards, Stephan >=20 >=20 > Let=B9s see what the the codec solutions/options are and figure out how to > proceed from there. > Or does one really think existing codec standards have a chance to > immortality? :-) >=20 > Thanks, Henry >=20 >=20 > On 6/23/09 1:27 PM, "stephen botzko" wrote: >=20 >>>>> >>> >> ...and it has recently failed for G.719 because Ericsson managed to have= its >> codec pass the qualification phase, meaning that Ericsson technology (an= d the >> correspondig patent) had to be included in the final codec. I think this= is >> the >> best illustration of why trying to standardise an unencumbered codec at = the >> ITU >> is not a good idea. Not only would you have to come up with the best cod= ec, >> but >> you would also have to be the only one to qualify a codec >>>>> >>> >>=20 >> This is not correct. After the qualification phase, there is a competiti= ve >> selection phase. This does not require merging of technologies. >>=20 >> With G.719, Polycom and Ericsson chose to colloborate and submit a joint >> candidate.=A0=20 >>=20 >> If we had not done so, then there would have been two candidate codecs, = only >> one of which would have been selected - based on which one had the best = test >> results against the terms of reference. The company with the winning cod= ec >> would have had full control over the licensing terms. >>=20 >> There is no obligation to partner at all, and=A0 you have full control ove= r who >> you partner with.=A0 If a consortium of companies agree to offer a royalty= -free >> candidate, they can keep it that way.=A0 >>=20 >> It is true that in order to be selected the royalty-free candidate has t= o win >> the selection process.=A0 Are you saying that you don't think royalty-free >> technology is good enough to win in a competitive process? >>=20 >>=20 >>=20 >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --B_3328615389_1939408 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] Codec BOF non-agenda-topics
On 6/23/09 2:35 PM, "Henry Sinnreich" <hsinnrei@adobe.com> wrote:

<= FONT SIZE=3D"5">I suggest that all reasons to kil= l codec development in the IETF should be a non-agenda item.
Also on this list.=

Huh???  Why that?

I think that this list, and the BOF, are actually the ONLY places where we = should discuss whether the IETF should venture once more into the codec stan= dardization space.  I further believe that this, rather strategic, disc= ussion, should come to a conclusion first, before we entertaining actual pro= posals and (much worse) their claimed IPR properties.

It is  my impression that the vast majority of codec standardization e= xperts are not IETF regulars, and many of those I know would have a hard tim= e to adapt to the IETF’s mode of working.  Worse, in the current = economic climate, few companies appear to be eager to send their experts to = yet another SDO for projects which they already handle elsewhere.  Many= of these companies are the powerhouses of speech and audio codec standardiz= ation.  In the end, we could easily end up with inferior technology (du= e to lack of participation of a large percentage of codec standardization ex= perts) that may be encumbered by patents without any obligation of licensing= (RF or otherwise) by the patent holders---since these patent holders may no= t Participate (in the sense of the note well and RFC3979) in the standardiza= tion process and, therefore, have not even disclosure, let alone licensing o= bligations.  

This whole codec-in-the-IETF business smells to me like venue-shopping, bas= ed at least partly on a misconception of the IETF’s IPR policy, the op= tions available in other SDOs, and that’s not what I consider a good i= dea.

Regards,
Stephan


<= FONT SIZE=3D"5">

Let’s see what the the codec solutions/options are and figure out how= to proceed from there.
Or does one really think existing codec standards have a chance to immortal= ity?   :-)

Thanks, Henry


On 6/23/09 1:27 PM, "stephen botzko" <stephen.botzko@gmail.com> wrote:

>>>
...and it has recently failed for G.719 because Ericsson managed to have it= s
codec pass the qualification phase, meaning that Ericsson technology (and t= he
correspondig patent) had to be included in the final codec. I think this is= the
best illustration of why trying to standardise an unencumbered codec at the= ITU
is not a good idea. Not only would you have to come up with the best codec,= but
you would also have to be the only one to qualify a codec
>>>

This is not correct. After the qualification phase, there is a co= mpetitive selection phase. This does not require merging of technologies= .

With G.719, Polycom and Ericsson chose to colloborate and submit a joint ca= ndidate.=A0

If we had not done so, then there would have been two candidate codecs, onl= y one of which would have been selected - based on which one had the best te= st results against the terms of reference. The company with the winning code= c would have had full control over the licensing terms.

There is no obligation to partner at all, and=A0 you have full control over w= ho you partner with.=A0 If a consortium of companies agree to offer a royalty-= free candidate, they can keep it that way.=A0

It is true that in order to be selected the royalty-free candidate has to w= in the selection process.=A0 Are you saying that you don't think royalty-free = technology is good enough to win in a competitive process?




___________= ____________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec
--B_3328615389_1939408-- From xiphmont@gmail.com Tue Jun 23 13:09:31 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 0549D3A6885 for ; Tue, 23 Jun 2009 13:09:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.502 X-Spam-Level: X-Spam-Status: No, score=-2.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 BSJloQIEWSAJ for ; Tue, 23 Jun 2009 13:09:30 -0700 (PDT) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id F153A3A6ABA for ; Tue, 23 Jun 2009 13:09:29 -0700 (PDT) Received: by gxk10 with SMTP id 10so547140gxk.13 for ; Tue, 23 Jun 2009 13:09:44 -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 :content-transfer-encoding; bh=WyCHiUz+mvuw72m8Qvcg9LtoCnAR1xm3/Fba78FxARw=; b=pW9q8esghp9ulxUGzyrnLVJUb4X7wqdbUaIo+OZT9uuHtWGvUrm3radvNAGztVibR0 EfngNBfl/RP7Ury8rOp/qzpERCtRBJfjWtSJ+Dj/fiF5odZj1vY9Z3R/BDrCU+lU8p7R RnuZIE+TXXjAqhY1kLnH/c+1HZYY5jZQSAGiE= 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:content-transfer-encoding; b=toM7Yh33CbPrNJpX9FC1wJjOnlk785vheYoy5zAkg7zCOtYPmiGKw0UaQ0gygWi7SK QQk/ppxkHIpxVJd7HzbPrUwdAsg853ZbwAKYv4qbDiyUVUhUh9tZJIizZRyoG+kFloCq 1nlzWVAD4lt6+PTRs/FNcznEHU2cx6n9gWpKU= MIME-Version: 1.0 Received: by 10.231.38.76 with SMTP id a12mr171525ibe.50.1245787783999; Tue, 23 Jun 2009 13:09:43 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Jun 2009 16:09:43 -0400 Message-ID: <806dafc20906231309j1780ca46sdd3e41a16cd945d8@mail.gmail.com> From: Christopher Montgomery To: Stephan Wenger Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" , stephen botzko Subject: Re: [codec] Codec BOF non-agenda-topics 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, 23 Jun 2009 20:09:31 -0000 > This whole codec-in-the-IETF business smells to me like venue-shopping, > based at least partly on a misconception of the IETF=92s IPR policy, the > options available in other SDOs, and that=92s not what I consider a good = idea. We've been approaching and gently cajoling the IETF on these points for approximately ten years. Our transports are already the subject of several RFCs. Aside from the IETF, the only other standards organization we actively participate in with regards to codecs is the W3C, and that also predates our run-in over the HTML5 baseline. There is no 'shopping' involved. We've been here for a long time. Monty (wearing his Xiph.Org hat) From stephen.botzko@gmail.com Tue Jun 23 13:31:52 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 61EBE28C2D8 for ; Tue, 23 Jun 2009 13:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.806 X-Spam-Level: X-Spam-Status: No, score=-1.806 tagged_above=-999 required=5 tests=[AWL=0.792, 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 3ivNF-Lxnfpf for ; Tue, 23 Jun 2009 13:31:51 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id D04C728C3E7 for ; Tue, 23 Jun 2009 13:31:50 -0700 (PDT) Received: by fxm9 with SMTP id 9so339437fxm.37 for ; Tue, 23 Jun 2009 13:32: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:message-id:subject:from:to:cc:content-type; bh=yiVbE5WCosNM4oE6e2JSzj9oY7kapYJmuK1b6dkrfKI=; b=EJPyDMjVZ60UNSBh9XY7gGurbsq8sKhxxxdW5H0Sfd/r/x6Om1ciOJDir9fIHNEim/ gd6s4fMxZqzcN1/R7OgEqF5nYQ5MX0+bcLTZ/UZp5iSWW3f493MMG1M6EUEmywHqJsLV u02bwAOIirpO7D3HzroEZxouu3ZHpIEAjYZUQ= 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=YbkWFgILzGKUO4tSmjltkQP8WGqygtZMSf09ho8V9GC688kf0Ft3YB5XnW5nJsxAyB k+NQdwyKDV0pe3gEPnRb/FP769ii2BBpEsjbPJkr5fIkWtEgT9uTddOYFY4Yj64j7mMw VOkv2Fz60M8fYbVlxGsLNsGa6EOj4G6l1K8Rk= MIME-Version: 1.0 Received: by 10.103.175.9 with SMTP id c9mr221759mup.3.1245789122081; Tue, 23 Jun 2009 13:32:02 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Jun 2009 16:32:02 -0400 Message-ID: <6e9223710906231332k6d35f158l8e8f7a86b7f63273@mail.gmail.com> From: stephen botzko To: Stephan Wenger Content-Type: multipart/alternative; boundary=0016367659761633f1046d09e23b Cc: "codec@ietf.org" Subject: Re: [codec] Codec BOF non-agenda-topics 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, 23 Jun 2009 20:31:52 -0000 --0016367659761633f1046d09e23b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >>> I suggest that all reasons to kill codec development in the IETF should be a non-agenda item. Also on this list. >>> I guess that must be aimed at me, since you copied my comments. If you read that post again, you will find that I did not take a position on the proposed IETF codec group. ALL I said is that it is certainly possible to standardize royalty-free codecs in the ITU-T, and that my own company has done it twice in the past 10 years. People are asserting that this is not possible, when in fact it is. Stephan Wenger's statement about IPR in the IETF (and also other standard bodies, including the ITU-T) is also clearly true. There is no guarantee that someone on the planet won't hold essential IPR on a standardized codec, because the patent holder might not be a participant with a duty to disclose. And to your suggestion, discussions regarding goals and aims, including an accurate assessment on what is and is not possible within exising SDOs is certainly relevant to this proposal. In my view, it is far more important than a technology discussion, given that the first outcome would need to be an agreed upon charter. Regards Stephen Botzko --0016367659761633f1046d09e23b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
I suggest that all reasons= to kill codec development in the IETF should be a non-agenda item.
Also= on this list.
>>>

I guess that must be aimed at me, since you copied my c= omments.

If you read that post again, you will find that I did not t= ake a position on the proposed IETF codec group.

ALL I said is that = it is certainly possible to standardize royalty-free codecs in the ITU-T, a= nd that my own company has done it twice in the past 10 years.=A0 People ar= e asserting that this is not possible, when in fact it is.

Stephan Wenger's statement about IPR in the IETF (and also other st= andard bodies, including the ITU-T) is also clearly true.=A0 There is no gu= arantee that someone on the planet won't hold essential IPR on a standa= rdized codec, because the patent holder might not be a participant with a d= uty to disclose.

And to your suggestion, discussions regarding goals and aims, including= an accurate assessment on what is and is not possible within exising SDOs = is certainly relevant to this proposal.=A0 In my view, it is far more impor= tant than a technology discussion, given that the first outcome would need = to be an agreed upon charter.

Regards
Stephen Botzko
--0016367659761633f1046d09e23b-- From macinnis@broadcom.com Tue Jun 23 13:54: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 C0AD83A6C38 for ; Tue, 23 Jun 2009 13:54:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.291 X-Spam-Level: X-Spam-Status: No, score=-2.291 tagged_above=-999 required=5 tests=[AWL=0.307, 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 gi1H5Y0GYwbM for ; Tue, 23 Jun 2009 13:54:34 -0700 (PDT) Received: from MMS3.broadcom.com (mms3.broadcom.com [216.31.210.19]) by core3.amsl.com (Postfix) with ESMTP id E8D113A6885 for ; Tue, 23 Jun 2009 13:54:33 -0700 (PDT) Received: from [10.16.192.232] by MMS3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.3.2)); Tue, 23 Jun 2009 13:54:38 -0700 X-Server-Uuid: B55A25B1-5D7D-41F8-BC53-C57E7AD3C201 Received: from SJEXCHCCR02.corp.ad.broadcom.com ([10.16.192.130]) by SJEXCHHUB02.corp.ad.broadcom.com ([10.16.192.232]) with mapi; Tue, 23 Jun 2009 13:54:38 -0700 From: "Sandy (Alexander) MacInnis" To: "Christian Hoene" , "codec@ietf.org" Date: Tue, 23 Jun 2009 13:53:25 -0700 Thread-Topic: Procedure on how to deal with "submarine" patents? Thread-Index: Acnw+gkTHL2SdLtVTDiF20h8Qld27QADaHaAAC7D3rEAAEzEwACLWUhAABS2MwA= Message-ID: <568A92CB079CCF43BA5C8D7B08BCB4AE8150B55632@SJEXCHCCR02.corp.ad.broadcom.com> References: <4a3bdc08.05a0660a.1836.ffffc55e@mx.google.com> <568A92CB079CCF43BA5C8D7B08BCB4AE8150B554D6@SJEXCHCCR02.corp.ad.broadcom.com> <006701c9f3f2$e177a680$a466f380$@de> In-Reply-To: <006701c9f3f2$e177a680$a466f380$@de> 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: 665F9E84600477709-01-01 Content-Type: multipart/alternative; boundary=_000_568A92CB079CCF43BA5C8D7B08BCB4AE8150B55632SJEXCHCCR02co_ Subject: Re: [codec] Procedure on how to deal with "submarine" patents? 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, 23 Jun 2009 20:54:42 -0000 --_000_568A92CB079CCF43BA5C8D7B08BCB4AE8150B55632SJEXCHCCR02co_ Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Sorry, I'm not familiar with CELT and patents that might perhaps cover it. = Without knowing, I'd assume there is some risk. Interesting question about what to do if a standard is created and one late= r decides that it's not actually royalty free. I don't know. It seems to m= e that no matter what the group says in advance, if this happens, it happen= s, and there's not much a standards group can do about it. I hope I'm wrong= . The choices depend, presumably, on whether the (hypothetical) patent hold= er participated in the standards activity. --Sandy ________________________________ From: Christian Hoene [mailto:hoene@uni-tuebingen.de] Sent: Tuesday, June 23, 2009 7:08 AM To: Sandy (Alexander) MacInnis; codec@ietf.org Subject: Procedure on how to deal with "submarine" patents? Dear Sandy, what do you think? How large is probability, that CELT is covered by patent= s, what we are not aware of? I just remember the patent struggle with the GIF file format (http://en.wik= ipedia.org/wiki/Graphics_Interchange_Format), for which Unisys requested li= cense fees after the format was spread widely (refer also to http://en.wiki= pedia.org/wiki/Submarine_patent) Should a procedure be considered and described in the standard, on how to a= ct if the assumed to be royalty free codec is not free anymore? I am just thinking of some kind of updating the codec software that MUST be= supported... Regards, Christian From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of S= andy (Alexander) MacInnis Sent: Saturday, June 20, 2009 6:52 PM To: codec@ietf.org Subject: Re: [codec] Royalty free is top motivation That sounds great. I'd like to point a few things that may or may not be obvious to everyone h= ere. I'm not a lawyer; this is an engineer's description (mine), so don't t= ake this a legal advice. I'm pretty familiar with patents, however. A potentially major problem with trying to make something royalty-free with= certainty, is the possibility of existing patents that may be infringed by= the "free" technology. There are lots of patents out there. Even if someone sat all by him/herself and created a codec from scratch, wi= th or without referring to any textbooks, journal articles, or openly avail= able source code, and the publishes the codec and declares that it's free t= o the world, that does not mean that it does not infringe on anyone's paten= ts. This is true whether or not the creator of the codec files any patent a= pplications on the work. If such a codec is published and used, a holder of a patent may wait until = there is widespread use of the codec, and then sue whoever they want. A dee= p-pockets company may make an attractive target. That could be a significan= t problem. For that reason, something that is thought to be royalty-free may turn out = not to be royalty free after all. It could go from seemingly free to quite = expensive rather quickly, or it could even be dropped by major companies, o= r even opposed by them in advance. It's difficult, but not quite impossible, to avoid this problem. Some standards groups try to avoid this problem by asking contributors to d= eclare what they know about any existing or planned patent coverage that ma= y cover their submission, and ask contributors who have their own patents t= o indicate on what terms they will license the patents. That may help a lot= , but it may not solve the problem. For one thing, contributors may not kno= w about patents that their method might infringe - often they don't know. T= here might also be some legal wrangling over the final terms for royalty-fr= ee licensing of patents held by contributors. Another way is to study very carefully all the patents that could possibly = be infringed, for each one, either work around it or see that the patent ha= s already expired. This is very hard to do, but it can be done. This does not mean that everyone wanting to implement a codec that's said t= o be royalty free has to read contracts. It would help however if someone h= ad done some diligence on sorting this out before the codec is published. W= ith suitable public licenses, it should be possible for all the world's use= rs to be confident that a codec is royalty-free, while also being high qual= ity, interoperable, open source, and a published standard. --Sandy ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of H= enry Sinnreich Sent: Saturday, June 20, 2009 12:18 PM To: Roni Even; codec@ietf.org Subject: [codec] Royalty free is top motivation Roni, (Topic changed for focus) Roni, Just to make it clear, royalty free was one of the top motivations and shou= ld probably be the main requirement for the Internet codec. Interoperability with existing codecs is nice, but IMHO a secondary order r= equirement, given that most interactive communications are already on the I= nternet and will be so even more in the future. Vendors and operators are a= lways free to include some other codecs and let SIP do the codec negotiatio= n - that's what it is for in SIP. Henry [... remainder of thread deleted for brevity...] --_000_568A92CB079CCF43BA5C8D7B08BCB4AE8150B55632SJEXCHCCR02co_ Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: quoted-printable Royalty fre= e is top motivation
Sorry, I'm not familiar with CELT and patents that= might=20 perhaps cover it. Without knowing, I'd assume there is some=20 risk.
 
Interesting question about what to do if a standar= d is=20 created and one later decides that it's not actually royalty free.&nbs= p; I=20 don't know. It seems to me that no matter what the group says in advance, i= f=20 this happens, it happens, and there's not much a standards group can do abo= ut=20 it. I hope I'm wrong. The choices depend, presumably, on whether the=20 (hypothetical) patent holder participated in the standards=20 activity.
 
--Sandy
 

From: Christian Hoene=20 [mailto:hoene@uni-tuebingen.de]
Sent: Tuesday, June 23, 2009 7:0= 8=20 AM
To: Sandy (Alexander) MacInnis; codec@ietf.org
Subject:<= /B>=20 Procedure on how to deal with "submarine" patents?

Dear=20 Sandy,

 

what=20 do you think? How large is probability, that CELT is covered by patents, wh= at we=20 are not aware of?

 

I=20 just remember the patent struggle with the GIF file format (http://en= .wikipedia.org/wiki/Graphics_Interchange_Format),=20 for which Unisys requested license fees after the format was spread widely= =20 (refer also to=20 http://en.wikipedia.org/wiki/Submarine_patent)

 

Should=20 a procedure be considered and described in the standard, on how to act if t= he=20 assumed to be royalty free codec is not free anymore?

 

I=20 am just thinking of some kind of updating the codec software that MUST be=20 supported…

 

Regards,

 

 Christian

 

 

From:<= /B>= =20 codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Sandy=20 (Alexander) MacInnis
Sent: Saturday, June 20, 2009 6:52=20 PM
To: codec@ietf.org
Subject: Re: [codec] Royalty free= is=20 top motivation

 

T= hat=20 sounds great.

 

I= 'd like=20 to point a few things that may or may not be obvious to everyone here. I'm = not a=20 lawyer; this is an engineer's description (mine), so don't take this a lega= l=20 advice. I'm pretty familiar with patents, however.

 

A= =20 potentially major problem with trying to make something royalty-free with=20 certainty, is the possibility of existing patents that may be infringed by = the=20 "free" technology. There are lots of patents out there.

 

E= ven if=20 someone sat all by him/herself and created a codec from scratch, with or wi= thout=20 referring to any textbooks, journal articles, or openly available source co= de,=20 and the publishes the codec and declares that it's free to the world, that = does=20 not mean that it does not infringe on anyone's patents. This is true whethe= r or=20 not the creator of the codec files any patent applications on the=20 work.

 

I= f such=20 a codec is published and used, a holder of a patent may wait until there is= =20 widespread use of the codec, and then sue whoever they want.=20 A deep-pockets company may make an attractive target. That could = be a=20 significant problem.

 

F= or that=20 reason, something that is thought to be royalty-free may turn out not to be= =20 royalty free after all. It could go from seemingly free to quite expensive= =20 rather quickly, or it could even be dropped by major companies, or even opp= osed=20 by them in advance.

 

I= t's=20 difficult, but not quite impossible, to avoid this problem.=20

 

S= ome=20 standards groups try to avoid this problem by asking contributors to declar= e=20 what they know about any existing or planned patent coverage that may cover= =20 their submission, and ask contributors who have their own patents to indica= te on=20 what terms they will license the patents. That may help a lot, but it may n= ot=20 solve the problem. For one thing, contributors may not know about patents t= hat=20 their method might infringe - often they don't know. There might also be so= me=20 legal wrangling over the final terms for royalty-free licensing of patents = held=20 by contributors.

 

A= nother=20 way is to study very carefully all the patents that could possibly be infri= nged,=20 for each one, either work around it or see that the patent has already expi= red.=20 This is very hard to do, but it can be done.

 

T= his=20 does not mean that everyone wanting to implement a codec that's said to be= =20 royalty free has to read contracts. It would help however if someone had do= ne=20 some diligence on sorting this out before the codec is published. With suit= able=20 public licenses, it should be possible for all the world's users to be conf= ident=20 that a codec is royalty-free, while also being high quality, interoperable,= open=20 source, and a published standard.

 

-= -Sandy

 

 

From:<= /B>= =20 codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = Henry=20 Sinnreich
Sent: Saturday, June 20, 2009 12:18 PM
To: Ro= ni=20 Even; codec@ietf.org
Subject: [codec] Royalty free is top=20 motivation

Roni,
(Topic changed for=20 focus)

Roni,

Just to make it clear, royalty free was one of t= he=20 top motivations and should probably be the main requirement for the Interne= t=20 codec.

Interoperability with existing codecs is nice, but IMHO a=20 secondary order requirement, given that most interactive communications are= =20 already on the Internet and will be so even more in the future. Vendors and= =20 operators are always free to include some other codecs and let SIP do the c= odec=20 negotiation – that’s what it is for in=20 SIP.

Henry

[= ... remainder=20 of thread deleted for brevity...] 

--_000_568A92CB079CCF43BA5C8D7B08BCB4AE8150B55632SJEXCHCCR02co_-- From ron.even.tlv@gmail.com Tue Jun 23 14:01:06 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 0124F28C107 for ; Tue, 23 Jun 2009 14:01:06 -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 zWvYWGXRY5D5 for ; Tue, 23 Jun 2009 14:01:04 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 3E5693A6885 for ; Tue, 23 Jun 2009 14:01:03 -0700 (PDT) Received: by fxm9 with SMTP id 9so355891fxm.37 for ; Tue, 23 Jun 2009 14:01:15 -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:thread-index:content-language; bh=BJSZLlcisEYlLGbnCZrDOIeg7CxCKUbbOpC5MChLFXA=; b=nMJcoaeX8JZMJXDVOzLIqEa2BDd6Flj6SYL2XiNhcwSNKi6P3Ne/VSG5HcqDxLBOqe /vZYHpJ0ZWk/Z9E4xZgf0THJzV2NpmoSDjpWiKgG+iIHeEX8E8MG4ZJTp/V1yHpIEISC sP6pQrTlRYF8SQd5X0VGxOhiwV6hNkqgvF3M0= 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:thread-index:content-language; b=VsYMB8Vk9eS9MCFHhh3JuhoWo+ZMgSjGincDRRpZQYZZ/awzPpFjWDsrg9MB23CX5r Eb+CU036ZAxOFt311AoTHmumRwQ1nJtHKST3EhkpIBMxL3FF8e2fGaCCa1/GquEit+za 3V/mdcHdGjuzOEXUqkR6z5XzCHidG42PrQEzc= Received: by 10.103.212.2 with SMTP id o2mr231407muq.18.1245790874881; Tue, 23 Jun 2009 14:01:14 -0700 (PDT) Received: from windows8d787f9 (bzq-79-181-103-217.red.bezeqint.net [79.181.103.217]) by mx.google.com with ESMTPS id t10sm1758318muh.0.2009.06.23.14.01.12 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 23 Jun 2009 14:01:13 -0700 (PDT) From: "Roni Even" To: "'stephen botzko'" , "'Jean-Marc Valin'" References: <6e9223710906230718p2b5cbdaekd98e6aa31ad32874@mail.gmail.com> <1245779613.4a41169d272bb@www.usherbrooke.ca> <6e9223710906231127w2a215e9bpcb0e0f29a4f164d@mail.gmail.com> In-Reply-To: <6e9223710906231127w2a215e9bpcb0e0f29a4f164d@mail.gmail.com> Date: Wed, 24 Jun 2009 00:01:07 +0300 Message-ID: <4a414299.0af6660a.48a2.ffffffc5@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00E6_01C9F45E.E1053D90" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn0MEYxe/Ix9YROS920W3LX4IzmjgAFBN8w Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 23 Jun 2009 21:01:06 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00E6_01C9F45E.E1053D90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Steve, I think that the assumption of Jean-Marc is that the major selection criteria for the codec will be royalty free and not quality. Also from reading the codec mailing list threads so far it does not look like collaboration is an option and this is not clear to me knowing the IETF process where content is added to a draft by consensus to get the best result, again unless there will be a rule not allowing anyone to suggest any content that is not royalty free. In the G.719 case the collaboration helped create a better codec than the individual proposals by taking the better technologies from both proposals. The truth is that I am very confused since there was no real discussion about the process by which this proposed group will work and there is no BOF time allocated to it, yet there is time to present some codecs. Roni Even From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of stephen botzko Sent: Tuesday, June 23, 2009 9:27 PM To: Jean-Marc Valin Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed >>> ...and it has recently failed for G.719 because Ericsson managed to have its codec pass the qualification phase, meaning that Ericsson technology (and the correspondig patent) had to be included in the final codec. I think this is the best illustration of why trying to standardise an unencumbered codec at the ITU is not a good idea. Not only would you have to come up with the best codec, but you would also have to be the only one to qualify a codec >>> This is not correct. After the qualification phase, there is a competitive selection phase. This does not require merging of technologies. With G.719, Polycom and Ericsson chose to colloborate and submit a joint candidate. If we had not done so, then there would have been two candidate codecs, only one of which would have been selected - based on which one had the best test results against the terms of reference. The company with the winning codec would have had full control over the licensing terms. There is no obligation to partner at all, and you have full control over who you partner with. If a consortium of companies agree to offer a royalty-free candidate, they can keep it that way. It is true that in order to be selected the royalty-free candidate has to win the selection process. Are you saying that you don't think royalty-free technology is good enough to win in a competitive process? ------=_NextPart_000_00E6_01C9F45E.E1053D90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Steve,

I think that the assumption of Jean-Marc is that the = major selection criteria for the codec will be royalty free and not = quality.

Also from reading the codec mailing list threads so far = it does not look like collaboration is an option and this is not clear to me = knowing the IETF process where content is added to a draft by consensus to get = the best result, again unless there will be a rule not allowing anyone to suggest = any content that is not royalty free.

In the G.719 case the collaboration helped create a = better codec than the individual proposals by taking the better technologies from = both proposals.

The truth is that I am very confused since there was no = real discussion about the process by which this proposed group will work and = there is no BOF  time allocated to it, yet there is time to present some = codecs.

Roni Even

 

 

From:= codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = stephen botzko
Sent: Tuesday, June 23, 2009 9:27 PM
To: Jean-Marc Valin
Cc: codec@ietf.org
Subject: Re: [codec] Codec BOF approved, much work = needed

 

>>>
...and it has recently failed for G.719 because Ericsson managed to have = its
codec pass the qualification phase, meaning that Ericsson technology = (and the
correspondig patent) had to be included in the final codec. I think this = is the
best illustration of why trying to standardise an unencumbered codec at = the ITU
is not a good idea. Not only would you have to come up with the best = codec, but
you would also have to be the only one to qualify a codec
>>>

This is not correct. After the qualification phase, there is a = competitive selection phase. This does not require merging of technologies.

With G.719, Polycom and Ericsson chose to colloborate and submit a joint candidate. 

If we had not done so, then there would have been two candidate codecs, = only one of which would have been selected - based on which one had the best = test results against the terms of reference. The company with the winning = codec would have had full control over the licensing terms.

There is no obligation to partner at all, and  you have full = control over who you partner with.  If a consortium of companies agree to offer = a royalty-free candidate, they can keep it that way. 

It is true that in order to be selected the royalty-free candidate has = to win the selection process.  Are you saying that you don't think = royalty-free technology is good enough to win in a competitive process?

------=_NextPart_000_00E6_01C9F45E.E1053D90-- From stewe@stewe.org Tue Jun 23 14:16:29 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 9B8943A6ABA for ; Tue, 23 Jun 2009 14:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[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 7a0Mq6T18VEy for ; Tue, 23 Jun 2009 14:16:19 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id EC3913A6D09 for ; Tue, 23 Jun 2009 14:16:15 -0700 (PDT) Received: from [172.16.0.136] (unverified [66.206.218.2]) by stewe.org (SurgeMail 3.9e) with ESMTP id 313244-1743317 for multiple; Tue, 23 Jun 2009 23:16:30 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 23 Jun 2009 17:16:15 -0400 From: Stephan Wenger To: "Sandy (Alexander) MacInnis" , Christian Hoene , "codec@ietf.org" Message-ID: Thread-Topic: [codec] Procedure on how to deal with "submarine" patents? Thread-Index: Acnw+gkTHL2SdLtVTDiF20h8Qld27QADaHaAAC7D3rEAAEzEwACLWUhAABS2MwAAAOsALg== In-Reply-To: <568A92CB079CCF43BA5C8D7B08BCB4AE8150B55632@SJEXCHCCR02.corp.ad.broadcom.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3328622187_2173285" X-Originating-IP: 66.206.218.2 X-Authenticated-User: stewe@stewe.org Subject: Re: [codec] Procedure on how to deal with "submarine" patents? 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, 23 Jun 2009 21:16: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_3328622187_2173285 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Sandy, On 6/23/09 4:53 PM, "Sandy (Alexander) MacInnis" wrote: > Sorry, I'm not familiar with CELT and patents that might perhaps cover it= . > Without knowing, I'd assume there is some risk. >=20 I share this feeling, but, due to the legal situation, I cannot be more precise. > =20 > Interesting question about what to do if a standard is created and one la= ter > decides that it's not actually royalty free. I don't know. It seems to m= e > that no matter what the group says in advance, if this happens, it happen= s, > and there's not much a standards group can do about it. I hope I'm wrong.= The > choices depend, presumably, on whether the (hypothetical) patent holder > participated in the standards activity. >=20 There are SDOs which have a goal to create only RF standards. These organizations generally have some form of a conflict resolution mechanism that kicks in when non-RF IPR is discovered---often regardless of the participation of the patent holder. One typical example is W3C, with its PAG concept. Sometimes these mechanisms even work. The IETF is not one of these organizations. In fact, the IETF does not eve= n have a requirement that essential patents must be licensable under RAND terms (as most RAND organizations, including ITU and ISO/IEC, have). Arguably, the risk of using a hypothetical IETF codec, advertised as RF or not, is higher than an ITU codec, at least for those entities which are willing to dish out RAND licensing money. That is unless there is very broad participation in the IETF work in question, but that seems unlikely i= n the current situation. I know that this does not help the open source people, though. I have no solution for them. Codecs are IMHO playing in a RAND licensing ecosystem, and I do not see a way to change that. Regards, Stephan =20 > --Sandy > =20 >=20 >=20 > From: Christian Hoene [mailto:hoene@uni-tuebingen.de] > Sent: Tuesday, June 23, 2009 7:08 AM > To: Sandy (Alexander) MacInnis; codec@ietf.org > Subject: Procedure on how to deal with "submarine" patents? >=20 > Dear Sandy, > =20 > what do you think? How large is probability, that CELT is covered by pate= nts, > what we are not aware of? > =20 > I just remember the patent struggle with the GIF file format > (http://en.wikipedia.org/wiki/Graphics_Interchange_Format), for which Uni= sys > requested license fees after the format was spread widely (refer also to > http://en.wikipedia.org/wiki/Submarine_patent) > =20 > Should a procedure be considered and described in the standard, on how to= act > if the assumed to be royalty free codec is not free anymore? > =20 > I am just thinking of some kind of updating the codec software that MUST = be > supported=8A > =20 > Regards, > =20 > Christian > =20 > =20 >=20 > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > Sandy (Alexander) MacInnis > Sent: Saturday, June 20, 2009 6:52 PM > To: codec@ietf.org > Subject: Re: [codec] Royalty free is top motivation > =20 > That sounds great. > =20 > I'd like to point a few things that may or may not be obvious to everyone > here. I'm not a lawyer; this is an engineer's description (mine), so don'= t > take this a legal advice. I'm pretty familiar with patents, however. > =20 > A potentially major problem with trying to make something royalty-free wi= th > certainty, is the possibility of existing patents that may be infringed b= y the > "free" technology. There are lots of patents out there. > =20 > Even if someone sat all by him/herself and created a codec from scratch, = with > or without referring to any textbooks, journal articles, or openly availa= ble > source code, and the publishes the codec and declares that it's free to t= he > world, that does not mean that it does not infringe on anyone's patents. = This > is true whether or not the creator of the codec files any patent applicat= ions > on the work. > =20 > If such a codec is published and used, a holder of a patent may wait unti= l > there is widespread use of the codec, and then sue whoever they want. A > deep-pockets company may make an attractive target. That could be a > significant problem. >=20 > =20 >=20 > For that reason, something that is thought to be royalty-free may turn ou= t not > to be royalty free after all. It could go from seemingly free to quite > expensive rather quickly, or it could even be dropped by major companies,= or > even opposed by them in advance. >=20 > =20 >=20 > It's difficult, but not quite impossible, to avoid this problem. >=20 > =20 >=20 > Some standards groups try to avoid this problem by asking contributors to > declare what they know about any existing or planned patent coverage that= may > cover their submission, and ask contributors who have their own patents t= o > indicate on what terms they will license the patents. That may help a lot= , but > it may not solve the problem. For one thing, contributors may not know ab= out > patents that their method might infringe - often they don't know. There m= ight > also be some legal wrangling over the final terms for royalty-free licens= ing > of patents held by contributors. >=20 > =20 >=20 > Another way is to study very carefully all the patents that could possibl= y be > infringed, for each one, either work around it or see that the patent has > already expired. This is very hard to do, but it can be done. >=20 > =20 >=20 > This does not mean that everyone wanting to implement a codec that's said= to > be royalty free has to read contracts. It would help however if someone h= ad > done some diligence on sorting this out before the codec is published. Wi= th > suitable public licenses, it should be possible for all the world's users= to > be confident that a codec is royalty-free, while also being high quality, > interoperable, open source, and a published standard. >=20 > =20 > --Sandy >=20 > =20 > =20 >=20 >=20 > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > Henry Sinnreich > Sent: Saturday, June 20, 2009 12:18 PM > To: Roni Even; codec@ietf.org > Subject: [codec] Royalty free is top motivation >=20 > Roni, > (Topic changed for focus) >=20 > Roni, >=20 > Just to make it clear, royalty free was one of the top motivations and sh= ould > probably be the main requirement for the Internet codec. >=20 > Interoperability with existing codecs is nice, but IMHO a secondary order > requirement, given that most interactive communications are already on th= e > Internet and will be so even more in the future. Vendors and operators ar= e > always free to include some other codecs and let SIP do the codec negotia= tion > =AD that=B9s what it is for in SIP. >=20 > Henry >=20 > [... remainder of thread deleted for brevity...] >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec --B_3328622187_2173285 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] Procedure on how to deal with "submarine" pate= nts? Hi Sandy,

On 6/23/09 4:53 PM, "Sandy (Alexander) MacInnis" <macinnis@broadcom.com> wrote:

Sorry, I'm not familiar with CELT and patents that migh= t perhaps cover it. Without knowing, I'd assume there is some risk.

I share this feeling, but, due to the le= gal situation, I cannot be more precise.

Interesting question about = what to do if a standard is created and one later decides that it's not actu= ally royalty free.  I don't know. It seems to me that no matter what th= e group says in advance, if this happens, it happens, and there's not much a= standards group can do about it. I hope I'm wrong. The choices depend, pres= umably, on whether the (hypothetical) patent holder participated in the stan= dards activity.

There are SDOs which have a goal to create only= RF standards.  These organizations generally have some form of a confl= ict resolution mechanism that kicks in when non-RF IPR is  discovered--= -often regardless of the participation of the patent holder.  One typic= al example is W3C, with its PAG concept.  Sometimes these mechanisms ev= en work.  

The IETF is not one of these organizations.  In fact, the IETF does no= t even have a requirement that essential patents must be licensable under RA= ND terms (as most RAND organizations, including ITU and ISO/IEC, have). &nbs= p;Arguably, the risk of using a hypothetical IETF codec, advertised as RF or= not, is higher than an ITU codec, at least for those entities which are wil= ling to dish out RAND licensing money.  That is unless there is very br= oad participation in the IETF work in question, but that seems unlikely in t= he current situation.  

I know that this does not help the open source people, though.  I have= no solution for them.  Codecs are IMHO playing in a RAND licensing eco= system, and I do not see a way to change that.

Regards,
Stephan

 
--Sandy

From: Christian Hoene [mailto:hoene@uni-tuebingen.de]
Sent: Tuesday, June 23, 2009 7:08 AM
To: Sandy (Alexander) MacInnis; codec@ietf.= org
Subject: Procedure on how to deal with "submarine" patents= ?

Dear Sandy,
 
what do you think? How large is probability, that CELT is covered by patent= s, what we are not aware of?
 
I just remember the patent struggle with the GIF file format (http://en.wikipedia.or= g/wiki/Graphics_Interchange_Format), for which Unisys requested license = fees after the format was spread widely (refer also to http://en.wikipedia.org/wiki/Submarine_pa= tent)
 
Should a procedure be considered and described in the standard, on how to a= ct if the assumed to be royalty free codec is not free anymore?
 
I am just thinking of some kind of updating the codec software that MUST be= supported…
 
Regards,
 
 Christian
 
 

From: = codec-bounces@ietf.org [mailto:c= odec-bounces@ietf.org] On Behalf Of Sandy (Alexander) MacInnis Sent: Saturday, June 20, 2009 6:52 PM
To: codec@ietf.org
Subject: Re: [codec] Royalty free is top motivation
That sounds great.
I'd like to point a few things that may or may not b= e obvious to everyone here. I'm not a lawyer; this is an engineer's descript= ion (mine), so don't take this a legal advice. I'm pretty familiar with pate= nts, however.
A potentially major problem with trying to make some= thing royalty-free with certainty, is the possibility of existing patents th= at may be infringed by the "free" technology. There are lots of pa= tents out there.
Even if someone sat all by him/herself and created a= codec from scratch, with or without referring to any textbooks, journal art= icles, or openly available source code, and the publishes the codec and decl= ares that it's free to the world, that does not mean that it does not infrin= ge on anyone's patents. This is true whether or not the creator of the codec= files any patent applications on the work.
If such a codec is published and used, a holder of a= patent may wait until there is widespread use of the codec, and then sue wh= oever they want. A deep-pockets company may make an attractive target. That = could be a significant problem.
For that reason, something that is thought to be roy= alty-free may turn out not to be royalty free after all. It could go from se= emingly free to quite expensive rather quickly, or it could even be dropped = by major companies, or even opposed by them in advance.
It's difficult, but not quite impossible, to avoid t= his problem.


Some standards groups try to avoid this problem by a= sking contributors to declare what they know about any existing or planned p= atent coverage that may cover their submission, and ask contributors who hav= e their own patents to indicate on what terms they will license the patents.= That may help a lot, but it may not solve the problem. For one thing, contr= ibutors may not know about patents that their method might infringe - often = they don't know. There might also be some legal wrangling over the final ter= ms for royalty-free licensing of patents held by contributors.
Another way is to study very carefully all the paten= ts that could possibly be infringed, for each one, either work around it or = see that the patent has already expired. This is very hard to do, but it can= be done.
This does not mean that everyone wanting to implemen= t a codec that's said to be royalty free has to read contracts. It would hel= p however if someone had done some diligence on sorting this out before the = codec is published. With suitable public licenses, it should be possible for= all the world's users to be confident that a codec is royalty-free, while a= lso being high quality, interoperable, open source, and a published standard= .

 --Sandy

  


From: = codec-bounces@ietf.org [mailto:c= odec-bounces@ietf.org] On Behalf Of Henry Sinnreich
Sent: Saturday, June 20, 2009 12:18 PM
To: Roni Even; codec@ietf.org
Subject: [codec] Royalty free is top motivation

Roni,
(Topic changed for focus)

Roni,

Just to make it clear, royalty free was one of the top motivations and shou= ld probably be the main requirement for the Internet codec.

Interoperability with existing codecs is nice, but IMHO a secondary order r= equirement, given that most interactive communications are already on the In= ternet and will be so even more in the future. Vendors and operators are alw= ays free to include some other codecs and let SIP do the codec negotiation &= #8211; that’s what it is for in SIP.

Henry

[... remainder of thread deleted for brevity...]

___________= ____________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec
--B_3328622187_2173285-- From stewe@stewe.org Tue Jun 23 14:39:08 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 8891E28C405 for ; Tue, 23 Jun 2009 14:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.203 X-Spam-Level: X-Spam-Status: No, score=-1.203 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, 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 ddtN-cbZszGE for ; Tue, 23 Jun 2009 14:39:07 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id EE82F28C442 for ; Tue, 23 Jun 2009 14:38:50 -0700 (PDT) Received: from [172.16.0.136] (unverified [66.206.218.2]) by stewe.org (SurgeMail 3.9e) with ESMTP id 313257-1743317 for multiple; Tue, 23 Jun 2009 23:39:06 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 23 Jun 2009 17:38:55 -0400 From: Stephan Wenger To: Christopher Montgomery Message-ID: Thread-Topic: [codec] Codec BOF non-agenda-topics Thread-Index: Acn0SwH/k9e4jnHWrki1fQm/5Pz16Q== In-Reply-To: <806dafc20906231309j1780ca46sdd3e41a16cd945d8@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 66.206.218.2 X-Authenticated-User: stewe@stewe.org Cc: "codec@ietf.org" , stephen botzko Subject: Re: [codec] Codec BOF non-agenda-topics 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, 23 Jun 2009 21:39:08 -0000 Hi Monty, There is absolutely nothing wrong in creating payload formats for codecs (royalty-free or otherwise) in IETF/AVT. I have, to the best of my recollection, never objected to that. (Occasionally, I have asked to remov= e IMHO likely incorrect marketing language in a few of these drafts related t= o IPR properties of the codecs in question, but that's about it.) I have eve= n been moderately supportive of the---failed, IMHO---iLBC experiment back then. What we are talking about here is something different. Pointedly put, just because the population in the SDOs with a long history of working on codecs are not that interested in your business model, you guys try to convince an organization to get into this space which has no history (beyond the mentioned experiment) in codec standardization. If that's not venue shopping, what is? Besides, as I mentioned in a different email, I would also argue that the IETF has no recent history in royalty-free standards---recent defined as over the course of the last 10 years or so. Just look at the IPR database and the number of RAND declarations. Certainly, there is no RF or open-source-compatibility requirement in the policy documents. (To be complete, I think that the agreement to keep baseline security in th= e IETF royalty-free is a special animal and not relevant for this discussion.= ) Regards, Stephan=20 (wearing no hat) On 6/23/09 4:09 PM, "Christopher Montgomery" wrote: >> This whole codec-in-the-IETF business smells to me like venue-shopping, >> based at least partly on a misconception of the IETF=B9s IPR policy, the >> options available in other SDOs, and that=B9s not what I consider a good i= dea. >=20 > We've been approaching and gently cajoling the IETF on these points > for approximately ten years. Our transports are already the subject > of several RFCs. Aside from the IETF, the only other standards > organization we actively participate in with regards to codecs is the > W3C, and that also predates our run-in over the HTML5 baseline. >=20 > There is no 'shopping' involved. We've been here for a long time. >=20 > Monty > (wearing his Xiph.Org hat) From jean-marc.valin@octasic.com Tue Jun 23 14:52:46 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 D30153A6DE2 for ; Tue, 23 Jun 2009 14:52:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.272 X-Spam-Level: X-Spam-Status: No, score=-2.272 tagged_above=-999 required=5 tests=[AWL=0.327, 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 k3PBsW9XZQwp for ; Tue, 23 Jun 2009 14:52:45 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id A69903A6C7B for ; Tue, 23 Jun 2009 14:52:45 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Jun 2009 17:53:01 -0400 Message-ID: <4A414EE4.7030500@octasic.com> Date: Tue, 23 Jun 2009 17:53:40 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Roni Even References: <6e9223710906230718p2b5cbdaekd98e6aa31ad32874@mail.gmail.com> <1245779613.4a41169d272bb@www.usherbrooke.ca> <6e9223710906231127w2a215e9bpcb0e0f29a4f164d@mail.gmail.com> <4a414299.0af6660a.48a2.ffffffc5@mx.google.com> In-Reply-To: <4a414299.0af6660a.48a2.ffffffc5@mx.google.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jun 2009 21:53:01.0659 (UTC) FILETIME=[FAA52AB0:01C9F44C] Cc: codec@ietf.org, 'stephen botzko' Subject: Re: [codec] Codec BOF approved, much work needed 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, 23 Jun 2009 21:52:46 -0000 Roni Even wrote: > I think that the assumption of Jean-Marc is that the major selection > criteria for the codec will be royalty free and not quality. The criteria will be quality with the constraint of being royalty-free. I don't think the ITU would standardise a codec for which a patent holder has already stated that it will not license the patent under reasonable terms? The proposed WG would be similar, but just more strict on licensing terms. > Also from reading the codec mailing list threads so far it does not look > like collaboration is an option and this is not clear to me knowing the > IETF process where content is added to a draft by consensus to get the > best result, I don't know why you keep bringing this up. I have stated multiple times in the discussion (usually responding to your email) that a collaboration is one of the main reasons I would like to have this codec WG and that I am not looking for rubber-stamping. > again unless there will be a rule not allowing anyone to > suggest any content that is not royalty free. I believe that should be the case. What use is a codec that people cannot legally use? > In the G.719 case the collaboration helped create a better codec than > the individual proposals by taking the better technologies from both > proposals. I'm not denying that. If we can create a better codec by combining several royalty-free technologies, I have absolutely no problem with that. > The truth is that I am very confused since there was no real discussion > about the process by which this proposed group will work and there is no > BOF time allocated to it, yet there is time to present some codecs. Since you're bringing this up, I think it's indeed a good time to discuss the process. I don't have a strong opinion yet on what the process should be, but here's a few thoughts: One side effect of having a royalty-free constraint is to remove barriers to collaboration as it will reduce/eliminate incentives for a company to push its own (patented) technology against other companies' technologies. I would hope there could be a single code base on which ideas can be tried and selected on their merit. It should be a lot easier to argue on purely technical terms when there is no conflict between "better" and "more licensing revenues". Regarding requirements, I would tend to go with a less rigid methodology than the ITU. How much so is not clear, but I don't see why the requirements can't evolve based on knowledge acquired while designing the codec. Taken to the extreme, that could go as far as "modifying the codec until the number of people who are happy with it is maximal". I'm not sure I'd want to go that far, but we should consider a wide range of options. Any thoughts on this? Jean-Marc From xiphmont@gmail.com Tue Jun 23 15:02: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 CA89E3A68C9 for ; Tue, 23 Jun 2009 15:02:59 -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 JXHcapsCTwrG for ; Tue, 23 Jun 2009 15:02:59 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id F10693A67D4 for ; Tue, 23 Jun 2009 15:02:58 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so171907ywj.49 for ; Tue, 23 Jun 2009 15:03:13 -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 :content-transfer-encoding; bh=gAWDdW1VBs7U8g3UAr3CwXivI9O3x3fMYfxWUmmlrVs=; b=I0GC0b3e5ln8hBq1LNYXtnfUXAGVwznOYSIax8QueWEzrw7Sx8jQd7QYb0tkS5PUP4 OeSPj7F576vRw19bACH68b2eFj3RROGX5UKHcwQ+418Ck0bm4CfHdI/BALy8HItW76Z2 D/jNONVv10TOJWjILmO4poaWHaseMl6zvvIVg= 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:content-transfer-encoding; b=oMITL4N8H9F91T1Nih2SYS5dDdFnFrd/YuyiTmDO6RS7e5hCgXnlRG1t0z3dgx/woU 909+GiCuNTIVnGqzabBQgnv2Woa3YNwDDL2V5x+g5syHgbcwJ9v3DrSfyQUj3zqMfGad 8aMO/OxkB5LPWqCdAo5QcMqVpWqBWB2GqfB+o= MIME-Version: 1.0 Received: by 10.231.37.68 with SMTP id w4mr223757ibd.33.1245794593331; Tue, 23 Jun 2009 15:03:13 -0700 (PDT) In-Reply-To: References: <806dafc20906231309j1780ca46sdd3e41a16cd945d8@mail.gmail.com> Date: Tue, 23 Jun 2009 18:03:13 -0400 Message-ID: <806dafc20906231503w7b3c2809y4872880c30237e50@mail.gmail.com> From: Christopher Montgomery To: Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" , stephen botzko Subject: Re: [codec] Codec BOF non-agenda-topics 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, 23 Jun 2009 22:02:59 -0000 > What we are talking about here is something different. =A0Pointedly put, = just > because the population in the SDOs with a long history of working on code= cs > are not that interested in your business model, We're a non-profit and as such don't have a business model. We'd also like to see a 'business model' be optional to general participation on the Internet. > you guys try to convince an > organization to get into this space which has no history (beyond the > mentioned experiment) in codec standardization. =A0If that's not venue > shopping, what is? Trying venue after venue until you find the one that works, which is not what we've done. > Besides, as I mentioned in a different email, I would also argue that the > IETF has no recent history in royalty-free standards---recent defined as > over the course of the last 10 years or so. No argument there. There are plenty of arguments being made against a WG or even the sensibility of a BOF here, but aren't they missing the point? Broad interest within the IETF is, of itself, sufficient condition for a BOF or WG is it not? Is there some worry that effort producing nothing (aka 'failure') will somehow do lasting harm to the IETF? Or is there also the worry perhaps that success might spread to the IPR assumptions of other new WGs? Monty From stewe@stewe.org Tue Jun 23 16:00: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 EF20828C13D for ; Tue, 23 Jun 2009 16:00:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[AWL=0.698, 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 ZVTzlcULZC3k for ; Tue, 23 Jun 2009 16:00:42 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id C48BA3A6936 for ; Tue, 23 Jun 2009 16:00:39 -0700 (PDT) Received: from [172.16.0.136] (unverified [66.206.218.2]) by stewe.org (SurgeMail 3.9e) with ESMTP id 313348-1743317 for multiple; Wed, 24 Jun 2009 01:00:54 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 23 Jun 2009 19:00:46 -0400 From: Stephan Wenger To: Christopher Montgomery Message-ID: Thread-Topic: [codec] Codec BOF non-agenda-topics Thread-Index: Acn0VnEuhmdx3h4HpEqdzcQ5UL0nlA== In-Reply-To: <806dafc20906231503w7b3c2809y4872880c30237e50@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 66.206.218.2 X-Authenticated-User: stewe@stewe.org Cc: "codec@ietf.org" , stephen botzko Subject: Re: [codec] Codec BOF non-agenda-topics 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, 23 Jun 2009 23:00:43 -0000 Hi Monty, Allow me to focus on your final points below, without agreeing to your argumentation on the earlier ones... On 6/23/09 6:03 PM, "Christopher Montgomery" wrote: [...] >> Besides, as I mentioned in a different email, I would also argue that the >> IETF has no recent history in royalty-free standards---recent defined as >> over the course of the last 10 years or so. > > No argument there. > > There are plenty of arguments being made against a WG or even the > sensibility of a BOF here, but aren't they missing the point? Broad > interest within the IETF is, of itself, sufficient condition for a BOF > or WG is it not? It depends on the definition of "broad interest". Broad interest in the IETF in WORKING towards a goal is a necessary condition to form a WG, no doubt. I don't think it is sufficient, but never mind that. Broad interest in the goal alone, without a critical mass of competent people committed to work towards the goal, IMHO, is insufficient. And I don't see this critical mass, certainly not yet. I do see this critical mass in the relevant groups in both 3GPP and in the ITU. But critical mass is precisely what the BOF will measure. Therefore, at present, I would speak against forming a WG, but I would not have spoken against a BOF, even if I would have been asked. > > Is there some worry that effort producing nothing (aka 'failure') will > somehow do lasting harm to the IETF? Very little on my side. The IETF has produced both successful and unsuccessful specifications in the past, and still thrived. Whole WGs have failed in the past, and the IETF is still there. > Or is there also the worry > perhaps that success might spread to the IPR assumptions of other new > WGs? That's closer to the point, but perhaps not quite dead on. I do not mind the existence of certain ecosystems where "free" standards are the norm---in whatever way you may want to define "free". What I'm worried about is an attempt of changing an organization-wide consensus, expressed in an IPR policy and IPR practice, in a single WG. Even more so since this proposed WG is operating in a space that is not the IETF's natural playground. Why don't you guys go out, take the open-source friendly legal framework some folks (including myself) create in the Open Web Foundation, and apply it to your work? Why push the IETF into an area where it is neither technically, nor from an IPR regime viewpoint, at home? Regards, Stephan > > Monty From jason.fischl@skype.net Tue Jun 23 16:41:21 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 8E4623A6D1D for ; Tue, 23 Jun 2009 16:41:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.532 X-Spam-Level: X-Spam-Status: No, score=-4.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 L6wmAfT3vIUg for ; Tue, 23 Jun 2009 16:41:20 -0700 (PDT) Received: from den-mipot-002.corp.ebay.com (den-mipot-002.corp.ebay.com [216.113.175.153]) by core3.amsl.com (Postfix) with ESMTP id AD2483A6D00 for ; Tue, 23 Jun 2009 16:41:20 -0700 (PDT) X-EBay-Corp: Yes X-IronPort-AV: E=Sophos;i="4.42,278,1243839600"; d="scan'208";a="51125740" Received: from den-exb-03.corp.ebay.com ([10.101.44.11]) by den-mipot-002.corp.ebay.com with ESMTP; 23 Jun 2009 16:41:36 -0700 Received: from DEN-EXM-04.corp.ebay.com ([10.241.16.37]) by DEN-EXB-03.corp.ebay.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 23 Jun 2009 17:41:36 -0600 Received: from 195.172.110.167 ([195.172.110.167]) by DEN-EXM-04.corp.ebay.com ([10.241.16.74]) via Exchange Front-End Server electron.corp.ebay.com ([10.101.112.26]) with Microsoft Exchange Server HTTP-DAV ; Tue, 23 Jun 2009 23:41:35 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 24 Jun 2009 01:41:34 +0200 From: Jason Fischl To: Stephan Wenger , Christopher Montgomery Message-ID: Thread-Topic: [codec] Codec BOF non-agenda-topics Thread-Index: Acn0VnEuhmdx3h4HpEqdzcQ5UL0nlAABbMfg In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Jun 2009 23:41:36.0124 (UTC) FILETIME=[2591A3C0:01C9F45C] Cc: "codec@ietf.org" , stephen botzko Subject: Re: [codec] Codec BOF non-agenda-topics 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, 23 Jun 2009 23:41:21 -0000 On 6/24/09 1:00 AM, "Stephan Wenger" wrote: > On 6/23/09 6:03 PM, "Christopher Montgomery" wrote: >> >> There are plenty of arguments being made against a WG or even the >> sensibility of a BOF here, but aren't they missing the point? Broad >> interest within the IETF is, of itself, sufficient condition for a BOF >> or WG is it not? > > It depends on the definition of "broad interest". Broad interest in the > IETF in WORKING towards a goal is a necessary condition to form a WG, no > doubt. I don't think it is sufficient, but never mind that. Broad interest > in the goal alone, without a critical mass of competent people committed to > work towards the goal, IMHO, is insufficient. And I don't see this critical > mass, certainly not yet. I do see this critical mass in the relevant groups > in both 3GPP and in the ITU. But critical mass is precisely what the BOF > will measure. Therefore, at present, I would speak against forming a WG, > but I would not have spoken against a BOF, even if I would have been asked. > Could you please define what you think it means to have "broad interest" or "critical mass"? How many audio codec experts should we have actively participating in the working group? Is there some other criteria that you are thinking about? Jason From stewe@stewe.org Tue Jun 23 17:08:34 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 501E53A6A41 for ; Tue, 23 Jun 2009 17:08:34 -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.466, 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 0cqTjSVFEHlN for ; Tue, 23 Jun 2009 17:08:33 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 7EC133A67EA for ; Tue, 23 Jun 2009 17:08:31 -0700 (PDT) Received: from [172.16.0.136] (unverified [66.206.218.2]) by stewe.org (SurgeMail 3.9e) with ESMTP id 313404-1743317 for multiple; Wed, 24 Jun 2009 02:08:42 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 23 Jun 2009 20:08:33 -0400 From: Stephan Wenger To: Jason Fischl , Christopher Montgomery Message-ID: Thread-Topic: [codec] Codec BOF non-agenda-topics Thread-Index: Acn0VnEuhmdx3h4HpEqdzcQ5UL0nlAABbMfgAADxQEo= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 66.206.218.2 X-Authenticated-User: stewe@stewe.org Cc: "codec@ietf.org" , stephen botzko Subject: Re: [codec] Codec BOF non-agenda-topics 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, 24 Jun 2009 00:08:34 -0000 Hi Jason, I don't think I can give you a fixed number. But if I see at least some of the folks who have worked for a couple of years in the ITU, 3GPP, MPEG, or 3GPP2 being committed to this effort, I would feel a lot better. It's not only numbers that count, its also previous experience in standardization of speech codecs. If those people come from known IPR powerhouses (and those powerhouses thereby show willingness to support an RF effort as it is argued for here), you would find me enthusiastically agreeing to a new WG. Regards, Stephan On 6/23/09 7:41 PM, "Jason Fischl" wrote: > On 6/24/09 1:00 AM, "Stephan Wenger" wrote: >> On 6/23/09 6:03 PM, "Christopher Montgomery" wrote: >>> >>> There are plenty of arguments being made against a WG or even the >>> sensibility of a BOF here, but aren't they missing the point? Broad >>> interest within the IETF is, of itself, sufficient condition for a BOF >>> or WG is it not? >> >> It depends on the definition of "broad interest". Broad interest in the >> IETF in WORKING towards a goal is a necessary condition to form a WG, no >> doubt. I don't think it is sufficient, but never mind that. Broad interest >> in the goal alone, without a critical mass of competent people committed to >> work towards the goal, IMHO, is insufficient. And I don't see this critical >> mass, certainly not yet. I do see this critical mass in the relevant groups >> in both 3GPP and in the ITU. But critical mass is precisely what the BOF >> will measure. Therefore, at present, I would speak against forming a WG, >> but I would not have spoken against a BOF, even if I would have been asked. >> > > Could you please define what you think it means to have "broad interest" or > "critical mass"? > > How many audio codec experts should we have actively participating in the > working group? Is there some other criteria that you are thinking about? > > Jason > From xiphmont@gmail.com Tue Jun 23 17:10:02 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 C4C1A3A6B7B for ; Tue, 23 Jun 2009 17:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 tz0ijjp7pJ-H for ; Tue, 23 Jun 2009 17:10:01 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.244]) by core3.amsl.com (Postfix) with ESMTP id A7BC83A67EA for ; Tue, 23 Jun 2009 17:10:01 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id c38so199129ana.4 for ; Tue, 23 Jun 2009 17:10:16 -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 :content-transfer-encoding; bh=NO144yi9gzjV8clBfPCDLyksmv64iGabifMgMcZ5bP0=; b=BcMs8v3iFW7JdmBNLRNqycUw/PE+cFmNnUs3P8u8TMn1rOTP0+mAURtGd2KPUyErlO slnrutTiNUprLRN6gBwwi6c7YseK4oqKFbmwVQRfm+jgWmEMvMo0AuTRyFh8uZ70Qmb/ nGwLeD8gkvQHuj4wp4H3jvmZnHs3JH3USgOMU= 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:content-transfer-encoding; b=hLS6GbBqzcnaNo/LRa06Ryo7XuL9I3Y49eQ3vWTFKtUjacvx20d1Chc+76RkFXP7KK zwpjmyyhq+cWcdC7nRVHmh4uNYemOwEc6MjZ2kiOrxaQqN/Glpz1LQORtH2soVzSaiye XTywtSHCOwPYv63Xr2T7Fq6+1xzPvoz6hMfxM= MIME-Version: 1.0 Received: by 10.231.39.202 with SMTP id h10mr250520ibe.35.1245802215675; Tue, 23 Jun 2009 17:10:15 -0700 (PDT) In-Reply-To: References: <806dafc20906231503w7b3c2809y4872880c30237e50@mail.gmail.com> Date: Tue, 23 Jun 2009 20:10:15 -0400 Message-ID: <806dafc20906231710i69dce538t51729beffb172068@mail.gmail.com> From: Christopher Montgomery To: Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" , stephen botzko Subject: Re: [codec] Codec BOF non-agenda-topics 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, 24 Jun 2009 00:10:02 -0000 > It depends on the definition of "broad interest". Yes, and I was not [yet] arguing there's indesputible evidence of broad interest, whatever the exact definition. But it seems like determining the level of interest is of primary importance to the question of WG or no WG, not most of the other arguments being made against. >=A0What I'm worried about is an > attempt of changing an organization-wide consensus, expressed in an IPR > policy and IPR practice, in a single WG. Even if that was my agenda (it isn't) I don't see how that would happen, especially not suddenly and against everyones' wills. However, if a royalty-free codec WG was formed, it would set a precedent that does, perhaps, suggest a possibility that hasn't seemed to have occurred within the IETF in some time. Across the board, royalty free codecs seem to have transitioned from 'first they laugh at you' to 'then they fight you' and I was trying to make people aware of whether or not an objection is well founded or simply a knee-jerk protection of 'we like things the way they are'. > Even more so since this proposed > WG is operating in a space that is not the IETF's natural playground. Only for the reason the IETF hasn't done it yet. But I think this is once again getting away from the crux of the argument. If the IETF has the interest, will and ability, why does this matter? > Why don't you guys go out, take the open-source friendly legal framework > some folks (including myself) create in the Open Web Foundation, and appl= y > it to your work? We're not talking only or even predominantly about the Web, otherwise we'd only be talking in the W3C. I assume this was just a slip. Mainly because we'd be trying to create a parallel IETF, with parallel discussion and decision-making structures, building the trust the world has in the IETF's transparency. And even if we succeed, don't you think the sensible reaction would be, "Why didn't you do this within the IETF?" > Why push the IETF into an area where it is neither > technically, nor from an IPR regime viewpoint, at home? Like-minded individuals within the IETF who have the interest, will and ability are discussing the idea of an RF codec working group. My organization was not behind this WG proposal, we merely support it. I'm surprised at the pushback from others who don't appear to be interested in participating anyway. Monty From xiphmont@gmail.com Tue Jun 23 17:14:06 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 DF8393A6BF4 for ; Tue, 23 Jun 2009 17:14:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 mTlKATifzlxF for ; Tue, 23 Jun 2009 17:14:06 -0700 (PDT) Received: from mail-yx0-f171.google.com (mail-yx0-f171.google.com [209.85.210.171]) by core3.amsl.com (Postfix) with ESMTP id 89C343A697F for ; Tue, 23 Jun 2009 17:13:47 -0700 (PDT) Received: by yxe1 with SMTP id 1so549380yxe.29 for ; Tue, 23 Jun 2009 17:14:01 -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 :content-transfer-encoding; bh=aMEp04W5HIS/3Pi5n/iIfzdfwqsCHWazmvXtEDjvTAI=; b=NLiLXMa8YqqMAxxGCzxuugFG1sofcwv5H/tBKyUMfUJ9jDWNptg3R+0JHol5OEk8qQ 5NPRlIxZ8xxhDbTUVJKh4qNR7sLu7NsY5p0coyqZhUWG8b0S2WZra9qPQ1eN1KV/OZUL J3UWW0P2P5RnEFM7AsK+HCUR+D5DeGuBlf/5U= 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:content-transfer-encoding; b=H8FkAQj2AOoBSjlFO7FAmEM8LrQd8emeIq9C4+iuIrV2jpZsGgUJwqPVIaHndc1tae uuJA7Bz5zLTVtt1IZrCz9UKuhvF3jB2zPs8Tgu/UObD3o2zAAou6daA/QmqnRlovR20H YaW3MoNLzncpJ9tjal2/4AOrnakENiawTCdyI= MIME-Version: 1.0 Received: by 10.231.17.199 with SMTP id t7mr252114iba.46.1245802441713; Tue, 23 Jun 2009 17:14:01 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Jun 2009 20:14:01 -0400 Message-ID: <806dafc20906231714x384d16f3jaf37d77f96ac1b4f@mail.gmail.com> From: Christopher Montgomery To: Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" , stephen botzko Subject: Re: [codec] Codec BOF non-agenda-topics 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, 24 Jun 2009 00:14:07 -0000 > If those people come from known IPR powerhouses (and those > powerhouses thereby show willingness to support an RF effort as it is argued > for here), you would find me enthusiastically agreeing to a new WG. I think we'd all like to see that. Monty From stewe@stewe.org Tue Jun 23 17:16:01 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 36E8828C421 for ; Tue, 23 Jun 2009 17:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.25 X-Spam-Level: X-Spam-Status: No, score=-2.25 tagged_above=-999 required=5 tests=[AWL=0.349, 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 LSOGjoZrhKLL for ; Tue, 23 Jun 2009 17:16:00 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 0FCBB28C41A for ; Tue, 23 Jun 2009 17:15:59 -0700 (PDT) Received: from [172.16.0.136] (unverified [66.206.218.2]) by stewe.org (SurgeMail 3.9e) with ESMTP id 313414-1743317 for multiple; Wed, 24 Jun 2009 02:16:12 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Tue, 23 Jun 2009 20:16:03 -0400 From: Stephan Wenger To: Christopher Montgomery Message-ID: Thread-Topic: [codec] Codec BOF non-agenda-topics Thread-Index: Acn0YPWF0POm416NGU6wgzMNPnEXow== In-Reply-To: <806dafc20906231714x384d16f3jaf37d77f96ac1b4f@mail.gmail.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 66.206.218.2 X-Authenticated-User: stewe@stewe.org Cc: "codec@ietf.org" , stephen botzko Subject: Re: [codec] Codec BOF non-agenda-topics 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, 24 Jun 2009 00:16:01 -0000 I'll mark this in red in my calendar: a point of agreement with Monty :-) Good night. Stephan On 6/23/09 8:14 PM, "Christopher Montgomery" wrote: >> If those people come from known IPR powerhouses (and those >> powerhouses thereby show willingness to support an RF effort as it is argued >> for here), you would find me enthusiastically agreeing to a new WG. > > I think we'd all like to see that. > > Monty From xiphmont@gmail.com Tue Jun 23 17:25: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 3C7943A6A77 for ; Tue, 23 Jun 2009 17:25:59 -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 McRZl7Wu2gLI for ; Tue, 23 Jun 2009 17:25:58 -0700 (PDT) Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.28]) by core3.amsl.com (Postfix) with ESMTP id 2E1AA3A67EA for ; Tue, 23 Jun 2009 17:25:58 -0700 (PDT) Received: by yw-out-2324.google.com with SMTP id 3so202669ywj.49 for ; Tue, 23 Jun 2009 17:26:11 -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 :content-transfer-encoding; bh=92EowAD+mUQfHM4BhfH/FCevQAPZnuovyxWF4k4RVlU=; b=KF3+WDkXM8Ep0FSKeFHEELpxgN9jh3Nuzamd4xbwRv/V59RCKWWlkguJABZGGKzYp9 jkqy+t7XoKQpGDQuxL1g3ZyiH3+bBh/QCBnPcO0sDdhmkrMb+oV4HBBlmf5LPBApmZb2 +OqAlfNHRWdEXhLnF/PMjo/wZDgOUaoF+pONY= 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:content-transfer-encoding; b=tIuzKyb0AQSewZGRUcWu20nsyHu27XGRWq5jgHaTd2/G4bMVVTkZanwV1MqGeztX7J kNscqojt5YJTMYZCS587t5d72iTdnxaCjsm7RzBaKxYam1Tj6dUzYXyda1UyNkSmG/tT RPmUOLOKjaGKjp3Hmcb1iGAzfkf5bcYu8mLDU= MIME-Version: 1.0 Received: by 10.231.38.76 with SMTP id a12mr253303ibe.50.1245803170876; Tue, 23 Jun 2009 17:26:10 -0700 (PDT) In-Reply-To: References: <806dafc20906231714x384d16f3jaf37d77f96ac1b4f@mail.gmail.com> Date: Tue, 23 Jun 2009 20:26:10 -0400 Message-ID: <806dafc20906231726j38007a70l797f83a739746c0c@mail.gmail.com> From: Christopher Montgomery To: Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" , stephen botzko Subject: Re: [codec] Codec BOF non-agenda-topics 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, 24 Jun 2009 00:25:59 -0000 For the record I did mean 'Participation from the large IPR powerhouses' not 'win the argument with Mr. Wenger' :-) Cheers, Monty From jean-marc.valin@usherbrooke.ca Tue Jun 23 17:26:14 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 4137D28C42C for ; Tue, 23 Jun 2009 17:26:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 YsKC9-k7+wYv for ; Tue, 23 Jun 2009 17:26:13 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id ECA953A67EA for ; Tue, 23 Jun 2009 17:26:12 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1 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-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KLP0025RVW4JQ00@VL-MO-MR003.ip.videotron.ca> for codec@ietf.org; Tue, 23 Jun 2009 20:26:29 -0400 (EDT) Message-id: <4A4172B4.5010201@usherbrooke.ca> Date: Tue, 23 Jun 2009 20:26:28 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) To: Stephan Wenger References: In-reply-to: X-Enigmail-Version: 0.95.2 Cc: "codec@ietf.org" , stephen botzko Subject: Re: [codec] Codec BOF non-agenda-topics 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, 24 Jun 2009 00:26:14 -0000 Stephan Wenger a écrit : > I don't think I can give you a fixed number. But if I see at least some of > the folks who have worked for a couple of years in the ITU, 3GPP, MPEG, or > 3GPP2 being committed to this effort, I would feel a lot better. It's not > only numbers that count, its also previous experience in standardization of > speech codecs. If those people come from known IPR powerhouses (and those > powerhouses thereby show willingness to support an RF effort as it is argued > for here), you would find me enthusiastically agreeing to a new WG. So according to you, there should only be an IETF IPR-free codec if the companies and people currently involved in the ITU change their minds and decide they want IPR-free codecs? That sort of misses the point. The reason we're trying to create this WG is *specifically* because the people involved in the ITU, MPEG and others are showing no interest in IPR-free codecs. Cheers, Jean-Marc > Regards, > Stephan > > > On 6/23/09 7:41 PM, "Jason Fischl" wrote: > >> On 6/24/09 1:00 AM, "Stephan Wenger" wrote: >>> On 6/23/09 6:03 PM, "Christopher Montgomery" wrote: >>>> There are plenty of arguments being made against a WG or even the >>>> sensibility of a BOF here, but aren't they missing the point? Broad >>>> interest within the IETF is, of itself, sufficient condition for a BOF >>>> or WG is it not? >>> It depends on the definition of "broad interest". Broad interest in the >>> IETF in WORKING towards a goal is a necessary condition to form a WG, no >>> doubt. I don't think it is sufficient, but never mind that. Broad interest >>> in the goal alone, without a critical mass of competent people committed to >>> work towards the goal, IMHO, is insufficient. And I don't see this critical >>> mass, certainly not yet. I do see this critical mass in the relevant groups >>> in both 3GPP and in the ITU. But critical mass is precisely what the BOF >>> will measure. Therefore, at present, I would speak against forming a WG, >>> but I would not have spoken against a BOF, even if I would have been asked. >>> >> Could you please define what you think it means to have "broad interest" or >> "critical mass"? >> >> How many audio codec experts should we have actively participating in the >> working group? Is there some other criteria that you are thinking about? >> >> Jason >> > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > From xiphmont@gmail.com Tue Jun 23 17:26:51 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 8146428C42C for ; Tue, 23 Jun 2009 17:26:51 -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.071, 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 hjuRngqixUkm for ; Tue, 23 Jun 2009 17:26:50 -0700 (PDT) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id 53E8A28C421 for ; Tue, 23 Jun 2009 17:26:50 -0700 (PDT) Received: by gxk10 with SMTP id 10so787603gxk.13 for ; Tue, 23 Jun 2009 17:27:04 -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 :content-transfer-encoding; bh=6QOb3sF+vDhuRacMMHGMMwGk7YScW2xlPgqFFmZlYjE=; b=QtHnG4YboFC7NHFRwZGwKgiYteQJ1FJXky4mGDPW1ZLSz/c0rm10CA4cXHBxAsLaz5 AEzTZ6AOj6dN20h61zOXPUAD0+WfhLiVpOa4lQoDmQOXhr0zL1LUGxmK78pd7roxZp3C FulwpWh5bThqkts8E+qDjLJ83KvYly0w+XAMQ= 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:content-transfer-encoding; b=E8pLRRvdXVs514iLvS1w9/X3suSLNXieVTrJBEBpy3eENnhVidsHdgYOPHx19UyBjs 7mxFT9z04KbJSFmRbou22i+6OFGGi/Jymtt3F2rGvDFOOW4dqCZV2F8WHoF4NBWmIWzu SH9NF00B04gx7EZxmQlxJTpJOehtyYmw6EED4= MIME-Version: 1.0 Received: by 10.231.35.66 with SMTP id o2mr254715ibd.41.1245803224728; Tue, 23 Jun 2009 17:27:04 -0700 (PDT) In-Reply-To: <806dafc20906231726j38007a70l797f83a739746c0c@mail.gmail.com> References: <806dafc20906231714x384d16f3jaf37d77f96ac1b4f@mail.gmail.com> <806dafc20906231726j38007a70l797f83a739746c0c@mail.gmail.com> Date: Tue, 23 Jun 2009 20:27:04 -0400 Message-ID: <806dafc20906231727g7e9f2b19g9b026a1ccffe302f@mail.gmail.com> From: Christopher Montgomery To: Stephan Wenger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "codec@ietf.org" , stephen botzko Subject: Re: [codec] Codec BOF non-agenda-topics 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, 24 Jun 2009 00:26:52 -0000 Argh, I mean 'Dr. Wenger' of course. No end of slip-ups tonight. Monty From hsinnrei@adobe.com Tue Jun 23 17:29:34 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 3C40128C421 for ; Tue, 23 Jun 2009 17:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.96 X-Spam-Level: X-Spam-Status: No, score=-5.96 tagged_above=-999 required=5 tests=[AWL=0.639, BAYES_00=-2.599, 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 GLyhn7JckDfI for ; Tue, 23 Jun 2009 17:29:32 -0700 (PDT) Received: from psmtp.com (exprod6ob109.obsmtp.com [64.18.1.22]) by core3.amsl.com (Postfix) with ESMTP id 29A153A676A for ; Tue, 23 Jun 2009 17:29:31 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKSkFzdW7ONHfjFjAe7hJ5IBmxoWXtg6bE@postini.com; Tue, 23 Jun 2009 17:29:49 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5O0TbWG026011; Tue, 23 Jun 2009 17:29:38 -0700 (PDT) Received: from nacas02.corp.adobe.com (nacas02.corp.adobe.com [10.8.189.100]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5O0Taiq029373; Tue, 23 Jun 2009 17:29:36 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas02.corp.adobe.com ([10.8.189.100]) with mapi; Tue, 23 Jun 2009 17:29:36 -0700 From: Henry Sinnreich To: Stephan Wenger , Jason Fischl , Christopher Montgomery Date: Tue, 23 Jun 2009 17:29:34 -0700 Thread-Topic: [codec] Codec BOF non-agenda-topics Thread-Index: Acn0VnEuhmdx3h4HpEqdzcQ5UL0nlAABbMfgAADxQEoAALvo7A== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C666DD9E44E4hsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" , stephen botzko Subject: Re: [codec] Codec BOF non-agenda-topics 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, 24 Jun 2009 00:29:34 -0000 --_000_C666DD9E44E4hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Stephen, With all respect and putting on my Internet engineer hat and as a former IS= P employee, most of the worlds multimedia applications traffic goes over th= e Internet using protocols and codecs that have been invented not by the po= werhouses you are referring to (remember their OSI, ATM and H.323?). P2P video and IPTV (The Flicker or YouTube varieties) are just examples of = pure Internet multimedia. RTP and SIP came from the IETF, and why are all the codec vendors making su= re they get an IETF AVT profile? I fail to understand (though I do) the opposition to new players in the fie= ld that may include innovators of the sort there are so many on the Interne= t. Last but not least, is not for the market to decide, instead of trying to k= ill the baby before it is even born? It seems there are here two irreconcilable camps: The established industry = and new Internet players. Can we please take the Internet view here in the IETF venue? My strict personal two cents, Henry On 6/23/09 7:08 PM, "Stephan Wenger" wrote: Hi Jason, I don't think I can give you a fixed number. But if I see at least some of the folks who have worked for a couple of years in the ITU, 3GPP, MPEG, or 3GPP2 being committed to this effort, I would feel a lot better. It's not only numbers that count, its also previous experience in standardization of speech codecs. If those people come from known IPR powerhouses (and those powerhouses thereby show willingness to support an RF effort as it is argue= d for here), you would find me enthusiastically agreeing to a new WG. Regards, Stephan On 6/23/09 7:41 PM, "Jason Fischl" wrote: > On 6/24/09 1:00 AM, "Stephan Wenger" wrote: >> On 6/23/09 6:03 PM, "Christopher Montgomery" wrote: >>> >>> There are plenty of arguments being made against a WG or even the >>> sensibility of a BOF here, but aren't they missing the point? Broad >>> interest within the IETF is, of itself, sufficient condition for a BOF >>> or WG is it not? >> >> It depends on the definition of "broad interest". Broad interest in the >> IETF in WORKING towards a goal is a necessary condition to form a WG, no >> doubt. I don't think it is sufficient, but never mind that. Broad inte= rest >> in the goal alone, without a critical mass of competent people committed= to >> work towards the goal, IMHO, is insufficient. And I don't see this crit= ical >> mass, certainly not yet. I do see this critical mass in the relevant gr= oups >> in both 3GPP and in the ITU. But critical mass is precisely what the BOF >> will measure. Therefore, at present, I would speak against forming a WG= , >> but I would not have spoken against a BOF, even if I would have been ask= ed. >> > > Could you please define what you think it means to have "broad interest" = or > "critical mass"? > > How many audio codec experts should we have actively participating in the > working group? Is there some other criteria that you are thinking about? > > Jason > _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C666DD9E44E4hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Codec BOF non-agenda-topics Hi Stephen,

With all respect and putting on my Internet engineer hat and as a former IS= P employee, most of the worlds multimedia applications traffic goes = over the Internet using protocols and codecs that have been invented not by= the powerhouses you are referring to (remember their OSI, ATM and H.323?).=
P2P video and IPTV (The Flicker or YouTube varieties) are just examples of = pure Internet multimedia.
RTP and SIP came from the IETF, and why are all the codec vendors making su= re they get an IETF AVT profile?

I fail to understand (though I do) the opposition to new players in the fie= ld that may include innovators of the sort there are so many on the Interne= t.

Last but not least, is not for the market to decide, instead of trying to k= ill the baby before it is even born?

It seems there are here two irreconcilable camps: The established industry = and new Internet players.
Can we please take the Internet view here in the IETF venue?

My strict personal two cents,

Henry


On 6/23/09 7:08 PM, "Stephan Wenger" <stewe@stewe.org> wrote:

Hi Jason,
I don't think I can give you a fixed number.  But if I see at least so= me of
the folks who have worked for a couple of years in the ITU, 3GPP, MPEG, or<= BR> 3GPP2 being committed to this effort, I would feel a lot better.  It's= not
only numbers that count, its also previous experience in standardization of=
speech codecs.  If those people come from known IPR powerhouses (and t= hose
powerhouses thereby show willingness to support an RF effort as it is argue= d
for here), you would find me enthusiastically agreeing to a new WG.
Regards,
Stephan


On 6/23/09 7:41 PM, "Jason Fischl" <jason.fischl@skype.net> wrote:

> On 6/24/09 1:00 AM, "Stephan Wenger" <stewe@stewe.org> wrote:
>> On 6/23/09 6:03 PM, "Christopher Montgomery" <xiphmont@gmail.com> wrote:
>>>
>>> There are plenty of arguments being made against a WG or even = the
>>> sensibility of a BOF here, but aren't they missing the point? =   Broad
>>> interest within the IETF is, of itself, sufficient condition f= or a BOF
>>> or WG is it not?
>>
>> It depends on the definition of "broad interest".  = Broad interest in the
>> IETF in WORKING towards a goal is a necessary condition to form a = WG, no
>> doubt.  I don't think it is sufficient, but never mind that. =  Broad interest
>> in the goal alone, without a critical mass of competent people com= mitted to
>> work towards the goal, IMHO, is insufficient.  And I don't se= e this critical
>> mass, certainly not yet.  I do see this critical mass in the = relevant groups
>> in both 3GPP and in the ITU. But critical mass is precisely what t= he BOF
>> will measure.  Therefore, at present, I would speak against f= orming a WG,
>> but I would not have spoken against a BOF, even if I would have be= en asked.
>>
>
> Could you please define what you think it means to have "broad in= terest" or
> "critical mass"?
>
> How many audio codec experts should we have actively participating in = the
> working group? Is there some other criteria that you are thinking abou= t?
>
> Jason
>


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

--_000_C666DD9E44E4hsinnreiadobecom_-- From ingemar.s.johansson@ericsson.com Wed Jun 24 01:42:23 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 1FD003A6F3A for ; Wed, 24 Jun 2009 01:42:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.949 X-Spam-Level: X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[AWL=0.300, 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 30QfqrmX4q26 for ; Wed, 24 Jun 2009 01:42:22 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C12183A6F35 for ; Wed, 24 Jun 2009 01:42:17 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba8ae0000072d6-c4-4a41d7bbc868 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 56.04.29398.BB7D14A4; Wed, 24 Jun 2009 09:37:32 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jun 2009 09:35:36 +0200 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: Wed, 24 Jun 2009 09:35:35 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se> In-Reply-To: <4A411E98.5080903@octasic.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acn0MDLy2GxBYXk0T4eaJtzQPMocLAAaKPVA References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> From: "Ingemar Johansson S" To: "Jean-Marc Valin" X-OriginalArrivalTime: 24 Jun 2009 07:35:36.0508 (UTC) FILETIME=[5D5BD7C0:01C9F49E] X-Brightmail-Tracker: AAAAAA== Cc: ron.even@gmail.com, codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 24 Jun 2009 08:42:23 -0000 Hi Comments inline=20 Regards Ingemar > -----Original Message----- > From: Jean-Marc Valin [mailto:jean-marc.valin@octasic.com]=20 > Sent: den 23 juni 2009 20:28 > To: Ingemar Johansson S > Cc: codec@ietf.org; ron.even@gmail.com > Subject: Re: [codec] Codec BOF approved, much work needed >=20 > Hi, >=20 > Ingemar Johansson S wrote: > > I support Stephanes opinion on this matter, I fail to see=20 > how this WG=20 > > (if formed) would add any substantial value. The proposed=20 > work clearly=20 > > overlaps with already existing work in other SDOs and I see=20 > a big risk=20 > > with this. Is the IETF willing to take the risk of stepping=20 > into other=20 > > SDOs areas?, >=20 > Care to elaborate on the risks involved in stepping into=20 > other SDO areas? I wrote Speex in 2002 and have yet to see=20 > the ITU police knocking on my door ;-) IMHO IETF relies on a good relationship with other SDOs, as an example ITU and IETF has had somewhat conflicting interests in the standardization of MPLS, today I believe an agreement has been reached where both parties are satisfied (I hope), I am not an MPLS expert so I must leave the details to others. My point is that if we decide to step into other SDOs areas so clearly as this BoF suggests, the benefits must clearly outweight the risk that work in other IETF areas is disturbed. This should be discussed at the BoF. >=20 > Seriously, we would be standardising something different from=20 > what the ITU-T and MPEG currently standardise. I don't agree, the EVS codec being specified in 3GPP clearly adresses packet switched access at various bitrates and sampling rates. Also, earlier work has shown that it is perfectly OK to tailor excisting codecs originally designed for circuit-switched access to work well in a packet-switched environment, see for instance http://www.ind.rwth-aachen.de/fileadmin/publications/mertz03.pdf (if you have access to the IEEE library I recommend a look at reference [3]). >=20 > > I see this not only as a RAI issue. This should be discussed at the=20 > > BoF. Also, I see that the main driver behind this WG is the=20 > strive for=20 > > a royalty free codec. >=20 >=20 > > Reality has however shown that this > > is much more complicated to achive than what is believed in the=20 > > beginning, >=20 > Again, I'd be interested if you could elaborate on this. The=20 > CELT codec is Xiph.Org's 5th codec (4th audio codec) and it=20 > has worked well so far. It's not a trivial task to do, but=20 > then patents are a reality for all software, not just codecs. OK... With H.264 the original intention was to make the baseline royaly-free, this however failed in the end. What makes you believe that IETF would work better here ?. The IPR situatuion has already been discussed by people more skilled in that area than me so I wont elaborate on this part.=20 In addition, reading your comment above, I don't really understand why you need IETF for the codec standardization?, why not just standardize your codecs in Xiph.org and propose a payload format in AVT?. This gives me the impression that the IETF involvement is just rubberstamping. >=20 > Cheers, >=20 > Jean-Marc >=20 From hoene@uni-tuebingen.de Wed Jun 24 02:21:47 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 D8F493A6F59 for ; Wed, 24 Jun 2009 02:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.174 X-Spam-Level: X-Spam-Status: No, score=-6.174 tagged_above=-999 required=5 tests=[AWL=0.075, 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 UhMpvHABSyZJ for ; Wed, 24 Jun 2009 02:21: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 725DF3A6B16 for ; Wed, 24 Jun 2009 02:21:46 -0700 (PDT) Received: from hoeneLenovoT60 (u-172-c216.cs.uni-tuebingen.de [134.2.172.216]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n5O9L3sv029335 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Jun 2009 11:21:04 +0200 From: "Christian Hoene" To: "'Ingemar Johansson S'" , "'Jean-Marc Valin'" References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se> In-Reply-To: <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se> Date: Wed, 24 Jun 2009 11:21:04 +0200 Message-ID: <008901c9f4ad$19be47f0$4d3ad7d0$@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: Acn0MDLy2GxBYXk0T4eaJtzQPMocLAAaKPVAAAPts3A= Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org, ron.even@gmail.com Subject: Re: [codec] Codec BOF approved, much work needed 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, 24 Jun 2009 09:21:47 -0000 Dear Ingemar Johannsson, > My point is that if we decide to step > into other SDOs areas so clearly as this BoF suggests, the benefits must > clearly outweight the risk that work in other IETF areas is disturbed. > This should be discussed at the BoF. > ... the EVS codec being specified in 3GPP clearly adresses > packet switched access at various bitrates and sampling rates. Also, > earlier work has shown that it is perfectly OK to tailor excisting > codecs originally designed for circuit-switched access to work well in a > packet-switched environment, see for instance > http://www.ind.rwth-aachen.de/fileadmin/publications/mertz03.pdf (if you > have access to the IEEE library I recommend a look at reference [3]). To my opinion, it is the greatest mistake of the traditional codec designs that they thought "Let's make a codec for circuit switched networks. It will work anyhow with packet sizes networks." In the days of NGN we do not need any support for circuit switched networks anymore. Why shall a codec be designed for a networking technology, which losses its relevance and importance at a high speed? One clear benefit of this BoF is that codec experts and Internet guys can come together to discuss on a codec intended only for the Internet. In my opinion, the requirements between a circuit switched codec design and a codec for the Internet differs, for example - The Internet codec should be royalty free because also most of the other Internet protocols are free of charge, too. It is a matter of fairness... - It should support packet loss concealment because it happens do often in the Internet. On the other hand, bit errors are quite seldom. - This BoF should think about a jitter compensation including modern time stretching and time concealment algorithms. Jitter is the norm not a "special" case. Codec designer should not ignore it. - The Internet codec should take advantage of a feedback loop for variable rate/frame control in order to allow a wide range of operation regardless of the current available bandwidth. Congestion control should a must for all Internet applications. BTW equally important to coding rate is the frame rate of a codec. All efficient ITU codecs that I am aware go, to not support variable frame rates. - It is fine if the internet codec has not perfect but fairly well audio quality. Most of the bandwidth is wasted for Internet packet headers anyhow. Does it make sense to optimize the coding rate, when Ethernet, IP, UDP, and RTP protocols are wasting bandwidth without any concerns? - Also, if no royalties and big money are involved, it does not make any difference, which of multiple nearly equally well designed codecs is selected. If the selection process is not as perfect as in ITU, a lot of money can be saved, which otherwise would be spend on professional codec testing. - Also, ITU, MPEG and 3GPP has failed yet to develop a codec supporting ultra low latency important for new kind of applications like ensemble performances over the net.. I am not a codec experts, but all these all requirements are quite different from the approach that the ITU follows. Also, the stockholders in the IETF are different. IETFs contribution are driven by individuals not by larger companies like in the ITU. Thus, hopefully the interests of users and the entire society will be considered to larger extend. > In addition, reading your comment above, I don't really understand why > you need IETF for the codec standardization?, why not just standardize > your codecs in Xiph.org and propose a payload format in AVT?. This gives > me the impression that the IETF involvement is just rubberstamping. If Jean-Marc wants to rubberstamp his codec, he has the option of submitting an independent RFC. Then, there is not be a need of a BoF... I do not believe this is the case. Greetings Christian Hoene From petithug@acm.org Wed Jun 24 02:36:33 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 DCBC328C48B for ; Wed, 24 Jun 2009 02:36:33 -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 GDvGJGw34pgL for ; Wed, 24 Jun 2009 02:36:32 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id DB86E3A67EB for ; Wed, 24 Jun 2009 02:36:32 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 91E5BDBCC01A; Wed, 24 Jun 2009 09:36:33 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id D7E97DBCC018; Wed, 24 Jun 2009 09:36:31 +0000 (UTC) Message-ID: <4A41F39F.5020402@acm.org> Date: Wed, 24 Jun 2009 02:36:31 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Christian Hoene References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se> <008901c9f4ad$19be47f0$4d3ad7d0$@de> In-Reply-To: <008901c9f4ad$19be47f0$4d3ad7d0$@de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: 'Ingemar Johansson S' , ron.even@gmail.com, codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 24 Jun 2009 09:36:34 -0000 Christian Hoene wrote: > Dear Ingemar Johannsson, > >> My point is that if we decide to step >> into other SDOs areas so clearly as this BoF suggests, the benefits must >> clearly outweight the risk that work in other IETF areas is disturbed. >> This should be discussed at the BoF. >> ... the EVS codec being specified in 3GPP clearly adresses >> packet switched access at various bitrates and sampling rates. Also, >> earlier work has shown that it is perfectly OK to tailor excisting >> codecs originally designed for circuit-switched access to work well in a >> packet-switched environment, see for instance >> http://www.ind.rwth-aachen.de/fileadmin/publications/mertz03.pdf (if you >> have access to the IEEE library I recommend a look at reference [3]). > > To my opinion, it is the greatest mistake of the traditional codec designs > that they thought "Let's make a codec for circuit switched networks. It will > work anyhow with packet sizes networks." In the days of NGN we do not need > any support for circuit switched networks anymore. Why shall a codec be > designed for a networking technology, which losses its relevance and > importance at a high speed? > > One clear benefit of this BoF is that codec experts and Internet guys can > come together to discuss on a codec intended only for the Internet. > > In my opinion, the requirements between a circuit switched codec design and > a codec for the Internet differs, for example > - The Internet codec should be royalty free because also most of the other > Internet protocols are free of charge, too. It is a matter of fairness... > - It should support packet loss concealment because it happens do often in > the Internet. On the other hand, bit errors are quite seldom. > - This BoF should think about a jitter compensation including modern time > stretching and time concealment algorithms. Jitter is the norm not a > "special" case. Codec designer should not ignore it. > - The Internet codec should take advantage of a feedback loop for variable > rate/frame control in order to allow a wide range of operation regardless of > the current available bandwidth. Congestion control should a must for all > Internet applications. BTW equally important to coding rate is the frame > rate of a codec. All efficient ITU codecs that I am aware go, to not support > variable frame rates. > - It is fine if the internet codec has not perfect but fairly well audio > quality. Most of the bandwidth is wasted for Internet packet headers anyhow. > Does it make sense to optimize the coding rate, when Ethernet, IP, UDP, and > RTP protocols are wasting bandwidth without any concerns? > - Also, if no royalties and big money are involved, it does not make any > difference, which of multiple nearly equally well designed codecs is > selected. If the selection process is not as perfect as in ITU, a lot of > money can be saved, which otherwise would be spend on professional codec > testing. > - Also, ITU, MPEG and 3GPP has failed yet to develop a codec supporting > ultra low latency important for new kind of applications like ensemble > performances over the net.. I would like to add support for layered coding in the codec in the list of requirements. This is the kind of requirement that is AFAIK specific to the Internet (multicast) and so it is an argument in favor of developing the codec in the IETF. (we did a bit of work at my previous employer to add layered coding to Speex, but that would be great to have the codec designed for layered coding from the beginning). -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From koen.vos@skype.net Wed Jun 24 03:05:16 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 3C8913A6909 for ; Wed, 24 Jun 2009 03:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.138 X-Spam-Level: X-Spam-Status: No, score=-6.138 tagged_above=-999 required=5 tests=[AWL=0.461, 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 wJ+3zAbwDWrL for ; Wed, 24 Jun 2009 03:05:15 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id C476D3A6BAD for ; Wed, 24 Jun 2009 03:05:14 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id AEADC2007A7AC for ; Wed, 24 Jun 2009 12:05:29 +0200 (CEST) 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=Pze218FXLrUZ p123CO9hgm8OQNI=; b=PwtWsbEJM8iQa2HZdRWeP/7gVVPUuu07eVt00sQY3qnn ait2v9pZmUe12myTfDcXfi2q04NTy+ev6LRvPN+FsNhW510Oj89XaZyM8KhAnMGJ Q7hTsufmZETEChPCiBuwjR7c1/rdsQ3R3uvRrFUNNVjoQQzy2upR8FHwv5nB9ns= 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=vPaXrRAt1UQ/rSlMhRys xQTB4sYbfhVrZ9Y05fGaBW9r/MQw7UVSlOAYC6QRK4wlwgAK8o7rRc/buxhX4n9i Y3kEn3QgNNvjIIP3Cws3zDp+mhepHo+D9u5QLwCeo7Eluiym0UYxsNmFqZnRCWEa KuxLZTQUSJP8TZ9/hjX1J3M= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id AD3962007A77F for ; Wed, 24 Jun 2009 12:05:29 +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 C9iKyMH20Ohc for ; Wed, 24 Jun 2009 12:05:29 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 07F832007A789; Wed, 24 Jun 2009 12:05:29 +0200 (CEST) Received: from adsl-71-141-96-214.dsl.snfc21.pacbell.net (adsl-71-141-96-214.dsl.snfc21.pacbell.net [71.141.96.214]) by mail.skype.net (Horde Framework) with HTTP; Wed, 24 Jun 2009 03:05:29 -0700 Message-ID: <20090624030529.40997313j6awm82x@mail.skype.net> Date: Wed, 24 Jun 2009 03:05:29 -0700 From: Koen Vos To: codec@ietf.org References: <6e9223710906230718p2b5cbdaekd98e6aa31ad32874@mail.gmail.com> In-Reply-To: <6e9223710906230718p2b5cbdaekd98e6aa31ad32874@mail.gmail.com> 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] Codec BOF approved, much work needed 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, 24 Jun 2009 10:05:16 -0000 Quoting stephen botzko: > G.722.1 is one ITU-T codec is that is available royalty-free, G.722.1 was not standardized as a royalty-free codec by ITU; it only became royalty-free after G.722.2 had been standardized. Similar for G.722: it is royalty-free now because the patents have expired. Clearly, ITU has a proven track record of standardizing royalty-bearing codecs. The last exception may have been G.711 (in 1972). > and actually [G.722.1] is quite suitable for use over the internet. G.722.1 is suitable for broadband connections with sufficient bandwidth. But with the Internet expanding to mobile devices connected through 3G+ networks, there is a need for codecs running at lower bitrates. koen From ron.even.tlv@gmail.com Wed Jun 24 03:08:27 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 059973A6BD1 for ; Wed, 24 Jun 2009 03:08:27 -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=[AWL=0.001, 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 VyN65rz2OjKH for ; Wed, 24 Jun 2009 03:08:25 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 1BF463A6A55 for ; Wed, 24 Jun 2009 03:08:24 -0700 (PDT) Received: by bwz9 with SMTP id 9so615509bwz.37 for ; Wed, 24 Jun 2009 03:08:39 -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:thread-index:content-language; bh=yP4QY6ZyGpX9QfigoBMZcO2HUhQMPGbgME1VGhiadx8=; b=IivQThfgDJoqG1fwNuw46tqhs8opdhP50UIkitRJgjG5yzBgjM2EjXC5Z+NgCaqElV Wv8M1x6oajKIuGiKKR+Nyidp+tW5DsvlU1Kp25PNVwEpgsdi9C70RI9CHPE9BvP74cjO uAjkCmgd7wQoj36dFkKuS/PjdU+GZ+TM7vYHw= 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 :thread-index:content-language; b=BF44Q/iLZbFz/sUeLX3cmmoAtkhLlDFVnFPY8C6qniKee7mLGcCB5bGRc71/mnnsrG 7ho0U+VfzwSf9/cssTEkqFeIHCfzU3CS+fPYOaeeoQ9OPwoAKfPA2UkGPPwv3e7rSm0S r9k0gnW45JYXHjH6v+OcMv/oqL6ilPEBGQtqI= Received: by 10.103.226.20 with SMTP id d20mr563326mur.17.1245838119004; Wed, 24 Jun 2009 03:08:39 -0700 (PDT) Received: from windows8d787f9 (bzq-79-181-103-217.red.bezeqint.net [79.181.103.217]) by mx.google.com with ESMTPS id j6sm4326355mue.31.2009.06.24.03.08.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 24 Jun 2009 03:08:37 -0700 (PDT) From: "Roni Even" To: "'Christian Hoene'" , "'Ingemar Johansson S'" , "'Jean-Marc Valin'" References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se> <008901c9f4ad$19be47f0$4d3ad7d0$@de> In-Reply-To: <008901c9f4ad$19be47f0$4d3ad7d0$@de> Date: Wed, 24 Jun 2009 13:08:30 +0300 Message-ID: <4a41fb25.06a1660a.2306.5ed8@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn0MDLy2GxBYXk0T4eaJtzQPMocLAAaKPVAAAPts3AAAjGWwA== Content-Language: en-us Cc: ron.even@gmail.com, codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 24 Jun 2009 10:08:27 -0000 Hi, The list you gave is not a codec requirement but a system requirement including all layers, this is not codec work, and maybe it shows why the IETF does not have currently the expertise to do such work. A small note, there is a contradiction between ensemble performance and low quality speech codec and by the way this application is already being used in distance video conferencing applications. It also require good support for open microphone. I will not go through your list but the information you gave about ITU codec not designed for the Internet but only for circuit switch is not correct please check the requirements that were used and the tests that were done for ITU codecs including support for packet loss. As for the comment " If Jean-Marc wants to rubberstamp his codec, he has the option of submitting an independent RFC". I think this is not true since my understanding is that the IETF currently will not look at such work even for informational RFC since it felt that there is no knowledge at the IETF to evaluate it. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Christian Hoene > Sent: Wednesday, June 24, 2009 12:21 PM > To: 'Ingemar Johansson S'; 'Jean-Marc Valin' > Cc: codec@ietf.org; ron.even@gmail.com > Subject: Re: [codec] Codec BOF approved, much work needed > > Dear Ingemar Johannsson, > > > My point is that if we decide to step > > into other SDOs areas so clearly as this BoF suggests, the benefits > must > > clearly outweight the risk that work in other IETF areas is > disturbed. > > This should be discussed at the BoF. > > ... the EVS codec being specified in 3GPP clearly adresses > > packet switched access at various bitrates and sampling rates. Also, > > earlier work has shown that it is perfectly OK to tailor excisting > > codecs originally designed for circuit-switched access to work well > in a > > packet-switched environment, see for instance > > http://www.ind.rwth-aachen.de/fileadmin/publications/mertz03.pdf (if > you > > have access to the IEEE library I recommend a look at reference [3]). > > To my opinion, it is the greatest mistake of the traditional codec > designs > that they thought "Let's make a codec for circuit switched networks. It > will > work anyhow with packet sizes networks." In the days of NGN we do not > need > any support for circuit switched networks anymore. Why shall a codec be > designed for a networking technology, which losses its relevance and > importance at a high speed? > > One clear benefit of this BoF is that codec experts and Internet guys > can > come together to discuss on a codec intended only for the Internet. > > In my opinion, the requirements between a circuit switched codec design > and > a codec for the Internet differs, for example > - The Internet codec should be royalty free because also most of the > other > Internet protocols are free of charge, too. It is a matter of > fairness... > - It should support packet loss concealment because it happens do often > in > the Internet. On the other hand, bit errors are quite seldom. > - This BoF should think about a jitter compensation including modern > time > stretching and time concealment algorithms. Jitter is the norm not a > "special" case. Codec designer should not ignore it. > - The Internet codec should take advantage of a feedback loop for > variable > rate/frame control in order to allow a wide range of operation > regardless of > the current available bandwidth. Congestion control should a must for > all > Internet applications. BTW equally important to coding rate is the > frame > rate of a codec. All efficient ITU codecs that I am aware go, to not > support > variable frame rates. > - It is fine if the internet codec has not perfect but fairly well > audio > quality. Most of the bandwidth is wasted for Internet packet headers > anyhow. > Does it make sense to optimize the coding rate, when Ethernet, IP, UDP, > and > RTP protocols are wasting bandwidth without any concerns? > - Also, if no royalties and big money are involved, it does not make > any > difference, which of multiple nearly equally well designed codecs is > selected. If the selection process is not as perfect as in ITU, a lot > of > money can be saved, which otherwise would be spend on professional > codec > testing. > - Also, ITU, MPEG and 3GPP has failed yet to develop a codec supporting > ultra low latency important for new kind of applications like ensemble > performances over the net.. > > I am not a codec experts, but all these all requirements are quite > different > from the approach that the ITU follows. Also, the stockholders in the > IETF > are different. IETFs contribution are driven by individuals not by > larger > companies like in the ITU. Thus, hopefully the interests of users and > the > entire society will be considered to larger extend. > > > In addition, reading your comment above, I don't really understand > why > > you need IETF for the codec standardization?, why not just > standardize > > your codecs in Xiph.org and propose a payload format in AVT?. This > gives > > me the impression that the IETF involvement is just rubberstamping. > > If Jean-Marc wants to rubberstamp his codec, he has the option of > submitting > an independent RFC. Then, there is not be a need of a BoF... I do not > believe this is the case. > > Greetings > Christian Hoene > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From herve.taddei@huawei.com Wed Jun 24 03:19:21 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 6F6D43A6A55 for ; Wed, 24 Jun 2009 03:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.299, 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 XW--EdyvkaPA for ; Wed, 24 Jun 2009 03:19:15 -0700 (PDT) Received: from lhrga01-in.huawei.com (lhrga01-in.huawei.com [195.33.106.110]) by core3.amsl.com (Postfix) with ESMTP id CD6F93A6A3D for ; Wed, 24 Jun 2009 03:19:14 -0700 (PDT) Received: from huawei.com (lhrml01-in [172.18.7.5]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KLQ003MVNCGPE@lhrga01-in.huawei.com> for codec@ietf.org; Wed, 24 Jun 2009 11:19:28 +0100 (BST) Received: from PCHERVE (host-85-30-160-140.sydskane.nu [85.30.160.140]) by lhrga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KLQ000QWNCA4L@lhrga01-in.huawei.com> for codec@ietf.org; Wed, 24 Jun 2009 11:19:28 +0100 (BST) Date: Wed, 24 Jun 2009 12:19:10 +0200 From: Herve Taddei In-reply-to: <008901c9f4ad$19be47f0$4d3ad7d0$@de> To: codec@ietf.org Message-id: <004a01c9f4b5$3b525840$0aa31e55@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: multipart/alternative; boundary="Boundary_(ID_1Uv4q5q0D21w5e7zblh7CA)" Thread-index: Acn0MDLy2GxBYXk0T4eaJtzQPMocLAAaKPVAAAPts3AAAWz5UA== References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se> <008901c9f4ad$19be47f0$4d3ad7d0$@de> Subject: Re: [codec] Codec BOF approved, much work needed 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, 24 Jun 2009 10:19:21 -0000 This is a multi-part message in MIME format. --Boundary_(ID_1Uv4q5q0D21w5e7zblh7CA) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Dear Christian, > One clear benefit of this BoF is that codec experts and Internet guys > can > come together to discuss on a codec intended only for the Internet. There has been quite a bit of concerns raised that this is not going to be the case. I would be interested also in understanding what you call "the Internet". Is that a network, a protocol, an application? ITU-T worked on codec for VoIP, 3GPP is looking to PS networks codecs and we hear companies speaking about all IP network. Is that what you call Internet? Then there is nothing really different to what is looking out by other SDOs. > - The Internet codec should be royalty free because also most of the other > Internet protocols are free of charge, too. It is a matter of fairness... We don't speak about protocols here but codecs. > the current available bandwidth. Congestion control should a must for all > Internet applications. BTW equally important to coding rate is the frame > rate of a codec. All efficient ITU codecs that I am aware go, to not support > variable frame rates. What about scalable codecs defined in ITU-T as G.718, G.729.1 or even G.722? They can well address congestion control. And I imagined you heard about G.722.2 (aka AMR-WB) that is an adaptive multi rate codec whose bitrate can be changed during the communication. > - It is fine if the internet codec has not perfect but fairly well audio > quality. Most of the bandwidth is wasted for Internet packet headers anyhow. Header compression can be used to reduce overhead. What is fairly well audio quality? > Does it make sense to optimize the coding rate, when Ethernet, IP, UDP, and > RTP protocols are wasting bandwidth without any concerns? Then why not transmitting non compressed audio signal? > selected. If the selection process is not as perfect as in ITU, a lot of > money can be saved, which otherwise would be spend on professional codec > testing. The money you save on one side will be lost on the other side when you will have to install and discuss mechanisms to interoperate with existing codecs. > - Also, ITU, MPEG and 3GPP has failed yet to develop a codec supporting > ultra low latency important for new kind of applications like ensemble > performances over the net.. G.711, G.711.1, G.722? At least those are low latency to my opinion. How do you define ultra low latency? BTW, for VoIP, the lower the delay the higher the overhead. That is why many VoIP codecs are rather looking to 10/20 and even 30 ms frame size. > I am not a codec experts, I think that is why many people would prefer that codec work is conducted where audio experts are, in other SDOs as ITU-T and 3GPP. > from the approach that the ITU follows. Also, the stockholders in the IETF > are different. IETFs contribution are driven by individuals not by larger > companies like in the ITU. Thus, hopefully the interests of users and the BTW, you could give a look to the ITU-T list of companies, there are some very small companies registered, sometime with less than 10 employees. So this statement is not really correct. Best regards Herve --Boundary_(ID_1Uv4q5q0D21w5e7zblh7CA) Content-type: text/html; charset=us-ascii Content-transfer-encoding: 7BIT

Dear Christian,

 

> One clear benefit of this BoF is that codec experts and Internet guys

> can

> come together to discuss on a codec intended only for the Internet.

There has been quite a bit of concerns raised that this is not going to be the case. I would be interested also in understanding what you call “the Internet”. Is that a network, a protocol, an application? ITU-T worked on codec for VoIP, 3GPP is looking to PS networks codecs and we hear companies speaking about all IP network. Is that what you call Internet? Then there is nothing really different to what is looking out by other SDOs.

 

> - The Internet codec should be royalty free because also most of the other

> Internet protocols are free of charge, too. It is a matter of fairness...

We don’t speak about protocols here but codecs.

 

> the current available bandwidth. Congestion control should a must for all

> Internet applications. BTW equally important to coding rate is the frame

> rate of a codec. All efficient ITU codecs that I am aware go, to not support

> variable frame rates.

What about scalable codecs defined in ITU-T as G.718, G.729.1 or even G.722? They can well address congestion control. And I imagined you heard about G.722.2 (aka AMR-WB) that is an adaptive multi rate codec whose bitrate can be changed during the communication.

 

> - It is fine if the internet codec has not perfect but fairly well audio

> quality. Most of the bandwidth is wasted for Internet packet headers anyhow.

Header compression can be used to reduce overhead. What is fairly well audio quality?

 

> Does it make sense to optimize the coding rate, when Ethernet, IP, UDP, and

> RTP protocols are wasting bandwidth without any concerns?

Then why not transmitting non compressed audio signal?

 

> selected. If the selection process is not as perfect as in ITU, a lot of

> money can be saved, which otherwise would be spend on professional codec

> testing.

The money you save on one side will be lost on the other side when you will have to install and discuss mechanisms to interoperate with existing codecs.

 

> - Also, ITU, MPEG and 3GPP has failed yet to develop a codec supporting

> ultra low latency important for new kind of applications like ensemble

> performances over the net..

G.711, G.711.1, G.722? At least those are low latency to my opinion.

How do you define ultra low latency? BTW, for VoIP, the lower the delay the higher the overhead. That is why many VoIP codecs are rather looking to 10/20 and even 30 ms frame size.

 

> I am not a codec experts,

I think that is why many people would prefer that codec work is conducted where audio experts are, in other SDOs as ITU-T and 3GPP.

 

> from the approach that the ITU follows. Also, the stockholders in the IETF

> are different. IETFs contribution are driven by individuals not by larger

> companies like in the ITU. Thus, hopefully the interests of users and the

BTW, you could give a look to the ITU-T list of companies, there are some very small companies registered, sometime with less than 10 employees. So this statement is not really correct.

 

Best regards

 

Herve

--Boundary_(ID_1Uv4q5q0D21w5e7zblh7CA)-- From Jon.Gibbs@motorola.com Wed Jun 24 03:24: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 4B6053A6F65 for ; Wed, 24 Jun 2009 03:24:45 -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 Gf9KQNUrNWgf for ; Wed, 24 Jun 2009 03:24:43 -0700 (PDT) Received: from mail128.messagelabs.com (mail128.messagelabs.com [216.82.250.131]) by core3.amsl.com (Postfix) with ESMTP id DB6853A6F64 for ; Wed, 24 Jun 2009 03:24:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Jon.Gibbs@motorola.com X-Msg-Ref: server-9.tower-128.messagelabs.com!1245839092!19432110!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [129.188.136.8] Received: (qmail 6774 invoked from network); 24 Jun 2009 10:24:53 -0000 Received: from motgate8.mot.com (HELO motgate8.mot.com) (129.188.136.8) by server-9.tower-128.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Jun 2009 10:24:53 -0000 Received: from il06exr04.mot.com (il06exr04.mot.com [129.188.137.134]) by motgate8.mot.com (8.14.3/8.14.3) with ESMTP id n5OAOkmI026702 for ; Wed, 24 Jun 2009 03:24:52 -0700 (MST) Received: from il06vts02.mot.com (il06vts02.mot.com [129.188.137.142]) by il06exr04.mot.com (8.13.1/Vontu) with SMTP id n5OAOkTC009194 for ; Wed, 24 Jun 2009 05:24:46 -0500 (CDT) Received: from zuk35exm64.ds.mot.com (zuk35exm64.ea.mot.com [10.178.4.15]) by il06exr04.mot.com (8.13.1/8.13.0) with ESMTP id n5OAOj90009191 for ; Wed, 24 Jun 2009 05:24:46 -0500 (CDT) 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: Wed, 24 Jun 2009 11:24:24 +0100 Message-ID: In-Reply-To: <4A41F39F.5020402@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acn0r1A7AQxg4xe8ScqVC8R0kf9VEQAAYa3Q References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se><008901c9f4ad$19be47f0$4d3ad7d0$@de> <4A41F39F.5020402@acm.org> From: "Gibbs Jon-CJG019" To: X-CFilter-Loop: Reflected Subject: Re: [codec] Codec BOF approved, much work needed 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, 24 Jun 2009 10:24:45 -0000 Dear All, There seem to be a few misconceptions about the codec development work of the ITU-T which I feel ought to be pointed out... > To my opinion, it is the greatest mistake of the traditional codec=20 > designs that they thought "Let's make a codec for circuit switched=20 > networks. It will work anyhow with packet sizes networks."=20 > I would like to add support for layered coding in the codec in the list of requirements. This > is the kind of requirement that is AFAIK specific to the Internet (multicast) and so it is an > argument in favor of developing the codec in the IETF. Please take a look at the features of the relatively recent ITU-T Codecs and, in particular, Rec ITU-T G.718 (http://www.itu.int/rec/T-REC-G.718/en & http://en.wikipedia.org/wiki/G.718). G.718 is optimized for packet transmission and highly resistant to packet loss. It provides a layered solution starting at 8kb/s for wideband speech transmission and there are also superwideband and stereo enhancement layers in development. So, I think that it's fair to say that the ITU-T does develop codecs which have relevance to the work of IETF.=20 Regards Jon Gibbs -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Marc Petit-Huguenin Sent: 24 June 2009 10:37 To: Christian Hoene Cc: 'Ingemar Johansson S'; ron.even@gmail.com; codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Christian Hoene wrote: > Dear Ingemar Johannsson, >=20 >> My point is that if we decide to step into other SDOs areas so=20 >> clearly as this BoF suggests, the benefits must clearly outweight the >> risk that work in other IETF areas is disturbed. >> This should be discussed at the BoF. >> ... the EVS codec being specified in 3GPP clearly adresses packet=20 >> switched access at various bitrates and sampling rates. Also, earlier >> work has shown that it is perfectly OK to tailor excisting codecs=20 >> originally designed for circuit-switched access to work well in a=20 >> packet-switched environment, see for instance=20 >> http://www.ind.rwth-aachen.de/fileadmin/publications/mertz03.pdf (if=20 >> you have access to the IEEE library I recommend a look at reference [3]). >=20 > To my opinion, it is the greatest mistake of the traditional codec=20 > designs that they thought "Let's make a codec for circuit switched=20 > networks. It will work anyhow with packet sizes networks." In the days > of NGN we do not need any support for circuit switched networks=20 > anymore. Why shall a codec be designed for a networking technology,=20 > which losses its relevance and importance at a high speed? >=20 > One clear benefit of this BoF is that codec experts and Internet guys=20 > can come together to discuss on a codec intended only for the Internet. >=20 > In my opinion, the requirements between a circuit switched codec=20 > design and a codec for the Internet differs, for example > - The Internet codec should be royalty free because also most of the=20 > other Internet protocols are free of charge, too. It is a matter of fairness... > - It should support packet loss concealment because it happens do=20 > often in the Internet. On the other hand, bit errors are quite seldom. > - This BoF should think about a jitter compensation including modern=20 > time stretching and time concealment algorithms. Jitter is the norm=20 > not a "special" case. Codec designer should not ignore it. > - The Internet codec should take advantage of a feedback loop for=20 > variable rate/frame control in order to allow a wide range of=20 > operation regardless of the current available bandwidth. Congestion=20 > control should a must for all Internet applications. BTW equally=20 > important to coding rate is the frame rate of a codec. All efficient=20 > ITU codecs that I am aware go, to not support variable frame rates. > - It is fine if the internet codec has not perfect but fairly well=20 > audio quality. Most of the bandwidth is wasted for Internet packet headers anyhow. > Does it make sense to optimize the coding rate, when Ethernet, IP,=20 > UDP, and RTP protocols are wasting bandwidth without any concerns? > - Also, if no royalties and big money are involved, it does not make=20 > any difference, which of multiple nearly equally well designed codecs=20 > is selected. If the selection process is not as perfect as in ITU, a=20 > lot of money can be saved, which otherwise would be spend on=20 > professional codec testing. > - Also, ITU, MPEG and 3GPP has failed yet to develop a codec=20 > supporting ultra low latency important for new kind of applications=20 > like ensemble performances over the net.. I would like to add support for layered coding in the codec in the list of requirements. This is the kind of requirement that is AFAIK specific to the Internet (multicast) and so it is an argument in favor of developing the codec in the IETF. (we did a bit of work at my previous employer to add layered coding to Speex, but that would be great to have the codec designed for layered coding from the beginning). -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From petithug@acm.org Wed Jun 24 04:21:51 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 C44DE3A6A69 for ; Wed, 24 Jun 2009 04:21:51 -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 KH3Vbog4xaNX for ; Wed, 24 Jun 2009 04:21:50 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id CB1583A6A65 for ; Wed, 24 Jun 2009 04:21:50 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 944DBDBCC01A; Wed, 24 Jun 2009 11:21:55 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 86076DBCC018; Wed, 24 Jun 2009 11:21:54 +0000 (UTC) Message-ID: <4A420C51.5060603@acm.org> Date: Wed, 24 Jun 2009 04:21:53 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Gibbs Jon-CJG019 References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se><008901c9f4ad$19be47f0$4d3ad7d0$@de> <4A41F39F.5020402@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 24 Jun 2009 11:21:51 -0000 Gibbs Jon-CJG019 wrote: > Dear All, > There seem to be a few misconceptions about the codec development work > of the ITU-T which I feel ought to be pointed out... > >> To my opinion, it is the greatest mistake of the traditional codec >> designs that they thought "Let's make a codec for circuit switched >> networks. It will work anyhow with packet sizes networks." > >> I would like to add support for layered coding in the codec in the > list of requirements. This > is the kind of requirement that is AFAIK > specific to the Internet (multicast) and so it is an > argument in favor > of developing the codec in the IETF. > > Please take a look at the features of the relatively recent ITU-T Codecs > and, in particular, Rec ITU-T G.718 > (http://www.itu.int/rec/T-REC-G.718/en & > http://en.wikipedia.org/wiki/G.718). G.718 is optimized for packet > transmission and highly resistant to packet loss. It provides a layered > solution starting at 8kb/s for wideband speech transmission and there > are also superwideband and stereo enhancement layers in development. I missed this draft, but yes, this is exactly what I am talking about. All RTP payload (and hopefully all future IETF codecs) should be designed like this. Too bad there is no open source implementation and an IPR statement on this draft. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From Jon.Gibbs@motorola.com Wed Jun 24 04:53:33 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 B6E663A6907 for ; Wed, 24 Jun 2009 04:53:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.651 X-Spam-Level: X-Spam-Status: No, score=-5.651 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB22=0.948] 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 eKi1Vo5FwBOO for ; Wed, 24 Jun 2009 04:53:32 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by core3.amsl.com (Postfix) with SMTP id 7C64B3A6767 for ; Wed, 24 Jun 2009 04:53:32 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Jon.Gibbs@motorola.com X-Msg-Ref: server-5.tower-119.messagelabs.com!1245844259!32091261!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 23356 invoked from network); 24 Jun 2009 11:51:00 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (136.182.1.14) by server-5.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Jun 2009 11:51:00 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate4.mot.com (8.14.3/8.14.3) with ESMTP id n5OBoxj5009772 for ; Wed, 24 Jun 2009 04:50:59 -0700 (MST) Received: from il27vts02.mot.com (il27vts02.cig.mot.com [10.17.196.86]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id n5OBoxuU004055 for ; Wed, 24 Jun 2009 06:50:59 -0500 (CDT) Received: from zuk35exm64.ds.mot.com (zuk35exm64.ea.mot.com [10.178.4.15]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id n5OBowmC004048 for ; Wed, 24 Jun 2009 06:50:58 -0500 (CDT) 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: Wed, 24 Jun 2009 12:50:36 +0100 Message-ID: In-Reply-To: <4A420C51.5060603@acm.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acn0vgB/EC8P90ZCTcqwU4qo3VDs2AAAXa1Q References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se><008901c9f4ad$19be47f0$4d3ad7d0$@de> <4A41F39F.5020402@acm.org> <4A420C51.5060603@acm.org> From: "Gibbs Jon-CJG019" To: "Marc Petit-Huguenin" X-CFilter-Loop: Reflected Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 24 Jun 2009 11:53:33 -0000 Marc Petit-Huguenin wrote: >Too bad there is no open source implementation and an IPR statement on this draft. FYI, The fixed point source code is freely available here (http://www.itu.int/rec/T-REC-G.718/en) already, all 60,000 lines of it, and the floating point code is coming soon as you'll see. The declared IPR patent and copyright statements may be found here http://www.itu.int/ipr/IPRSearch.aspx - just enter "G.718" for Recommendation No. ...but it seems that you've already decided that it's not for you, or the IETF... ...and so you want to re-invent the wheel... ...paradoxically to save some money...=20 ..."Too bad", indeed! Jon Gibbs -----Original Message----- From: Marc Petit-Huguenin [mailto:petithug@acm.org]=20 Sent: 24 June 2009 12:22 To: Gibbs Jon-CJG019 Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed Gibbs Jon-CJG019 wrote: > Dear All, > There seem to be a few misconceptions about the codec development work > of the ITU-T which I feel ought to be pointed out... >=20 >> To my opinion, it is the greatest mistake of the traditional codec=20 >> designs that they thought "Let's make a codec for circuit switched=20 >> networks. It will work anyhow with packet sizes networks." >=20 >> I would like to add support for layered coding in the codec in the > list of requirements. This > is the kind of requirement that is AFAIK > specific to the Internet (multicast) and so it is an > argument in=20 > favor of developing the codec in the IETF. >=20 > Please take a look at the features of the relatively recent ITU-T=20 > Codecs and, in particular, Rec ITU-T G.718=20 > (http://www.itu.int/rec/T-REC-G.718/en &=20 > http://en.wikipedia.org/wiki/G.718). G.718 is optimized for packet=20 > transmission and highly resistant to packet loss. It provides a=20 > layered solution starting at 8kb/s for wideband speech transmission=20 > and there are also superwideband and stereo enhancement layers in development. I missed this draft, but yes, this is exactly what I am talking about. All RTP payload (and hopefully all future IETF codecs) should be designed like this. Too bad there is no open source implementation and an IPR statement on this draft. -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From jean-marc.valin@usherbrooke.ca Wed Jun 24 05:29:08 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 D817128C37F for ; Wed, 24 Jun 2009 05:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, SARE_UNSUB22=0.948] 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 tQpuhr7KwETa for ; Wed, 24 Jun 2009 05:29:08 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 017783A6F9A for ; Wed, 24 Jun 2009 05:28:46 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.10] ([70.81.109.112]) by VL-MH-MR002.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KLQ00H0HT9OLA00@VL-MH-MR002.ip.videotron.ca> for codec@ietf.org; Wed, 24 Jun 2009 08:27:25 -0400 (EDT) Message-id: <4A421BAC.1030206@usherbrooke.ca> Date: Wed, 24 Jun 2009 08:27:24 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) To: Gibbs Jon-CJG019 References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se> <008901c9f4ad$19be47f0$4d3ad7d0$@de> <4A41F39F.5020402@acm.org> <4A420C51.5060603@acm.org> In-reply-to: X-Enigmail-Version: 0.95.2 Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 24 Jun 2009 12:29:08 -0000 Gibbs Jon-CJG019 a écrit : > Marc Petit-Huguenin wrote: >> Too bad there is no open source implementation and an IPR statement on > this draft. > > FYI, > The fixed point source code is freely available here > (http://www.itu.int/rec/T-REC-G.718/en) already, all 60,000 lines of it, > and the floating point code is coming soon as you'll see. "source code freely available" and "open source implementation" are totally different things. I suggest you have a look at (first Google result) http://www.opensource.org/docs/definition.php > The declared IPR patent and copyright statements may be found here > http://www.itu.int/ipr/IPRSearch.aspx - just enter "G.718" for > Recommendation No. > > ...but it seems that you've already decided that it's not for you, or > the IETF... It is actually the other way around. Someone has decided that G.718 was not for us. I am not familiar with all the technical details of G.718, but I have no problem imagining that it fits the telco's needs very well -- even for IP transport. The problem is that its licensing makes it impossible to use for many applications because of the patents it involves. How good is a codec which you cannot use. If my VoIP application has to be freely downloadable, or embedded in a web page as a Java applet, or if I want to link it with open source software... then a patent-encumbered codec cannot be legally used. What are you suggesting we should do. So far, I see three possible options: 1) Break the law by infringing on patents 2) Use codecs on which patents are expired (G.711 and GSM-FR are still popular) 3) Design a new codec that will solve the problem I choose 3). Jean-Marc From hoene@uni-tuebingen.de Wed Jun 24 05:44:46 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 C198028C37F for ; Wed, 24 Jun 2009 05:44:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.199 X-Spam-Level: X-Spam-Status: No, score=-6.199 tagged_above=-999 required=5 tests=[AWL=0.050, 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 AD42whYuTJPr for ; Wed, 24 Jun 2009 05:44: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 AD66628C0FE for ; Wed, 24 Jun 2009 05:44:45 -0700 (PDT) Received: from hoeneLenovoT60 (u-172-c216.cs.uni-tuebingen.de [134.2.172.216]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n5OBtwtp024278 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 24 Jun 2009 13:55:58 +0200 From: "Christian Hoene" To: "'Roni Even'" References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se> <008901c9f4ad$19be47f0$4d3ad7d0$@de> <4a41fb25.06a1660a.2306.5ed8@mx.google.com> In-Reply-To: <4a41fb25.06a1660a.2306.5ed8@mx.google.com> Date: Wed, 24 Jun 2009 13:55:58 +0200 Message-ID: <00a901c9f4c2$bd33ef60$379bce20$@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: Acn0MDLy2GxBYXk0T4eaJtzQPMocLAAaKPVAAAPts3AAAjGWwAAD0a8A Content-Language: de x-cr-hashedpuzzle: Am99 BqPS B7gh E8lS Flnt IS70 L6e4 OzN4 Qdgk RWxT TXn8 Tqtp UFJ8 UkXb VpkN VsEy; 2; YwBvAGQAZQBjAEAAaQBlAHQAZgAuAG8AcgBnADsAcgBvAG4ALgBlAHYAZQBuAC4AdABsAHYAQABnAG0AYQBpAGwALgBjAG8AbQA=; Sosha1_v1; 7; {911EAF53-A13F-40F2-804C-A0198B0FBA04}; aABvAGUAbgBlAEAAdQBuAGkALQB0AHUAZQBiAGkAbgBnAGUAbgAuAGQAZQA=; Wed, 24 Jun 2009 11:55:11 GMT; UgBFADoAIABbAGMAbwBkAGUAYwBdACAAQwBvAGQAZQBjACAAQgBPAEYAIABhAHAAcAByAG8AdgBlAGQALAAgAG0AdQBjAGgAIAB3AG8AcgBrACAAbgBlAGUAZABlAGQA x-cr-puzzleid: {911EAF53-A13F-40F2-804C-A0198B0FBA04} X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 24 Jun 2009 12:44:46 -0000 Hi Roni, > The list you gave is not a codec requirement but a system requirement > including all layers, this is not codec work, and maybe it shows why the > IETF does not have currently the expertise to do such work. But should the codec be aware of the surrounding system? Does it makes sense to have a perfect codec, if the rest of the system is in bad shape or the interfaces between system and codec are not defined rightly? The last ten years of research have shown that a joint optimization of codec and the rest of the system can yield high performance gains. For example, if the time concealment, the controlling of the frame rate, or the amount of FEC/redundancy are controlled jointly. To support these enhancements, the old functionality split between codecs and the rest of the world cannot be maintained. > I will not go through your list but the information you gave about ITU codec > not designed for the Internet but only for circuit switch is not correct > please check the requirements that were used and the tests that were done > for ITU codecs including support for packet loss. Please, Roni, convince me with technical arguments and references to documents that I am wrong. Then--I promise--I will stop to discuss these issues immediately. Christian From stephen.botzko@gmail.com Wed Jun 24 05:50:54 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 C648E3A6F7E for ; Wed, 24 Jun 2009 05:50:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.919 X-Spam-Level: X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[AWL=0.679, 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 PhBRK2yaPatt for ; Wed, 24 Jun 2009 05:50:53 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 78D9F3A6C4E for ; Wed, 24 Jun 2009 05:50:53 -0700 (PDT) Received: by fxm9 with SMTP id 9so721209fxm.37 for ; Wed, 24 Jun 2009 05:49: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:message-id:subject:from:to:cc:content-type; bh=kCrx2C5NdbPP1oZ7K2CIcNya7XO/0Birg6N40aveimQ=; b=pafMVbzP8OVIk9aZGsZ5OTg1k4qUgt5g/eNZhhP29XM5CZp/RkXHWt1MYciyIn1++1 T0eldkWhF4PWAHazD3XRSy0QCDbRGwOcBZfQOjBjtrI6xIP+VptAgLYH9W7QQ5sfe5Vk mOJQLKi8qC1kflRaddwBXad0rvY0KY45uw0Kk= 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=s98O4//FDyWeCuWUO/Qm7SbppOsfEf2akcX3Xo1i6peVGiVj6x0kPQFvPeLRbIHpUK Sx+BuHk5pCJsoW4HzQWTPcvMP15bXxQf11QbLN3ctfNsu1taMuhm2uNwuMRj7Qaj8Xyt aeaj9ZxEgsNsncUP3Twawfz4vJ9OAABDTsfhw= MIME-Version: 1.0 Received: by 10.103.240.15 with SMTP id s15mr667990mur.102.1245847783159; Wed, 24 Jun 2009 05:49:43 -0700 (PDT) In-Reply-To: <20090624030529.40997313j6awm82x@mail.skype.net> References: <6e9223710906230718p2b5cbdaekd98e6aa31ad32874@mail.gmail.com> <20090624030529.40997313j6awm82x@mail.skype.net> Date: Wed, 24 Jun 2009 08:49:43 -0400 Message-ID: <6e9223710906240549w16609bd3n7c5024056490bc18@mail.gmail.com> From: stephen botzko To: Koen Vos Content-Type: multipart/alternative; boundary=0016367ed4e18f38ef046d178a1c Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 24 Jun 2009 12:50:54 -0000 --0016367ed4e18f38ef046d178a1c Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit G.722.1 became royalty free when Polycom decided to offer it on royalty-free terms. Annex C (2005) is higher quality, and has always been royalty free. It made sense for us to offer G.722.1 itself on the same terms as Annex C. This decision was not related to G.722.2. I agree that G.722.1 is not suitable for low-bandwidth connections. Other codecs (including Silk of course) are. Stephen Botzko Polycom On Wed, Jun 24, 2009 at 6:05 AM, Koen Vos wrote: > Quoting stephen botzko: > >> G.722.1 is one ITU-T codec is that is available royalty-free, >> > > G.722.1 was not standardized as a royalty-free codec by ITU; it only became > royalty-free after G.722.2 had been standardized. Similar for G.722: it is > royalty-free now because the patents have expired. > > Clearly, ITU has a proven track record of standardizing royalty-bearing > codecs. The last exception may have been G.711 (in 1972). > > > and actually [G.722.1] is quite suitable for use over the internet. >> > > G.722.1 is suitable for broadband connections with sufficient bandwidth. > But with the Internet expanding to mobile devices connected through 3G+ > networks, there is a need for codecs running at lower bitrates. > > koen > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016367ed4e18f38ef046d178a1c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable G.722.1 became royalty free when Polycom decided to offer it on royalty-fre= e terms.=A0 Annex C (2005) is higher quality, and has always been royalty f= ree. It made sense for us to offer G.722.1 itself on the same terms as Anne= x C.=A0 This decision was not related to G.722.2.

I agree that G.722.1 is not suitable for low-bandwidth connections.=A0 = Other codecs (including Silk of course) are.

Stephen Botzko
Polyc= om


On Wed, Jun 24, 2009 at 6:05 AM, K= oen Vos <koen.vo= s@skype.net> wrote:
Quoting stephen botzko:
G.722.1 is one ITU-T codec is that is available royalty-free,

G.722.1 was not standardized as a royalty-free codec by ITU; it only became= royalty-free after G.722.2 had been standardized. Similar for G.722: it is= royalty-free now because the patents have expired.

Clearly, ITU has a proven track record of standardizing royalty-bearing cod= ecs. The last exception may have been G.711 (in 1972).


and actually [G.722.1] is quite suitable for use over the internet.

G.722.1 is suitable for broadband connections with sufficient bandwidth. Bu= t with the Internet expanding to mobile devices connected through 3G+ netwo= rks, there is a need for codecs running at lower bitrates.

koen


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

--0016367ed4e18f38ef046d178a1c-- From stephen.botzko@gmail.com Wed Jun 24 05:55: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 57FEA3A6F10 for ; Wed, 24 Jun 2009 05:55:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.004 X-Spam-Level: X-Spam-Status: No, score=-2.004 tagged_above=-999 required=5 tests=[AWL=0.594, 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 vjdsmU3aigBc for ; Wed, 24 Jun 2009 05:55:35 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id E372B3A6C8C for ; Wed, 24 Jun 2009 05:55:34 -0700 (PDT) Received: by bwz9 with SMTP id 9so707566bwz.37 for ; Wed, 24 Jun 2009 05:55:24 -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=lb0C8aTkWWZgmsFg6B0okUJ0wxBmB5a8zcdHVyArsB8=; b=tooeuSsYJiD0TLBMWJRMcDKUqYUKH/UnUGolu+blBpZmf4CbowXj9LYsw8LkbGJXns w08Y5YqMwvm5PLzU/tlCRrZqHMR2F5S/04x6JAsiD3E+3a+GY2xy2hSpm+Cmgh+YseCP yu74VOm0QitFoED9pX0HsPPRZxaH2uTsmRkIg= 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=C5YGPAVICplQ/ZEd9h0+qruJO23gbs4UwFK30RuXjmD0iN+cH0YZbkC5SOebS8t4Zs Swamvx1eitmJ+oYrKboZGbmIndB6r0YoM6qyfQwb5xh74WkrwhivIcscaNo35YafxOHq +/V+Xx14qQfqjO7ajY3FbSd7WJ8qh8LMNfaIA= MIME-Version: 1.0 Received: by 10.103.213.10 with SMTP id p10mr677134muq.132.1245848124103; Wed, 24 Jun 2009 05:55:24 -0700 (PDT) In-Reply-To: <00a901c9f4c2$bd33ef60$379bce20$@de> References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se> <008901c9f4ad$19be47f0$4d3ad7d0$@de> <4a41fb25.06a1660a.2306.5ed8@mx.google.com> <00a901c9f4c2$bd33ef60$379bce20$@de> Date: Wed, 24 Jun 2009 08:55:24 -0400 Message-ID: <6e9223710906240555v61e633f4gd6f67fa9af2cfdef@mail.gmail.com> From: stephen botzko To: Christian Hoene Content-Type: multipart/alternative; boundary=001636c5b244e19d74046d179ee7 Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 24 Jun 2009 12:55:36 -0000 --001636c5b244e19d74046d179ee7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit No one is interested in circuit-switch codecs anymore. The focus is wireless, IP networks, and distribution of TV and music. Stephen Botzko Polycom On Wed, Jun 24, 2009 at 7:55 AM, Christian Hoene wrote: > Hi Roni, > > > The list you gave is not a codec requirement but a system requirement > > including all layers, this is not codec work, and maybe it shows why the > > IETF does not have currently the expertise to do such work. > > But should the codec be aware of the surrounding system? Does it makes > sense > to have a perfect codec, if the rest of the system is in bad shape or the > interfaces between system and codec are not defined rightly? > > The last ten years of research have shown that a joint optimization of > codec > and the rest of the system can yield high performance gains. For example, > if > the time concealment, the controlling of the frame rate, or the amount of > FEC/redundancy are controlled jointly. To support these enhancements, the > old functionality split between codecs and the rest of the world cannot be > maintained. > > > I will not go through your list but the information you gave about ITU > codec > > not designed for the Internet but only for circuit switch is not correct > > please check the requirements that were used and the tests that were done > > for ITU codecs including support for packet loss. > > Please, Roni, convince me with technical arguments and references to > documents that I am wrong. Then--I promise--I will stop to discuss these > issues immediately. > > Christian > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636c5b244e19d74046d179ee7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable No one is interested in circuit-switch codecs anymore.=A0
The focus is = wireless, IP networks, and distribution of TV and music.

Stephen Bot= zko
Polycom



On Wed, Jun 24, 20= 09 at 7:55 AM, Christian Hoene <hoene@uni-tuebingen.de> wrote:
Hi Roni,

> The list you gave is not a codec requirement but a system requirement<= br> > including all layers, this is not codec work, and maybe it shows why t= he
> IETF does not have currently the expertise to do such work.

But should the codec be aware of the surrounding system? Does it make= s sense
to have a perfect codec, if the rest of the system is in bad shape or the interfaces between system and codec are not defined rightly?

The last ten years of research have shown that a joint optimization of code= c
and the rest of the system can yield high performance gains. For example, i= f
the time concealment, the controlling of the frame rate, or the amount of FEC/redundancy are controlled jointly. To support these enhancements, the old functionality split between codecs and the rest of the world cannot be<= br> maintained.

> I will not go through your list but the information you gave about ITU=
codec
> not designed for the Internet but only for circuit switch is not corre= ct
> please check the requirements that were used and the tests that were d= one
> for ITU codecs including support for packet loss.

Please, Roni, convince me with technical arguments and references to<= br> documents that I am wrong. Then--I promise--I will stop to discuss these issues immediately.

Christian


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

--001636c5b244e19d74046d179ee7-- From ingemar.s.johansson@ericsson.com Wed Jun 24 05:56:55 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 E64213A6C3F for ; Wed, 24 Jun 2009 05:56:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.049 X-Spam-Level: X-Spam-Status: No, score=-6.049 tagged_above=-999 required=5 tests=[AWL=0.200, 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 E9vbh1S4G+Ls for ; Wed, 24 Jun 2009 05:56:54 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C28DF3A6B14 for ; Wed, 24 Jun 2009 05:56:53 -0700 (PDT) X-AuditID: c1b4fb3c-b7bdcae0000052f9-2b-4a421eeb2e6b Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 3C.F0.21241.BEE124A4; Wed, 24 Jun 2009 14:41:16 +0200 (CEST) Received: from esealmw109.eemea.ericsson.se ([153.88.200.2]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 24 Jun 2009 14:41:15 +0200 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: Wed, 24 Jun 2009 14:41:14 +0200 Message-ID: <130EBB38279E9847BAAAE0B8F9905F8C016BDB1F@esealmw109.eemea.ericsson.se> In-Reply-To: <008901c9f4ad$19be47f0$4d3ad7d0$@de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acn0MDLy2GxBYXk0T4eaJtzQPMocLAAaKPVAAAPts3AABtsrgA== References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se> <008901c9f4ad$19be47f0$4d3ad7d0$@de> From: "Ingemar Johansson S" To: "Christian Hoene" , "Jean-Marc Valin" X-OriginalArrivalTime: 24 Jun 2009 12:41:15.0485 (UTC) FILETIME=[103DA8D0:01C9F4C9] X-Brightmail-Tracker: AAAAAA== Cc: codec@ietf.org, ron.even@gmail.com Subject: Re: [codec] Codec BOF approved, much work needed 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, 24 Jun 2009 12:56:56 -0000 Hi What stikes me is that there seems to be some kind of misconception that other SDOs that do speech coding standardization still live in a circuit-switched world where bit-errors are the key design constraint.=20 This was maybe true 10 years ago but time changes and so does other SDOs.=20 But... speech codec standardization also has to recognize the fact that today > 3 billion users are talking through legacy handset using circuit switched technology where bit-errors are a key factor.=20 We cannot assume that all these users will switch to VoIP all of a sudden, making a call must be as simple as 1-2-3 even when the underlying technology changes. 99.9999% of the users don't care about the codec and transport, it is the quality, cost, ease of use and reliability that counts.=20 This may give people the idea that e.g 3GPP sticks to "old technology" but nothing could be more wrong. My comments to comments below, I believe I have made my point for now, look forward to discuss this more at the BoF. Regards Ingemar > -----Original Message----- > From: Christian Hoene [mailto:hoene@uni-tuebingen.de]=20 > Sent: den 24 juni 2009 11:21 > To: Ingemar Johansson S; 'Jean-Marc Valin' > Cc: ron.even@gmail.com; codec@ietf.org > Subject: RE: [codec] Codec BOF approved, much work needed >=20 > Dear Ingemar Johannsson, >=20 > > My point is that if we decide to step > > into other SDOs areas so clearly as this BoF suggests, the benefits=20 > > must clearly outweight the risk that work in other IETF=20 > areas is disturbed. > > This should be discussed at the BoF. > > ... the EVS codec being specified in 3GPP clearly adresses packet=20 > > switched access at various bitrates and sampling rates.=20 > Also, earlier=20 > > work has shown that it is perfectly OK to tailor excisting codecs=20 > > originally designed for circuit-switched access to work well in a=20 > > packet-switched environment, see for instance=20 > >=20 > http://www.ind.rwth-aachen.de/fileadmin/publications/mertz03.pdf (if=20 > > you have access to the IEEE library I recommend a look at=20 > reference [3]). >=20 > To my opinion, it is the greatest mistake of the traditional=20 > codec designs that they thought "Let's make a codec for=20 > circuit switched networks. It will work anyhow with packet=20 > sizes networks." In the days of NGN we do not need any=20 > support for circuit switched networks anymore. Why shall a=20 > codec be designed for a networking technology, which losses=20 > its relevance and importance at a high speed? Wrong interpretation of work done in other SDOs, see above why. >=20 > One clear benefit of this BoF is that codec experts and=20 > Internet guys can come together to discuss on a codec=20 > intended only for the Internet. Like said above, other SDOs does it already. >=20 > In my opinion, the requirements between a circuit switched=20 > codec design and a codec for the Internet differs, for example > - The Internet codec should be royalty free because also most=20 > of the other Internet protocols are free of charge, too. It=20 > is a matter of fairness... The ambitions are fine but if you look at the other discussion on this list there is raised a number of reasons why this may well fall flat in the end. > - It should support packet loss concealment because it=20 > happens do often in the Internet. On the other hand, bit=20 > errors are quite seldom. This is fact is clearly recognized in other SDOs as well. > - This BoF should think about a jitter compensation including=20 > modern time stretching and time concealment algorithms.=20 > Jitter is the norm not a "special" case. Codec designer=20 > should not ignore it. Also recognized by other SDOs. > - The Internet codec should take advantage of a feedback loop=20 > for variable rate/frame control in order to allow a wide=20 > range of operation regardless of the current available=20 > bandwidth. Congestion control should a must for all Internet=20 > applications. BTW equally important to coding rate is the=20 > frame rate of a codec. All efficient ITU codecs that I am=20 > aware go, to not support variable frame rates. This is also recognized by other SDOs, have a look for instance at 3GPP TS26.114 http://www.3gpp.org/ftp/Specs/archive/26_series/26.114/26114-830.zip The busy reader may want to read sections 9, 10 and annex C > - It is fine if the internet codec has not perfect but fairly=20 > well audio quality. Most of the bandwidth is wasted for=20 > Internet packet headers anyhow. > Does it make sense to optimize the coding rate, when=20 > Ethernet, IP, UDP, and RTP protocols are wasting bandwidth=20 > without any concerns? Header compression can be used, which means that this argument is not valid. > - Also, if no royalties and big money are involved, it does=20 > not make any difference, which of multiple nearly equally=20 > well designed codecs is selected. If the selection process is=20 > not as perfect as in ITU, a lot of money can be saved, which=20 > otherwise would be spend on professional codec testing. Codec testing is not only about selecting the best codec, it is also about finding bugs before standards are frozen. Lack of testing likely means contly bugfixes/patches later on.=20 > - Also, ITU, MPEG and 3GPP has failed yet to develop a codec=20 > supporting ultra low latency important for new kind of=20 > applications like ensemble performances over the net.. Does not mean that this has not been considered. >=20 > I am not a codec experts, but all these all requirements are=20 > quite different from the approach that the ITU follows. Also,=20 > the stockholders in the IETF are different. IETFs=20 > contribution are driven by individuals not by larger=20 > companies like in the ITU. Thus, hopefully the interests of=20 > users and the entire society will be considered to larger extend. Please then feel free to dig more into the work done in e.g ITU and 3GPP, you will find out that lots of the technical issues that are brought forward to motivate a Codec WG are already addressed in other SDOs. The only one left is possibly the "royalty-free" motivation but this is a very shaky argument IMHO. >=20 > > In addition, reading your comment above, I don't really=20 > understand why=20 > > you need IETF for the codec standardization?, why not just=20 > standardize=20 > > your codecs in Xiph.org and propose a payload format in AVT?. This=20 > > gives me the impression that the IETF involvement is just=20 > rubberstamping. >=20 > If Jean-Marc wants to rubberstamp his codec, he has the=20 > option of submitting an independent RFC. Then, there is not=20 > be a need of a BoF... I do not believe this is the case. >=20 > Greetings > Christian Hoene >=20 >=20 From petithug@acm.org Wed Jun 24 06:00:21 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 4EE743A6C55 for ; Wed, 24 Jun 2009 06:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.791 X-Spam-Level: X-Spam-Status: No, score=-101.791 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_UNSUB22=0.948, 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 nBT7ESGAICS8 for ; Wed, 24 Jun 2009 06:00:20 -0700 (PDT) Received: from server.implementers.org (server.implementers.org [69.55.225.91]) by core3.amsl.com (Postfix) with ESMTP id 186553A6869 for ; Wed, 24 Jun 2009 06:00:20 -0700 (PDT) Received: by server.implementers.org (Postfix, from userid 1001) id 861DE6C98462; Wed, 24 Jun 2009 12:22:47 +0000 (UTC) Received: from [192.168.2.3] (server.implementers.org [127.0.0.1]) by server.implementers.org (Postfix) with ESMTPA id 4AA756C9845C; Wed, 24 Jun 2009 12:22:45 +0000 (UTC) Message-ID: <4A421A94.8090401@acm.org> Date: Wed, 24 Jun 2009 05:22:44 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Gibbs Jon-CJG019 References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se><008901c9f4ad$19be47f0$4d3ad7d0$@de> <4A41F39F.5020402@acm.org> <4A420C51.5060603@acm.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 24 Jun 2009 13:00:21 -0000 Gibbs Jon-CJG019 wrote: > Marc Petit-Huguenin wrote: >> Too bad there is no open source implementation and an IPR statement on > this draft. > > FYI, > The fixed point source code is freely available here > (http://www.itu.int/rec/T-REC-G.718/en) already, all 60,000 lines of it, > and the floating point code is coming soon as you'll see. > > The declared IPR patent and copyright statements may be found here > http://www.itu.int/ipr/IPRSearch.aspx - just enter "G.718" for > Recommendation No. > > ...but it seems that you've already decided that it's not for you, or > the IETF... I do not decide for the IETF, only for me. > > ...and so you want to re-invent the wheel... > > ...paradoxically to save some money... > > ..."Too bad", indeed! No open source implementation is not the problem - I can write code, it's just nice to have one. A RAND IPR is definitively a problem (for me). -- Marc Petit-Huguenin Home: marc@petit-huguenin.org Work: petithug@acm.org From ron.even.tlv@gmail.com Wed Jun 24 06:00:25 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 E595F3A6C77 for ; Wed, 24 Jun 2009 06:00:25 -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=[AWL=0.000, 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 XeB5k4LZfUkr for ; Wed, 24 Jun 2009 06:00:25 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id C89623A6A37 for ; Wed, 24 Jun 2009 06:00:24 -0700 (PDT) Received: by fxm9 with SMTP id 9so727362fxm.37 for ; Wed, 24 Jun 2009 05:59:50 -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:thread-index:content-language; bh=PA51kBso/U5vnds1C8JstkWhHSx8SQ9yZLej/90qAbQ=; b=J6/RVr8PiACSuW2vf2ouk44ZLNHGtuzu5YUpt+Jf5Ki0mt1uZctBBXXMllUKQ0PXTM 1OiLQL+qXrDeQ6GUya+AabOaUhmZq7JplK2fQYb89ljnumtuO/hvvxYP/QBedEh7HhHE 6+0uKO4MKWg2dLBo8xgJ/YVwM5ZSiLq2naHmU= 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 :thread-index:content-language; b=Oz2SmK+AsF8q9RF1vs8mJjpnA8sWeCmYHICQ6pPai41UmJDIKS5EwurwFqeivHCCpz exOYPAmCfjVJXs8XreE5/KvYUd5X7NVDrWfGwwSA0T7RyjqTjoJ0/IEe6KEF8macLQD5 9tkEi6MXUojinQGIGZUaSNFq5Vklm+Rze/GEI= Received: by 10.103.248.17 with SMTP id a17mr671640mus.83.1245848390632; Wed, 24 Jun 2009 05:59:50 -0700 (PDT) Received: from windows8d787f9 (bzq-79-181-103-217.red.bezeqint.net [79.181.103.217]) by mx.google.com with ESMTPS id u9sm2979772muf.37.2009.06.24.05.59.49 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 24 Jun 2009 05:59:50 -0700 (PDT) From: "Roni Even" To: "'Christian Hoene'" References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se> <008901c9f4ad$19be47f0$4d3ad7d0$@de> <4a41fb25.06a1660a.2306.5ed8@mx.google.com> <00a901c9f4c2$bd33ef60$379bce20$@de> In-Reply-To: <00a901c9f4c2$bd33ef60$379bce20$@de> Date: Wed, 24 Jun 2009 15:59:26 +0300 Message-ID: <4a422346.09c5660a.109d.ffff9614@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn0MDLy2GxBYXk0T4eaJtzQPMocLAAaKPVAAAPts3AAAjGWwAAD0a8AAAKzIGA= Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 24 Jun 2009 13:00:26 -0000 What you describe is different scope than codec because some of it is codec independent. For ITU codecs look at John Gibbs email and at G.718 Roni > -----Original Message----- > From: Christian Hoene [mailto:hoene@uni-tuebingen.de] > Sent: Wednesday, June 24, 2009 2:56 PM > To: 'Roni Even' > Cc: codec@ietf.org > Subject: RE: [codec] Codec BOF approved, much work needed > > Hi Roni, > > > The list you gave is not a codec requirement but a system requirement > > including all layers, this is not codec work, and maybe it shows why > the > > IETF does not have currently the expertise to do such work. > > But should the codec be aware of the surrounding system? Does it makes > sense > to have a perfect codec, if the rest of the system is in bad shape or > the > interfaces between system and codec are not defined rightly? > > The last ten years of research have shown that a joint optimization of > codec > and the rest of the system can yield high performance gains. For > example, if > the time concealment, the controlling of the frame rate, or the amount > of > FEC/redundancy are controlled jointly. To support these enhancements, > the > old functionality split between codecs and the rest of the world cannot > be > maintained. > > > I will not go through your list but the information you gave about > ITU > codec > > not designed for the Internet but only for circuit switch is not > correct > > please check the requirements that were used and the tests that were > done > > for ITU codecs including support for packet loss. > > Please, Roni, convince me with technical arguments and references to > documents that I am wrong. Then--I promise--I will stop to discuss > these > issues immediately. > > Christian From ron.even.tlv@gmail.com Wed Jun 24 06:12:08 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 C73403A63CB for ; Wed, 24 Jun 2009 06:12:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.125 X-Spam-Level: X-Spam-Status: No, score=-2.125 tagged_above=-999 required=5 tests=[AWL=-0.474, BAYES_00=-2.599, SARE_UNSUB22=0.948] 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 QMWaxfDMsEg1 for ; Wed, 24 Jun 2009 06:12:07 -0700 (PDT) Received: from mail-bw0-f219.google.com (mail-bw0-f219.google.com [209.85.218.219]) by core3.amsl.com (Postfix) with ESMTP id 566F43A6A86 for ; Wed, 24 Jun 2009 06:12:07 -0700 (PDT) Received: by bwz19 with SMTP id 19so936981bwz.4 for ; Wed, 24 Jun 2009 06:11:25 -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:thread-index:content-language; bh=0KFxmAkt52p4j1q/1wVgt/ow/iuXD9tB1+SfBBWLFGs=; b=o1zIgedSmv/CbbIdN4rhU/QVt3uQ2pgbX7In5RlD1hWcezVaEKyIysFOZ/TPIugwqb NBvNPVKWG8TZJxLvQ3RiFHToRmSbE03/JZxHXBDFezcKtpTqqwDLjwT1oooXbMhMGINl crZfcb5MSaj6HqgWI4m5gHqOmawLDO91+6N2M= 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 :thread-index:content-language; b=C8fMZCFw7pDjHc7qHSbtZRtoZpG72jztPLmyYuaNkGlwwyj3Q0MZRNs/5NQyP/Z3IP lUlOrZtzZTE8Djv0duiMQo05zmCws6TlapQ5CypcmS2ozzhh9mwYpcjxH44ByHEOcmZo oxkuUtlYrHxSCnRNK2bLbKvin5s+I0W3wKBX8= Received: by 10.204.113.198 with SMTP id b6mr1267239bkq.108.1245848694976; Wed, 24 Jun 2009 06:04:54 -0700 (PDT) Received: from windows8d787f9 (bzq-79-181-103-217.red.bezeqint.net [79.181.103.217]) by mx.google.com with ESMTPS id z15sm1792738fkz.34.2009.06.24.06.04.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 24 Jun 2009 06:04:54 -0700 (PDT) From: "Roni Even" To: "'Jean-Marc Valin'" , "'Gibbs Jon-CJG019'" References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se> <008901c9f4ad$19be47f0$4d3ad7d0$@de> <4A41F39F.5020402@acm.org> <4A420C51.5060603@acm.org> <4A421BAC.1030206@usherbrooke.ca> In-Reply-To: <4A421BAC.1030206@usherbrooke.ca> Date: Wed, 24 Jun 2009 16:04:48 +0300 Message-ID: <4a422476.0f345e0a.6184.22b8@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 Thread-Index: Acn0x2skDbzOcmgRRUqe5G+aSbyRBAABImLg Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 24 Jun 2009 13:12:08 -0000 Hi, G.718 is a new codec and I am not aware that some entity decided that it = is not for us humans. As for your third choice you forgot to say "hopefully" solve the problem since like was discussed in separate thread you cannot guarantee it and = you will not provide any protection against it.=20 Roni > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Jean-Marc Valin > Sent: Wednesday, June 24, 2009 3:27 PM > To: Gibbs Jon-CJG019 > Cc: codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed >=20 > Gibbs Jon-CJG019 a =E9crit : > > Marc Petit-Huguenin wrote: > >> Too bad there is no open source implementation and an IPR statement > on > > this draft. > > > > FYI, > > The fixed point source code is freely available here > > (http://www.itu.int/rec/T-REC-G.718/en) already, all 60,000 lines of > it, > > and the floating point code is coming soon as you'll see. >=20 > "source code freely available" and "open source implementation" are > totally different things. I suggest you have a look at (first Google > result) http://www.opensource.org/docs/definition.php >=20 > > The declared IPR patent and copyright statements may be found here > > http://www.itu.int/ipr/IPRSearch.aspx - just enter "G.718" for > > Recommendation No. > > > > ...but it seems that you've already decided that it's not for you, = or > > the IETF... >=20 > It is actually the other way around. Someone has decided that G.718 = was > not for us. I am not familiar with all the technical details of G.718, > but I have no problem imagining that it fits the telco's needs very > well > -- even for IP transport. The problem is that its licensing makes it > impossible to use for many applications because of the patents it > involves. How good is a codec which you cannot use. If my VoIP > application has to be freely downloadable, or embedded in a web page = as > a Java applet, or if I want to link it with open source software... > then > a patent-encumbered codec cannot be legally used. What are you > suggesting we should do. So far, I see three possible options: > 1) Break the law by infringing on patents > 2) Use codecs on which patents are expired (G.711 and GSM-FR are still > popular) > 3) Design a new codec that will solve the problem >=20 > I choose 3). >=20 > Jean-Marc >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From Jon.Gibbs@motorola.com Wed Jun 24 06:34:10 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 A79DE3A68CC for ; Wed, 24 Jun 2009 06:34:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.651 X-Spam-Level: X-Spam-Status: No, score=-5.651 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_UNSUB22=0.948] 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 BXyIQLlknkqn for ; Wed, 24 Jun 2009 06:34:09 -0700 (PDT) Received: from mail55.messagelabs.com (mail55.messagelabs.com [216.82.241.163]) by core3.amsl.com (Postfix) with SMTP id 766363A683F for ; Wed, 24 Jun 2009 06:33:40 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: Jon.Gibbs@motorola.com X-Msg-Ref: server-8.tower-55.messagelabs.com!1245850313!94382814!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [136.182.1.14] Received: (qmail 32141 invoked from network); 24 Jun 2009 13:31:53 -0000 Received: from motgate4.mot.com (HELO motgate4.mot.com) (136.182.1.14) by server-8.tower-55.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 24 Jun 2009 13:31:53 -0000 Received: from il27exr03.cig.mot.com (il27exr03.mot.com [10.17.196.72]) by motgate4.mot.com (8.14.3/8.14.3) with ESMTP id n5ODVqB3024857 for ; Wed, 24 Jun 2009 06:31:53 -0700 (MST) Received: from il27vts01 (il27vts01.cig.mot.com [10.17.196.85]) by il27exr03.cig.mot.com (8.13.1/Vontu) with SMTP id n5ODVqL4024200 for ; Wed, 24 Jun 2009 08:31:52 -0500 (CDT) Received: from zuk35exm64.ds.mot.com (zuk35exm64.ea.mot.com [10.178.4.15]) by il27exr03.cig.mot.com (8.13.1/8.13.0) with ESMTP id n5ODVpT8024176 for ; Wed, 24 Jun 2009 08:31:52 -0500 (CDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jun 2009 14:31:30 +0100 Message-ID: In-Reply-To: <4a422476.0f345e0a.6184.22b8@mx.google.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acn0x2skDbzOcmgRRUqe5G+aSbyRBAABImLgAABS7BA= References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se> <008901c9f4ad$19be47f0$4d3ad7d0$@de> <4A41F39F.5020402@acm.org> <4A420C51.5060603@acm.org> <4A421BAC.1030206@usherbrooke.ca> <4a422476.0f345e0a.6184.22b8@mx.google.com> From: "Gibbs Jon-CJG019" To: "Roni Even" X-CFilter-Loop: Reflected Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 24 Jun 2009 13:34:10 -0000 Thanks Roni - I couldn't have put it better myself. Jon=20 -----Original Message----- From: Roni Even [mailto:ron.even.tlv@gmail.com]=20 Sent: 24 June 2009 14:05 To: 'Jean-Marc Valin'; Gibbs Jon-CJG019 Cc: codec@ietf.org Subject: RE: [codec] Codec BOF approved, much work needed Hi, G.718 is a new codec and I am not aware that some entity decided that it = is not for us humans. As for your third choice you forgot to say "hopefully" solve the problem = since like was discussed in separate thread you cannot guarantee it and = you will not provide any protection against it.=20 Roni > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = > Of Jean-Marc Valin > Sent: Wednesday, June 24, 2009 3:27 PM > To: Gibbs Jon-CJG019 > Cc: codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed >=20 > Gibbs Jon-CJG019 a =E9crit : > > Marc Petit-Huguenin wrote: > >> Too bad there is no open source implementation and an IPR statement > on > > this draft. > > > > FYI, > > The fixed point source code is freely available here > > (http://www.itu.int/rec/T-REC-G.718/en) already, all 60,000 lines of > it, > > and the floating point code is coming soon as you'll see. >=20 > "source code freely available" and "open source implementation" are=20 > totally different things. I suggest you have a look at (first Google > result) http://www.opensource.org/docs/definition.php >=20 > > The declared IPR patent and copyright statements may be found here=20 > > http://www.itu.int/ipr/IPRSearch.aspx - just enter "G.718" for=20 > > Recommendation No. > > > > ...but it seems that you've already decided that it's not for you,=20 > > or the IETF... >=20 > It is actually the other way around. Someone has decided that G.718=20 > was not for us. I am not familiar with all the technical details of=20 > G.718, but I have no problem imagining that it fits the telco's needs=20 > very well > -- even for IP transport. The problem is that its licensing makes it=20 > impossible to use for many applications because of the patents it=20 > involves. How good is a codec which you cannot use. If my VoIP=20 > application has to be freely downloadable, or embedded in a web page=20 > as a Java applet, or if I want to link it with open source software... > then > a patent-encumbered codec cannot be legally used. What are you=20 > suggesting we should do. So far, I see three possible options: > 1) Break the law by infringing on patents > 2) Use codecs on which patents are expired (G.711 and GSM-FR are still > popular) > 3) Design a new codec that will solve the problem >=20 > I choose 3). >=20 > Jean-Marc >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From hoene@uni-tuebingen.de Wed Jun 24 07:50:43 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 16D863A69A3 for ; Wed, 24 Jun 2009 07:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.206 X-Spam-Level: X-Spam-Status: No, score=-6.206 tagged_above=-999 required=5 tests=[AWL=0.043, 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 h7+Fi1+8EH6F for ; Wed, 24 Jun 2009 07:50:41 -0700 (PDT) Received: from mx06.uni-tuebingen.de (mx06.uni-tuebingen.de [134.2.3.3]) by core3.amsl.com (Postfix) with ESMTP id 284B728C333 for ; Wed, 24 Jun 2009 07:50:40 -0700 (PDT) Received: from hoeneLenovoT60 (vpn0273.extern.uni-tuebingen.de [134.2.165.23]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n5OEnD6v017160 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Wed, 24 Jun 2009 16:49:18 +0200 From: "Christian Hoene" To: Date: Wed, 24 Jun 2009 16:49:12 +0200 Message-ID: <00c401c9f4da$f36dd880$da498980$@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: Acn02u4I34EyXe11TkaMJV+fd5M2fg== Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Subject: [codec] Disruptive Technology? 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, 24 Jun 2009 14:50:43 -0000 Hi all, this discussion reminds me on the concept of "Disruptive Technology" as introduced by Clayton M. Christensen in 1995. Did you read his book? The Wikipedia article gives a short introduction: http://en.wikipedia.org/wiki/Disruptive_technology "A disruptive technology or disruptive innovation is an innovation that improves a product or service in ways that the market does not expect, typically by being lower priced or designed for a different set of consumers. ... Disruptive technologies are particularly threatening to = the leaders of an existing market, because they are competition coming from = an unexpected direction. A disruptive technology can come to dominate an existing market by either filling a role in a new market that the older technology could not fill (as cheaper, lower capacity but smaller-sized flash memory is doing for personal data storage in the 2000s) or by successively moving up-market through performance improvements until = finally displacing the market incumbents (as digital photography has largely replaced film photography)." "as Christensen points out and studies have shown, it is often entirely rational for incumbent companies to ignore disruptive innovations, since they compare so badly with existing technologies or products, and the deceptively small market available for a disruptive innovation is often = very small compared to the market for the established technology." "Even if a disruptive innovation is recognized, existing businesses are often reluctant to take advantage of it, since it would involve = competing with their existing (and more profitable) technological approach. Christensen recommends that existing firms watch for these innovations, invest in small firms that might adopt these innovations, and continue = to push technological demands in their core market so that performance = stays above what disruptive technologies can achieve." It is clear that this discussion is not about businesses, firms or = products but on standards and SDOs. However, there are many parallels: Jean-Marcs approach on codec design can be seen as disruptive technology. The = working procedures of ITU/3GPP are the traditional technological approach. If this discussion is really about a new disruptive technology, it makes perfectly sense to start a new group in a new organizational structure. Because disruptive technologies cannot be developed in the existing organizations--to many resistances--but only in newly formed. With best regards, Christian=20 -------------------------------------------------------- Dr.-Ing. Christian Hoene Computer Networks and Internet, University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://net.informatik.uni-tuebingen.de/~hoene From stewe@stewe.org Wed Jun 24 08:13:27 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 46AD828C2C3 for ; Wed, 24 Jun 2009 08:13:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.253 X-Spam-Level: * X-Spam-Status: No, score=1.253 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 mlW8FuJxflah for ; Wed, 24 Jun 2009 08:13:20 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 6DAEE3A67FF for ; Wed, 24 Jun 2009 08:13:17 -0700 (PDT) Received: from [192.168.1.12] (unverified [68.197.227.183]) by stewe.org (SurgeMail 3.9e) with ESMTP id 314276-1743317 for multiple; Wed, 24 Jun 2009 17:12:30 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 24 Jun 2009 11:12:08 -0400 From: Stephan Wenger To: Henry Sinnreich , Jason Fischl , Christopher Montgomery Message-ID: Thread-Topic: [codec] Codec BOF non-agenda-topics Thread-Index: Acn0VnEuhmdx3h4HpEqdzcQ5UL0nlAABbMfgAADxQEoAALvo7AAe0sKa In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3328686740_4201373" X-Originating-IP: 68.197.227.183 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (68.197.227.183) was found in the spamhaus database. http://www.spamhaus.net Cc: "codec@ietf.org" , stephen botzko Subject: Re: [codec] Codec BOF non-agenda-topics 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, 24 Jun 2009 15:13:27 -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_3328686740_4201373 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Henry, the problem with your argumentation seems that the =B3established industry=B2 may not have conceived RTP, SIP, and so on, but they made it happen (to the extend it has happened :-). Arguably, the base concepts of speech coding have also not been conceived in the =B3established industry=B2, but rather in academic circles and in the US military. I=B9m not against newcomers, but I also do not see why the IETF should favor newcomers, especially when those newcomers wish to establish a competing ecosystem (at least in commercial terms) by working under non-established IPR practices and in an area which is (as the very minimum) not the core competency of the IETF. With respect to the marketplace argument: standard reply to standard argument---standards are there to promote interoperability; having many of them is not helpful for interoperability, therefore overlap in standardization should be avoided. To summarize, it looks like we agree to disagree. We are going in circles in this discussion, which is not productive. I=B9m dropping out. Best regards, Stephan (who works nowadays for a very small company, which by no means belongs to the =B3established industry=B2) On 6/23/09 8:29 PM, "Henry Sinnreich" wrote: > Hi Stephen, >=20 > With all respect and putting on my Internet engineer hat and as a former = ISP > employee, most of the worlds multimedia applications traffic goes over th= e > Internet using protocols and codecs that have been invented not by the > powerhouses you are referring to (remember their OSI, ATM and H.323?). > P2P video and IPTV (The Flicker or YouTube varieties) are just examples o= f > pure Internet multimedia. > RTP and SIP came from the IETF, and why are all the codec vendors making = sure > they get an IETF AVT profile? >=20 > I fail to understand (though I do) the opposition to new players in the f= ield > that may include innovators of the sort there are so many on the Internet= . >=20 > Last but not least, is not for the market to decide, instead of trying to= kill > the baby before it is even born? >=20 > It seems there are here two irreconcilable camps: The established industr= y and > new Internet players. > Can we please take the Internet view here in the IETF venue? >=20 > My strict personal two cents, >=20 > Henry >=20 >=20 > On 6/23/09 7:08 PM, "Stephan Wenger" wrote: >=20 >> Hi Jason, >> I don't think I can give you a fixed number. But if I see at least some= of >> the folks who have worked for a couple of years in the ITU, 3GPP, MPEG, = or >> 3GPP2 being committed to this effort, I would feel a lot better. It's n= ot >> only numbers that count, its also previous experience in standardization= of >> speech codecs. If those people come from known IPR powerhouses (and tho= se >> powerhouses thereby show willingness to support an RF effort as it is ar= gued >> for here), you would find me enthusiastically agreeing to a new WG. >> Regards, >> Stephan >>=20 >>=20 >> On 6/23/09 7:41 PM, "Jason Fischl" wrote: >>=20 >>> > On 6/24/09 1:00 AM, "Stephan Wenger" wrote: >>>> >> On 6/23/09 6:03 PM, "Christopher Montgomery" w= rote: >>>>> >>> >>>>> >>> There are plenty of arguments being made against a WG or even the >>>>> >>> sensibility of a BOF here, but aren't they missing the point? B= road >>>>> >>> interest within the IETF is, of itself, sufficient condition for = a BOF >>>>> >>> or WG is it not? >>>> >> >>>> >> It depends on the definition of "broad interest". Broad interest i= n the >>>> >> IETF in WORKING towards a goal is a necessary condition to form a W= G, no >>>> >> doubt. I don't think it is sufficient, but never mind that. Broad >>>> interest >>>> >> in the goal alone, without a critical mass of competent people comm= itted to >>>> >> work towards the goal, IMHO, is insufficient. And I don't see this >>>> critical >>>> >> mass, certainly not yet. I do see this critical mass in the releva= nt >>>> groups >>>> >> in both 3GPP and in the ITU. But critical mass is precisely what th= e BOF >>>> >> will measure. Therefore, at present, I would speak against forming= a >>>> WG, >>>> >> but I would not have spoken against a BOF, even if I would have bee= n >>>> asked. >>>> >> >>> > >>> > Could you please define what you think it means to have "broad intere= st" >>> or >>> > "critical mass"? >>> > >>> > How many audio codec experts should we have actively participating in= the >>> > working group? Is there some other criteria that you are thinking abo= ut? >>> > >>> > Jason >>> > >>=20 >>=20 >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >>=20 >=20 --B_3328686740_4201373 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] Codec BOF non-agenda-topics Hi Henry,

the problem with your argumentation seems that the “established indus= try” may not have conceived RTP, SIP, and so on, but they made it happ= en (to the extend it has happened :-).  Arguably, the base concepts of = speech coding have also not been conceived in the “established industr= y”, but rather in academic circles and in the US military.
I’m not against newcomers, but I also do not see why the IETF should = favor newcomers, especially when those newcomers wish to establish a competi= ng ecosystem (at least in commercial terms) by working under non-established= IPR practices and in an area which is (as the very minimum) not the core co= mpetency of the IETF.

With respect to the marketplace argument: standard reply to standard argume= nt---standards are there to promote interoperability; having many of them is= not helpful for interoperability, therefore overlap in standardization shou= ld be avoided.

To summarize, it looks like we agree to disagree.

We are going in circles in this discussion, which is not productive.  = I’m dropping out.

Best regards,
Stephan
(who works nowadays for a very small company, which by no means belongs to = the “established industry”)

On 6/23/09 8:29 PM, "Henry Sinnreich" <hsinnrei@adobe.com> wrote:

 --B_3328686740_4201373-- From hsinnrei@adobe.com Wed Jun 24 08:25:18 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 7871328C48E for ; Wed, 24 Jun 2009 08:25:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.972 X-Spam-Level: X-Spam-Status: No, score=-5.972 tagged_above=-999 required=5 tests=[AWL=0.626, BAYES_00=-2.599, 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 hGj0qvUiVmsG for ; Wed, 24 Jun 2009 08:25:16 -0700 (PDT) Received: from psmtp.com (exprod6ob117.obsmtp.com [64.18.1.38]) by core3.amsl.com (Postfix) with ESMTP id 9ACF93A6CAF for ; Wed, 24 Jun 2009 08:23:40 -0700 (PDT) Received: from source ([192.150.11.134]) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKSkJE8T+K5Ufz+X3XoT2/7Jbm3D2dIMTM@postini.com; Wed, 24 Jun 2009 08:24:04 PDT Received: from inner-relay-3.eur.adobe.com ([192.150.8.236]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5OFHBao010878; Wed, 24 Jun 2009 08:17:12 -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 n5OFNPY2011360; Wed, 24 Jun 2009 08:23:26 -0700 (PDT) Received: from nacas03.corp.adobe.com (10.8.189.121) by nahub01.corp.adobe.com (10.8.189.97) with Microsoft SMTP Server (TLS) id 8.1.340.0; Wed, 24 Jun 2009 08:23:24 -0700 Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Wed, 24 Jun 2009 08:23:25 -0700 From: Henry Sinnreich To: Christian Hoene , "codec@ietf.org" Date: Wed, 24 Jun 2009 08:23:20 -0700 Thread-Topic: [codec] Disruptive Technology? Thread-Index: Acn02u4I34EyXe11TkaMJV+fd5M2fgABMZ6c Message-ID: In-Reply-To: <00c401c9f4da$f36dd880$da498980$@de> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C667AF184520hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] Disruptive Technology? 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, 24 Jun 2009 15:25:18 -0000 --_000_C667AF184520hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christian, Thanks for sharing this valuable insight. It comes at the right time, when apparently the discussions here seem all a= bout how the voice codec incumbents can keep the newcomers out. My strict personal (IETF contributor hat) 2 cents, Henry On 6/24/09 9:49 AM, "Christian Hoene" wrote: Hi all, this discussion reminds me on the concept of "Disruptive Technology" as introduced by Clayton M. Christensen in 1995. Did you read his book? The Wikipedia article gives a short introduction: http://en.wikipedia.org/wiki/Disruptive_technology "A disruptive technology or disruptive innovation is an innovation that improves a product or service in ways that the market does not expect, typically by being lower priced or designed for a different set of consumers. ... Disruptive technologies are particularly threatening to the leaders of an existing market, because they are competition coming from an unexpected direction. A disruptive technology can come to dominate an existing market by either filling a role in a new market that the older technology could not fill (as cheaper, lower capacity but smaller-sized flash memory is doing for personal data storage in the 2000s) or by successively moving up-market through performance improvements until finall= y displacing the market incumbents (as digital photography has largely replaced film photography)." "as Christensen points out and studies have shown, it is often entirely rational for incumbent companies to ignore disruptive innovations, since they compare so badly with existing technologies or products, and the deceptively small market available for a disruptive innovation is often ver= y small compared to the market for the established technology." "Even if a disruptive innovation is recognized, existing businesses are often reluctant to take advantage of it, since it would involve competing with their existing (and more profitable) technological approach. Christensen recommends that existing firms watch for these innovations, invest in small firms that might adopt these innovations, and continue to push technological demands in their core market so that performance stays above what disruptive technologies can achieve." It is clear that this discussion is not about businesses, firms or products but on standards and SDOs. However, there are many parallels: Jean-Marcs approach on codec design can be seen as disruptive technology. The working procedures of ITU/3GPP are the traditional technological approach. If this discussion is really about a new disruptive technology, it makes perfectly sense to start a new group in a new organizational structure. Because disruptive technologies cannot be developed in the existing organizations--to many resistances--but only in newly formed. With best regards, Christian -------------------------------------------------------- Dr.-Ing. Christian Hoene Computer Networks and Internet, University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://net.informatik.uni-tuebingen.de/~hoene _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C667AF184520hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Disruptive Technology? Christian,

Thanks for sharing this valuable insight.
It comes at the right time, when apparently the discussions here seem all a= bout how the voice codec incumbents can keep the newcomers out.

My strict personal (IETF contributor hat) 2 cents,

Henry


On 6/24/09 9:49 AM, "Christian Hoene" <hoene@uni-tuebingen.de> wrote:

Hi all,

this discussion reminds me on the concept of "Disruptive Technology&qu= ot; as
introduced by Clayton M. Christensen in 1995. Did you read his book? The Wikipedia article gives a short introduction:
http://en.wi= kipedia.org/wiki/Disruptive_technology

"A disruptive technology or disruptive innovation is an innovation tha= t
improves a product or service in ways that the market does not expect,
typically by being lower priced or designed for a different set of
consumers. ... Disruptive technologies are particularly threatening to the<= BR> leaders of an existing market, because they are competition coming from an<= BR> unexpected direction. A disruptive technology can come to dominate an
existing market by either filling a role in a new market that the older
technology could not fill (as cheaper, lower capacity but smaller-sized
flash memory is doing for personal data storage in the 2000s) or by
successively moving up-market through performance improvements until finall= y
displacing the market incumbents (as digital photography has largely
replaced film photography)."
"as Christensen points out and studies have shown, it is often entirel= y
rational for incumbent companies to ignore disruptive innovations, since they compare so badly with existing technologies or products, and the
deceptively small market available for a disruptive innovation is often ver= y
small compared to the market for the established technology."
"Even if a disruptive innovation is recognized, existing businesses ar= e
often reluctant to take advantage of it, since it would involve competing with their existing (and more profitable) technological approach.
Christensen recommends that existing firms watch for these innovations,
invest in small firms that might adopt these innovations, and continue to push technological demands in their core market so that performance stays above what disruptive technologies can achieve."

It is clear that this discussion is not about businesses, firms or products=
but on standards and SDOs. However, there are many parallels: Jean-Marcs approach on codec design can be seen as disruptive technology. The working<= BR> procedures of ITU/3GPP are the traditional technological approach.

If this discussion is really about a new disruptive technology, it makes perfectly sense to start a new group in a new organizational structure.
Because disruptive technologies cannot be developed in the existing
organizations--to many resistances--but only in newly formed.

With best regards,

 Christian


--------------------------------------------------------
Dr.-Ing. Christian Hoene
Computer Networks and Internet, University of Tübingen
Sand 13, 72076 Tübingen, Germany, Phone +49 7071 2970532
http://net.inform= atik.uni-tuebingen.de/~hoene



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

--_000_C667AF184520hsinnreiadobecom_-- From stephen.botzko@gmail.com Wed Jun 24 10:23:32 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 7213028C4CC for ; Wed, 24 Jun 2009 10:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.842 X-Spam-Level: X-Spam-Status: No, score=-0.842 tagged_above=-999 required=5 tests=[AWL=-0.699, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 cvmbXtQgdxMR for ; Wed, 24 Jun 2009 10:23:30 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 3AECA3A6CC8 for ; Wed, 24 Jun 2009 10:23:30 -0700 (PDT) Received: by fxm9 with SMTP id 9so916886fxm.37 for ; Wed, 24 Jun 2009 10:20:17 -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=1OB6ibIxGOzHzsitXvZ05yc/tXiykFP2uEYuFUqyNUk=; b=tBSXfMVW0zPJmCCCrJSF0GpP1QBy2QFrIB3e39+JVV5XhRtcbT98R3Nu6S/EBVmCRw XznE4NH/FP6Es9+RhgfDt1FnsWjatbIredHJFjRoJJjhtNUX98Y8Tr8c7QFXCvltudYX XWbKHzO1kfEyY1Ewo0g3RUR0ZYBY3Mz0tcFb8= 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=kpzGjTS2Anwu5B0eHUdGojQiZJ7t99C942K6SLGmbUvOCNkdMFrZ9sh40C3GkgCpOL Z6Ub1xIWOEnAwmhelAzFoRIr2rL9qYByp+YysTSrhHjEefhNvaRypUodJ5Kbuk5RRnu7 EZ/V2H3iziDF15qFRSXn/FeXNQ+RAq1jVo14Q= MIME-Version: 1.0 Received: by 10.103.131.13 with SMTP id i13mr870688mun.64.1245862120989; Wed, 24 Jun 2009 09:48:40 -0700 (PDT) In-Reply-To: References: <00c401c9f4da$f36dd880$da498980$@de> Date: Wed, 24 Jun 2009 12:48:40 -0400 Message-ID: <6e9223710906240948v56119fceocc9fa5217a7f67d8@mail.gmail.com> From: stephen botzko To: Henry Sinnreich Content-Type: multipart/alternative; boundary=001636416adf292320046d1ae12f Cc: "codec@ietf.org" Subject: Re: [codec] Disruptive Technology? 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, 24 Jun 2009 17:23:32 -0000 --001636416adf292320046d1ae12f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't think this is fair characterization of the discussion. No one is attempting to exclude anyone, the discussion is centered on whether an IETF codec working group is necessary or useful. Regards Stephen Botzko Polycom On Wed, Jun 24, 2009 at 11:23 AM, Henry Sinnreich wrote= : > Christian, > > Thanks for sharing this valuable insight. > It comes at the right time, when apparently the discussions here seem all > about how the voice codec incumbents can keep the newcomers out. > > My strict personal (IETF contributor hat) 2 cents, > > Henry > > > > On 6/24/09 9:49 AM, "Christian Hoene" wrote: > > Hi all, > > this discussion reminds me on the concept of "Disruptive Technology" as > introduced by Clayton M. Christensen in 1995. Did you read his book? The > Wikipedia article gives a short introduction: > http://en.wikipedia.org/wiki/Disruptive_technology > > "A disruptive technology or disruptive innovation is an innovation that > improves a product or service in ways that the market does not expect, > typically by being lower priced or designed for a different set of > consumers. ... Disruptive technologies are particularly threatening to th= e > leaders of an existing market, because they are competition coming from a= n > unexpected direction. A disruptive technology can come to dominate an > existing market by either filling a role in a new market that the older > technology could not fill (as cheaper, lower capacity but smaller-sized > flash memory is doing for personal data storage in the 2000s) or by > successively moving up-market through performance improvements until > finally > displacing the market incumbents (as digital photography has largely > replaced film photography)." > "as Christensen points out and studies have shown, it is often entirely > rational for incumbent companies to ignore disruptive innovations, since > they compare so badly with existing technologies or products, and the > deceptively small market available for a disruptive innovation is often > very > small compared to the market for the established technology." > "Even if a disruptive innovation is recognized, existing businesses are > often reluctant to take advantage of it, since it would involve competing > with their existing (and more profitable) technological approach. > Christensen recommends that existing firms watch for these innovations, > invest in small firms that might adopt these innovations, and continue to > push technological demands in their core market so that performance stays > above what disruptive technologies can achieve." > > It is clear that this discussion is not about businesses, firms or produc= ts > but on standards and SDOs. However, there are many parallels: Jean-Marcs > approach on codec design can be seen as disruptive technology. The workin= g > procedures of ITU/3GPP are the traditional technological approach. > > If this discussion is really about a new disruptive technology, it makes > perfectly sense to start a new group in a new organizational structure. > Because disruptive technologies cannot be developed in the existing > organizations--to many resistances--but only in newly formed. > > With best regards, > > Christian > > > -------------------------------------------------------- > Dr.-Ing. Christian Hoene > Computer Networks and Internet, University of T=FCbingen > Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 > http://net.informatik.uni-tuebingen.de/~hoene > > > > _______________________________________________ > 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 > > --001636416adf292320046d1ae12f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't think this is fair characterization of the discussion.=A0 No on= e is attempting to exclude anyone, the discussion is centered on whether an= IETF codec working group is necessary or useful.

Regards
Stephe= n Botzko
Polycom




On Wed, Jun 24, 2009 = at 11:23 AM, Henry Sinnreich <hsinnrei@adobe.com> wrote:
Christian,

Thanks for sharing this valuable insight.
It comes at the right time, when apparently the discussions here seem all a= bout how the voice codec incumbents can keep the newcomers out.

My strict personal (IETF contributor hat) 2 cents,

Henry



On 6/24/09 9:49 AM, "Christian Hoene" <hoene@uni-tuebingen.de> wrote:<= br>
Hi all,

this discussion reminds me on the concept of "Disruptive Technology&qu= ot; as
introduced by Clayton M. Christensen in 1995. Did you read his book? The Wikipedia article gives a short introduction:
http://en.wikipedia.org/wiki/Disruptive_technology

"A disruptive technology or disruptive innovation is an innovation tha= t
improves a product or service in ways that the market does not expect,
typically by being lower priced or designed for a different set of
consumers. ... Disruptive technologies are particularly threatening to the<= br> leaders of an existing market, because they are competition coming from an<= br> unexpected direction. A disruptive technology can come to dominate an
existing market by either filling a role in a new market that the older
technology could not fill (as cheaper, lower capacity but smaller-sized
flash memory is doing for personal data storage in the 2000s) or by
successively moving up-market through performance improvements until finall= y
displacing the market incumbents (as digital photography has largely
replaced film photography)."
"as Christensen points out and studies have shown, it is often entirel= y
rational for incumbent companies to ignore disruptive innovations, since they compare so badly with existing technologies or products, and the
deceptively small market available for a disruptive innovation is often ver= y
small compared to the market for the established technology."
"Even if a disruptive innovation is recognized, existing businesses ar= e
often reluctant to take advantage of it, since it would involve competing with their existing (and more profitable) technological approach.
Christensen recommends that existing firms watch for these innovations,
invest in small firms that might adopt these innovations, and continue to push technological demands in their core market so that performance stays above what disruptive technologies can achieve."

It is clear that this discussion is not about businesses, firms or products=
but on standards and SDOs. However, there are many parallels: Jean-Marcs approach on codec design can be seen as disruptive technology. The working<= br> procedures of ITU/3GPP are the traditional technological approach.

If this discussion is really about a new disruptive technology, it makes perfectly sense to start a new group in a new organizational structure.
Because disruptive technologies cannot be developed in the existing
organizations--to many resistances--but only in newly formed.

With best regards,

=A0Christian


--------------------------------------------------------
Dr.-Ing. Christian Hoene
Computer Networks and Internet, University of T=FCbingen
Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532
http://net.informatik.uni-tuebingen.de/~hoene



_______________________________________________
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


--001636416adf292320046d1ae12f-- From koen.vos@skype.net Wed Jun 24 12:36: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 3C0153A6FF5 for ; Wed, 24 Jun 2009 12:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.184 X-Spam-Level: X-Spam-Status: No, score=-6.184 tagged_above=-999 required=5 tests=[AWL=0.415, 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 Kn6BElJ5dLLU for ; Wed, 24 Jun 2009 12:36:02 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id DB7973A6FE5 for ; Wed, 24 Jun 2009 12:36:01 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 8F1182007A977 for ; Wed, 24 Jun 2009 21:36:07 +0200 (CEST) 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=14ig38QipZCZ fCCTs6b20UebGu8=; b=MLzhLfsOsbwH+EOV0wdTd/ksjibN2JcVItOaMuLJ3t2U +0N/0/GVCb8JYT4vIspvP05b3sg7cr5udNK7Lu1HsvA0GXHiBy7ZHXqkZ+ycaK1Z P8DD4TzHE8Nl01bOfVognMOmojyxSx/+Rt6cAGWBaGozclW1aSzgepVTtUzL6uA= 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=sDSeGyQagZ9D1n8Nnc2I mYLcEGaJ9mptpkuGBDccCE0DwYZgpAkDjB9DbkoPgjJZQBlVXpB55KXUhhWuH6S/ ipQO6NCPK+1xAgbGNk4J0qS/RfhChjCQ52HX3Wh2H6ObDXH49MTUVYlMBPObPdSD PXLfiqKOCK15xoLmxRA9/uY= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 8D98B2007A974 for ; Wed, 24 Jun 2009 21:36:07 +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 BxklQ44RDMbm for ; Wed, 24 Jun 2009 21:36:06 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id D20862007A978; Wed, 24 Jun 2009 21:36:06 +0200 (CEST) Received: from adsl-71-141-96-214.dsl.snfc21.pacbell.net (adsl-71-141-96-214.dsl.snfc21.pacbell.net [71.141.96.214]) by mail.skype.net (Horde Framework) with HTTP; Wed, 24 Jun 2009 12:36:06 -0700 Message-ID: <20090624123606.72776dheyi1qxzja@mail.skype.net> Date: Wed, 24 Jun 2009 12:36:06 -0700 From: Koen Vos To: codec@ietf.org References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se> <008901c9f4ad$19be47f0$4d3ad7d0$@de> <4A41F39F.5020402@acm.org> <4A420C51.5060603@acm.org> <4A421BAC.1030206@usherbrooke.ca> <4a422476.0f345e0a.6184.22b8@mx.google.com> In-Reply-To: <4a422476.0f345e0a.6184.22b8@mx.google.com> 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] Codec BOF approved, much work needed 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, 24 Jun 2009 19:36:03 -0000 Quoting Roni Even about the risk of patent infringement: > As for your third choice you forgot to say "hopefully" solve the problem > since like was discussed in separate thread you cannot guarantee it and you > will not provide any protection against it. Good point. Wouldn't the IETF WG be especially useful for solving the problem with a larger degree of confidence? We want to identify patents that may be infringed upon as early as possible - when we can still modify the codec without disrupting a large install base. Having more experts involved increases the likelihood of that. As a bonus it will instill confidence in adopters of the codec that the IP risk is low. koen. From stewe@stewe.org Wed Jun 24 18:41: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 39CBA28C150 for ; Wed, 24 Jun 2009 18:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.795 X-Spam-Level: X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[AWL=-0.246, BAYES_00=-2.599, SARE_TOWRITE=1.05] 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 TkPMtDTt55gn for ; Wed, 24 Jun 2009 18:41:04 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id D33603A6D7B for ; Wed, 24 Jun 2009 18:41:03 -0700 (PDT) Received: from [172.16.0.136] (unverified [66.206.218.2]) by stewe.org (SurgeMail 3.9e) with ESMTP id 314796-1743317 for multiple; Thu, 25 Jun 2009 03:40:16 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Wed, 24 Jun 2009 21:40:08 -0400 From: Stephan Wenger To: Koen Vos , Message-ID: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acn1Nd79n7RjTDhz1EOC8OA4vWGXTg== In-Reply-To: <20090624123606.72776dheyi1qxzja@mail.skype.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 66.206.218.2 X-Authenticated-User: stewe@stewe.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 25 Jun 2009 01:41:05 -0000 On 6/24/09 3:36 PM, "Koen Vos" wrote: > Quoting Roni Even about the risk of patent infringement: > >> As for your third choice you forgot to say "hopefully" solve the problem >> since like was discussed in separate thread you cannot guarantee it and you >> will not provide any protection against it. > > Good point. Wouldn't the IETF WG be especially useful for solving the > problem with a larger degree of confidence? We want to identify > patents that may be infringed upon as early as possible - when we can > still modify the codec without disrupting a large install base. > Having more experts involved increases the likelihood of that. As a > bonus it will instill confidence in adopters of the codec that the IP > risk is low. > > koen. > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec Hi Koen, I thought I would drop out of this discussion, but since this is something where I think I can educate without necessarily being opinionated in the creation of a Codec WG, I decided to write anyway. FYI, I have followed the IETF IPR policy process for many years, and influencing IPR policies in some 30 SDOs was my day job during my Nokia tenure. The IETF's patent policy can be found in RFC3979. Compared to the IPR policies of some other SDOs, this is a reasonably accessible document, and I encourage study. Also very relevant are are the "Note Well" statement and RFC 2026. A number of other documents complete the framework; you can find references to those, for example, here: http://www.ietf.org/IESG/content/procdocs.html . To summarize the parts relevant for my argumentation below in my own words, one has to "participate" in the creation of a document in order to be obligated to make IPR disclosures. Common understanding is that if you go to the mike during the WG meeting, or post something to a relevant mailing list, or co-author an I-D, you have a disclosure obligation. However, if you sit in a meeting and/or are subscribed to a mailing list, and you are careful not to influence the consensus process (and therefore do not "participate"), you do not have a disclosure obligation. See section 7 of RFC 3978. This situation, I can assure you, is very well known and understood in companies who are actively playing in the IPR playground. Now, if you were from one of these companies which think that they have valuable IPR in this field to protect, would you participate? Probably not---even if you would wish so personally---because you may well be under orders by the lawyers. However, it is completely acceptable, by IETF policy and practice, to sit in those meetings, take notes, perhaps improve the codec back home and file applications of your improving inventions like crazy. Those may well "interpolate" the possible outcome. You just must never say a thing. Beyond that, while those who open their mouth do have a disclosure obligation, the policy is silent about minimum licensing terms that need to be offered. There's not even a requirement for RAND terms---though those (and non-assert terms) are most common in the IETF. This is in contrast to, for example, the ITU---where you do have to license your stuff under RAND terms. This doesn't help opens source, but---all in all---has worked well enough in the rest of the industry. In W3C, to go to the other end of the spectrum, when you are a member of a WG, you must license under Royalty-Free (though not necessarily open-source compatible) terms, or face consequences. The IETF disclosure process is designed to work well when most (or all) of the companies in the room have the same goal of creating a successful IETF RFC to solve a certain problem. It even works when competing proposals are in the picture. However, it's not my reading that some of the powerhouses will likely participate in hypothetical IETF codec work. In that case, the IETF's IPR policy IMO does not work very well for your goal of an accessible standard. There is also one other thing that should be kept in mind: the possibility of gaming. If you would have an (unwritten, I assume) WG-local policy of a codec whose IPR is available under open-source compatible terms, it takes only one reckless---or, uninformed, or erroneous---disclosure to derail the whole process. This is FUD at its best. Possibly, the work will come to a screeching halt for more than a year, until the disclosed application is published. Even if there is a published application, someone would have to offer a claim chart or another analysis of the patent or application. That's lawyer work and not likely to happen, due to the possible consequences (willful infringement etc.). Organizations such as the W3C have a well defined conflict resolution mechanism for this situation; the IETF has not. IMHO, IPR-related gaming (or something that comes awfully close to it) has happened before in our organization---you will have to allow me to skip expressing my suspicions. That is why I do not see the IETF as a good organization to entertain a contentious project like this. Regards, Stephan From rjesup@wgate.com Wed Jun 24 22:15: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 D71A528C160 for ; Wed, 24 Jun 2009 22:15:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.202 X-Spam-Level: X-Spam-Status: No, score=-1.202 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.1, SARE_UNSUB22=0.948] 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 Gkfrrx3Wz+Nw for ; Wed, 24 Jun 2009 22:15:37 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id CB6503A6813 for ; Wed, 24 Jun 2009 22:15:36 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 00:41:42 -0400 To: "Roni Even" References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se> <008901c9f4ad$19be47f0$4d3ad7d0$@de> <4A41F39F.5020402@acm.org> <4A420C51.5060603@acm.org> <4A421BAC.1030206@usherbrooke.ca> <4a422476.0f345e0a.6184.22b8@mx.google.com> From: Randell Jesup Date: Thu, 25 Jun 2009 00:42:12 -0400 In-Reply-To: <4a422476.0f345e0a.6184.22b8@mx.google.com> (Roni Even's message of "Wed\, 24 Jun 2009 16\:04\:48 +0300") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 25 Jun 2009 04:41:42.0537 (UTC) FILETIME=[3CA3F790:01C9F54F] Cc: 'Gibbs Jon-CJG019' , codec@ietf.org, 'Jean-Marc Valin' Subject: Re: [codec] Codec BOF approved, much work needed X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup 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, 25 Jun 2009 05:15:38 -0000 "Roni Even" writes: >G.718 is a new codec and I am not aware that some entity decided that it is >not for us humans. What Jean-Marc meant (I think) was that G.718 is (quite) encumbered, and thus not useful to people who can't license it for the application they want to persue (open-source, downloadable, etc - see below). I couldn't even find a unified licensing agency like MPEG-LA (though I didn't look hard either). >> > The declared IPR patent and copyright statements may be found here >> > http://www.itu.int/ipr/IPRSearch.aspx - just enter "G.718" for >> > Recommendation No. >> > >> > ...but it seems that you've already decided that it's not for you, or >> > the IETF... >> >> It is actually the other way around. Someone has decided that G.718 was >> not for us. I am not familiar with all the technical details of G.718, >> but I have no problem imagining that it fits the telco's needs very >> well >> -- even for IP transport. The problem is that its licensing makes it >> impossible to use for many applications because of the patents it >> involves. How good is a codec which you cannot use. If my VoIP >> application has to be freely downloadable, or embedded in a web page as >> a Java applet, or if I want to link it with open source software... >> then >> a patent-encumbered codec cannot be legally used. What are you >> suggesting we should do. So far, I see three possible options: >> 1) Break the law by infringing on patents >> 2) Use codecs on which patents are expired (G.711 and GSM-FR are still >> popular) >> 3) Design a new codec that will solve the problem >> >> I choose 3). -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From rjesup@wgate.com Wed Jun 24 22:15:39 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 5BA713A6778 for ; Wed, 24 Jun 2009 22:15:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.634 X-Spam-Level: X-Spam-Status: No, score=-1.634 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.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 ZctzRzkLQpEx for ; Wed, 24 Jun 2009 22:15:37 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 411A428C142 for ; Wed, 24 Jun 2009 22:15:37 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 00:48:46 -0400 To: Herve Taddei References: <130EBB38279E9847BAAAE0B8F9905F8C016BD2F8@esealmw109.eemea.ericsson.se> <4A411E98.5080903@octasic.com> <130EBB38279E9847BAAAE0B8F9905F8C016BD5C6@esealmw109.eemea.ericsson.se> <008901c9f4ad$19be47f0$4d3ad7d0$@de> <004a01c9f4b5$3b525840$0aa31e55@china.huawei.com> From: Randell Jesup Date: Thu, 25 Jun 2009 00:49:17 -0400 In-Reply-To: <004a01c9f4b5$3b525840$0aa31e55@china.huawei.com> (Herve Taddei's message of "Wed\, 24 Jun 2009 12\:19\:10 +0200") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 25 Jun 2009 04:48:46.0787 (UTC) FILETIME=[39836130:01C9F550] Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup 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, 25 Jun 2009 05:15:39 -0000 Herve Taddei writes: >> - It is fine if the internet codec has not perfect but fairly well audio >> quality. Most of the bandwidth is wasted for Internet packet headers >> anyhow. > >Header compression can be used to reduce overhead. What is fairly well audio >quality? Header compression may not be usable in a lot of (most?) situations. >> - Also, ITU, MPEG and 3GPP has failed yet to develop a codec supporting >> ultra low latency important for new kind of applications like ensemble >> performances over the net.. > >G.711, G.711.1, G.722? At least those are low latency to my opinion. > >How do you define ultra low latency? BTW, for VoIP, the lower the delay the >higher the overhead. That is why many VoIP codecs are rather looking to >10/20 and even 30 ms frame size. G.718 for example has over 40ms of algorithmic latency (add that to packetization period, jitter-buffering delay, other fixed delays, and transit time, and you have issues. Usable: sure, for some network types and applications, but limited due to that >40 ms delay. >> from the approach that the ITU follows. Also, the stockholders in the IETF >> are different. IETFs contribution are driven by individuals not by larger >> companies like in the ITU. Thus, hopefully the interests of users and the > >BTW, you could give a look to the ITU-T list of companies, there are some >very small companies registered, sometime with less than 10 employees. So >this statement is not really correct. "Being in the list" and "driving development" (especially day-to-day) are very different things. I checked; ITU membership is WAY to expensive for me. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From koen.vos@skype.net Wed Jun 24 22:29:21 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 4514C3A68A1 for ; Wed, 24 Jun 2009 22:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.697 X-Spam-Level: X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[AWL=-0.148, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_TOWRITE=1.05] 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 QyJxul5tNXMN for ; Wed, 24 Jun 2009 22:29:18 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 25E6528C0F8 for ; Wed, 24 Jun 2009 22:29:07 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 2B92C2007A7F2 for ; Thu, 25 Jun 2009 07:28:09 +0200 (CEST) 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=xulXq1GCM0+X ZYvONGFYsA5Oj0E=; b=VJhegolVx0kxbI87Ubl1BD/gpmx2fGECbdn78A3dwOtn uOYttyixwV1X6E7JkR94AnakIvi+4/3sSI62iUEp0ZlbtLe84a3wa7tHSy3Qnm8k hFOpgGW1u3Qb1TuYqgkp/fM1XvA4K0xR5Aavl7ujjvFmp1PiI+RaKRvRWtePmWM= 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=VPwP6aPgTdMl115Ovvk9 W4Wh8Tuw5o9W+8qASC3AiHYTLYMT4b7VAZplT6Y1dC5qj2Src0DK7EOBUIZiG3Kh Jk5PLLRGaTjcxN3LfCMs8cjypD820hLB8+1/08rDzBCGLypAE5Ea2COhDaJLEkli fZk1O5mVI7nfYUlxKBpO4uI= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 2A2342007A7EC for ; Thu, 25 Jun 2009 07:28: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 HhypthfwlCYO for ; Thu, 25 Jun 2009 07:27:59 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 57E652007A7BA; Thu, 25 Jun 2009 07:27:59 +0200 (CEST) Received: from adsl-71-141-96-214.dsl.snfc21.pacbell.net (adsl-71-141-96-214.dsl.snfc21.pacbell.net [71.141.96.214]) by mail.skype.net (Horde Framework) with HTTP; Wed, 24 Jun 2009 22:27:59 -0700 Message-ID: <20090624222759.13482jyf2wr43nq7@mail.skype.net> Date: Wed, 24 Jun 2009 22:27:59 -0700 From: Koen Vos To: codec@ietf.org References: 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] Codec BOF approved, much work needed 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, 25 Jun 2009 05:29:21 -0000 Stephan, You may have missed my point - I meant the following: People who write speech codecs typically have a decent grasp of what is already patented and what not - even for patents not owned by themselves or their employers. Being part of the Codec WG, some of these codec developers will feel inclined to notify that a codec proposal may infringe on a certain patent, because doing so is in the interest of achieving the Royalty Free goal. Patents that are found to be infringed on can usually be worked around. As a result, the IETF codec standardization process results in a higher degree of confidence that no patents are infringed than if the codec were made available without the IETF process. > Now, if you were from one of these companies which think that they have > valuable IPR in this field to protect, would you participate? Probably > not---even if you would wish so personally---because you may well be under > orders by the lawyers. That's not an argument against my thesis: I'm talking about other people, who will participate. > However, it is completely acceptable, by IETF policy and practice, to sit in > those meetings, take notes, perhaps improve the codec back home and file > applications of your improving inventions like crazy. Those may well > "interpolate" the possible outcome. You just must never say a thing. This approach to gaming the system seems like a long (and expensive) shot. But if we're really paranoid about it we could decide to only make modifications for which prior art exists. In that case these modifications can not have been patented in the mean time. Would that alleviate your worries? koen. Quoting Stephan Wenger : > On 6/24/09 3:36 PM, "Koen Vos" wrote: > >> Quoting Roni Even about the risk of patent infringement: >> >>> As for your third choice you forgot to say "hopefully" solve the problem >>> since like was discussed in separate thread you cannot guarantee it and you >>> will not provide any protection against it. >> >> Good point. Wouldn't the IETF WG be especially useful for solving the >> problem with a larger degree of confidence? We want to identify >> patents that may be infringed upon as early as possible - when we can >> still modify the codec without disrupting a large install base. >> Having more experts involved increases the likelihood of that. As a >> bonus it will instill confidence in adopters of the codec that the IP >> risk is low. >> >> koen. >> >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec > > Hi Koen, > > I thought I would drop out of this discussion, but since this is something > where I think I can educate without necessarily being opinionated in the > creation of a Codec WG, I decided to write anyway. FYI, I have followed the > IETF IPR policy process for many years, and influencing IPR policies in some > 30 SDOs was my day job during my Nokia tenure. > > The IETF's patent policy can be found in RFC3979. Compared to the IPR > policies of some other SDOs, this is a reasonably accessible document, and I > encourage study. Also very relevant are are the "Note Well" statement and > RFC 2026. A number of other documents complete the framework; you can find > references to those, for example, here: > http://www.ietf.org/IESG/content/procdocs.html . > > To summarize the parts relevant for my argumentation below in my own words, > one has to "participate" in the creation of a document in order to be > obligated to make IPR disclosures. Common understanding is that if you go > to the mike during the WG meeting, or post something to a relevant mailing > list, or co-author an I-D, you have a disclosure obligation. However, if > you sit in a meeting and/or are subscribed to a mailing list, and you are > careful not to influence the consensus process (and therefore do not > "participate"), you do not have a disclosure obligation. See section 7 of > RFC 3978. This situation, I can assure you, is very well known and > understood in companies who are actively playing in the IPR playground. > > Now, if you were from one of these companies which think that they have > valuable IPR in this field to protect, would you participate? Probably > not---even if you would wish so personally---because you may well be under > orders by the lawyers. > > However, it is completely acceptable, by IETF policy and practice, to sit in > those meetings, take notes, perhaps improve the codec back home and file > applications of your improving inventions like crazy. Those may well > "interpolate" the possible outcome. You just must never say a thing. > > Beyond that, while those who open their mouth do have a disclosure > obligation, the policy is silent about minimum licensing terms that need to > be offered. There's not even a requirement for RAND terms---though those > (and non-assert terms) are most common in the IETF. This is in contrast to, > for example, the ITU---where you do have to license your stuff under RAND > terms. This doesn't help opens source, but---all in all---has worked well > enough in the rest of the industry. In W3C, to go to the other end of the > spectrum, when you are a member of a WG, you must license under Royalty-Free > (though not necessarily open-source compatible) terms, or face consequences. > > The IETF disclosure process is designed to work well when most (or all) of > the companies in the room have the same goal of creating a successful IETF > RFC to solve a certain problem. It even works when competing proposals are > in the picture. However, it's not my reading that some of the powerhouses > will likely participate in hypothetical IETF codec work. In that case, the > IETF's IPR policy IMO does not work very well for your goal of an accessible > standard. > > There is also one other thing that should be kept in mind: the possibility > of gaming. If you would have an (unwritten, I assume) WG-local policy of a > codec whose IPR is available under open-source compatible terms, it takes > only one reckless---or, uninformed, or erroneous---disclosure to derail the > whole process. This is FUD at its best. Possibly, the work will come to a > screeching halt for more than a year, until the disclosed application is > published. Even if there is a published application, someone would have to > offer a claim chart or another analysis of the patent or application. > That's lawyer work and not likely to happen, due to the possible > consequences (willful infringement etc.). Organizations such as the W3C > have a well defined conflict resolution mechanism for this situation; the > IETF has not. IMHO, IPR-related gaming (or something that comes awfully > close to it) has happened before in our organization---you will have to > allow me to skip expressing my suspicions. > > That is why I do not see the IETF as a good organization to entertain a > contentious project like this. > > Regards, > Stephan > > > > From stephen.botzko@gmail.com Thu Jun 25 04:55: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 ADAEE3A6A64 for ; Thu, 25 Jun 2009 04:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.475 X-Spam-Level: X-Spam-Status: No, score=-1.475 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_TOWRITE=1.05] 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 ce4ixI0MUu+G for ; Thu, 25 Jun 2009 04:55:23 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 359153A6AAD for ; Thu, 25 Jun 2009 04:55:22 -0700 (PDT) Received: by fxm9 with SMTP id 9so1388892fxm.37 for ; Thu, 25 Jun 2009 04:52:53 -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=ZIWMkWxBH/YwB2eEBjXuOM3pZBlITvEX8HT2Ownale8=; b=JBkfm9v2KuA5zn1LjeNTuZAeHs4VQ+4u9cgYjKy7t8qaCN3AWN38zM62f3hj2BnSu9 wZt5GIXNMOW0wMFYXLw0FI8WCKrc9eXSMDVm90Mf6jgYPT2vAqSnCamatK4zCNi4k+zG gPIXjwKBLHxaX2Hi4C0Psgi3/8sXwoJMt8DeU= 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=vLfuQdCUeg3PSuyKoZc3LoDiaXz1iybZeYlrAbpoKV7YrE/dULojO3W4TrFBorHBSy HOzhS+LEwH7hx5J0fzlJBmGiiouIChEmIUwmRjC6JQv9RIJtlrxOSHmys29Ump6iubiZ +0kMlB5echEPBSmFEz/A9LrdcK7DMKrFGJKMc= MIME-Version: 1.0 Received: by 10.103.121.19 with SMTP id y19mr1450736mum.103.1245930773148; Thu, 25 Jun 2009 04:52:53 -0700 (PDT) In-Reply-To: <20090624222759.13482jyf2wr43nq7@mail.skype.net> References: <20090624222759.13482jyf2wr43nq7@mail.skype.net> Date: Thu, 25 Jun 2009 07:52:53 -0400 Message-ID: <6e9223710906250452p70f11547gec483cdd0d7ac072@mail.gmail.com> From: stephen botzko To: Koen Vos Content-Type: multipart/alternative; boundary=001636b430fb25f6ac046d2add34 Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 25 Jun 2009 11:55:24 -0000 --001636b430fb25f6ac046d2add34 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'd be interested in Stephan's response as well, but I do have a couple of comments inline. Stephen Botzko Polycom On Thu, Jun 25, 2009 at 1:27 AM, Koen Vos wrote: > Stephan, > > You may have missed my point - I meant the following: > > People who write speech codecs typically have a decent grasp of what is > already patented and what not - even for patents not owned by themselves or > their employers. Being part of the Codec WG, some of these codec developers > will feel inclined to notify that a codec proposal may infringe on a certain > patent, because doing so is in the interest of achieving the Royalty Free > goal. Patents that are found to be infringed on can usually be worked > around. As a result, the IETF codec standardization process results in a > higher degree of confidence that no patents are infringed than if the codec > were made available without the IETF process. > I think you will find in practice that the knowledge of what's patented is much less complete than you are thinking. There are lots of countries where patents can be filed, translations of applications are not always available, and understanding of claim scope requires an attorney's guidance and access to the prosecution history. Design-arounds require a legal analysis of the claim scope. Also, many patents are never asserted by the original assignee, and are "under the radar" until they are purchased (and asserted) by a patent "troll". Codec designers may have some idea of what other codec technologies need to be licensed, but I think this is the just the tip of the iceberg. > > > Now, if you were from one of these companies which think that they have >> valuable IPR in this field to protect, would you participate? Probably >> not---even if you would wish so personally---because you may well be under >> orders by the lawyers. >> > > That's not an argument against my thesis: I'm talking about other people, > who will participate. > I think Stephan is using "participate" in limited definition of RFC 3978/3979. They might very well attend the working group meetings, and might even make some contributions (perhaps to other codecs than the one they hold IPR on). > > > > However, it is completely acceptable, by IETF policy and practice, to sit >> in >> those meetings, take notes, perhaps improve the codec back home and file >> applications of your improving inventions like crazy. Those may well >> "interpolate" the possible outcome. You just must never say a thing. >> > > This approach to gaming the system seems like a long (and expensive) shot. > But if we're really paranoid about it we could decide to only make > modifications for which prior art exists. In that case these modifications > can not have been patented in the mean time. Would that alleviate your > worries? US applications do not need to be published, and can take 5 or more years to issue. It would be difficult to apply your prior art rule unless you are thinking about using very old prior art. Also, the expense of this approach is not prohibitive if your organization has a goal of obtaining revenue from their patents. This is not just a commercial activity either, since some universities also have signficant patent portfolios. I am concerned that a rule like this would greatly diminish the value of the collaboration you are seeking. Since codec quality matters, not just IPR terms, I'd say we need to be very careful here. > > > koen. > > > > Quoting Stephan Wenger : > >> On 6/24/09 3:36 PM, "Koen Vos" wrote: >> >> Quoting Roni Even about the risk of patent infringement: >>> >>> As for your third choice you forgot to say "hopefully" solve the problem >>>> since like was discussed in separate thread you cannot guarantee it and >>>> you >>>> will not provide any protection against it. >>>> >>> >>> Good point. Wouldn't the IETF WG be especially useful for solving the >>> problem with a larger degree of confidence? We want to identify >>> patents that may be infringed upon as early as possible - when we can >>> still modify the codec without disrupting a large install base. >>> Having more experts involved increases the likelihood of that. As a >>> bonus it will instill confidence in adopters of the codec that the IP >>> risk is low. >>> >>> koen. >>> >>> _______________________________________________ >>> codec mailing list >>> codec@ietf.org >>> https://www.ietf.org/mailman/listinfo/codec >>> >> >> Hi Koen, >> >> I thought I would drop out of this discussion, but since this is something >> where I think I can educate without necessarily being opinionated in the >> creation of a Codec WG, I decided to write anyway. FYI, I have followed >> the >> IETF IPR policy process for many years, and influencing IPR policies in >> some >> 30 SDOs was my day job during my Nokia tenure. >> >> The IETF's patent policy can be found in RFC3979. Compared to the IPR >> policies of some other SDOs, this is a reasonably accessible document, and >> I >> encourage study. Also very relevant are are the "Note Well" statement and >> RFC 2026. A number of other documents complete the framework; you can >> find >> references to those, for example, here: >> http://www.ietf.org/IESG/content/procdocs.html . >> >> To summarize the parts relevant for my argumentation below in my own >> words, >> one has to "participate" in the creation of a document in order to be >> obligated to make IPR disclosures. Common understanding is that if you go >> to the mike during the WG meeting, or post something to a relevant mailing >> list, or co-author an I-D, you have a disclosure obligation. However, if >> you sit in a meeting and/or are subscribed to a mailing list, and you are >> careful not to influence the consensus process (and therefore do not >> "participate"), you do not have a disclosure obligation. See section 7 of >> RFC 3978. This situation, I can assure you, is very well known and >> understood in companies who are actively playing in the IPR playground. >> >> Now, if you were from one of these companies which think that they have >> valuable IPR in this field to protect, would you participate? Probably >> not---even if you would wish so personally---because you may well be under >> orders by the lawyers. >> >> However, it is completely acceptable, by IETF policy and practice, to sit >> in >> those meetings, take notes, perhaps improve the codec back home and file >> applications of your improving inventions like crazy. Those may well >> "interpolate" the possible outcome. You just must never say a thing. >> >> Beyond that, while those who open their mouth do have a disclosure >> obligation, the policy is silent about minimum licensing terms that need >> to >> be offered. There's not even a requirement for RAND terms---though those >> (and non-assert terms) are most common in the IETF. This is in contrast >> to, >> for example, the ITU---where you do have to license your stuff under RAND >> terms. This doesn't help opens source, but---all in all---has worked well >> enough in the rest of the industry. In W3C, to go to the other end of the >> spectrum, when you are a member of a WG, you must license under >> Royalty-Free >> (though not necessarily open-source compatible) terms, or face >> consequences. >> >> The IETF disclosure process is designed to work well when most (or all) of >> the companies in the room have the same goal of creating a successful IETF >> RFC to solve a certain problem. It even works when competing proposals >> are >> in the picture. However, it's not my reading that some of the powerhouses >> will likely participate in hypothetical IETF codec work. In that case, >> the >> IETF's IPR policy IMO does not work very well for your goal of an >> accessible >> standard. >> >> There is also one other thing that should be kept in mind: the possibility >> of gaming. If you would have an (unwritten, I assume) WG-local policy of >> a >> codec whose IPR is available under open-source compatible terms, it takes >> only one reckless---or, uninformed, or erroneous---disclosure to derail >> the >> whole process. This is FUD at its best. Possibly, the work will come to >> a >> screeching halt for more than a year, until the disclosed application is >> published. Even if there is a published application, someone would have >> to >> offer a claim chart or another analysis of the patent or application. >> That's lawyer work and not likely to happen, due to the possible >> consequences (willful infringement etc.). Organizations such as the W3C >> have a well defined conflict resolution mechanism for this situation; the >> IETF has not. IMHO, IPR-related gaming (or something that comes awfully >> close to it) has happened before in our organization---you will have to >> allow me to skip expressing my suspicions. >> >> That is why I do not see the IETF as a good organization to entertain a >> contentious project like this. >> >> Regards, >> Stephan >> >> >> >> >> > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636b430fb25f6ac046d2add34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd be interested in Stephan's response as well, but I do have a co= uple of comments inline.

Stephen Botzko
Polycom

On Thu, Jun 25, 2009 at 1:27 AM, Koen Vos <koen.vos@skype.net> wrote:
Stephan,

You may have missed my point - I meant the following:

People who write speech codecs typically have a decent grasp of what is alr= eady patented and what not - even for patents not owned by themselves or th= eir employers. Being part of the Codec WG, some of these codec developers w= ill feel inclined to notify that a codec proposal may infringe on a certain= patent, because doing so is in the interest of achieving the Royalty Free = goal. Patents that are found to be infringed on can usually be worked aroun= d. As a result, the IETF codec standardization process results in a higher = degree of confidence that no patents are infringed than if the codec were m= ade available without the IETF process.

I think you will find in practice that the knowledg= e of what's patented is much less complete than you are thinking.=A0 Th= ere are lots of countries where patents can be filed, translations of appli= cations are not always available, and understanding of claim scope requires= an attorney's guidance and access to the prosecution history. Design-a= rounds require a legal analysis of the claim scope.

Also, many patents are never asserted by the original assignee, and are= "under the radar" until they are purchased (and asserted) by a p= atent "troll".=A0 Codec designers may have some idea of what othe= r codec technologies need to be licensed, but I think this is the just the = tip of the iceberg.
=A0


Now, if you were from one of these companies which think that they have
valuable IPR in this field to protect, would you participate? =A0Probably not---even if you would wish so personally---because you may well be under<= br> orders by the lawyers.

That's not an argument against my thesis: I'm talking about other p= eople, who will participate.

I= think Stephan is using "participate" in limited definition of RF= C 3978/3979.=A0 They might very well attend the working group meetings, and= might even make some contributions (perhaps to other codecs than the one t= hey hold IPR on).
=A0



However, it is completely acceptable, by IETF policy and practice, to sit i= n
those meetings, take notes, perhaps improve the codec back home and file applications of your improving inventions like crazy. Those may well
"interpolate" the possible outcome. =A0You just must never say a = thing.

This approach to gaming the system seems like a long (and expensive) shot. = But if we're really paranoid about it we could decide to only make modi= fications for which prior art exists. In that case these modifications can = not have been patented in the mean time. Would that alleviate your worries?=
=A0
US applications do not need to be published, and can tak= e 5 or more years to issue.=A0 It would be difficult to apply your prior ar= t rule unless you are thinking about using very old prior art.=A0 Also, the= expense of this approach is not prohibitive if your organization has a goa= l of obtaining revenue from their patents.=A0 This is not just a commercial= activity either, since some universities also have signficant patent portf= olios.

I am concerned that a rule like this would greatly diminish the value o= f the collaboration you are seeking.=A0 Since codec quality matters, not ju= st IPR terms, I'd say we need to be very careful here.
=A0


koen.



Quoting Stephan Wenger <stewe@stewe.org>:
On 6/24/09 3:36 PM, "Koen Vos" <koen.vos@skype.net> wrote:

Quoting Roni Even about the risk of patent infringement:

As for your third choice you forgot to say "hopefully" solve the = problem
since like was discussed in separate thread you cannot guarantee it and you=
will not provide any protection against it.

Good point. =A0Wouldn't the IETF WG be especially useful for solving th= e
problem with a larger degree of confidence? =A0We want to identify
patents that may be infringed upon as early as possible - when we can
still modify the codec without disrupting a large install base.
Having more experts involved increases the likelihood of that. =A0As a
bonus it will instill confidence in adopters of the codec that the IP
risk is low.

koen.

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

Hi Koen,

I thought I would drop out of this discussion, but since this is something<= br> where I think I can educate without necessarily being opinionated in the creation of a Codec WG, I decided to write anyway. =A0FYI, I have followed = the
IETF IPR policy process for many years, and influencing IPR policies in som= e
30 SDOs was my day job during my Nokia tenure.

The IETF's patent policy can be found in RFC3979. =A0Compared to the IP= R
policies of some other SDOs, this is a reasonably accessible document, and = I
encourage study. =A0Also very relevant are are the "Note Well" st= atement and
RFC 2026. =A0A number of other documents complete the framework; you can fi= nd
references to those, for example, here:
http://www.ietf.org/IESG/content/procdocs.html .

To summarize the parts relevant for my argumentation below in my own words,=
one has to "participate" in the creation of a document in order t= o be
obligated to make IPR disclosures. =A0Common understanding is that if you g= o
to the mike during the WG meeting, or post something to a relevant mailing<= br> list, or co-author an I-D, you have a disclosure obligation. =A0However, if=
you sit in a meeting and/or are subscribed to a mailing list, and you are careful not to influence the consensus process (and therefore do not
"participate"), you do not have a disclosure obligation. =A0See s= ection 7 of
RFC 3978. =A0This situation, I can assure you, is very well known and
understood in companies who are actively playing in the IPR playground.

Now, if you were from one of these companies which think that they have
valuable IPR in this field to protect, would you participate? =A0Probably not---even if you would wish so personally---because you may well be under<= br> orders by the lawyers.

However, it is completely acceptable, by IETF policy and practice, to sit i= n
those meetings, take notes, perhaps improve the codec back home and file applications of your improving inventions like crazy. =A0Those may well
"interpolate" the possible outcome. =A0You just must never say a = thing.

Beyond that, while those who open their mouth do have a disclosure
obligation, the policy is silent about minimum licensing terms that need to=
be offered. =A0There's not even a requirement for RAND terms---though t= hose
(and non-assert terms) are most common in the IETF. =A0This is in contrast = to,
for example, the ITU---where you do have to license your stuff under RAND terms. =A0This doesn't help opens source, but---all in all---has worked= well
enough in the rest of the industry. =A0In W3C, to go to the other end of th= e
spectrum, when you are a member of a WG, you must license under Royalty-Fre= e
(though not necessarily open-source compatible) terms, or face consequences= .

The IETF disclosure process is designed to work well when most (or all) of<= br> the companies in the room have the same goal of creating a successful IETF<= br> RFC to solve a certain problem. =A0It even works when competing proposals a= re
in the picture. =A0However, it's not my reading that some of the powerh= ouses
will likely participate in hypothetical IETF codec work. =A0In that case, t= he
IETF's IPR policy IMO does not work very well for your goal of an acces= sible
standard.

There is also one other thing that should be kept in mind: the possibility<= br> of gaming. =A0 If you would have an (unwritten, I assume) WG-local policy o= f a
codec whose IPR is available under open-source compatible terms, it takes only one reckless---or, uninformed, or erroneous---disclosure to derail the=
whole process. =A0This is FUD at its best. =A0Possibly, the work will come = to a
screeching halt for more than a year, until the disclosed application is published. =A0Even if there is a published application, someone would have = to
offer a claim chart or another analysis of the patent or application.
That's lawyer work and not likely to happen, due to the possible
consequences (willful infringement etc.). =A0Organizations such as the W3C<= br> have a well defined conflict resolution mechanism for this situation; the IETF has not. =A0 IMHO, IPR-related gaming (or something that comes awfully=
close to it) has happened before in our organization---you will have to
allow me to skip expressing my suspicions.

That is why I do not see the IETF as a good organization to entertain a
contentious project like this.

Regards,
Stephan






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

--001636b430fb25f6ac046d2add34-- From koen.vos@skype.net Thu Jun 25 12:38: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 06CDA3A6E04 for ; Thu, 25 Jun 2009 12:38:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=0.390, 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 fW9f0Madmlhn for ; Thu, 25 Jun 2009 12:38:11 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id AC9193A6ACA for ; Thu, 25 Jun 2009 12:38:10 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 84A102007AAD8 for ; Thu, 25 Jun 2009 21:37:38 +0200 (CEST) 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=tDrG5eBIJxxe HUbhMfLwxPqQHS0=; b=jYvc3j0o6PdVOtzFwNUj12jheel2hsB0+R8IrfvcFtnf OkM1ZCjofmE1fRW+addkYMz7Ld3hpKF/J4Xce4Y1aYBPZkZEQn7wKIeYUR9IMF25 oY35x3t+KwSDENmYALMHZzw4v1yHZlApBLzsTMianu1zjEBEETCXnYObqgcVUvk= 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=FPehz9ciWd6e2MrpUSQH cUKu0Bf9kBReozRtoFC+q1rsqkAogvy896T3Bee7XOMvhPEpRp/Z11Hnt6C97LiN 2Wy8URcStAqoTg5XLANRLxbBywKoe6GQtOLhpLD2ca0IE0dptZssCw2q+cxvS9m4 0Kx+7eu8C9pp2R2+5tZMMUE= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 833C82007AAD1 for ; Thu, 25 Jun 2009 21:37:38 +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 2Vmb4Punbijl for ; Thu, 25 Jun 2009 21:37:37 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 760802007AAD5; Thu, 25 Jun 2009 21:37:37 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Thu, 25 Jun 2009 12:37:37 -0700 Message-ID: <20090625123737.26143iaxh4bom77l@mail.skype.net> Date: Thu, 25 Jun 2009 12:37:37 -0700 From: Koen Vos To: codec@ietf.org References: <20090624222759.13482jyf2wr43nq7@mail.skype.net> <6e9223710906250452p70f11547gec483cdd0d7ac072@mail.gmail.com> In-Reply-To: <6e9223710906250452p70f11547gec483cdd0d7ac072@mail.gmail.com> 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] Codec BOF approved, much work needed 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, 25 Jun 2009 19:38:12 -0000 Quoting stephen botzko: >> But if we're really paranoid about it we could decide to only make >> modifications for which prior art exists. In that case these modifications >> can not have been patented in the mean time. Would that alleviate your >> worries? > > > US applications do not need to be published, and can take 5 or more years to > issue. It would be difficult to apply your prior art rule unless you are > thinking about using very old prior art. Also, the expense of this approach > is not prohibitive if your organization has a goal of obtaining revenue from > their patents. This is not just a commercial activity either, since some > universities also have signficant patent portfolios. If the modifications consists of a method (let's say from a journal publication) that already existed before today, then that modification cannot be patented anymore. So someone trying to "sneakily" file for a patent on an improvement that he sees coming by "interpolating" events at IETF could indeed be stopped. > I am concerned that a rule like this would greatly diminish the value of the > collaboration you are seeking. Since codec quality matters, not just IPR > terms, I'd say we need to be very careful here. Not sure. A good approach to building a royalty free codec is by starting out with prior art. Preferably from the 70s and 80s. I'd say at least 80% of the technology in any modern speech codec already existed in 1990. You get a long way by just combining existing ideas. Otherwise I agree with you that we'll never be sure that a codec does not infringe on any patents. That's a risk with any standard, and in fact any piece of technology. But I maintain that a codec that has gone through IETF standardization will be perceived as having less risk than if the same codec had not gone through standardization. koen. From stewe@stewe.org Thu Jun 25 13:19:29 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 220703A6972 for ; Thu, 25 Jun 2009 13:19:29 -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=1.926, 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 xIvTBF4dvJv3 for ; Thu, 25 Jun 2009 13:19:28 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id E1A6F3A67E3 for ; Thu, 25 Jun 2009 13:18:51 -0700 (PDT) Received: from [192.168.1.2] (unverified [68.197.227.183]) by stewe.org (SurgeMail 3.9e) with ESMTP id 315738-1743317 for multiple; Thu, 25 Jun 2009 21:59:31 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 25 Jun 2009 15:59:20 -0400 From: Stephan Wenger To: Koen Vos , Message-ID: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acn1z21yBcBqHDPpgkWAvLrFe67y/w== In-Reply-To: <20090625123737.26143iaxh4bom77l@mail.skype.net> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 68.197.227.183 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (68.197.227.183) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [codec] Codec BOF approved, much work needed 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, 25 Jun 2009 20:19:29 -0000 Hi Koen, See a few remarks inline. Stephan On 6/25/09 3:37 PM, "Koen Vos" wrote: > Quoting stephen botzko: >>> But if we're really paranoid about it we could decide to only make >>> modifications for which prior art exists. In that case these modifications >>> can not have been patented in the mean time. Would that alleviate your >>> worries? >> >> >> US applications do not need to be published, and can take 5 or more years to >> issue. It would be difficult to apply your prior art rule unless you are >> thinking about using very old prior art. Also, the expense of this approach >> is not prohibitive if your organization has a goal of obtaining revenue from >> their patents. This is not just a commercial activity either, since some >> universities also have signficant patent portfolios. > > If the modifications consists of a method (let's say from a journal > publication) that already existed before today, then that modification > cannot be patented anymore. To be precise, it depends on whether the journal article precedes the priority date of the patent application in question. The priority "locks in" the specification, but not necessarily the claims. > So someone trying to "sneakily" file for > a patent on an improvement that he sees coming by "interpolating" > events at IETF could indeed be stopped. > >> I am concerned that a rule like this would greatly diminish the value of the >> collaboration you are seeking. Since codec quality matters, not just IPR >> terms, I'd say we need to be very careful here. > > Not sure. A good approach to building a royalty free codec is by > starting out with prior art. Preferably from the 70s and 80s. I'd say > at least 80% of the technology in any modern speech codec already > existed in 1990. That's correct, IMHO. > You get a long way by just combining existing ideas. A novel combination of Prior Art "ideas" can be patentable in its own right. > > Otherwise I agree with you that we'll never be sure that a codec does > not infringe on any patents. That's a risk with any standard, and in > fact any piece of technology. But I maintain that a codec that has > gone through IETF standardization will be perceived as having less > risk than if the same codec had not gone through standardization. Now this is the real problem. Yes, it probably will be PERCEIVED has having less IPR risk. But what good does that do, except damaging the IETF's image as an organization that knows what it's doing---in the case the perception is wrong? If the IETF were to engage in an effort that specifically requires an RF IPR property (or, worse from a requirements viewpoint, an open-source compatibility property---I'm not even talking about what some people in the Boston area call "free" software), then the IETF must be able to stand behind that claim. I don't see a way how the IETF can do this, neither from a policy, nor from a practical viewpoint. > > koen. > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From stewe@stewe.org Thu Jun 25 13:49: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 58EF03A67F2 for ; Thu, 25 Jun 2009 13:49:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.092 X-Spam-Level: X-Spam-Status: No, score=-0.092 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, SARE_TOWRITE=1.05] 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 8Zj3HAuOvhP4 for ; Thu, 25 Jun 2009 13:49:22 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id EF4C83A67C0 for ; Thu, 25 Jun 2009 13:49:20 -0700 (PDT) Received: from [192.168.1.2] (unverified [68.197.227.183]) by stewe.org (SurgeMail 3.9e) with ESMTP id 315717-1743317 for multiple; Thu, 25 Jun 2009 21:24:25 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 25 Jun 2009 15:24:01 -0400 From: Stephan Wenger To: stephen botzko , Koen Vos Message-ID: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acn1yn5spnJqSv337E67N+CREeGoVA== In-Reply-To: <6e9223710906250452p70f11547gec483cdd0d7ac072@mail.gmail.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3328788250_6200348" X-Originating-IP: 68.197.227.183 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (68.197.227.183) was found in the spamhaus database. http://www.spamhaus.net Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 25 Jun 2009 20:49:36 -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_3328788250_6200348 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Stephen, hi Koen, Another long email: sorry. A couple of points on the third party studies: 1. Relying on third party opinions, rendered by engineers without a legal background (and, I fear, with limited or no legal support) will hardly provide anyone with an environment where one can, with reasonable certainty= , argue that patents were avoided. The end result may well be that large companies will make their own assessment, and act on it, by arguing to avoi= d any endorsement of the new standard; that is, killing it after it=B9s finished. =20 2. Providing a third party opinion of a patent is a risky business. In doing so, you show that you have studied the patent. In the US, if you wer= e later found infringing on the patent, you cold be in for triple damages. This is one reason among many why most larger companies are very careful to retain an external law firm for this kind of study, especially if there is the intention of making the results public. Sometimes, even standardizatio= n organizations do so; see, for example, some of the PAGs of W3C. 3. Because of point 2, large companies are careful in letting their engineers study other company=B9s patents. Let alone talk about the results. Engineers of the larger companies, in my experience, have often much more experience with patents than, say, open source hackers or academics. Two generic points: 4. In most legislations, as long as there is still one application open in = a given patent family, one can amend claims and thereby adjust the scope of protection long after the application publication date. That is, one can d= o so as long as the specification supports the amended claims. If the lawyer/agent who drafted the specification has not completely screwed up, you can quite likely find yourself in a situation where you thought you hav= e avoided the claims of a published application, and didn=B9t, because you didn=B9t review the prosecution history and its fine-print. Just grab a random US patent application, download the =B3File Wrapper=B2 in USPTO=B9s Public PAIR, and look for claims and claim amendments for examples. Chances are, if the application is long enough down the prosecution path, you will find several instances of claim amendments. Some may be triggered by the examiner, but others may stem from the above mentioned mechanism. This is the key reason why it is basically impossible to =B3design around=B2 well written patent applications in a closely related field. The fact that you don=B9t have visibility into the third party filings for 18 months---more= , if provisionals are involved---is just the icing on the cake. 5. The IPR game is always a question of risks and benefits. In the codec world, big industry operates by licensing and cross-licensing patents and dishing out licensing fees if they have to, and occasionally entertaining legal disputes that typically end up in settlements, that make the lawyers rich and no one else. There are provisions that make this environment quit= e survivable for smaller players, and that=B9s IMHO not going away as the antitrust efforts in most developed countries are really getting teeth. On= e clear problem that the Open Source community (not the world, I insist!) has= , is that they are so inflexible in their own legal framework that they canno= t adapt to this business model. A few open source projects do against the spirit of their own policies AFAIK, by boldly ignoring known royalty bearin= g IPR. So far, I have not heard of anyone going after them. They play the risk/benefit equation in their own way, taking into account that they have not enough flesh on their bones to be a valuable target for the rightholders. All that said, it=B9s not unheard of that a reasonably sized pool of experts, with sufficient legal support, comes together to create a meaningful patent landscape study. Especially if the field is as limited as speech coding. Arguably, we did so during the early H.264 royalty-free baseline discussions. There have been a few more attempts since then; less in publi= c view. Without discussing the success/failure of any of these exercises, it should be clear that serious money was invested by those interested in the RF baseline. Serious in the sense that it was more than most individuals would be interested or willing to pay, even if they were very emotionally invested in the project and determined to make it a success. One key facto= r that=B9s different from the hypothetical IETF speech codec exercise has been that a large part of the industry was behind the effort. That is, a large percentage of the existing and future right holders. The reasoning behind is that a large group is more likely to be able to use business tools to lure in the rest of the industry. I would be personally interested to be involved in such an effort once more= , although I do not know right now whether I would have the time. However, a necessary condition is that at least a good percentage of the existing powerhouses would be interested in the outcome. If they were, the effort could as well take place in traditional SDOs; there have always been ways i= n those organizations to overcome logistic troubles such as membership fees. Regards, Stephan =20 On 6/25/09 7:52 AM, "stephen botzko" wrote: > I'd be interested in Stephan's response as well, but I do have a couple o= f > comments inline. >=20 > Stephen Botzko > Polycom >=20 > On Thu, Jun 25, 2009 at 1:27 AM, Koen Vos wrote: >> Stephan, >>=20 >> You may have missed my point - I meant the following: >>=20 >> People who write speech codecs typically have a decent grasp of what is >> already patented and what not - even for patents not owned by themselves= or >> their employers. Being part of the Codec WG, some of these codec develop= ers >> will feel inclined to notify that a codec proposal may infringe on a cer= tain >> patent, because doing so is in the interest of achieving the Royalty Fre= e >> goal. Patents that are found to be infringed on can usually be worked ar= ound. >> As a result, the IETF codec standardization process results in a higher >> degree of confidence that no patents are infringed than if the codec wer= e >> made available without the IETF process. >>=20 > I think you will find in practice that the knowledge of what's patented i= s > much less complete than you are thinking.=A0 There are lots of countries wh= ere > patents can be filed, translations of applications are not always availab= le, > and understanding of claim scope requires an attorney's guidance and acce= ss to > the prosecution history. Design-arounds require a legal analysis of the c= laim > scope. >=20 > Also, many patents are never asserted by the original assignee, and are "= under > the radar" until they are purchased (and asserted) by a patent "troll".=A0 = Codec > designers may have some idea of what other codec technologies need to be > licensed, but I think this is the just the tip of the iceberg. > =A0 >>=20 >>=20 >>> Now, if you were from one of these companies which think that they have >>> valuable IPR in this field to protect, would you participate? =A0Probably >>> not---even if you would wish so personally---because you may well be un= der >>> orders by the lawyers. >>=20 >> That's not an argument against my thesis: I'm talking about other people= , who >> will participate. >=20 > I think Stephan is using "participate" in limited definition of RFC > 3978/3979.=A0 They might very well attend the working group meetings, and m= ight > even make some contributions (perhaps to other codecs than the one they h= old > IPR on). > =A0 >>=20 >>=20 >>=20 >>> However, it is completely acceptable, by IETF policy and practice, to s= it in >>> those meetings, take notes, perhaps improve the codec back home and fil= e >>> applications of your improving inventions like crazy. Those may well >>> "interpolate" the possible outcome. =A0You just must never say a thing. >>=20 >> This approach to gaming the system seems like a long (and expensive) sho= t. >> But if we're really paranoid about it we could decide to only make >> modifications for which prior art exists. In that case these modificatio= ns >> can not have been patented in the mean time. Would that alleviate your >> worries? > =A0 > US applications do not need to be published, and can take 5 or more years= to > issue.=A0 It would be difficult to apply your prior art rule unless you are > thinking about using very old prior art.=A0 Also, the expense of this appro= ach > is not prohibitive if your organization has a goal of obtaining revenue f= rom > their patents.=A0 This is not just a commercial activity either, since some > universities also have signficant patent portfolios. >=20 > I am concerned that a rule like this would greatly diminish the value of = the > collaboration you are seeking.=A0 Since codec quality matters, not just IPR > terms, I'd say we need to be very careful here. > =A0 >>=20 >>=20 >> koen. >>=20 >>=20 >>=20 >> Quoting Stephan Wenger : >>> On 6/24/09 3:36 PM, "Koen Vos" wrote: >>>=20 >>>> Quoting Roni Even about the risk of patent infringement: >>>>=20 >>>>> As for your third choice you forgot to say "hopefully" solve the prob= lem >>>>> since like was discussed in separate thread you cannot guarantee it a= nd >>>>> you >>>>> will not provide any protection against it. >>>>=20 >>>> Good point. =A0Wouldn't the IETF WG be especially useful for solving the >>>> problem with a larger degree of confidence? =A0We want to identify >>>> patents that may be infringed upon as early as possible - when we can >>>> still modify the codec without disrupting a large install base. >>>> Having more experts involved increases the likelihood of that. =A0As a >>>> bonus it will instill confidence in adopters of the codec that the IP >>>> risk is low. >>>>=20 >>>> koen. >>>>=20 >>>> _______________________________________________ >>>> codec mailing list >>>> codec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/codec >>>=20 >>> Hi Koen, >>>=20 >>> I thought I would drop out of this discussion, but since this is someth= ing >>> where I think I can educate without necessarily being opinionated in th= e >>> creation of a Codec WG, I decided to write anyway. =A0FYI, I have followe= d the >>> IETF IPR policy process for many years, and influencing IPR policies in= some >>> 30 SDOs was my day job during my Nokia tenure. >>>=20 >>> The IETF's patent policy can be found in RFC3979. =A0Compared to the IPR >>> policies of some other SDOs, this is a reasonably accessible document, = and I >>> encourage study. =A0Also very relevant are are the "Note Well" statement = and >>> RFC 2026. =A0A number of other documents complete the framework; you can = find >>> references to those, for example, here: >>> http://www.ietf.org/IESG/content/procdocs.html . >>>=20 >>> To summarize the parts relevant for my argumentation below in my own wo= rds, >>> one has to "participate" in the creation of a document in order to be >>> obligated to make IPR disclosures. =A0Common understanding is that if you= go >>> to the mike during the WG meeting, or post something to a relevant mail= ing >>> list, or co-author an I-D, you have a disclosure obligation. =A0However, = if >>> you sit in a meeting and/or are subscribed to a mailing list, and you a= re >>> careful not to influence the consensus process (and therefore do not >>> "participate"), you do not have a disclosure obligation. =A0See section 7= of >>> RFC 3978. =A0This situation, I can assure you, is very well known and >>> understood in companies who are actively playing in the IPR playground. >>>=20 >>> Now, if you were from one of these companies which think that they have >>> valuable IPR in this field to protect, would you participate? =A0Probably >>> not---even if you would wish so personally---because you may well be un= der >>> orders by the lawyers. >>>=20 >>> However, it is completely acceptable, by IETF policy and practice, to s= it in >>> those meetings, take notes, perhaps improve the codec back home and fil= e >>> applications of your improving inventions like crazy. =A0Those may well >>> "interpolate" the possible outcome. =A0You just must never say a thing. >>>=20 >>> Beyond that, while those who open their mouth do have a disclosure >>> obligation, the policy is silent about minimum licensing terms that nee= d to >>> be offered. =A0There's not even a requirement for RAND terms---though tho= se >>> (and non-assert terms) are most common in the IETF. =A0This is in contras= t to, >>> for example, the ITU---where you do have to license your stuff under RA= ND >>> terms. =A0This doesn't help opens source, but---all in all---has worked w= ell >>> enough in the rest of the industry. =A0In W3C, to go to the other end of = the >>> spectrum, when you are a member of a WG, you must license under Royalty= -Free >>> (though not necessarily open-source compatible) terms, or face conseque= nces. >>>=20 >>> The IETF disclosure process is designed to work well when most (or all)= of >>> the companies in the room have the same goal of creating a successful I= ETF >>> RFC to solve a certain problem. =A0It even works when competing proposals= are >>> in the picture. =A0However, it's not my reading that some of the powerhou= ses >>> will likely participate in hypothetical IETF codec work. =A0In that case,= the >>> IETF's IPR policy IMO does not work very well for your goal of an acces= sible >>> standard. >>>=20 >>> There is also one other thing that should be kept in mind: the possibil= ity >>> of gaming. =A0 If you would have an (unwritten, I assume) WG-local policy= of a >>> codec whose IPR is available under open-source compatible terms, it tak= es >>> only one reckless---or, uninformed, or erroneous---disclosure to derail= the >>> whole process. =A0This is FUD at its best. =A0Possibly, the work will come = to a >>> screeching halt for more than a year, until the disclosed application i= s >>> published. =A0Even if there is a published application, someone would hav= e to >>> offer a claim chart or another analysis of the patent or application. >>> That's lawyer work and not likely to happen, due to the possible >>> consequences (willful infringement etc.). =A0Organizations such as the W3= C >>> have a well defined conflict resolution mechanism for this situation; t= he >>> IETF has not. =A0 IMHO, IPR-related gaming (or something that comes awful= ly >>> close to it) has happened before in our organization---you will have to >>> allow me to skip expressing my suspicions. >>>=20 >>> That is why I do not see the IETF as a good organization to entertain a >>> contentious project like this. >>>=20 >>> Regards, >>> Stephan >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >>=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_3328788250_6200348 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] Codec BOF approved, much work needed Hi Stephen, hi Koen,

Another long email: sorry.

A couple of points on the third party studies:
1. Relying on third party opinions, rendered by engineers without a legal b= ackground (and, I fear, with limited or no legal support) will hardly provid= e anyone with an environment where one can, with reasonable certainty, argue= that patents were avoided.  The end result may well be that large comp= anies will make their own assessment, and act on it, by arguing to avoid any= endorsement of the new standard; that is, killing it after it’s finis= hed.    
2. Providing a third party opinion of a patent is a risky business.  I= n doing so, you show that you have studied the patent.  In the US, if y= ou were later found infringing on the patent, you cold be in for triple dama= ges.  This is one reason among many why most larger companies are very = careful to retain an external law firm for this kind of study, especially if= there is the intention of making the results public.  Sometimes, even = standardization organizations do so; see, for example, some of the PAGs of W= 3C.
3. Because of point 2, large companies are careful in letting their enginee= rs study other company’s patents.  Let alone talk about the resul= ts.  Engineers of the larger companies, in my experience, have often mu= ch more experience with patents than, say, open source hackers or academics.=

Two generic points:
4. In most legislations, as long as there is still one application open in = a given patent family, one can amend claims and thereby adjust the scope of = protection long after the application publication date.  That is, one c= an do so as long as the specification supports the amended claims.  If = the lawyer/agent who drafted the specification has not completely screwed up= , you can quite likely find yourself in a situation where you thought you ha= ve avoided the claims of a published application, and didn’t, because = you didn’t review the prosecution history and its fine-print.  Ju= st grab a random US patent application, download the “File WrapperR= 21; in USPTO’s Public PAIR, and look for claims and claim amendments f= or examples.  Chances are, if the application is long enough down the p= rosecution path, you will find several instances of claim amendments.  = Some may be triggered by the examiner, but others may stem from the above me= ntioned mechanism.
This is the key reason why it is basically impossible to “design arou= nd” well written patent applications in a closely related field.  = ;The fact that you don’t have visibility into the third party filings = for 18 months---more, if provisionals are involved---is just the icing on th= e cake.  
5. The IPR game is always a question of risks and benefits.  In the co= dec world, big industry operates by licensing and cross-licensing patents an= d dishing out licensing fees if they have to, and occasionally entertaining = legal disputes that typically end up in settlements, that make the lawyers r= ich and no one else.  There are provisions that make this environment q= uite survivable for smaller players, and that’s IMHO not going away as= the antitrust efforts in most developed countries are really getting teeth.=  One clear problem that the Open Source community (not the world, I in= sist!) has, is that they are so inflexible in their own legal framework that= they cannot adapt to this business model.  A few open source projects = do against the spirit of their own policies AFAIK, by boldly ignoring known = royalty bearing IPR.  So far, I have not heard of anyone going after th= em.  They play the risk/benefit equation in their own way, taking into = account that they have not enough flesh on their bones to be a valuable targ= et for the rightholders.

All that said, it’s not unheard of that a reasonably sized pool of ex= perts, with sufficient legal support, comes together to create a meaningful = patent landscape study.  Especially if the field is as limited as speec= h coding.  Arguably, we did so during the early H.264 royalty-free base= line discussions.  There have been a few more attempts since then; less= in public view.  Without discussing the success/failure of any of thes= e exercises, it should be clear that serious money was invested by those int= erested in the RF baseline.  Serious in the sense that it was more than= most individuals would be interested or willing to pay, even if they were v= ery emotionally invested in the project and determined to make it a success.=  One key factor that’s different from the hypothetical IETF spee= ch codec exercise has been that a large part of the industry was behind the = effort.  That is, a large percentage of the existing and future right h= olders.  The reasoning behind is that a large group is more likely to b= e able to use business tools to lure in the rest of the industry.

I would be personally interested to be involved in such an effort once more= , although I do not know right now whether I would have the time.  Howe= ver, a necessary condition is that at least a good percentage of the existin= g powerhouses would be interested in the outcome.  If they were, the ef= fort could as well take place in traditional SDOs; there have always been wa= ys in those organizations to overcome logistic troubles such as membership f= ees.

Regards,
Stephan


 

On 6/25/09 7:52 AM, "stephen botzko" <stephen.botzko@gmail.com> wrote:

<= SPAN STYLE=3D'font-size:11pt'>I'd be interested in Stephan's response as well,= but I do have a couple of comments inline.

Stephen Botzko
Polycom

On Thu, Jun 25, 2009 at 1:27 AM, Koen Vos <= koen.vos@skype.net> wrote:
<= SPAN STYLE=3D'font-size:11pt'>Stephan,

You may have missed my point - I meant the following:

People who write speech codecs typically have a decent grasp of what is alr= eady patented and what not - even for patents not owned by themselves or the= ir employers. Being part of the Codec WG, some of these codec developers wil= l feel inclined to notify that a codec proposal may infringe on a certain pa= tent, because doing so is in the interest of achieving the Royalty Free goal= . Patents that are found to be infringed on can usually be worked around. As= a result, the IETF codec standardization process results in a higher degree= of confidence that no patents are infringed than if the codec were made ava= ilable without the IETF process.

= I think you will find in practice that the know= ledge of what's patented is much less complete than you are thinking.=A0 There= are lots of countries where patents can be filed, translations of applicati= ons are not always available, and understanding of claim scope requires an a= ttorney's guidance and access to the prosecution history. Design-arounds req= uire a legal analysis of the claim scope.

Also, many patents are never asserted by the original assignee, and are &qu= ot;under the radar" until they are purchased (and asserted) by a patent= "troll".=A0 Codec designers may have some idea of what other codec = technologies need to be licensed, but I think this is the just the tip of th= e iceberg.
=A0
<= SPAN STYLE=3D'font-size:11pt'>

<= SPAN STYLE=3D'font-size:11pt'>Now, if you were from one of these companies whi= ch think that they have
valuable IPR in this field to protect, would you participate? =A0Probably
not---even if you would wish so personally---because you may well be under<= BR> orders by the lawyers.
=
That's not an argument against my thesis: I'm talking about other people, w= ho will participate.
=
I think Stephan is using "participate" in limited definition of R= FC 3978/3979.=A0 They might very well attend the working group meetings, and m= ight even make some contributions (perhaps to other codecs than the one they= hold IPR on).
=A0
<= SPAN STYLE=3D'font-size:11pt'>


<= SPAN STYLE=3D'font-size:11pt'>However, it is completely acceptable, by IETF po= licy and practice, to sit in
those meetings, take notes, perhaps improve the codec back home and file applications of your improving inventions like crazy. Those may well
"interpolate" the possible outcome. =A0You just must never say a th= ing.
=
This approach to gaming the system seems like a long (and expensive) shot. = But if we're really paranoid about it we could decide to only make modificat= ions for which prior art exists. In that case these modifications can not ha= ve been patented in the mean time. Would that alleviate your worries?
= =A0
US applications do not need to be published, and can take 5 or more years t= o issue.=A0 It would be difficult to apply your prior art rule unless you are = thinking about using very old prior art.=A0 Also, the expense of this approach= is not prohibitive if your organization has a goal of obtaining revenue fro= m their patents.=A0 This is not just a commercial activity either, since some = universities also have signficant patent portfolios.

I am concerned that a rule like this would greatly diminish the value of th= e collaboration you are seeking.=A0 Since codec quality matters, not just IPR = terms, I'd say we need to be very careful here.
=A0
<= SPAN STYLE=3D'font-size:11pt'>

koen.



Quoting Stephan Wenger <stewe@stewe.org>= ;:
<= SPAN STYLE=3D'font-size:11pt'>On 6/24/09 3:36 PM, "Koen Vos" <koen.vos@skype.net> wrote:

<= SPAN STYLE=3D'font-size:11pt'>Quoting Roni Even about the risk of patent infri= ngement:

<= SPAN STYLE=3D'font-size:11pt'>As for your third choice you forgot to say "= ;hopefully" solve the problem
since like was discussed in separate thread you cannot guarantee it and you=
will not provide any protection against it.
=
Good point. =A0Wouldn't the IETF WG be especially useful for solving the
problem with a larger degree of confidence? =A0We want to identify
patents that may be infringed upon as early as possible - when we can
still modify the codec without disrupting a large install base.
Having more experts involved increases the likelihood of that. =A0As a
bonus it will instill confidence in adopters of the codec that the IP
risk is low.

koen.

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

I thought I would drop out of this discussion, but since this is something<= BR> where I think I can educate without necessarily being opinionated in the creation of a Codec WG, I decided to write anyway. =A0FYI, I have followed th= e
IETF IPR policy process for many years, and influencing IPR policies in som= e
30 SDOs was my day job during my Nokia tenure.

The IETF's patent policy can be found in RFC3979. =A0Compared to the IPR
policies of some other SDOs, this is a reasonably accessible document, and = I
encourage study. =A0Also very relevant are are the "Note Well" stat= ement and
RFC 2026. =A0A number of other documents complete the framework; you can find=
references to those, for example, here:
http://www.ietf.or= g/IESG/content/procdocs.html .

To summarize the parts relevant for my argumentation below in my own words,=
one has to "participate" in the creation of a document in order t= o be
obligated to make IPR disclosures. =A0Common understanding is that if you go<= BR> to the mike during the WG meeting, or post something to a relevant mailing<= BR> list, or co-author an I-D, you have a disclosure obligation. =A0However, if you sit in a meeting and/or are subscribed to a mailing list, and you are careful not to influence the consensus process (and therefore do not
"participate"), you do not have a disclosure obligation. =A0See sec= tion 7 of
RFC 3978. =A0This situation, I can assure you, is very well known and
understood in companies who are actively playing in the IPR playground.

Now, if you were from one of these companies which think that they have
valuable IPR in this field to protect, would you participate? =A0Probably
not---even if you would wish so personally---because you may well be under<= BR> orders by the lawyers.

However, it is completely acceptable, by IETF policy and practice, to sit i= n
those meetings, take notes, perhaps improve the codec back home and file applications of your improving inventions like crazy. =A0Those may well
"interpolate" the possible outcome. =A0You just must never say a th= ing.

Beyond that, while those who open their mouth do have a disclosure
obligation, the policy is silent about minimum licensing terms that need to=
be offered. =A0There's not even a requirement for RAND terms---though those (and non-assert terms) are most common in the IETF. =A0This is in contrast to= ,
for example, the ITU---where you do have to license your stuff under RAND terms. =A0This doesn't help opens source, but---all in all---has worked well<= BR> enough in the rest of the industry. =A0In W3C, to go to the other end of the<= BR> spectrum, when you are a member of a WG, you must license under Royalty-Fre= e
(though not necessarily open-source compatible) terms, or face consequences= .

The IETF disclosure process is designed to work well when most (or all) of<= BR> the companies in the room have the same goal of creating a successful IETF<= BR> RFC to solve a certain problem. =A0It even works when competing proposals are=
in the picture. =A0However, it's not my reading that some of the powerhouses<= BR> will likely participate in hypothetical IETF codec work. =A0In that case, the=
IETF's IPR policy IMO does not work very well for your goal of an accessibl= e
standard.

There is also one other thing that should be kept in mind: the possibility<= BR> of gaming. =A0 If you would have an (unwritten, I assume) WG-local policy of = a
codec whose IPR is available under open-source compatible terms, it takes only one reckless---or, uninformed, or erroneous---disclosure to derail the=
whole process. =A0This is FUD at its best. =A0Possibly, the work will come to a=
screeching halt for more than a year, until the disclosed application is published. =A0Even if there is a published application, someone would have to=
offer a claim chart or another analysis of the patent or application.
That's lawyer work and not likely to happen, due to the possible
consequences (willful infringement etc.). =A0Organizations such as the W3C have a well defined conflict resolution mechanism for this situation; the IETF has not. =A0 IMHO, IPR-related gaming (or something that comes awfully close to it) has happened before in our organization---you will have to
allow me to skip expressing my suspicions.

That is why I do not see the IETF as a good organization to entertain a
contentious project like this.

Regards,
Stephan




=

_______________________________________________
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_3328788250_6200348-- From Jean-Marc.Valin@USherbrooke.ca Thu Jun 25 14:09:48 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 E72FE3A68A8 for ; Thu, 25 Jun 2009 14:09:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.351 X-Spam-Level: X-Spam-Status: No, score=-2.351 tagged_above=-999 required=5 tests=[AWL=0.248, 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 dFsdsNCLEcnv for ; Thu, 25 Jun 2009 14:09:48 -0700 (PDT) Received: from smtpi5.usherbrooke.ca (smtpi5.usherbrooke.ca [132.210.236.1]) by core3.amsl.com (Postfix) with ESMTP id 07F243A6811 for ; Thu, 25 Jun 2009 14:09:47 -0700 (PDT) Received: from localhost (www04.USherbrooke.ca [132.210.244.64]) by smtpi5.usherbrooke.ca (8.13.8/8.13.8) with ESMTP id n5PL8HQP022425; Thu, 25 Jun 2009 17:08:18 -0400 Received: from mail.octasic.com (mail.octasic.com [70.54.254.106]) by www.usherbrooke.ca (IMP) with HTTP for ; Thu, 25 Jun 2009 17:08:17 -0400 Message-ID: <1245964097.4a43e741e8391@www.usherbrooke.ca> Date: Thu, 25 Jun 2009 17:08:17 -0400 From: Jean-Marc Valin To: Stephan Wenger References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.6 X-Originating-IP: 70.54.254.106 X-UdeS-MailScanner-Information: Veuillez consulter le http://www.usherbrooke.ca/vers/virus-courriel X-MailScanner-ID: n5PL8HQP022425 X-UdeS-MailScanner: Aucun code suspect =?ISO-8859-1?Q?d=E9tect=E9?= X-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-7.499, requis 5, autolearn=not spam, BAYES_00 -2.60, RDNS_NONE 0.10, UDES_MONBUREAU02 -5.00) X-UdeS-MailScanner-From: jean-marc.valin@usherbrooke.ca Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 25 Jun 2009 21:09:49 -0000 (sorry if this ends up as a dupe, more mail problems) Quoting Stephan Wenger : > > Otherwise I agree with you that we'll never be sure that a codec does > > not infringe on any patents. That's a risk with any standard, and in > > fact any piece of technology. But I maintain that a codec that has > > gone through IETF standardization will be perceived as having less > > risk than if the same codec had not gone through standardization. > > Now this is the real problem. Yes, it probably will be PERCEIVED has having > less IPR risk. But what good does that do, except damaging the IETF's image > as an organization that knows what it's doing---in the case the perception > is wrong? Just curious, how does the ITU protect itself from patent trolls? Jean-Marc From jean-marc.valin@octasic.com Thu Jun 25 14:12: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 3EB9A3A6817 for ; Thu, 25 Jun 2009 14:12:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.304 X-Spam-Level: X-Spam-Status: No, score=-2.304 tagged_above=-999 required=5 tests=[AWL=0.295, 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 HqSE+ixwCvGX for ; Thu, 25 Jun 2009 14:12:04 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 62A753A69DE for ; Thu, 25 Jun 2009 14:12:04 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 16:38:40 -0400 Message-ID: <4A43E082.3060804@octasic.com> Date: Thu, 25 Jun 2009 16:39:30 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 25 Jun 2009 20:38:40.0622 (UTC) FILETIME=[EC7C70E0:01C9F5D4] Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 25 Jun 2009 21:12:05 -0000 >> Otherwise I agree with you that we'll never be sure that a codec does >> not infringe on any patents. That's a risk with any standard, and in >> fact any piece of technology. But I maintain that a codec that has >> gone through IETF standardization will be perceived as having less >> risk than if the same codec had not gone through standardization. > > Now this is the real problem. Yes, it probably will be PERCEIVED has having > less IPR risk. But what good does that do, except damaging the IETF's image > as an organization that knows what it's doing---in the case the perception > is wrong? Just curious, how does the ITU protect itself from patent trolls? Jean-Marc From stewe@stewe.org Thu Jun 25 14:29:51 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 216C13A68A4 for ; Thu, 25 Jun 2009 14:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.33 X-Spam-Level: X-Spam-Status: No, score=-1.33 tagged_above=-999 required=5 tests=[AWL=1.269, 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 SfJBRbSMxx8F for ; Thu, 25 Jun 2009 14:29:50 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 0F2A03A6807 for ; Thu, 25 Jun 2009 14:29:47 -0700 (PDT) Received: from [192.168.1.2] (unverified [68.197.227.183]) by stewe.org (SurgeMail 3.9e) with ESMTP id 315798-1743317 for multiple; Thu, 25 Jun 2009 23:26:34 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 25 Jun 2009 17:26:25 -0400 From: Stephan Wenger To: Jean-Marc Valin Message-ID: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acn125fJ5OvblaBBxEGBP5f+gDsZvw== In-Reply-To: <4A43E082.3060804@octasic.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 68.197.227.183 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (68.197.227.183) was found in the spamhaus database. http://www.spamhaus.net Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 25 Jun 2009 21:29:51 -0000 Hi Jean Marc, On 6/25/09 4:39 PM, "Jean-Marc Valin" wrote: [...] > > Just curious, how does the ITU protect itself from patent trolls? > Not sure that this is the right forum, but nevertheless: To take your question verbatim: the ITU does not need to fear trolls, as it hardly can be sued over patent infringement as it is not practicing the inventions in its standards. The ITU also has no real image problem, as its statements related to possible encumbrances of its standards are quite clear. You can easily find those by downloading any ITU Recommendation. Packed in one sentence, they say: you are on your own in determining how much, and to whom, you need to pay to practice a standard. To answer the implied question (hope I got that one right): If one is practicing potentially patented technologies, there is no real mechanism to protect oneself from a troll, standard or not. The main mitigation the ITU has implemented to benefit its members is the RAND licensing commitment requirement, which is bound to the ITU membership. Historically, most companies interested in, and with the resources for, standardization in the Telco market have been ITU members, and were therefore bound to the RAND commitment. Arguably, that's still mostly the case. This RAND commitment is, on one hand, liberal enough to drag in most companies which see IPR royalty revenues as their business model as well as those who don't. On the other hand, it has also historically been strict enough to avoid the worst excesses on royalty charging. Stephan > Jean-Marc From stephen.botzko@gmail.com Thu Jun 25 14:38:19 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 9EA523A68F5 for ; Thu, 25 Jun 2009 14:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.006 X-Spam-Level: X-Spam-Status: No, score=-2.006 tagged_above=-999 required=5 tests=[AWL=0.592, 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 zRg6QzCl8Ytn for ; Thu, 25 Jun 2009 14:38:18 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 277EF3A6807 for ; Thu, 25 Jun 2009 14:38:17 -0700 (PDT) Received: by bwz9 with SMTP id 9so1688892bwz.37 for ; Thu, 25 Jun 2009 14:37:50 -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=8NojQOEezv/IHKKJJTLwkTKFPoQD8O7vlN2dyz+rtO4=; b=ALs57KHpOrDzZFgJ95DZbEqkEvtUZ8lQkDIFGSB0y8uSINV2jXqSA7LBxVK1Hz1bly PPMhcL6q9Z0MRBYGTJvZZNnshDzcrn+uIz6U/FoTkyZr0L+FuNf0eJgvSpi6f1SvTopd bmy58TteA9H6eVbTywLxccn+2gFGv1m9JcqHk= 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=JCnz3gy8xPLsZtFGt8pO6rnfEBCeeAlVqYhAMUCOasW3khCO+h+XAnMnMYNH/1bnpa RzQwYKkqS/12qt7DqCFHjqJ6KLfefMb9d/5kt6QFba/iiWWdVMtHb7ZK/aKTvhZBVzd9 /IVWeY1L8ulQiDo41xpJOzKOvk9p4Bw+tCekw= MIME-Version: 1.0 Received: by 10.103.131.13 with SMTP id i13mr1805990mun.64.1245962007488; Thu, 25 Jun 2009 13:33:27 -0700 (PDT) In-Reply-To: <20090625123737.26143iaxh4bom77l@mail.skype.net> References: <20090624222759.13482jyf2wr43nq7@mail.skype.net> <6e9223710906250452p70f11547gec483cdd0d7ac072@mail.gmail.com> <20090625123737.26143iaxh4bom77l@mail.skype.net> Date: Thu, 25 Jun 2009 16:33:27 -0400 Message-ID: <6e9223710906251333q56576064mc11184d0a7dacd83@mail.gmail.com> From: stephen botzko To: Koen Vos Content-Type: multipart/alternative; boundary=001636416adfdc2919046d3222ac Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 25 Jun 2009 21:38:19 -0000 --001636416adfdc2919046d3222ac Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >>> If the modifications consists of a method (let's say from a journal publication) that already existed before today, then that modification cannot be patented anymore. So someone trying to "sneakily" file for a patent on an improvement that he sees coming by "interpolating" events at IETF could indeed be stopped. >>> A patent application could have been filed prior to the publication. Also, a US patent application can be filed up to one year after publication. Or specific modification could be claimed by a broader earler patent that the inventor was not even aware of. Regards, Stephen Botzko Polycom On Thu, Jun 25, 2009 at 3:37 PM, Koen Vos wrote: > Quoting stephen botzko: > >> But if we're really paranoid about it we could decide to only make >>> modifications for which prior art exists. In that case these >>> modifications >>> can not have been patented in the mean time. Would that alleviate your >>> worries? >>> >> >> >> US applications do not need to be published, and can take 5 or more years >> to >> issue. It would be difficult to apply your prior art rule unless you are >> thinking about using very old prior art. Also, the expense of this >> approach >> is not prohibitive if your organization has a goal of obtaining revenue >> from >> their patents. This is not just a commercial activity either, since some >> universities also have signficant patent portfolios. >> > > If the modifications consists of a method (let's say from a journal > publication) that already existed before today, then that modification > cannot be patented anymore. So someone trying to "sneakily" file for a > patent on an improvement that he sees coming by "interpolating" events at > IETF could indeed be stopped. > > I am concerned that a rule like this would greatly diminish the value of >> the >> collaboration you are seeking. Since codec quality matters, not just IPR >> terms, I'd say we need to be very careful here. >> > > Not sure. A good approach to building a royalty free codec is by starting > out with prior art. Preferably from the 70s and 80s. I'd say at least 80% of > the technology in any modern speech codec already existed in 1990. You get a > long way by just combining existing ideas. > > Otherwise I agree with you that we'll never be sure that a codec does not > infringe on any patents. That's a risk with any standard, and in fact any > piece of technology. But I maintain that a codec that has gone through IETF > standardization will be perceived as having less risk than if the same codec > had not gone through standardization. > > > koen. > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636416adfdc2919046d3222ac Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
If the modifications consists of a method (let's say fr= om a journal publication) that already existed before today, then that modification cannot be patented anymore. =A0So someone trying to "sneakily" fi= le for a patent on an improvement that he sees coming by "interpolating" e= vents at IETF could indeed be stopped.
>>>

A patent applicatio= n could have been filed prior to the publication.=A0 Also, a US patent appl= ication can be filed up to one year after publication.=A0 Or specific modif= ication could be claimed by a broader earler patent that the inventor was n= ot even aware of.

Regards,
Stephen Botzko
Polycom


On Thu, Jun 25, 2009 at 3:37 PM, Koen Vos <koen.vos@skype.net> wrote:
Quoting stephen botzko:
But if we're really paranoid about it we could decide to only make
modifications for which prior art exists. In that case these modifications<= br> can not have been patented in the mean time. Would that alleviate your
worries?


US applications do not need to be published, and can take 5 or more years t= o
issue. =A0It would be difficult to apply your prior art rule unless you are=
thinking about using very old prior art. =A0Also, the expense of this appro= ach
is not prohibitive if your organization has a goal of obtaining revenue fro= m
their patents. =A0This is not just a commercial activity either, since some=
universities also have signficant patent portfolios.

If the modifications consists of a method (let's say from a journal pub= lication) that already existed before today, then that modification cannot = be patented anymore. =A0So someone trying to "sneakily" file for = a patent on an improvement that he sees coming by "interpolating"= events at IETF could indeed be stopped.


I am concerned that a rule like this would greatly diminish the value of th= e
collaboration you are seeking. =A0Since codec quality matters, not just IPR=
terms, I'd say we need to be very careful here.

Not sure. A good approach to building a royalty free codec is by starting o= ut with prior art. Preferably from the 70s and 80s. I'd say at least 80= % of the technology in any modern speech codec already existed in 1990. You= get a long way by just combining existing ideas.

Otherwise I agree with you that we'll never be sure that a codec does n= ot infringe on any patents. That's a risk with any standard, and in fac= t any piece of technology. But I maintain that a codec that has gone throug= h IETF standardization will be perceived as having less risk than if the sa= me codec had not gone through standardization.


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

--001636416adfdc2919046d3222ac-- From jean-marc.valin@octasic.com Thu Jun 25 14:44:13 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 8E1383A6976 for ; Thu, 25 Jun 2009 14:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.331 X-Spam-Level: X-Spam-Status: No, score=-2.331 tagged_above=-999 required=5 tests=[AWL=0.268, 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 1ijplBrpODeH for ; Thu, 25 Jun 2009 14:44:12 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 1BFDF3A68F5 for ; Thu, 25 Jun 2009 14:44:08 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 17:42:16 -0400 Message-ID: <4A43EF6A.30205@octasic.com> Date: Thu, 25 Jun 2009 17:43:06 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 25 Jun 2009 21:42:16.0188 (UTC) FILETIME=[CEBD9BC0:01C9F5DD] Cc: codec@ietf.org, stephen botzko Subject: Re: [codec] Codec BOF approved, much work needed 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, 25 Jun 2009 21:44:13 -0000 Stephan Wenger wrote: > 5. The IPR game is always a question of risks and benefits. In the > codec world, big industry operates by licensing and cross-licensing > patents and dishing out licensing fees if they have to, and occasionally > entertaining legal disputes that typically end up in settlements, that > make the lawyers rich and no one else. There are provisions that make > this environment quite survivable for smaller players, and that’s IMHO > not going away as the antitrust efforts in most developed countries are > really getting teeth. One clear problem that the Open Source community > (not the world, I insist!) has, is that they are so inflexible in their > own legal framework that they cannot adapt to this business model. There's a lot more than open source involved in here. While I agree that the environment (i.e. having to pay $x of royalties per channel) may be survivable for even small players in the standard "carrier market", it is not viable for many other applications. I can probably start a new phone company, pay the royalties for some ITU codec and still make a profit. On the other hand, in other markets, even the *big* players cannot pay the per-channel royalties. Why do you think players as big as Google (Talk), Adobe (Flash) and Skype use Speex and/or iLBC and not G.729 or AMR-* ? It's not about the size, but about the business model. The current way the ITU works just does not support many of the new business models created by the Internet. When we talk about an "Internet audio codec", it's a lot more than merely transporting the bits over an IP network. > A few open source projects do against the spirit of their own policies > AFAIK, by boldly ignoring known royalty bearing IPR. So far, I have not > heard of anyone going after them. They play the risk/benefit equation > in their own way, taking into account that they have not enough flesh on > their bones to be a valuable target for the rightholders. I totally agree that this is certainly not something that should be encouraged. Jean-Marc From stewe@stewe.org Thu Jun 25 16:55:32 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 313323A68A4 for ; Thu, 25 Jun 2009 16:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.279 X-Spam-Level: X-Spam-Status: No, score=-2.279 tagged_above=-999 required=5 tests=[AWL=0.320, 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 vwR9ZokaMN9g for ; Thu, 25 Jun 2009 16:55:31 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 160EF3A6840 for ; Thu, 25 Jun 2009 16:55:28 -0700 (PDT) Received: from [172.16.0.136] (unverified [66.206.218.2]) by stewe.org (SurgeMail 3.9e) with ESMTP id 315873-1743317 for multiple; Fri, 26 Jun 2009 01:38:27 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 25 Jun 2009 19:38:21 -0400 From: Stephan Wenger To: Jean-Marc Valin Message-ID: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acn17gYXFLoMNleJmUOLXdH6lwcZ8g== In-Reply-To: <4A43EF6A.30205@octasic.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-Originating-IP: 66.206.218.2 X-Authenticated-User: stewe@stewe.org Cc: codec@ietf.org, stephen botzko Subject: Re: [codec] Codec BOF approved, much work needed 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, 25 Jun 2009 23:55:32 -0000 Jean-Marc, Do you know that these players have not been approached by a possible rightholder? Are you sure they will not? Do you know the business arrangements that have in place? Have they picked up a license, perhaps? Subject to a very broad cross-licensing deal? Or are the leads of their licensing group golf buddies and decided over a game not to go at each othe= r right now? Concluding from the current situation (no litigation around speex that I'm aware of, no licensing deal I have heard of) that there are really no patents related to that technology, is not really a clever move. However, I concede that the googles of the world have a very different business model compared to traditional telco operators or vendors (not so certain about skype, but let's skip that discussion :-). You have not convinced me that those players necessarily need a royalty-free codec, but if they would, they could make their voices easily heard in the traditional venues. Everyone listens to google, and everyone smart in the Telco industry listens to Skype, considering their respective successes. Regards, Stephan =20 On 6/25/09 5:43 PM, "Jean-Marc Valin" wrote: > Stephan Wenger wrote: >> 5. The IPR game is always a question of risks and benefits. In the >> codec world, big industry operates by licensing and cross-licensing >> patents and dishing out licensing fees if they have to, and occasionally >> entertaining legal disputes that typically end up in settlements, that >> make the lawyers rich and no one else. There are provisions that make >> this environment quite survivable for smaller players, and that=B9s IMHO >> not going away as the antitrust efforts in most developed countries are >> really getting teeth. One clear problem that the Open Source community >> (not the world, I insist!) has, is that they are so inflexible in their >> own legal framework that they cannot adapt to this business model. >=20 > There's a lot more than open source involved in here. While I agree that > the environment (i.e. having to pay $x of royalties per channel) may be > survivable for even small players in the standard "carrier market", it is > not viable for many other applications. I can probably start a new phone > company, pay the royalties for some ITU codec and still make a profit. On > the other hand, in other markets, even the *big* players cannot pay the > per-channel royalties. Why do you think players as big as Google (Talk), > Adobe (Flash) and Skype use Speex and/or iLBC and not G.729 or AMR-* ? It= 's > not about the size, but about the business model. The current way the ITU > works just does not support many of the new business models created by th= e > Internet. When we talk about an "Internet audio codec", it's a lot more > than merely transporting the bits over an IP network. >=20 >> A few open source projects do against the spirit of their own policies >> AFAIK, by boldly ignoring known royalty bearing IPR. So far, I have not >> heard of anyone going after them. They play the risk/benefit equation >> in their own way, taking into account that they have not enough flesh on >> their bones to be a valuable target for the rightholders. >=20 > I totally agree that this is certainly not something that should be > encouraged. >=20 > Jean-Marc >=20 From fluffy@cisco.com Thu Jun 25 20:50:49 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 63C833A6A99 for ; Thu, 25 Jun 2009 20:50:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.43 X-Spam-Level: X-Spam-Status: No, score=-106.43 tagged_above=-999 required=5 tests=[AWL=-0.131, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, 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 8sxJmw3JAtdg for ; Thu, 25 Jun 2009 20:50:48 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id A728D3A67DD for ; Thu, 25 Jun 2009 20:50:48 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,294,1243814400"; d="scan'208";a="332098203" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 26 Jun 2009 03:49:39 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n5Q3nd8J030542; Thu, 25 Jun 2009 20:49:39 -0700 Received: from [192.168.1.75] (sjc-vpn2-1453.cisco.com [10.21.117.173]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5Q3ncQp010698; Fri, 26 Jun 2009 03:49:39 GMT Message-Id: <40525BF9-603F-4302-8ABD-623846857702@cisco.com> From: Cullen Jennings To: Slava Borilin 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 v935.3) Date: Thu, 25 Jun 2009 20:49:38 -0700 References: <20090618103404.20747hsmkwbyohdo@webmail.uni-tuebingen.de> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=643; t=1245988179; x=1246852179; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20=3D?ISO-8859-1?Q?Re=3A_[codec]_RE=3DA0=3A_Codec _BOF_approved,_much_work_?=3D=0A=20=3D?ISO-8859-1?Q?needed?= 3D |Sender:=20; bh=Ch/k8ANV5aSbyT0Fq8Ajm+/We+AP612No7TXiLrHM2k=; b=qAxhPHjphSotqQGp3xeLmdnyD7HhcePQeriXRncfjegnj9pLF3AlYxvuQC yECptq5SFvN7tbcXrD5Utnxsfn2B5UvlM9+mPKuDA5fj9t62qM01uPzBiZPA I9qSkWAg7v; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: codec@ietf.org Subject: Re: [codec] =?iso-8859-1?q?RE=A0=3A_Codec_BOF_approved=2C_much_work_n?= =?iso-8859-1?q?eeded?= 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: Fri, 26 Jun 2009 03:50:49 -0000 On Jun 18, 2009, at 6:56 , Slava Borilin wrote: > For congested networks - I assume that the way to judge the codec is =20= > to judge the MOS over TIA-921 network profiles (that=92s what we use) =20= > which covers realistic packet loss and congestion scenarios, and not =20= > just =93average normally distributed XX% packet loss=94. Roni brought up and interesting point about looking at how other =20 groups doing codec design did the design and evaluation. Just out of =20 curiosity, are the TIA-921 profiles what folks doing codec design at =20 the ITU use as the basis of design for codecs to run over IP networks? From ron.even.tlv@gmail.com Thu Jun 25 21:25: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 E672E3A68FB for ; Thu, 25 Jun 2009 21:25:44 -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 UIaQemqytZsH for ; Thu, 25 Jun 2009 21:25:43 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 2ECD63A67F8 for ; Thu, 25 Jun 2009 21:25:42 -0700 (PDT) Received: by fxm9 with SMTP id 9so1863392fxm.37 for ; Thu, 25 Jun 2009 21:25:03 -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:thread-index:content-language; bh=VoN+JinViJQ+Tv7PfPF+c+mZdQz5Sb2Mq9cmOUOt5VI=; b=NojAqbuOeGIGfyZjmI5f80N3L+nVO+ay7YVnrnU3XbY4SfOfjC3YkzFiqHRh4WtNhT CokTlmFync8yy83PgdyYcrRGhWHOGSCPSQ3mOXRO4bCzpBYD6zNRhIlPrk2lwH+2QW2P /hP7txVFNL69ld5ARbfgczBvcei/8rkf+icaY= 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 :thread-index:content-language; b=ITYeG5XN6DC5VOVd6CPJ5CadCUvy/RvK6is92pYWU8WmXOMnDeJONMZbFBmpG69qJ7 TY/XrCWfI9zpzB+y+6lHNuNJBT7dLJRfJSiHr/aqhEThP7co8SEvlN3VtM0WlnYQQVIX llDvbm8jL1qCL25phBUa2u0Ei799eXq+GuE9o= Received: by 10.103.224.17 with SMTP id b17mr2020097mur.61.1245990303271; Thu, 25 Jun 2009 21:25:03 -0700 (PDT) Received: from windows8d787f9 (bzq-79-182-68-39.red.bezeqint.net [79.182.68.39]) by mx.google.com with ESMTPS id 12sm14389317muq.23.2009.06.25.21.24.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 25 Jun 2009 21:25:00 -0700 (PDT) From: "Roni Even" To: "'Stephan Wenger'" , "'Jean-Marc Valin'" References: <4A43EF6A.30205@octasic.com> In-Reply-To: Date: Fri, 26 Jun 2009 07:24:45 +0300 Message-ID: <4a444d9c.0c11660a.3855.0abe@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn17gYXFLoMNleJmUOLXdH6lwcZ8gAJ4Glg Content-Language: en-us Cc: codec@ietf.org, 'stephen botzko' Subject: Re: [codec] Codec BOF approved, much work needed 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: Fri, 26 Jun 2009 04:25:45 -0000 Hi, I would like to add that I am not sure why the "googles of the world" require a standard codec since they do not worry about interoperability issue. I am also wondering why should the IETF who care about interoperability worry about non-interoperable solutions. Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Stephan Wenger > Sent: Friday, June 26, 2009 2:38 AM > To: Jean-Marc Valin > Cc: codec@ietf.org; stephen botzko > Subject: Re: [codec] Codec BOF approved, much work needed >=20 > Jean-Marc, >=20 > Do you know that these players have not been approached by a possible > rightholder? Are you sure they will not? Do you know the business > arrangements that have in place? Have they picked up a license, > perhaps? > Subject to a very broad cross-licensing deal? Or are the leads of > their > licensing group golf buddies and decided over a game not to go at each > other > right now? >=20 > Concluding from the current situation (no litigation around speex that > I'm > aware of, no licensing deal I have heard of) that there are really no > patents related to that technology, is not really a clever move. >=20 > However, I concede that the googles of the world have a very different > business model compared to traditional telco operators or vendors (not > so > certain about skype, but let's skip that discussion :-). You have not > convinced me that those players necessarily need a royalty-free codec, > but > if they would, they could make their voices easily heard in the > traditional > venues. Everyone listens to google, and everyone smart in the Telco > industry listens to Skype, considering their respective successes. >=20 > Regards, > Stephan >=20 >=20 >=20 > On 6/25/09 5:43 PM, "Jean-Marc Valin" > wrote: >=20 > > Stephan Wenger wrote: > >> 5. The IPR game is always a question of risks and benefits. In the > >> codec world, big industry operates by licensing and cross-licensing > >> patents and dishing out licensing fees if they have to, and > occasionally > >> entertaining legal disputes that typically end up in settlements, > that > >> make the lawyers rich and no one else. There are provisions that > make > >> this environment quite survivable for smaller players, and that=B9s > IMHO > >> not going away as the antitrust efforts in most developed countries > are > >> really getting teeth. One clear problem that the Open Source > community > >> (not the world, I insist!) has, is that they are so inflexible in > their > >> own legal framework that they cannot adapt to this business model. > > > > There's a lot more than open source involved in here. While I agree > that > > the environment (i.e. having to pay $x of royalties per channel) may > be > > survivable for even small players in the standard "carrier market", > it is > > not viable for many other applications. I can probably start a new > phone > > company, pay the royalties for some ITU codec and still make a > profit. On > > the other hand, in other markets, even the *big* players cannot pay > the > > per-channel royalties. Why do you think players as big as Google > (Talk), > > Adobe (Flash) and Skype use Speex and/or iLBC and not G.729 or AMR-* > ? It's > > not about the size, but about the business model. The current way = the > ITU > > works just does not support many of the new business models created > by the > > Internet. When we talk about an "Internet audio codec", it's a lot > more > > than merely transporting the bits over an IP network. > > > >> A few open source projects do against the spirit of their own > policies > >> AFAIK, by boldly ignoring known royalty bearing IPR. So far, I = have > not > >> heard of anyone going after them. They play the risk/benefit > equation > >> in their own way, taking into account that they have not enough > flesh on > >> their bones to be a valuable target for the rightholders. > > > > I totally agree that this is certainly not something that should be > > encouraged. > > > > Jean-Marc > > >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From fluffy@cisco.com Thu Jun 25 23:09: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 F34DF3A67DF for ; Thu, 25 Jun 2009 23:09:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.573 X-Spam-Level: X-Spam-Status: No, score=-106.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 OwaGePgsEaU2 for ; Thu, 25 Jun 2009 23:09:52 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0DAAC3A6910 for ; Thu, 25 Jun 2009 23:09:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,294,1243814400"; d="scan'208";a="205952043" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 26 Jun 2009 06:09:04 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n5Q694JH002403; Thu, 25 Jun 2009 23:09:04 -0700 Received: from [192.168.1.75] (sjc-vpn2-1453.cisco.com [10.21.117.173]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n5Q681Ha009235; Fri, 26 Jun 2009 06:09:04 GMT Message-Id: <945FAEF4-1515-4816-8A3A-9ED2475BA455@cisco.com> From: Cullen Jennings To: Ron Even In-Reply-To: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 25 Jun 2009 23:09:03 -0700 References: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4124; t=1245996544; x=1246860544; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20[codec]=20Codec=20BOF=20approved,=20muc h=20work=20needed |Sender:=20; bh=J50kGBkzD1SW5OKPK3thbULKghz/J63/6NDuP+cK/X8=; b=tzBN7Ta1rvQtbpCF7P75dr9tJXphIER2NNgoDDYYGNJflvD70qlrA7IBug 1FeMyi0yD6x54ThgFNNF0/D7vFgP+I4afTzYykPnpUUiIDy8aUpIw06LxlsF QY4jDlpUi3; Authentication-Results: sj-dkim-3; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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: Fri, 26 Jun 2009 06:09:53 -0000 Roni, The primary goal of this BOF should be collecting the information that helps make an informed decision about if a WG should be formed or not. I certainly did not mean to imply by the agenda that there was any assumption that a WG would be formed. I agree the charter below is far from ideal for collecting this information. I'm expecting the agenda to change, based on the list discussion, so we have time to talk about the key topics where community input is needed to drive the decisions about if a WG should be formed or not. Cullen On Jun 19, 2009, at 8:59 , Ron Even wrote: > Cullen, > I looked at the agenda > > 1. Administrative (Chairs, 5 min) > - Note takers, Jabber scribes > - Agenda bashing > > 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) > > 3. Proposed CODECs (TBD, 25 min) > - Expect to have two or more drafts here > > 4. Charter Discussion (All, 40 min) > > 5. Decisions and HUMs (All, 5 min) > > 6. Conclusions and Next Steps (Chairs/ADs, 5 min) > > > And it looks to me that it starts with assumption that we will have > a new working group. > > I am not sure that that this was agreed and yet I see no time > allocated to discuss the topic. I would expect that item 3 will be > rational for doing codec at the IETF considering that this work is > done also by other SDOs that the IETF is working with. > > Now even if there will be such a WG starting with proposed CODECS is > like having a solution before the requirements. In other standard > bodies requirements are not just names but they also have values. So > what is the purpose of proposing codecs, do we need to select at the > BOF which one will be standardize, to me it looks like this should > be done later. > > Roni Even > > > > > > -----Original Message----- > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > Behalf > > Of Cullen Jennings > > Sent: Friday, June 12, 2009 8:32 PM > > To: codec@ietf.org > > Subject: [codec] Codec BOF approved, much work needed > > > > > > I have approved the CODEC BOF proposal. However, we need a bunch of > > work to get ready. Various people on IESG/IAB were not comfortable > > with the current charter and agenda so we need to work on theses > > before the meeting. > > > > A draft agenda/charter Jason provided are at > > > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-bof/agenda.txt > > > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- > > bof/charter.txt > > > > After discussion with the IESG/IAB: > > > > I'd like to remove the "as Proposed Standard" from the charter text > > for both milestones and see how the discussion goes in the BOF > before > > deciding which way this should go. > > > > I'd like to see more consideration around the issues of designing a > > codec that did a good job of mapping a real time stream onto IP > > packets. The way IP deals with packet loss and congestion has > > implications for designing a codec that works well over IP. I know > > some of the discussion I have had off list people talked about how > we > > wanted a codec that supported adaptive bit rates that could change > on > > the fly to be able to work well on an IP network. > > > > I will be working the folks to make sure the agenda has time to > > directly address the key topics which include (more may be coming): > > > > Will we be able to get qualified people to do and review the work? > > > > Key design goals of a new codec? > > > > Do we need a new codec or are there already ones defined that meet > the > > needs? > > > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this BOF. > > > > Thanks, > > > > Cullen > > > > > > > > > > > > _______________________________________________ > > 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 ron.even.tlv@gmail.com Fri Jun 26 00:49:16 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 0EF203A6849 for ; Fri, 26 Jun 2009 00:49:16 -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 N7O0xXDaeb6e for ; Fri, 26 Jun 2009 00:49:14 -0700 (PDT) Received: from mail-fx0-f213.google.com (mail-fx0-f213.google.com [209.85.220.213]) by core3.amsl.com (Postfix) with ESMTP id 64A563A67A4 for ; Fri, 26 Jun 2009 00:49:14 -0700 (PDT) Received: by fxm9 with SMTP id 9so1924850fxm.37 for ; Fri, 26 Jun 2009 00:48:03 -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:thread-index:content-language; bh=zIVtAn124viP2Cwo+aCRLntB0BHopXsJEpSjLLlWxpo=; b=xi1s6lUkZpl1n5LYnwlZdL9QwUpbVeT/tYMfahfDiL+0qMaSvOg3hiGMc3IGaNp79p 1yx84Bu9ZBfOm3DgtzFpMUztoc4AIArQZ5+DQGTe3rgQpz8m0n3eTnU0tY1yxLPfJD7d tQsNi278MyTibbKkO7I1JtVpZeKG9KiPqhaFI= 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 :thread-index:content-language; b=ps51gT8sBRnYvAI6G7wn9xkP4ZmU4+1g9ke1aJ773AX4Y3BEyCEAH4A6QTB5hbzx0g FElWaC+r+/YfdkVqwrTP/rf5eQv9WMzNcPkdCKotBVGDdw9Sk8+spZbd9hFoA1g5CC+M zlw6qAsT009xDzW4lMmE2w6pUwJM/kI9Sjd3k= Received: by 10.103.214.13 with SMTP id r13mr2118095muq.37.1246001989550; Fri, 26 Jun 2009 00:39:49 -0700 (PDT) Received: from windows8d787f9 (bzq-79-182-68-39.red.bezeqint.net [79.182.68.39]) by mx.google.com with ESMTPS id y6sm15322698mug.40.2009.06.26.00.39.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 26 Jun 2009 00:39:49 -0700 (PDT) From: "Roni Even" To: "'Cullen Jennings'" References: <7381fad80906190859y711a515dw2307a7836e9c555e@mail.gmail.com> <945FAEF4-1515-4816-8A3A-9ED2475BA455@cisco.com> In-Reply-To: <945FAEF4-1515-4816-8A3A-9ED2475BA455@cisco.com> Date: Fri, 26 Jun 2009 10:39:33 +0300 Message-ID: <4a447b45.06e2660a.7f72.7db8@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn2JJ4wfm1mrNCXSBaPJNxVOyk89wACqJoQ Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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: Fri, 26 Jun 2009 07:49:16 -0000 Cullen, Thanks, If I may, I would like to suggest based on my observations on the list discussion that the agenda will also include the following topics. 1. Should the IETF work on codecs (speech/audio) 2. If yes, should the these codecs be standard track or informational. I am suggesting this item since as far as I understand after iLBC publication the conclusion was that the IETF cannot do expert review on codecs even for Informational status. 3. If the IETF will do standard track, Is the prerequisite to qualify for approval is Royalty Free. The list discussion points that there is no agreement that the IETF can provide with high probability a RF codec. I think that only after these topics, which looks to me like ground rules, are addressed we can start discussing the content of the charter. Roni Even > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, June 26, 2009 9:09 AM > To: Ron Even > Cc: codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > > Roni, > > The primary goal of this BOF should be collecting the information that > helps make an informed decision about if a WG should be formed or not. > I certainly did not mean to imply by the agenda that there was any > assumption that a WG would be formed. > > I agree the charter below is far from ideal for collecting this > information. I'm expecting the agenda to change, based on the list > discussion, so we have time to talk about the key topics where > community input is needed to drive the decisions about if a WG should > be formed or not. > > Cullen > > > On Jun 19, 2009, at 8:59 , Ron Even wrote: > > > Cullen, > > I looked at the agenda > > > > 1. Administrative (Chairs, 5 min) > > - Note takers, Jabber scribes > > - Agenda bashing > > > > 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) > > > > 3. Proposed CODECs (TBD, 25 min) > > - Expect to have two or more drafts here > > > > 4. Charter Discussion (All, 40 min) > > > > 5. Decisions and HUMs (All, 5 min) > > > > 6. Conclusions and Next Steps (Chairs/ADs, 5 min) > > > > > > And it looks to me that it starts with assumption that we will have > > a new working group. > > > > I am not sure that that this was agreed and yet I see no time > > allocated to discuss the topic. I would expect that item 3 will be > > rational for doing codec at the IETF considering that this work is > > done also by other SDOs that the IETF is working with. > > > > Now even if there will be such a WG starting with proposed CODECS is > > like having a solution before the requirements. In other standard > > bodies requirements are not just names but they also have values. So > > what is the purpose of proposing codecs, do we need to select at the > > BOF which one will be standardize, to me it looks like this should > > be done later. > > > > Roni Even > > > > > > > > > > > -----Original Message----- > > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > > Behalf > > > Of Cullen Jennings > > > Sent: Friday, June 12, 2009 8:32 PM > > > To: codec@ietf.org > > > Subject: [codec] Codec BOF approved, much work needed > > > > > > > > > I have approved the CODEC BOF proposal. However, we need a bunch of > > > work to get ready. Various people on IESG/IAB were not comfortable > > > with the current charter and agenda so we need to work on theses > > > before the meeting. > > > > > > A draft agenda/charter Jason provided are at > > > > > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec- > bof/agenda.txt > > > > > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- > > > bof/charter.txt > > > > > > After discussion with the IESG/IAB: > > > > > > I'd like to remove the "as Proposed Standard" from the charter text > > > for both milestones and see how the discussion goes in the BOF > > before > > > deciding which way this should go. > > > > > > I'd like to see more consideration around the issues of designing a > > > codec that did a good job of mapping a real time stream onto IP > > > packets. The way IP deals with packet loss and congestion has > > > implications for designing a codec that works well over IP. I know > > > some of the discussion I have had off list people talked about how > > we > > > wanted a codec that supported adaptive bit rates that could change > > on > > > the fly to be able to work well on an IP network. > > > > > > I will be working the folks to make sure the agenda has time to > > > directly address the key topics which include (more may be coming): > > > > > > Will we be able to get qualified people to do and review the work? > > > > > > Key design goals of a new codec? > > > > > > Do we need a new codec or are there already ones defined that meet > > the > > > needs? > > > > > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this > BOF. > > > > > > Thanks, > > > > > > Cullen > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 Fri Jun 26 01:14: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 1B1BD3A684C for ; Fri, 26 Jun 2009 01:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.239 X-Spam-Level: X-Spam-Status: No, score=-6.239 tagged_above=-999 required=5 tests=[AWL=0.360, 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 RucuCbJU1pN5 for ; Fri, 26 Jun 2009 01:14:11 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id EC08E3A6890 for ; Fri, 26 Jun 2009 01:14:10 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id BA5572007A7F2; Fri, 26 Jun 2009 10:13:11 +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=TxLOMuTnFedu cJ86yk5YzuZS59M=; b=HUNpOtPBCRvkU7hyiNQ3aCMEpRKVJ6VV7Wn9bAOGTh9a KytQz1ybyrYKEItASmX9hPCidhEA63Y5BcRjH4/vXAKUA/UkX2nvX0NJA7sWZyIm 2JOF7epIDntV3bKKD2ThHsJVziwRsK8tVddphYqVu8/HLdf6dzX9NT2xAP9bYN4= 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=UmQm1/EBwRJ516r76aTa ++o+W7B3OS5e6s/6iQTOiKVDD6/9iKoXt/6SCPeYz+QSHq6XY7D1dJcZw3hgfvNl K8rXJxAMYUJ7ia06sPIqeBIrkwf5QGwNU0NUPUmpxDHvnzA7R26G6ypccTgMfWk2 B9wcyK29hAQFQJoAXemBl8c= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id B85D02007A57B; Fri, 26 Jun 2009 10:13:11 +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 n9td15mlRGVs; Fri, 26 Jun 2009 10:13:10 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id C2C752007A7E0; Fri, 26 Jun 2009 10:13:10 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Fri, 26 Jun 2009 01:13:10 -0700 Message-ID: <20090626011310.19195qynicusn312@mail.skype.net> Date: Fri, 26 Jun 2009 01:13:10 -0700 From: Koen Vos To: stephen botzko References: <20090624222759.13482jyf2wr43nq7@mail.skype.net> <6e9223710906250452p70f11547gec483cdd0d7ac072@mail.gmail.com> <20090625123737.26143iaxh4bom77l@mail.skype.net> <6e9223710906251333q56576064mc11184d0a7dacd83@mail.gmail.com> In-Reply-To: <6e9223710906251333q56576064mc11184d0a7dacd83@mail.gmail.com> 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] Codec BOF approved, much work needed 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: Fri, 26 Jun 2009 08:14:12 -0000 Quoting stephen botzko: >>>> > If the modifications consists of a method (let's say from a journal > publication) that already existed before today, then that modification > cannot be patented anymore. So someone trying to "sneakily" file for a > patent on an improvement that he sees coming by "interpolating" events at > IETF could indeed be stopped. >>>> > > A patent application could have been filed prior to the publication. Also, > a US patent application can be filed up to one year after publication. Or > specific modification could be claimed by a broader earler patent that the > inventor was not even aware of. Just to clarify: we were talking about the situation that Stefan mentioned where someone would quietly listen in on the IETF WG and predict/interpolate a future modification, and then files a patent on that modification before it was actually verbalized in the WG. You're right that we'd have to limit the modifications to prior art that's at least a year old (and preferably older). And also require the combination of the prior art and the codec proposal to be an obvious one. (Because non-obvious combinations may also be patentable, as Stefan has pointed out.) koen. From jean-marc.valin@usherbrooke.ca Fri Jun 26 05:09:11 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 4F74F3A69CE for ; Fri, 26 Jun 2009 05:09:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[AWL=0.245, 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 hLqUzxWJlJyL for ; Fri, 26 Jun 2009 05:09:10 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id CD4AF3A67B0 for ; Fri, 26 Jun 2009 05:08:40 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-type: text/plain; charset=ISO-8859-1 Received: from [192.168.1.10] ([70.81.109.112]) by VL-MH-MR002.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KLU00F5JHM31C50@VL-MH-MR002.ip.videotron.ca> for codec@ietf.org; Fri, 26 Jun 2009 08:06:04 -0400 (EDT) Message-id: <4A44B9AB.8020600@usherbrooke.ca> Date: Fri, 26 Jun 2009 08:06:03 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) To: Roni Even References: <4A43EF6A.30205@octasic.com> <4a444d9c.0c11660a.3855.0abe@mx.google.com> In-reply-to: <4a444d9c.0c11660a.3855.0abe@mx.google.com> X-Enigmail-Version: 0.95.2 Cc: codec@ietf.org, 'stephen botzko' Subject: Re: [codec] Codec BOF approved, much work needed 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: Fri, 26 Jun 2009 12:09:11 -0000 Roni Even a écrit : > I would like to add that I am not sure why the "googles of the world" > require a standard codec since they do not worry about interoperability > issue. I am also wondering why should the IETF who care about > interoperability worry about non-interoperable solutions. Why do you think that supporting SIP and XMPP for signalling and codecs such as G.711 and Speex isn't enough? What else is required for interoperability? Jean-Marc (not related to Google in any way) > Roni Even > >> -----Original Message----- >> From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf >> Of Stephan Wenger >> Sent: Friday, June 26, 2009 2:38 AM >> To: Jean-Marc Valin >> Cc: codec@ietf.org; stephen botzko >> Subject: Re: [codec] Codec BOF approved, much work needed >> >> Jean-Marc, >> >> Do you know that these players have not been approached by a possible >> rightholder? Are you sure they will not? Do you know the business >> arrangements that have in place? Have they picked up a license, >> perhaps? >> Subject to a very broad cross-licensing deal? Or are the leads of >> their >> licensing group golf buddies and decided over a game not to go at each >> other >> right now? >> >> Concluding from the current situation (no litigation around speex that >> I'm >> aware of, no licensing deal I have heard of) that there are really no >> patents related to that technology, is not really a clever move. >> >> However, I concede that the googles of the world have a very different >> business model compared to traditional telco operators or vendors (not >> so >> certain about skype, but let's skip that discussion :-). You have not >> convinced me that those players necessarily need a royalty-free codec, >> but >> if they would, they could make their voices easily heard in the >> traditional >> venues. Everyone listens to google, and everyone smart in the Telco >> industry listens to Skype, considering their respective successes. >> >> Regards, >> Stephan >> >> >> >> On 6/25/09 5:43 PM, "Jean-Marc Valin" >> wrote: >> >>> Stephan Wenger wrote: >>>> 5. The IPR game is always a question of risks and benefits. In the >>>> codec world, big industry operates by licensing and cross-licensing >>>> patents and dishing out licensing fees if they have to, and >> occasionally >>>> entertaining legal disputes that typically end up in settlements, >> that >>>> make the lawyers rich and no one else. There are provisions that >> make >>>> this environment quite survivable for smaller players, and that¹s >> IMHO >>>> not going away as the antitrust efforts in most developed countries >> are >>>> really getting teeth. One clear problem that the Open Source >> community >>>> (not the world, I insist!) has, is that they are so inflexible in >> their >>>> own legal framework that they cannot adapt to this business model. >>> There's a lot more than open source involved in here. While I agree >> that >>> the environment (i.e. having to pay $x of royalties per channel) may >> be >>> survivable for even small players in the standard "carrier market", >> it is >>> not viable for many other applications. I can probably start a new >> phone >>> company, pay the royalties for some ITU codec and still make a >> profit. On >>> the other hand, in other markets, even the *big* players cannot pay >> the >>> per-channel royalties. Why do you think players as big as Google >> (Talk), >>> Adobe (Flash) and Skype use Speex and/or iLBC and not G.729 or AMR-* >> ? It's >>> not about the size, but about the business model. The current way the >> ITU >>> works just does not support many of the new business models created >> by the >>> Internet. When we talk about an "Internet audio codec", it's a lot >> more >>> than merely transporting the bits over an IP network. >>> >>>> A few open source projects do against the spirit of their own >> policies >>>> AFAIK, by boldly ignoring known royalty bearing IPR. So far, I have >> not >>>> heard of anyone going after them. They play the risk/benefit >> equation >>>> in their own way, taking into account that they have not enough >> flesh on >>>> their bones to be a valuable target for the rightholders. >>> I totally agree that this is certainly not something that should be >>> encouraged. >>> >>> 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 From koen.vos@skype.net Fri Jun 26 11:52: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 206C328C122 for ; Fri, 26 Jun 2009 11:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.108 X-Spam-Level: X-Spam-Status: No, score=-6.108 tagged_above=-999 required=5 tests=[AWL=0.176, 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 J2OS6WDG1G7d for ; Fri, 26 Jun 2009 11:52:25 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id A195528C125 for ; Fri, 26 Jun 2009 11:52:24 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 198FB2007AAB6 for ; Fri, 26 Jun 2009 20:44:03 +0200 (CEST) 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=mWJC0Tt86Zrg F1VBqrDLQvLWfkM=; b=EZKuIe68iLuXRnA2eQ49OmDm6PqfdM5/Yl7Dppv26vuY WkZBUbCCkZ3zpznNhVHmvIJMwzLCbHcCnJuU3WxsrIjSQEkahBUEB7emzep5uT9J 5TATvEX3LJF/FaKwhj6Qm2tgiJj+517i0cukkDIP6DjKTDnPudMTUMPJ1nOJruI= 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=FyyJNj2EI0EaZxvmC3Nb AyJmeW0whkwbCZ+3xg+IeVivGVDt4ufrQD6y1WuO7mvMbKuj0BHG0dWWcceb3PAu RLBIemCt7Ck/OAP4+a0Z3+acgd/qCEQP3fBks6/xZMMINw5nx6QjjXon85ZXOSsT LbXe7LUDJsJAuj9v6IqlIGE= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 182EC2007AAB2 for ; Fri, 26 Jun 2009 20:44:03 +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 6HwtvmFw+wXb for ; Fri, 26 Jun 2009 20:43:55 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 23F902007AAC7; Fri, 26 Jun 2009 20:43:55 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Fri, 26 Jun 2009 11:43:55 -0700 Message-ID: <20090626114355.16720yb6jhzzxxij@mail.skype.net> Date: Fri, 26 Jun 2009 11:43:55 -0700 From: Koen Vos To: codec@ietf.org References: 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] Codec BOF approved, much work needed 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: Fri, 26 Jun 2009 18:52:26 -0000 Stephan Wenger: > Concluding from the current situation (no litigation around speex that I'm > aware of, no licensing deal I have heard of) that there are really no > patents related to that technology, is not really a clever move. When big companies adopt open technology, they do due diligence to evaluate the risk of being sued for infringement. Sometimes they may indeed find patents that are their own, or which they cross-license already, and are thus no threat to them. Other patents they may overlook. But when enough large companies adopt an open technology, that (1) reduces the patent risk, and (2) that creates a powerful body to fight against frivolous patent claims (as in the SCO case). Stephan, no new(ish) technology can ever be guaranteed to avoid patents. You sound as if open source and IETF standardization are fundamentally flawed in this regard. But they've been working well so far, and I just don't see a better alternative to creating free, interoperable technology. > However, I concede that the googles of the world have a very different > business model compared to traditional telco operators or vendors (not so > certain about skype, but let's skip that discussion :-). Skype has 100s of millions of downloads per year, the vast majority of which never brings Skype a cent in revenue. > You have not > convinced me that those players necessarily need a royalty-free codec, but > if they would, they could make their voices easily heard in the traditional > venues. Everyone listens to google, and everyone smart in the Telco > industry listens to Skype, considering their respective successes. Are you suggesting that ITU could create a royalty free standard? Many ITU stakeholders have big interests in avoiding exactly that. They have invested lots of R&D in this area and are now earning this back through their current standard codecs. Some of them even depend on codec royalties for their existence. And bear in mind that the ITU process is very expensive - who is going to pay for it if it only means less revenues for the average ITU member? But most importantly, even if ITU would try to standardize a royalty free codec, why would that codec have any less risk of infringing patents? Surely all the stakeholders who are today earning royalties would not participate, and therefore have no obligation to disclose related patents (just like with IETF). http://www.itu.int/ITU-T/dbase/patent/patent-policy.html best, koen. From hsinnrei@adobe.com Fri Jun 26 12:48:14 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 2CA503A6B62 for ; Fri, 26 Jun 2009 12:48:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.99 X-Spam-Level: X-Spam-Status: No, score=-5.99 tagged_above=-999 required=5 tests=[AWL=0.608, BAYES_00=-2.599, 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 TV9AcWoMLbe1 for ; Fri, 26 Jun 2009 12:48:12 -0700 (PDT) Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by core3.amsl.com (Postfix) with ESMTP id 60A633A68CD for ; Fri, 26 Jun 2009 12:48:11 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKSkUmBuqBjffRhRvQ9Gcv9iDT/S4YRyc/@postini.com; Fri, 26 Jun 2009 12:48:30 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5QJmJWG025304; Fri, 26 Jun 2009 12:48:19 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5QJmIlT016218; Fri, 26 Jun 2009 12:48:18 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Fri, 26 Jun 2009 12:48:18 -0700 From: Henry Sinnreich To: Roni Even , Cullen Jennings Date: Fri, 26 Jun 2009 12:48:09 -0700 Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acn2JJ4wfm1mrNCXSBaPJNxVOyk89wACqJoQABnx1Fo= Message-ID: In-Reply-To: <4a447b45.06e2660a.7f72.7db8@mx.google.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_C66A902945F6hsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] Codec BOF approved, much work needed 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: Fri, 26 Jun 2009 19:48:14 -0000 --_000_C66A902945F6hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Cullen, Roni Even wrote >>1. Should the IETF work on codecs? These arguments have been repeated countless time on the list. There is not reason to waste precious BOF face-to-face time by regurgitati= ng them again. It definitely has the appearance legacy codec people will go to great lengt= h to keep newcomers out; and suppress even discussing the potential Interne= t and software technologies that could innovate voice codecs for use on the= Internet. Take for example the usage scenario of rich internet applications in the br= owser and/or desktop. Countless new applications, business models and software development techni= ques for the web have made legacy codecs undesirable or even inapplicable f= or such as enabling voice for content providers, social networks, any type = of business imaginable and for no-profits alike. Especially for non-profits= . For example, web sites for broadcasting sport events, political events or s= ocial network can have huge traffic surges that are often completely event = driven. Traffic may practically disappear after the event. Nobody can also predict the success (or otherwise) and traffic for any web = site or web based service. Moreover, nobody expects to pay for a browser and plug-ins. 1. Business models are different than they were for legacy codecs, 2. Technology is also vastly different, from every facet. Let the agenda for the BOF explore and inform about this potential, though I understand the stake legacy codec people have to suppress this inf= ormation in the first place. (My individual contributor hat on) Henry On 6/26/09 2:39 AM, "Roni Even" wrote: Cullen, Thanks, If I may, I would like to suggest based on my observations on the list discussion that the agenda will also include the following topics. 1. Should the IETF work on codecs (speech/audio) 2. If yes, should the these codecs be standard track or informational. I am suggesting this item since as far as I understand after iLBC publication th= e conclusion was that the IETF cannot do expert review on codecs even for Informational status. 3. If the IETF will do standard track, Is the prerequisite to qualify for approval is Royalty Free. The list discussion points that there is no agreement that the IETF can provide with high probability a RF codec. I think that only after these topics, which looks to me like ground rules, are addressed we can start discussing the content of the charter. Roni Even > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, June 26, 2009 9:09 AM > To: Ron Even > Cc: codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > > Roni, > > The primary goal of this BOF should be collecting the information that > helps make an informed decision about if a WG should be formed or not. > I certainly did not mean to imply by the agenda that there was any > assumption that a WG would be formed. > > I agree the charter below is far from ideal for collecting this > information. I'm expecting the agenda to change, based on the list > discussion, so we have time to talk about the key topics where > community input is needed to drive the decisions about if a WG should > be formed or not. > > Cullen > > > On Jun 19, 2009, at 8:59 , Ron Even wrote: > > > Cullen, > > I looked at the agenda > > > > 1. Administrative (Chairs, 5 min) > > - Note takers, Jabber scribes > > - Agenda bashing > > > > 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) > > > > 3. Proposed CODECs (TBD, 25 min) > > - Expect to have two or more drafts here > > > > 4. Charter Discussion (All, 40 min) > > > > 5. Decisions and HUMs (All, 5 min) > > > > 6. Conclusions and Next Steps (Chairs/ADs, 5 min) > > > > > > And it looks to me that it starts with assumption that we will have > > a new working group. > > > > I am not sure that that this was agreed and yet I see no time > > allocated to discuss the topic. I would expect that item 3 will be > > rational for doing codec at the IETF considering that this work is > > done also by other SDOs that the IETF is working with. > > > > Now even if there will be such a WG starting with proposed CODECS is > > like having a solution before the requirements. In other standard > > bodies requirements are not just names but they also have values. So > > what is the purpose of proposing codecs, do we need to select at the > > BOF which one will be standardize, to me it looks like this should > > be done later. > > > > Roni Even > > > > > > > > > > > -----Original Message----- > > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > > Behalf > > > Of Cullen Jennings > > > Sent: Friday, June 12, 2009 8:32 PM > > > To: codec@ietf.org > > > Subject: [codec] Codec BOF approved, much work needed > > > > > > > > > I have approved the CODEC BOF proposal. However, we need a bunch of > > > work to get ready. Various people on IESG/IAB were not comfortable > > > with the current charter and agenda so we need to work on theses > > > before the meeting. > > > > > > A draft agenda/charter Jason provided are at > > > > > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec- > bof/agenda.txt > > > > > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- > > > bof/charter.txt > > > > > > After discussion with the IESG/IAB: > > > > > > I'd like to remove the "as Proposed Standard" from the charter text > > > for both milestones and see how the discussion goes in the BOF > > before > > > deciding which way this should go. > > > > > > I'd like to see more consideration around the issues of designing a > > > codec that did a good job of mapping a real time stream onto IP > > > packets. The way IP deals with packet loss and congestion has > > > implications for designing a codec that works well over IP. I know > > > some of the discussion I have had off list people talked about how > > we > > > wanted a codec that supported adaptive bit rates that could change > > on > > > the fly to be able to work well on an IP network. > > > > > > I will be working the folks to make sure the agenda has time to > > > directly address the key topics which include (more may be coming): > > > > > > Will we be able to get qualified people to do and review the work? > > > > > > Key design goals of a new codec? > > > > > > Do we need a new codec or are there already ones defined that meet > > the > > > needs? > > > > > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this > BOF. > > > > > > Thanks, > > > > > > Cullen > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 --_000_C66A902945F6hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Codec BOF approved, much work needed Cullen,

Roni Even wrote
>>1. Should the IETF work on codecs?

These arguments have been repeated countless time on the list.
 There is not reason to waste precious BOF face-to-face time by regurg= itating them again.
It definitely has the appearance legacy codec people will go to great lengt= h to keep newcomers out; and suppress even discussing the potential Interne= t and software technologies that could innovate voice codecs for use on the= Internet.  

Take for example the usage scenario of rich internet applications in the br= owser and/or desktop.
Countless new applications, business models and software development techni= ques for the web have made legacy codecs undesirable or even inapplicable f= or such as enabling voice for content providers, social networks, any type = of business imaginable and for no-profits alike. Especially for non-profits= .

For example, web sites for broadcasting sport events, political events or s= ocial network can have huge traffic surges that are often completely event = driven. Traffic may practically disappear after the event.

Nobody can also predict the success (or otherwise) and traffic for any web = site or web based service.
Moreover, nobody expects to pay for a browser and plug-ins.

  1. Business models are different than they were fo= r legacy codecs,
  2. Technology is also vastly different, from every fac= et.

Let the agenda for the BOF explore and inform about this potential,
though I understand the stake legacy codec people have to suppress this inf= ormation in the first place.

(My individual contributor hat on)
Henry


On 6/26/09 2:39 AM, "Roni Even" <ron.even.tlv@gmail.com> wrote:

Cullen,
Thanks,
If I may, I would like to suggest based on my observations on the list
discussion that the agenda will also include the following topics.

1. Should the IETF work on codecs (speech/audio)
2. If yes, should the these codecs be standard track or informational. I am=
suggesting this item since as far as I understand after iLBC publication th= e
conclusion was that the IETF cannot do expert review on codecs even for
Informational status.

3. If the IETF will do standard track, Is the prerequisite to qualify for approval is Royalty Free. The list discussion points that there is no
agreement that the IETF can provide with high probability a RF codec.


I think that only after these topics, which looks to me like ground rules,<= BR> are addressed we can start discussing the content of the charter.

Roni Even



> -----Original Message-----
> From: Cullen Jennings [mailto:fluf= fy@cisco.com]
> Sent: Friday, June 26, 2009 9:09 AM
> To: Ron Even
> Cc: codec@ietf.org
> Subject: Re: [codec] Codec BOF approved, much work needed
>
>
> Roni,
>
> The primary goal of this BOF should be collecting the information that=
> helps make an informed decision about if a WG should be formed or not.=
> I certainly did not mean to imply by the agenda that there was any
> assumption that a WG would be formed.
>
> I agree the charter below is far from ideal for collecting this
> information. I'm expecting the agenda to change, based on the list
> discussion, so we have time to talk about the key topics where
> community input is needed to drive the decisions about if a WG should<= BR> > be formed or not.
>
> Cullen <RAI AD>
>
>
> On Jun 19, 2009, at 8:59 , Ron Even wrote:
>
> > Cullen,
> > I looked at the agenda
> >
> > 1. Administrative (Chairs, 5 min)
> >   - Note takers, Jabber scribes
> >   - Agenda bashing
> >
> > 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min)
> >
> > 3. Proposed CODECs (TBD, 25 min)
> >   - Expect to have two or more drafts here
> >
> > 4. Charter Discussion (All, 40 min)
> >
> > 5. Decisions and HUMs (All, 5 min)
> >
> > 6. Conclusions and Next Steps (Chairs/ADs, 5 min)
> >
> >
> > And it looks to me that it starts with assumption that we will ha= ve
> > a new working group.
> >
> > I am not sure that that this was agreed and yet I see no time
> > allocated to discuss the topic. I would expect that item 3 will b= e
> > rational for doing codec at the IETF considering that this work i= s
> > done also by other SDOs that the IETF is working with.
> >
> > Now even if there will be such a WG starting with proposed CODECS= is
> > like having a solution before the requirements. In other standard=
> > bodies requirements are not just names but they also have values.= So
> > what is the purpose of proposing codecs, do we need to select at = the
> > BOF which one will be standardize, to me it looks like this shoul= d
> > be done later.
> >
> > Roni Even
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: codec-bounces@ietf.= org [mailto:codec-bounces@iet= f.org] On
> > Behalf
> > > Of Cullen Jennings
> > > Sent: Friday, June 12, 2009 8:32 PM
> > > To: codec@ietf.org
> > > Subject: [codec] Codec BOF approved, much work needed
> > >
> > >
> > > I have approved the CODEC BOF proposal. However, we need a b= unch of
> > > work to get ready.  Various people on IESG/IAB were not= comfortable
> > > with the current charter and agenda so we need to work on th= eses
> > > before the meeting.
> > >
> > > A draft agenda/charter Jason provided are at
> > >
> > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-
> bof/agenda.txt
> > >
> > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-
> > > bof/charter.txt
> > >
> > > After discussion with the IESG/IAB:
> > >
> > > I'd like to remove the "as Proposed Standard" from= the charter text
> > > for both milestones and see how the discussion goes in the B= OF
> > before
> > > deciding which way this should go.
> > >
> > > I'd like to see more consideration around the issues of desi= gning a
> > > codec that did a good job of mapping a real time stream onto= IP
> > > packets. The way IP deals with packet loss and congestion ha= s
> > > implications for designing a codec that works well over IP. = I know
> > > some of the discussion I have had off list people talked abo= ut how
> > we
> > > wanted a codec that supported adaptive bit rates that could = change
> > on
> > > the fly to be able to work well on an IP network.
> > >
> > > I will be working the folks to make sure the agenda has time= to
> > > directly address the key topics which include (more may be c= oming):
> > >
> > > Will we be able to get qualified people to do and review the= work?
> > >
> > > Key design goals of a new codec?
> > >
> > > Do we need a new codec or are there already ones defined tha= t meet
> > the
> > > needs?
> > >
> > > I have asked Jason Fischl  and Jean-Marc Valin to co-ch= air this
> BOF.
> > >
> > > Thanks,
> > >
> > > Cullen <RAI AD>
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > codec mailing list
> > > codec@ietf.org
> > > http= s://www.ietf.org/mailman/listinfo/codec
> > _______________________________________________
> > codec mailing list
> > codec@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/codec

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

--_000_C66A902945F6hsinnreiadobecom_-- From stewe@stewe.org Fri Jun 26 16:17:21 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 97F0D28C1BD for ; Fri, 26 Jun 2009 16:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.025 X-Spam-Level: X-Spam-Status: No, score=0.025 tagged_above=-999 required=5 tests=[AWL=-1.228, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 07qL4qHCSdfx for ; Fri, 26 Jun 2009 16:17:14 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id B450C28C179 for ; Fri, 26 Jun 2009 16:17:13 -0700 (PDT) Received: from [192.168.1.103] (unverified [75.60.27.130]) by stewe.org (SurgeMail 3.9e) with ESMTP id 317095-1743317 for multiple; Sat, 27 Jun 2009 01:17:30 +0200 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Fri, 26 Jun 2009 16:17:21 -0700 From: Stephan Wenger To: Henry Sinnreich , Roni Even , Cullen Jennings Message-ID: Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acn2JJ4wfm1mrNCXSBaPJNxVOyk89wACqJoQABnx1FoAB05lBg== In-Reply-To: Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3328877848_7097702" X-Originating-IP: 75.60.27.130 X-Authenticated-User: stewe@stewe.org Cc: "codec@ietf.org" Subject: Re: [codec] Codec BOF approved, much work needed 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: Fri, 26 Jun 2009 23:17:21 -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_3328877848_7097702 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Hi Henry, as you probably expect, I disagree. It=B9s not a waste of BOF time to discus= s whether the IETF should =B3work on codecs=B2. However, I agree that this aspec= t has received recently significant, probably even adequate, coverage on the list, and unorganized repetition of the same arguments would not be overly helpful, nor time-efficient. Why not have the chairs, or the AD, summarize the discussion here, and take an early humm on that question? Alternatively, have the BOF hearing one advocate in favor, and one against, and then take a humm? Stephan On 6/26/09 12:48 PM, "Henry Sinnreich" wrote: > Cullen, >=20 > Roni Even wrote >>> >>1. Should the IETF work on codecs? >=20 > These arguments have been repeated countless time on the list. > There is not reason to waste precious BOF face-to-face time by regurgita= ting > them again.=20 > It definitely has the appearance legacy codec people will go to great len= gth > to keep newcomers out; and suppress even discussing the potential Interne= t and > software technologies that could innovate voice codecs for use on the > Internet. =20 >=20 > Take for example the usage scenario of rich internet applications in the > browser and/or desktop. > Countless new applications, business models and software development > techniques for the web have made legacy codecs undesirable or even > inapplicable for such as enabling voice for content providers, social > networks, any type of business imaginable and for no-profits alike. Espec= ially > for non-profits. >=20 > For example, web sites for broadcasting sport events, political events or > social network can have huge traffic surges that are often completely eve= nt > driven. Traffic may practically disappear after the event. >=20 > Nobody can also predict the success (or otherwise) and traffic for any we= b > site or web based service. > Moreover, nobody expects to pay for a browser and plug-ins. >=20 > 1. Business models are different than they were for legacy codecs, > 2. Technology is also vastly different, from every facet. >=20 > Let the agenda for the BOF explore and inform about this potential, > though I understand the stake legacy codec people have to suppress this > information in the first place. >=20 > (My individual contributor hat on) > Henry >=20 >=20 > On 6/26/09 2:39 AM, "Roni Even" wrote: >=20 >> Cullen, >> Thanks, >> If I may, I would like to suggest based on my observations on the list >> discussion that the agenda will also include the following topics. >>=20 >> 1. Should the IETF work on codecs (speech/audio) >> 2. If yes, should the these codecs be standard track or informational. I= am >> suggesting this item since as far as I understand after iLBC publication= the >> conclusion was that the IETF cannot do expert review on codecs even for >> Informational status. >>=20 >> 3. If the IETF will do standard track, Is the prerequisite to qualify fo= r >> approval is Royalty Free. The list discussion points that there is no >> agreement that the IETF can provide with high probability a RF codec. >>=20 >>=20 >> I think that only after these topics, which looks to me like ground rule= s, >> are addressed we can start discussing the content of the charter. >>=20 >> Roni Even >>=20 >>=20 >>=20 >>> > -----Original Message----- >>> > From: Cullen Jennings [mailto:fluffy@cisco.com] >>> > Sent: Friday, June 26, 2009 9:09 AM >>> > To: Ron Even >>> > Cc: codec@ietf.org >>> > Subject: Re: [codec] Codec BOF approved, much work needed >>> > >>> > >>> > Roni, >>> > >>> > The primary goal of this BOF should be collecting the information tha= t >>> > helps make an informed decision about if a WG should be formed or not= . >>> > I certainly did not mean to imply by the agenda that there was any >>> > assumption that a WG would be formed. >>> > >>> > I agree the charter below is far from ideal for collecting this >>> > information. I'm expecting the agenda to change, based on the list >>> > discussion, so we have time to talk about the key topics where >>> > community input is needed to drive the decisions about if a WG should >>> > be formed or not. >>> > >>> > Cullen >>> > >>> > >>> > On Jun 19, 2009, at 8:59 , Ron Even wrote: >>> > >>>> > > Cullen, >>>> > > I looked at the agenda >>>> > > >>>> > > 1. Administrative (Chairs, 5 min) >>>> > > - Note takers, Jabber scribes >>>> > > - Agenda bashing >>>> > > >>>> > > 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) >>>> > > >>>> > > 3. Proposed CODECs (TBD, 25 min) >>>> > > - Expect to have two or more drafts here >>>> > > >>>> > > 4. Charter Discussion (All, 40 min) >>>> > > >>>> > > 5. Decisions and HUMs (All, 5 min) >>>> > > >>>> > > 6. Conclusions and Next Steps (Chairs/ADs, 5 min) >>>> > > >>>> > > >>>> > > And it looks to me that it starts with assumption that we will hav= e >>>> > > a new working group. >>>> > > >>>> > > I am not sure that that this was agreed and yet I see no time >>>> > > allocated to discuss the topic. I would expect that item 3 will be >>>> > > rational for doing codec at the IETF considering that this work is >>>> > > done also by other SDOs that the IETF is working with. >>>> > > >>>> > > Now even if there will be such a WG starting with proposed CODECS = is >>>> > > like having a solution before the requirements. In other standard >>>> > > bodies requirements are not just names but they also have values. = So >>>> > > what is the purpose of proposing codecs, do we need to select at t= he >>>> > > BOF which one will be standardize, to me it looks like this should >>>> > > be done later. >>>> > > >>>> > > Roni Even >>>> > > >>>> > > >>>> > > >>>> > > >>>>> > > > -----Original Message----- >>>>> > > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On >>>> > > Behalf >>>>> > > > Of Cullen Jennings >>>>> > > > Sent: Friday, June 12, 2009 8:32 PM >>>>> > > > To: codec@ietf.org >>>>> > > > Subject: [codec] Codec BOF approved, much work needed >>>>> > > > >>>>> > > > >>>>> > > > I have approved the CODEC BOF proposal. However, we need a bunc= h of >>>>> > > > work to get ready. Various people on IESG/IAB were not comfort= able >>>>> > > > with the current charter and agenda so we need to work on these= s >>>>> > > > before the meeting. >>>>> > > > >>>>> > > > A draft agenda/charter Jason provided are at >>>>> > > > >>>>> > > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec- >>> > bof/agenda.txt >>>>> > > > >>>>> > > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- >>>>> > > > bof/charter.txt >>>>> > > > >>>>> > > > After discussion with the IESG/IAB: >>>>> > > > >>>>> > > > I'd like to remove the "as Proposed Standard" from the charter = text >>>>> > > > for both milestones and see how the discussion goes in the BOF >>>> > > before >>>>> > > > deciding which way this should go. >>>>> > > > >>>>> > > > I'd like to see more consideration around the issues of designi= ng a >>>>> > > > codec that did a good job of mapping a real time stream onto IP >>>>> > > > packets. The way IP deals with packet loss and congestion has >>>>> > > > implications for designing a codec that works well over IP. I k= now >>>>> > > > some of the discussion I have had off list people talked about = how >>>> > > we >>>>> > > > wanted a codec that supported adaptive bit rates that could cha= nge >>>> > > on >>>>> > > > the fly to be able to work well on an IP network. >>>>> > > > >>>>> > > > I will be working the folks to make sure the agenda has time to >>>>> > > > directly address the key topics which include (more may be comi= ng): >>>>> > > > >>>>> > > > Will we be able to get qualified people to do and review the wo= rk? >>>>> > > > >>>>> > > > Key design goals of a new codec? >>>>> > > > >>>>> > > > Do we need a new codec or are there already ones defined that m= eet >>>> > > the >>>>> > > > needs? >>>>> > > > >>>>> > > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this >>> > BOF. >>>>> > > > >>>>> > > > Thanks, >>>>> > > > >>>>> > > > Cullen >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > >>>>> > > > _______________________________________________ >>>>> > > > 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 >>=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_3328877848_7097702 Content-type: text/html; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable Re: [codec] Codec BOF approved, much work needed Hi Henry,

as you probably expect, I disagree.  It’s not a waste of BOF tim= e to discuss whether the IETF should “work on codecs”.  How= ever, I agree that this aspect has received recently significant, probably e= ven adequate, coverage on the list, and unorganized repetition of the same a= rguments would not be overly helpful, nor time-efficient.  Why not have= the chairs, or the AD, summarize the discussion here, and take an early hum= m on that question?  Alternatively, have the BOF hearing one advocate i= n favor, and one against, and then take a humm?  
Stephan





On 6/26/09 12:48 PM, "Henry Sinnreich" <hsinnrei@adobe.com> wrote:

<= FONT SIZE=3D"5">Cullen,

Roni Even wrote
>>1. Should the IETF work on codecs?

These arguments have been repeated countless time on the list.
 There is not reason to waste precious BOF face-to-face time by regurg= itating them again.
It definitely has the appearance legacy codec people will go to great lengt= h to keep newcomers out; and suppress even discussing the potential Internet= and software technologies that could innovate voice codecs for use on the I= nternet.  

Take for example the usage scenario of rich internet applications in the br= owser and/or desktop.
Countless new applications, business models and software development techni= ques for the web have made legacy codecs undesirable or even inapplicable fo= r such as enabling voice for content providers, social networks, any type of= business imaginable and for no-profits alike. Especially for non-profits.
For example, web sites for broadcasting sport events, political events or s= ocial network can have huge traffic surges that are often completely event d= riven. Traffic may practically disappear after the event.

Nobody can also predict the success (or otherwise) and traffic for any web = site or web based service.
Moreover, nobody expects to pay for a browser and plug-ins.

  1. Business models are different = than they were for legacy codecs,=20
  2. Technology is also vastly differen= t, from every facet.
<= FONT SIZE=3D"5">
Let the agenda for the BOF explore and inform about this potential,
though I understand the stake legacy codec people have to suppress this inf= ormation in the first place.

(My individual contributor hat on)
Henry


On 6/26/09 2:39 AM, "Roni Even" <ron.even.tlv@gmail.com> wrote:

Cullen,
Thanks,
If I may, I would like to suggest based on my observations on the list
discussion that the agenda will also include the following topics.

1. Should the IETF work on codecs (speech/audio)
2. If yes, should the these codecs be standard track or informational. I am=
suggesting this item since as far as I understand after iLBC publication th= e
conclusion was that the IETF cannot do expert review on codecs even for
Informational status.

3. If the IETF will do standard track, Is the prerequisite to qualify for approval is Royalty Free. The list discussion points that there is no
agreement that the IETF can provide with high probability a RF codec.


I think that only after these topics, which looks to me like ground rules,<= BR> are addressed we can start discussing the content of the charter.

Roni Even



> -----Original Message-----
> From: Cullen Jennings [mailto:fluffy= @cisco.com]
> Sent: Friday, June 26, 2009 9:09 AM
> To: Ron Even
> Cc: codec@ietf.org
> Subject: Re: [codec] Codec BOF approved, much work needed
>
>
> Roni,
>
> The primary goal of this BOF should be collecting the information that=
> helps make an informed decision about if a WG should be formed or not.=
> I certainly did not mean to imply by the agenda that there was any
> assumption that a WG would be formed.
>
> I agree the charter below is far from ideal for collecting this
> information. I'm expecting the agenda to change, based on the list
> discussion, so we have time to talk about the key topics where
> community input is needed to drive the decisions about if a WG should<= BR> > be formed or not.
>
> Cullen <RAI AD>
>
>
> On Jun 19, 2009, at 8:59 , Ron Even wrote:
>
> > Cullen,
> > I looked at the agenda
> >
> > 1. Administrative (Chairs, 5 min)
> >   - Note takers, Jabber scribes
> >   - Agenda bashing
> >
> > 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min)
> >
> > 3. Proposed CODECs (TBD, 25 min)
> >   - Expect to have two or more drafts here
> >
> > 4. Charter Discussion (All, 40 min)
> >
> > 5. Decisions and HUMs (All, 5 min)
> >
> > 6. Conclusions and Next Steps (Chairs/ADs, 5 min)
> >
> >
> > And it looks to me that it starts with assumption that we will ha= ve
> > a new working group.
> >
> > I am not sure that that this was agreed and yet I see no time
> > allocated to discuss the topic. I would expect that item 3 will b= e
> > rational for doing codec at the IETF considering that this work i= s
> > done also by other SDOs that the IETF is working with.
> >
> > Now even if there will be such a WG starting with proposed CODECS= is
> > like having a solution before the requirements. In other standard=
> > bodies requirements are not just names but they also have values.= So
> > what is the purpose of proposing codecs, do we need to select at = the
> > BOF which one will be standardize, to me it looks like this shoul= d
> > be done later.
> >
> > Roni Even
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: codec-bounces@ietf.or= g [mailto:codec-bounces@ietf.org= ] On
> > Behalf
> > > Of Cullen Jennings
> > > Sent: Friday, June 12, 2009 8:32 PM
> > > To: codec@ietf.org
> > > Subject: [codec] Codec BOF approved, much work needed
> > >
> > >
> > > I have approved the CODEC BOF proposal. However, we need a b= unch of
> > > work to get ready.  Various people on IESG/IAB were not= comfortable
> > > with the current charter and agenda so we need to work on th= eses
> > > before the meeting.
> > >
> > > A draft agenda/charter Jason provided are at
> > >
> > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-
> bof/agenda.txt
> > >
> > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-
> > > bof/charter.txt
> > >
> > > After discussion with the IESG/IAB:
> > >
> > > I'd like to remove the "as Proposed Standard" from= the charter text
> > > for both milestones and see how the discussion goes in the B= OF
> > before
> > > deciding which way this should go.
> > >
> > > I'd like to see more consideration around the issues of desi= gning a
> > > codec that did a good job of mapping a real time stream onto= IP
> > > packets. The way IP deals with packet loss and congestion ha= s
> > > implications for designing a codec that works well over IP. = I know
> > > some of the discussion I have had off list people talked abo= ut how
> > we
> > > wanted a codec that supported adaptive bit rates that could = change
> > on
> > > the fly to be able to work well on an IP network.
> > >
> > > I will be working the folks to make sure the agenda has time= to
> > > directly address the key topics which include (more may be c= oming):
> > >
> > > Will we be able to get qualified people to do and review the= work?
> > >
> > > Key design goals of a new codec?
> > >
> > > Do we need a new codec or are there already ones defined tha= t meet
> > the
> > > needs?
> > >
> > > I have asked Jason Fischl  and Jean-Marc Valin to co-ch= air this
> BOF.
> > >
> > > Thanks,
> > >
> > > Cullen <RAI AD>
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > 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


___________= ____________________________________
codec mailing list
codec@ietf.org
https://www.ietf.org/= mailman/listinfo/codec
--B_3328877848_7097702-- From jmh@joelhalpern.com Fri Jun 26 16:32:11 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 35AC928C1EC for ; Fri, 26 Jun 2009 16:32:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=-1.198, BAYES_00=-2.599, FRT_ADOBE2=2.455, 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 inEfRRVaMPYY for ; Fri, 26 Jun 2009 16:32:09 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id DE52E28C1E9 for ; Fri, 26 Jun 2009 16:32:09 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id AB7C44303F1; Fri, 26 Jun 2009 16:32:28 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 9EDBF4303F4; Fri, 26 Jun 2009 16:32:25 -0700 (PDT) Message-ID: <4A455A86.2020506@joelhalpern.com> Date: Fri, 26 Jun 2009 19:32:22 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Stephan Wenger References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "codec@ietf.org" Subject: Re: [codec] Codec BOF approved, much work needed 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: Fri, 26 Jun 2009 23:32:11 -0000 To put this a little differently, one of the primary uses for our face-to-face time is supposed to be to work out sticky questions that provoke lots of on-list discussion. hence, the fact of the discussion, without clear resolution, is in fact a good indication that it would be a reasonable topic for the BoF. And, looked at from the quesiton of what a BoF is for, it is to evaluate whether the work makes sense for the IETF, and if it makes sense, exactly what we should do. Declaring that the BoF should not discuss the central topic on which there is significant disagreement seems very wrong. Yes, it takes some organizing so that the discussion does not devolve into people shouting at each other at the microphone. That does not do anyone any good. But we (the IETF) have defined criteria for these things, and a careful discussion of whether a) the purpose and capabilities match the criteria; b) whether the stated purposes are achievable and reviewable in this community; both seem to be dimensions worthy of explicit discussion at the BoF. In my understanding, the use of BoF time for charter refinement, or even more clearly, for solution review, really needs to come after appropriate time has been given to the first dimension, if there is disagreement. Of course different topics need different handling. Some topics the real task for the BoF is to find a single problem that everyone agrees on (because folks have been, in some cases, talking about different problems under the same name.) That does not appear to be the issue here. Some BoFs need extensive discussion about the charter, because the folks pushing really want to solve more than can be done. (Some folks like trying to drain the ocean. We try to discourage it.) But this case, the disagreement is very basic, and it would seem quite necessary and appropraite to address it with a significant portion of the BoF time. Yours, Joel Stephan Wenger wrote: > Hi Henry, > > as you probably expect, I disagree. It’s not a waste of BOF time to > discuss whether the IETF should “work on codecs”. However, I agree that > this aspect has received recently significant, probably even adequate, > coverage on the list, and unorganized repetition of the same arguments > would not be overly helpful, nor time-efficient. Why not have the > chairs, or the AD, summarize the discussion here, and take an early humm > on that question? Alternatively, have the BOF hearing one advocate in > favor, and one against, and then take a humm? > Stephan > > > > > > On 6/26/09 12:48 PM, "Henry Sinnreich" wrote: > > Cullen, > > Roni Even wrote > > >1. Should the IETF work on codecs? > > These arguments have been repeated countless time on the list. > There is not reason to waste precious BOF face-to-face time by > regurgitating them again. > It definitely has the appearance legacy codec people will go to > great length to keep newcomers out; and suppress even discussing the > potential Internet and software technologies that could innovate > voice codecs for use on the Internet. > > Take for example the usage scenario of rich internet applications in > the browser and/or desktop. > Countless new applications, business models and software development > techniques for the web have made legacy codecs undesirable or even > inapplicable for such as enabling voice for content providers, > social networks, any type of business imaginable and for no-profits > alike. Especially for non-profits. > > For example, web sites for broadcasting sport events, political > events or social network can have huge traffic surges that are often > completely event driven. Traffic may practically disappear after the > event. > > Nobody can also predict the success (or otherwise) and traffic for > any web site or web based service. > Moreover, nobody expects to pay for a browser and plug-ins. > > 1. Business models are different than they were for legacy codecs, > 2. Technology is also vastly different, from every facet. > > > Let the agenda for the BOF explore and inform about this potential, > though I understand the stake legacy codec people have to suppress > this information in the first place. > > (My individual contributor hat on) > Henry > > > On 6/26/09 2:39 AM, "Roni Even" wrote: > > Cullen, > Thanks, > If I may, I would like to suggest based on my observations on > the list > discussion that the agenda will also include the following topics. > > 1. Should the IETF work on codecs (speech/audio) > 2. If yes, should the these codecs be standard track or > informational. I am > suggesting this item since as far as I understand after iLBC > publication the > conclusion was that the IETF cannot do expert review on codecs > even for > Informational status. > > 3. If the IETF will do standard track, Is the prerequisite to > qualify for > approval is Royalty Free. The list discussion points that there > is no > agreement that the IETF can provide with high probability a RF > codec. > > > I think that only after these topics, which looks to me like > ground rules, > are addressed we can start discussing the content of the charter. > > Roni Even > > > > > -----Original Message----- > > From: Cullen Jennings [mailto:fluffy@cisco.com] > > Sent: Friday, June 26, 2009 9:09 AM > > To: Ron Even > > Cc: codec@ietf.org > > Subject: Re: [codec] Codec BOF approved, much work needed > > > > > > Roni, > > > > The primary goal of this BOF should be collecting the > information that > > helps make an informed decision about if a WG should be formed > or not. > > I certainly did not mean to imply by the agenda that there was any > > assumption that a WG would be formed. > > > > I agree the charter below is far from ideal for collecting this > > information. I'm expecting the agenda to change, based on the list > > discussion, so we have time to talk about the key topics where > > community input is needed to drive the decisions about if a WG > should > > be formed or not. > > > > Cullen > > > > > > On Jun 19, 2009, at 8:59 , Ron Even wrote: > > > > > Cullen, > > > I looked at the agenda > > > > > > 1. Administrative (Chairs, 5 min) > > > - Note takers, Jabber scribes > > > - Agenda bashing > > > > > > 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) > > > > > > 3. Proposed CODECs (TBD, 25 min) > > > - Expect to have two or more drafts here > > > > > > 4. Charter Discussion (All, 40 min) > > > > > > 5. Decisions and HUMs (All, 5 min) > > > > > > 6. Conclusions and Next Steps (Chairs/ADs, 5 min) > > > > > > > > > And it looks to me that it starts with assumption that we > will have > > > a new working group. > > > > > > I am not sure that that this was agreed and yet I see no time > > > allocated to discuss the topic. I would expect that item 3 > will be > > > rational for doing codec at the IETF considering that this > work is > > > done also by other SDOs that the IETF is working with. > > > > > > Now even if there will be such a WG starting with proposed > CODECS is > > > like having a solution before the requirements. In other > standard > > > bodies requirements are not just names but they also have > values. So > > > what is the purpose of proposing codecs, do we need to > select at the > > > BOF which one will be standardize, to me it looks like this > should > > > be done later. > > > > > > Roni Even > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: codec-bounces@ietf.org > [mailto:codec-bounces@ietf.org] On > > > Behalf > > > > Of Cullen Jennings > > > > Sent: Friday, June 12, 2009 8:32 PM > > > > To: codec@ietf.org > > > > Subject: [codec] Codec BOF approved, much work needed > > > > > > > > > > > > I have approved the CODEC BOF proposal. However, we need a > bunch of > > > > work to get ready. Various people on IESG/IAB were not > comfortable > > > > with the current charter and agenda so we need to work on > theses > > > > before the meeting. > > > > > > > > A draft agenda/charter Jason provided are at > > > > > > > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec- > > bof/agenda.txt > > > > > > > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- > > > > bof/charter.txt > > > > > > > > After discussion with the IESG/IAB: > > > > > > > > I'd like to remove the "as Proposed Standard" from the > charter text > > > > for both milestones and see how the discussion goes in the BOF > > > before > > > > deciding which way this should go. > > > > > > > > I'd like to see more consideration around the issues of > designing a > > > > codec that did a good job of mapping a real time stream > onto IP > > > > packets. The way IP deals with packet loss and congestion has > > > > implications for designing a codec that works well over > IP. I know > > > > some of the discussion I have had off list people talked > about how > > > we > > > > wanted a codec that supported adaptive bit rates that > could change > > > on > > > > the fly to be able to work well on an IP network. > > > > > > > > I will be working the folks to make sure the agenda has > time to > > > > directly address the key topics which include (more may be > coming): > > > > > > > > Will we be able to get qualified people to do and review > the work? > > > > > > > > Key design goals of a new codec? > > > > > > > > Do we need a new codec or are there already ones defined > that meet > > > the > > > > needs? > > > > > > > > I have asked Jason Fischl and Jean-Marc Valin to co-chair > this > > BOF. > > > > > > > > Thanks, > > > > > > > > Cullen > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > _______________________________________________ > 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 christer.holmberg@ericsson.com Fri Jun 26 19:47: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 51EDC3A6940 for ; Fri, 26 Jun 2009 19:47:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.493 X-Spam-Level: X-Spam-Status: No, score=-5.493 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_93=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 Ca5Nl2qg1mMv for ; Fri, 26 Jun 2009 19:47:23 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B72D33A6CAE for ; Fri, 26 Jun 2009 19:47:22 -0700 (PDT) X-AuditID: c1b4fb3c-b7bdcae0000052f9-c9-4a45884b4951 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 58.58.21241.B48854A4; Sat, 27 Jun 2009 04:47:39 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sat, 27 Jun 2009 04:47:38 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 27 Jun 2009 04:47:38 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] FW: [AVT] RFC 5574 on RTP Payload Format for the Speex Codec Thread-Index: Acnzlx2AupiQhwLfS7+8oIyFA1upgAAD3XpSAMpiotA= References: <20090623000920.AFDB52D6515@bosco.isi.edu> From: "Christer Holmberg" To: "Henry Sinnreich" , X-OriginalArrivalTime: 27 Jun 2009 02:47:38.0810 (UTC) FILETIME=[A24999A0:01C9F6D1] X-Brightmail-Tracker: AAAAAA== Subject: Re: [codec] FW: [AVT] RFC 5574 on RTP Payload Format for the Speex Codec 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, 27 Jun 2009 02:47:24 -0000 Henry, If there already exists an open-source codec, suitable for VoIP, why do = you need a new one? Regards, Christer ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Henry Sinnreich Sent: Tuesday, June 23, 2009 5:02 AM To: codec@ietf.org Subject: [codec] FW: [AVT] RFC 5574 on RTP Payload Format for the Speex = Codec ------ Forwarded Message From: Date: Mon, 22 Jun 2009 17:09:20 -0700 To: , Cc: , Subject: [AVT] RFC 5574 on RTP Payload Format for the Speex Codec A new Request for Comments is now available in online RFC libraries. =20 RFC 5574 Title: RTP Payload Format for the Speex Codec Author: G. Herlein, J. Valin, A. Heggestad, A. Moizard Status: Standards Track Date: June 2009 Mailbox: gherlein@herlein.com, jean-marc.valin@usherbrooke.ca, aeh@db.org, jack@atosc.org Pages: 14 Characters: 27995 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-rtp-speex-07.txt URL: http://www.rfc-editor.org/rfc/rfc5574.txt Speex is an open-source voice codec suitable for use in VoIP (Voice over IP) type applications. This document describes the payload format for Speex-generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP). [STANDARDS TRACK] This document is a product of the Audio/Video Transport Working Group of = the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and = suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see = http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt ------ End of Forwarded Message From xiphmont@gmail.com Fri Jun 26 19:49:23 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 CDD6D28C135 for ; Fri, 26 Jun 2009 19:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.534 X-Spam-Level: X-Spam-Status: No, score=-2.534 tagged_above=-999 required=5 tests=[AWL=0.065, 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 VLJPv8lFv762 for ; Fri, 26 Jun 2009 19:49:23 -0700 (PDT) Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by core3.amsl.com (Postfix) with ESMTP id 13C463A6920 for ; Fri, 26 Jun 2009 19:49:22 -0700 (PDT) Received: by gxk26 with SMTP id 26so1612176gxk.13 for ; Fri, 26 Jun 2009 19:49:39 -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 :content-transfer-encoding; bh=Tg1NSB4Eq2zXaiTMGVaTL/1UFDle9v9ZfoqKeeDcizs=; b=jl8zQM5PDMa1VnkjLvlFvhc8CqDwUfcRIQjMYLNxrpPl+fNozJOmEkiM77sf4y7f0F tNb+RdHfbjI7SR6/gfDxtGDjLrvLzIaxdcgaHhAm82hyFgqk9JG5aeeQL98Vx0TuPkyO 2Kwk+sO7QLQbM+8heKVfKwU9w0heHnhLLuZxE= 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:content-transfer-encoding; b=DBzroVbW7jNMs8y+vubD6sNxoqVdgh/0fvo74MVlVWRYsOLpxUM0TVgj+bYQ4miT5p ifDd1FrK6s33N6yfP2Oaf2B+fC0WXO+vn5RCsrN4bZ5gANuiZQwRyHZLVc4F7+7AyA4b DPsIcAiHqimLMEHpAcrP/1cPyNqYyXQqUS8jA= MIME-Version: 1.0 Received: by 10.231.34.66 with SMTP id k2mr1534250ibd.19.1246070978751; Fri, 26 Jun 2009 19:49:38 -0700 (PDT) In-Reply-To: References: <20090623000920.AFDB52D6515@bosco.isi.edu> Date: Fri, 26 Jun 2009 22:49:38 -0400 Message-ID: <806dafc20906261949k709025feq76f2143ef180475b@mail.gmail.com> From: Christopher Montgomery To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: codec@ietf.org Subject: Re: [codec] FW: [AVT] RFC 5574 on RTP Payload Format for the Speex Codec 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, 27 Jun 2009 02:49:23 -0000 On Fri, Jun 26, 2009 at 10:47 PM, Christer Holmberg wrote: > Henry, > > If there already exists an open-source codec, suitable for VoIP, why do you need a new one? The terrifying possibility that one might want something good for more than mid-latency VoIP. Monty From ron.even.tlv@gmail.com Sat Jun 27 02:50:55 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 E4CD53A6CF3 for ; Sat, 27 Jun 2009 02:50:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.758 X-Spam-Level: X-Spam-Status: No, score=-1.758 tagged_above=-999 required=5 tests=[AWL=-0.842, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, URIBL_RHS_DOB=1.083] 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 JkVIi55Uiv5l for ; Sat, 27 Jun 2009 02:50:54 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 663DB3A6BC5 for ; Sat, 27 Jun 2009 02:50:54 -0700 (PDT) Received: by fxm18 with SMTP id 18so125771fxm.37 for ; Sat, 27 Jun 2009 02:51:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=+Zs5+dP0k7ZdrS1bUkbMyvp7p0TuYfBA1vzwL5I8TTo=; b=RFdZYqZW9PX3VXe6TrJfIxkVLFn+8hK6ha7K7KBGCZ0KgxuGeZ3US29MuiSGTehnIf az4p1RWDd9FO2yvMmYWEtjGRZAc1r17daV8OghjUE8gAIm64I4zKwdMdqjPUXsyzTIYL KejXFJy8V+pJffaPmYyBVEd5gB+2V/PJqzSMc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=qh0KxXL96b4NpNkbNanm70MyYGgqNv7zJKHyBevqO+0fiWjPPEjx8JrPgM9YnPjf8i nsvNe1LQdPlfdA+KzRAd3zmThQzACIptRkXjLxo5b8teKmXcuW5Pz2bVx754/06Nf2o+ 2qtiGOlslc/iZfWskKcZLK0vpKMk+VGwudHR8= Received: by 10.103.189.15 with SMTP id r15mr2780654mup.126.1246096262633; Sat, 27 Jun 2009 02:51:02 -0700 (PDT) Received: from windows8d787f9 (bzq-79-182-68-39.red.bezeqint.net [79.182.68.39]) by mx.google.com with ESMTPS id g1sm19274400muf.26.2009.06.27.02.51.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 27 Jun 2009 02:51:01 -0700 (PDT) From: "Roni Even" To: "'Christer Holmberg'" , "'Henry Sinnreich'" , References: <20090623000920.AFDB52D6515@bosco.isi.edu> In-Reply-To: Date: Sat, 27 Jun 2009 12:50:47 +0300 Message-ID: <4a45eb85.01b7660a.100e.ffff8499@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acnzlx2AupiQhwLfS7+8oIyFA1upgAAD3XpSAMpiotAADs3C4A== Content-Language: en-us Subject: Re: [codec] FW: [AVT] RFC 5574 on RTP Payload Format for the Speex Codec 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, 27 Jun 2009 09:50:56 -0000 Christer, The IETF work only covers the payload specification not the codec itself. The BOF is to discuss publishing the codec itself as an RFC. I agree that if it is open source and is already being used and wonder why do we need the IETF RFC. I am not sure whether the objective there is to define a new one or publish an existing one or one that being worked by another "open" group as an IETF RFC, the one I see being pushed is the "CELT" done by XIPH.org. You are right that it can be published the same as speex as an open source and the IETF will publish the payload specification. Roni > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: Saturday, June 27, 2009 5:48 AM > To: Henry Sinnreich; codec@ietf.org > Subject: Re: [codec] FW: [AVT] RFC 5574 on RTP Payload Format for the > Speex Codec > > Henry, > > If there already exists an open-source codec, suitable for VoIP, why do > you need a new one? > > Regards, > > Christer > > ________________________________ > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Henry Sinnreich > Sent: Tuesday, June 23, 2009 5:02 AM > To: codec@ietf.org > Subject: [codec] FW: [AVT] RFC 5574 on RTP Payload Format for the Speex > Codec > > > > ------ Forwarded Message > From: > Date: Mon, 22 Jun 2009 17:09:20 -0700 > To: , > Cc: , > Subject: [AVT] RFC 5574 on RTP Payload Format for the Speex Codec > > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 5574 > > Title: RTP Payload Format for the > Speex Codec > Author: G. Herlein, J. Valin, > A. Heggestad, A. Moizard > Status: Standards Track > Date: June 2009 > Mailbox: gherlein@herlein.com, > jean-marc.valin@usherbrooke.ca, > aeh@db.org, jack@atosc.org > Pages: 14 > Characters: 27995 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-avt-rtp-speex-07.txt > > URL: http://www.rfc-editor.org/rfc/rfc5574.txt > > Speex is an open-source voice codec suitable for use in VoIP (Voice > over IP) type applications. This document describes the payload > format for Speex-generated bit streams within an RTP packet. Also > included here are the necessary details for the use of Speex with the > Session Description Protocol (SDP). [STANDARDS TRACK] > > This document is a product of the Audio/Video Transport Working Group > of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc- > editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > USC/Information Sciences Institute > > > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > > ------ End of Forwarded Message > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From stephen.botzko@gmail.com Sat Jun 27 03:38:30 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 562AD3A6B79 for ; Sat, 27 Jun 2009 03:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.357 X-Spam-Level: X-Spam-Status: No, score=-1.357 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MILLIONSOF=0.315, URIBL_RHS_DOB=1.083] 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 9hGphflrcjx1 for ; Sat, 27 Jun 2009 03:38:28 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 00AAC3A6ADC for ; Sat, 27 Jun 2009 03:38:27 -0700 (PDT) Received: by bwz9 with SMTP id 9so2436497bwz.37 for ; Sat, 27 Jun 2009 03:38:44 -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=YRbR6B9gugF457iE9Sc9Dr6ve+5kzOkh2aGoKXI9lgw=; b=onv/GngK2OXn0OionCQDcAVqMEvDXKLU3/y3fl1juZvaxc5ULFUIV7GUpeKk3AKC1r ApqTwOJ+OLeFCvBHqxR/Fj5fkn3tNOPe14BJn5i1o47AkahJHPaSmKxSUgXBFu3q4aEw QpL4vHyLPOD8phRmnZtBjP1DYsf2hN1VkhbRs= 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=SB77f/1EMTArsJoZPVFUOmBMysix9ohnDr0D9AXUP86M/e1HC4nj4I0vdy5c3CBv+k oWTz4wfwxdRAZ3V7s5iZ+Bp+V+Fs0p/MW3VqEiY4bvOCFov0s3m+zoCGGe4z09nNMxNb FkRSA0P9rgNh0nT4Tz/r/Lr480Rj1uDHz9spI= MIME-Version: 1.0 Received: by 10.103.224.2 with SMTP id b2mr2845762mur.30.1246099124109; Sat, 27 Jun 2009 03:38:44 -0700 (PDT) In-Reply-To: <20090626114355.16720yb6jhzzxxij@mail.skype.net> References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> Date: Sat, 27 Jun 2009 06:38:43 -0400 Message-ID: <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> From: stephen botzko To: Koen Vos Content-Type: multipart/alternative; boundary=001636a7d825a5c589046d520fd0 Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 27 Jun 2009 10:38:30 -0000 --001636a7d825a5c589046d520fd0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I am not intenting to preempt Stephan's reply >>> But they've been working well so far, and I just don't see a better alternative to creating free, interoperable technology. >>> (a) generally speaking, there seems to be a lot less interest in patenting (or at least asserting patents) on signaling and transport specifications than for codecs. This applies both to the IETF (SIP for instance), as well as the ITU (H.323). So I sdon't think the "free" component of the above statement is a result of the IETF process differences. If you remove the audio and video codec groups from SG16 (ITU), then you'd find that there is little if any difference in the need to license / pay royalties on the standards produced by the two organizations. >>> Surely all the stakeholders who are today earning royalties would not participate, and therefore have no obligation to disclose related patents (just like with IETF). >>> (b) Source code is disclosed very late in the ITU audio standardization process, making it much more difficult for non-participant attendees to know exactly how the codec functions. So if it unlikely that someone can research/patent improvements ahead of the process. I agree that the obligations to disclose are similar in both organizations, so the obligation to disclose is not an advantage (nor a disadvantage) of the IETF when compared with the ITU. >>> Are you suggesting that ITU could create a royalty free standard? >>> I believe Stephan is saying that Skype (and others) can create a standard in the ITU for which the proposing companines do not charge royalties. G.722.1 is one proof point that this can be done in the ITU, I believe he is also saying (in other posts) that developing a codec which is guaranteed not to infringe any exisitng patents is not possible in either organization. I would concur with both statements. I would be particularly concerned about a working group that requires participants to research other organization's patents - as Stephan indicates, that is against the policies of many corporations because it can result in liability for triple damages in the US. >>> And bear in mind that the ITU process is very expensive - who is going to pay for it if it only means less revenues for the average ITU member? >>> (d) I don't understand what expense you are talking about here. Audio codec standardization requires the proposers of the each codec candidate to pay for the listening tests. ITU membership fees do not depend on what workiing groups you participate in (that is, your membership fees do not go up if you standardize codecs). Are you somehow thinking that ITU members share the codec revemues? The ITU is not a patent pool, and does not license anything. (Neither does the IETF of course). There's been no discussion about who bears the expense of codec qualitifcation tests in the proposed IETF working group, other than some folks expressing a hope that the testimg might be cost less. Stephen Botzko Polycom On Fri, Jun 26, 2009 at 2:43 PM, Koen Vos wrote: > Stephan Wenger: > >> Concluding from the current situation (no litigation around speex that I'm >> aware of, no licensing deal I have heard of) that there are really no >> patents related to that technology, is not really a clever move. >> > > When big companies adopt open technology, they do due diligence to evaluate > the risk of being sued for infringement. Sometimes they may indeed find > patents that are their own, or which they cross-license already, and are > thus no threat to them. Other patents they may overlook. But when enough > large companies adopt an open technology, that (1) reduces the patent risk, > and (2) that creates a powerful body to fight against frivolous patent > claims (as in the SCO case). > > Stephan, no new(ish) technology can ever be guaranteed to avoid patents. > You sound as if open source and IETF standardization are fundamentally > flawed in this regard. But they've been working well so far, and I just > don't see a better alternative to creating free, interoperable technology. > > > However, I concede that the googles of the world have a very different >> business model compared to traditional telco operators or vendors (not so >> certain about skype, but let's skip that discussion :-). >> > > Skype has 100s of millions of downloads per year, the vast majority of > which never brings Skype a cent in revenue. > > > You have not >> convinced me that those players necessarily need a royalty-free codec, but >> if they would, they could make their voices easily heard in the >> traditional >> venues. Everyone listens to google, and everyone smart in the Telco >> industry listens to Skype, considering their respective successes. >> > > Are you suggesting that ITU could create a royalty free standard? Many ITU > stakeholders have big interests in avoiding exactly that. They have invested > lots of R&D in this area and are now earning this back through their current > standard codecs. Some of them even depend on codec royalties for their > existence. And bear in mind that the ITU process is very expensive - who is > going to pay for it if it only means less revenues for the average ITU > member? But most importantly, even if ITU would try to standardize a royalty > free codec, why would that codec have any less risk of infringing patents? > Surely all the stakeholders who are today earning royalties would not > participate, and therefore have no obligation to disclose related patents > (just like with IETF). > http://www.itu.int/ITU-T/dbase/patent/patent-policy.html > > best, > koen. > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636a7d825a5c589046d520fd0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I am not intenting to preempt Stephan's reply

>>>
Bu= t they've been working well so far, and I just don't see a better a= lternative to creating free, interoperable technology.
>>>

(a) generally speaking, there seems to be a lot less interest in patent= ing (or at least asserting patents) on signaling and transport specificatio= ns than for codecs.=A0 This applies both to the IETF (SIP for instance), as= well as the ITU (H.323).=A0 So I sdon't think the "free" com= ponent of the above statement is a result of the IETF process differences.= =A0

If you remove the audio and video codec groups from SG16 (ITU), then yo= u'd find that there is little if any difference in the need to license = / pay royalties on the standards produced by the two organizations.

>>>
Surely all the stakeholders who are today earning royal= ties would not participate, and therefore have no obligation to disclose related patents (just like with IETF).
>>>
(b) Source code is disclo= sed very late in the ITU audio standardization process, making it much more= difficult for non-participant attendees to know exactly how the codec func= tions.=A0 So if it unlikely that someone can research/patent improvements a= head of the process.

I agree that the obligations to disclose are similar in both organizati= ons, so the obligation to disclose is not an advantage (nor a disadvantage)= of the IETF when compared with the ITU.

>>>
Are you sug= gesting that ITU could create a royalty free standard?
>>>
I believe Stephan is saying that Skype (and others) can cre= ate a standard in the ITU for which the proposing companines do not charge = royalties.=A0 G.722.1 is one proof point that this can be done in the ITU,<= br>
I believe he is also saying (in other posts) that developing a codec wh= ich is guaranteed not to infringe any exisitng patents is not possible in e= ither organization.=A0 I would concur with both statements.=A0 I would be p= articularly concerned about a working group that requires participants to r= esearch other organization's patents - as Stephan indicates, that is ag= ainst the policies of many corporations because it can result in liability = for triple damages in the US.

>>>
And bear in mind that the ITU process is very expensive= - who is going to pay for it if it only means less revenues for the average ITU member?>>>
(d) I don't understand what expense you are talking ab= out here.=A0 Audio codec standardization requires the proposers of the each= codec candidate to pay for the listening tests.=A0 ITU membership fees do = not depend on what workiing groups you participate in (that is, your member= ship fees do not go up if you standardize codecs).=A0 Are you somehow think= ing that ITU members share the codec revemues?=A0 The ITU is not a patent p= ool, and does not license anything.=A0 (Neither does the IETF of course).
There's been no discussion about who bears the expense of codec qua= litifcation tests in the proposed IETF working group, other than some folks= expressing a hope that the testimg might be cost less.

Stephen Botz= ko
Polycom

On Fri, Jun 26, 2009 at 2:43 PM, Koen Vos <koen.vos@skype.net> wrote:
Stephan Wenger:

Concluding from the current situation (no litigation around speex that I= 9;m
aware of, no licensing deal I have heard of) that there are really no
patents related to that technology, is not really a clever move.

When big companies adopt open technology, they do due diligence to evaluate= the risk of being sued for infringement. Sometimes they may indeed find pa= tents that are their own, or which they cross-license already, and are thus= no threat to them. Other patents they may overlook. But when enough large = companies adopt an open technology, that (1) reduces the patent risk, and (= 2) that creates a powerful body to fight against frivolous patent claims (a= s in the SCO case).

Stephan, no new(ish) technology can ever be guaranteed to avoid patents. Yo= u sound as if open source and IETF standardization are fundamentally flawed= in this regard. But they've been working well so far, and I just don&#= 39;t see a better alternative to creating free, interoperable technology.


However, I concede that the googles of the world have a very different
business model compared to traditional telco operators or vendors (not so certain about skype, but let's skip that discussion :-).

Skype has 100s of millions of downloads per year, the vast majority of whic= h never brings Skype a cent in revenue.



You have not
convinced me that those players necessarily need a royalty-free codec, but<= br> if they would, they could make their voices easily heard in the traditional=
venues. =A0Everyone listens to google, and everyone smart in the Telco
industry listens to Skype, considering their respective successes.

Are you suggesting that ITU could create a royalty free standard? Many ITU = stakeholders have big interests in avoiding exactly that. They have investe= d lots of R&D in this area and are now earning this back through their = current standard codecs. Some of them even depend on codec royalties for th= eir existence. And bear in mind that the ITU process is very expensive - wh= o is going to pay for it if it only means less revenues for the average ITU= member? But most importantly, even if ITU would try to standardize a royal= ty free codec, why would that codec have any less risk of infringing patent= s? Surely all the stakeholders who are today earning royalties would not pa= rticipate, and therefore have no obligation to disclose related patents (ju= st like with IETF).
http://www.itu.int/ITU-T/dbase/patent/patent-policy.html
best,
koen.

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

--001636a7d825a5c589046d520fd0-- From rjesup@wgate.com Sat Jun 27 11:40:17 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 B0F063A6CBB for ; Sat, 27 Jun 2009 11:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.651 X-Spam-Level: X-Spam-Status: No, score=-1.651 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.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 TPUnOADIE1Ak for ; Sat, 27 Jun 2009 11:40:17 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id C34073A6C89 for ; Sat, 27 Jun 2009 11:40:16 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 27 Jun 2009 14:40:22 -0400 To: stephen botzko References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> From: Randell Jesup Date: Sat, 27 Jun 2009 14:41:09 -0400 In-Reply-To: <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> (stephen botzko's message of "Sat\, 27 Jun 2009 06\:38\:43 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 27 Jun 2009 18:40:22.0479 (UTC) FILETIME=[BA7D45F0:01C9F756] Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup 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, 27 Jun 2009 18:40:17 -0000 stephen botzko writes: >>>> >Are you suggesting that ITU could create a royalty free standard? >>>> >I believe Stephan is saying that Skype (and others) can create a standard in >the ITU for which the proposing companines do not charge royalties. G.722.1 >is one proof point that this can be done in the ITU, Sure - but that's not what's being proposed/discussed here. That's been done in IETF as well with iLBC. >I believe he is also saying (in other posts) that developing a codec which >is guaranteed not to infringe any exisitng patents is not possible in either >organization. I would concur with both statements. I would be particularly >concerned about a working group that requires participants to research other >organization's patents - as Stephan indicates, that is against the policies >of many corporations because it can result in liability for triple damages >in the US. Who would do that in ITU, or would it simply be assumed that the proposing entity had dealt with it (if needed), and the RAND requirement covered their patents? Wouldn't the issues be pretty much the same? Even if IETF has not RAND requirement, there are IPR disclosure requirements, and the (likely) royalty/licensing status can be part of the evaluation/selection/development. >>>> >And bear in mind that the ITU process is very expensive - who is going to >pay for it if it only means less revenues for the average ITU member? >>>> >(d) I don't understand what expense you are talking about here. Audio codec >standardization requires the proposers of the each codec candidate to pay >for the listening tests. ITU membership fees do not depend on what workiing >groups you participate in (that is, your membership fees do not go up if you >standardize codecs). Are you somehow thinking that ITU members share the >codec revemues? The ITU is not a patent pool, and does not license >anything. (Neither does the IETF of course). "proposer pays" makes sense for an all-industry, royalty-generating standards organization where it's a selection group, but it does no group "development" or testing. The proposer stands to benefit monetarily in most cases. In an organization where individuals often participate, and proposals may be group efforts or incorporate input from many sources, this may not be a reasonable way to proceed. As for the cost, as I said before, I'm not able/willing to pay the cost of participating in ITU groups as an individual - even if one of the groups you have to go through would allow me in. IETF participation is much more free-form, individual, and without hurdles to participation. >There's been no discussion about who bears the expense of codec >qualitifcation tests in the proposed IETF working group, other than some >folks expressing a hope that the testimg might be cost less. Well worth discussing, not just costs but also what's needed to accomplish the goals. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From hsinnrei@adobe.com Sat Jun 27 12:37:56 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 805E53A6AAF for ; Sat, 27 Jun 2009 12:37:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=-1.189, BAYES_00=-2.599, FRT_ADOBE2=2.455, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083] 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 O3XfRy2++DS2 for ; Sat, 27 Jun 2009 12:37:48 -0700 (PDT) Received: from psmtp.com (exprod6ob109.obsmtp.com [64.18.1.22]) by core3.amsl.com (Postfix) with ESMTP id BD7613A6870 for ; Sat, 27 Jun 2009 12:37:47 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob109.postini.com ([64.18.5.12]) with SMTP ID DSNKSkZ1Get/8syhrNl82YWt7pXMU1wdAXzU@postini.com; Sat, 27 Jun 2009 12:38:08 PDT Received: from inner-relay-1.corp.adobe.com ([153.32.1.51]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5RJbvWG013534; Sat, 27 Jun 2009 12:37:58 -0700 (PDT) Received: from nahub02.corp.adobe.com (nahub02.corp.adobe.com [10.8.189.98]) by inner-relay-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5RJbuiq019749; Sat, 27 Jun 2009 12:37:56 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub02.corp.adobe.com ([10.8.189.98]) with mapi; Sat, 27 Jun 2009 12:37:56 -0700 From: Henry Sinnreich To: Stephan Wenger , Roni Even , Cullen Jennings Date: Sat, 27 Jun 2009 12:37:52 -0700 Thread-Topic: [codec] Codec BOF approved, much work needed Thread-Index: Acn2JJ4wfm1mrNCXSBaPJNxVOyk89wACqJoQABnx1FoAB05lBgAqoEUP Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C66BDF40461Chsinnreiadobecom_" MIME-Version: 1.0 Cc: "codec@ietf.org" Subject: Re: [codec] Codec BOF approved, much work needed 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, 27 Jun 2009 19:37:56 -0000 --_000_C66BDF40461Chsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Stephan, The idea of summarizing the discussion is excellent IMO. Humming is not a good idea since it favors people with a travel budget to a= ttend, and also IMO favors groupthink. When the demographics of attendees favors incumbent codec vendors, I like i= t even less :-) Henry On 6/26/09 6:17 PM, "Stephan Wenger" wrote: Hi Henry, as you probably expect, I disagree. It's not a waste of BOF time to discus= s whether the IETF should "work on codecs". However, I agree that this asp= ect has received recently significant, probably even adequate, coverage on = the list, and unorganized repetition of the same arguments would not be ove= rly helpful, nor time-efficient. Why not have the chairs, or the AD, summa= rize the discussion here, and take an early humm on that question? Alterna= tively, have the BOF hearing one advocate in favor, and one against, and th= en take a humm? Stephan On 6/26/09 12:48 PM, "Henry Sinnreich" wrote: Cullen, Roni Even wrote >>1. Should the IETF work on codecs? These arguments have been repeated countless time on the list. There is not reason to waste precious BOF face-to-face time by regurgitati= ng them again. It definitely has the appearance legacy codec people will go to great lengt= h to keep newcomers out; and suppress even discussing the potential Interne= t and software technologies that could innovate voice codecs for use on the= Internet. Take for example the usage scenario of rich internet applications in the br= owser and/or desktop. Countless new applications, business models and software development techni= ques for the web have made legacy codecs undesirable or even inapplicable f= or such as enabling voice for content providers, social networks, any type = of business imaginable and for no-profits alike. Especially for non-profits= . For example, web sites for broadcasting sport events, political events or s= ocial network can have huge traffic surges that are often completely event = driven. Traffic may practically disappear after the event. Nobody can also predict the success (or otherwise) and traffic for any web = site or web based service. Moreover, nobody expects to pay for a browser and plug-ins. 1. Business models are different than they were for legacy codecs, 2. Technology is also vastly different, from every facet. Let the agenda for the BOF explore and inform about this potential, though I understand the stake legacy codec people have to suppress this inf= ormation in the first place. (My individual contributor hat on) Henry On 6/26/09 2:39 AM, "Roni Even" wrote: Cullen, Thanks, If I may, I would like to suggest based on my observations on the list discussion that the agenda will also include the following topics. 1. Should the IETF work on codecs (speech/audio) 2. If yes, should the these codecs be standard track or informational. I am suggesting this item since as far as I understand after iLBC publication th= e conclusion was that the IETF cannot do expert review on codecs even for Informational status. 3. If the IETF will do standard track, Is the prerequisite to qualify for approval is Royalty Free. The list discussion points that there is no agreement that the IETF can provide with high probability a RF codec. I think that only after these topics, which looks to me like ground rules, are addressed we can start discussing the content of the charter. Roni Even > -----Original Message----- > From: Cullen Jennings [mailto:fluffy@cisco.com] > Sent: Friday, June 26, 2009 9:09 AM > To: Ron Even > Cc: codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > > Roni, > > The primary goal of this BOF should be collecting the information that > helps make an informed decision about if a WG should be formed or not. > I certainly did not mean to imply by the agenda that there was any > assumption that a WG would be formed. > > I agree the charter below is far from ideal for collecting this > information. I'm expecting the agenda to change, based on the list > discussion, so we have time to talk about the key topics where > community input is needed to drive the decisions about if a WG should > be formed or not. > > Cullen > > > On Jun 19, 2009, at 8:59 , Ron Even wrote: > > > Cullen, > > I looked at the agenda > > > > 1. Administrative (Chairs, 5 min) > > - Note takers, Jabber scribes > > - Agenda bashing > > > > 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min) > > > > 3. Proposed CODECs (TBD, 25 min) > > - Expect to have two or more drafts here > > > > 4. Charter Discussion (All, 40 min) > > > > 5. Decisions and HUMs (All, 5 min) > > > > 6. Conclusions and Next Steps (Chairs/ADs, 5 min) > > > > > > And it looks to me that it starts with assumption that we will have > > a new working group. > > > > I am not sure that that this was agreed and yet I see no time > > allocated to discuss the topic. I would expect that item 3 will be > > rational for doing codec at the IETF considering that this work is > > done also by other SDOs that the IETF is working with. > > > > Now even if there will be such a WG starting with proposed CODECS is > > like having a solution before the requirements. In other standard > > bodies requirements are not just names but they also have values. So > > what is the purpose of proposing codecs, do we need to select at the > > BOF which one will be standardize, to me it looks like this should > > be done later. > > > > Roni Even > > > > > > > > > > > -----Original Message----- > > > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On > > Behalf > > > Of Cullen Jennings > > > Sent: Friday, June 12, 2009 8:32 PM > > > To: codec@ietf.org > > > Subject: [codec] Codec BOF approved, much work needed > > > > > > > > > I have approved the CODEC BOF proposal. However, we need a bunch of > > > work to get ready. Various people on IESG/IAB were not comfortable > > > with the current charter and agenda so we need to work on theses > > > before the meeting. > > > > > > A draft agenda/charter Jason provided are at > > > > > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec- > bof/agenda.txt > > > > > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec- > > > bof/charter.txt > > > > > > After discussion with the IESG/IAB: > > > > > > I'd like to remove the "as Proposed Standard" from the charter text > > > for both milestones and see how the discussion goes in the BOF > > before > > > deciding which way this should go. > > > > > > I'd like to see more consideration around the issues of designing a > > > codec that did a good job of mapping a real time stream onto IP > > > packets. The way IP deals with packet loss and congestion has > > > implications for designing a codec that works well over IP. I know > > > some of the discussion I have had off list people talked about how > > we > > > wanted a codec that supported adaptive bit rates that could change > > on > > > the fly to be able to work well on an IP network. > > > > > > I will be working the folks to make sure the agenda has time to > > > directly address the key topics which include (more may be coming): > > > > > > Will we be able to get qualified people to do and review the work? > > > > > > Key design goals of a new codec? > > > > > > Do we need a new codec or are there already ones defined that meet > > the > > > needs? > > > > > > I have asked Jason Fischl and Jean-Marc Valin to co-chair this > BOF. > > > > > > Thanks, > > > > > > Cullen > > > > > > > > > > > > > > > > > > _______________________________________________ > > > 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 ________________________________ _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec --_000_C66BDF40461Chsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] Codec BOF approved, much work needed Stephan,

The idea of summarizing the discussion is excellent IMO.

Humming is not a good idea since it favors people with a travel budget to a= ttend,
and also IMO favors groupthink.
When the demographics of attendees favors incumbent codec vendors, I like i= t even less :-)

Henry


On 6/26/09 6:17 PM, "Stephan Wenger" <stewe@stewe.org> wrote:

Hi Henry,

as you probably expect, I disagree.  It’s not a waste of BOF tim= e to discuss whether the IETF should “work on codecs”.  Ho= wever, I agree that this aspect has received recently significant, probably= even adequate, coverage on the list, and unorganized repetition of the sam= e arguments would not be overly helpful, nor time-efficient.  Why not = have the chairs, or the AD, summarize the discussion here, and take an earl= y humm on that question?  Alternatively, have the BOF hearing one advo= cate in favor, and one against, and then take a humm?  
Stephan





On 6/26/09 12:48 PM, "Henry Sinnreich" <hsinnrei@adobe.com> wrote:

Cullen,

Roni Even wrote
>>1. Should the IETF work on codecs?

These arguments have been repeated countless time on the list.
 There is not reason to waste precious BOF face-to-face time by regurg= itating them again.
It definitely has the appearance legacy codec people will go to great lengt= h to keep newcomers out; and suppress even discussing the potential Interne= t and software technologies that could innovate voice codecs for use on the= Internet.  

Take for example the usage scenario of rich internet applications in the br= owser and/or desktop.
Countless new applications, business models and software development techni= ques for the web have made legacy codecs undesirable or even inapplicable f= or such as enabling voice for content providers, social networks, any type = of business imaginable and for no-profits alike. Especially for non-profits= .

For example, web sites for broadcasting sport events, political events or s= ocial network can have huge traffic surges that are often completely event = driven. Traffic may practically disappear after the event.

Nobody can also predict the success (or otherwise) and traffic for any web = site or web based service.
Moreover, nobody expects to pay for a browser and plug-ins.

  1. Business models are different than they were fo= r legacy codecs,=20
  2. Technology is also vastly different, from every fac= et.

Let the agenda for the BOF explore and inform about this potential,
though I understand the stake legacy codec people have to suppress this inf= ormation in the first place.

(My individual contributor hat on)
Henry


On 6/26/09 2:39 AM, "Roni Even" <ron.even.tlv@gmail.com> wrote:

Cullen,
Thanks,
If I may, I would like to suggest based on my observations on the list
discussion that the agenda will also include the following topics.

1. Should the IETF work on codecs (speech/audio)
2. If yes, should the these codecs be standard track or informational. I am=
suggesting this item since as far as I understand after iLBC publication th= e
conclusion was that the IETF cannot do expert review on codecs even for
Informational status.

3. If the IETF will do standard track, Is the prerequisite to qualify for approval is Royalty Free. The list discussion points that there is no
agreement that the IETF can provide with high probability a RF codec.


I think that only after these topics, which looks to me like ground rules,<= BR> are addressed we can start discussing the content of the charter.

Roni Even



> -----Original Message-----
> From: Cullen Jennings [mailto:fluf= fy@cisco.com]
> Sent: Friday, June 26, 2009 9:09 AM
> To: Ron Even
> Cc: codec@ietf.org
> Subject: Re: [codec] Codec BOF approved, much work needed
>
>
> Roni,
>
> The primary goal of this BOF should be collecting the information that=
> helps make an informed decision about if a WG should be formed or not.=
> I certainly did not mean to imply by the agenda that there was any
> assumption that a WG would be formed.
>
> I agree the charter below is far from ideal for collecting this
> information. I'm expecting the agenda to change, based on the list
> discussion, so we have time to talk about the key topics where
> community input is needed to drive the decisions about if a WG should<= BR> > be formed or not.
>
> Cullen <RAI AD>
>
>
> On Jun 19, 2009, at 8:59 , Ron Even wrote:
>
> > Cullen,
> > I looked at the agenda
> >
> > 1. Administrative (Chairs, 5 min)
> >   - Note takers, Jabber scribes
> >   - Agenda bashing
> >
> > 2. Introduction and Scoping of BOF (Chairs/ADs, 15 min)
> >
> > 3. Proposed CODECs (TBD, 25 min)
> >   - Expect to have two or more drafts here
> >
> > 4. Charter Discussion (All, 40 min)
> >
> > 5. Decisions and HUMs (All, 5 min)
> >
> > 6. Conclusions and Next Steps (Chairs/ADs, 5 min)
> >
> >
> > And it looks to me that it starts with assumption that we will ha= ve
> > a new working group.
> >
> > I am not sure that that this was agreed and yet I see no time
> > allocated to discuss the topic. I would expect that item 3 will b= e
> > rational for doing codec at the IETF considering that this work i= s
> > done also by other SDOs that the IETF is working with.
> >
> > Now even if there will be such a WG starting with proposed CODECS= is
> > like having a solution before the requirements. In other standard=
> > bodies requirements are not just names but they also have values.= So
> > what is the purpose of proposing codecs, do we need to select at = the
> > BOF which one will be standardize, to me it looks like this shoul= d
> > be done later.
> >
> > Roni Even
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: codec-bounces@ietf.= org [mailto:codec-bounces@iet= f.org] On
> > Behalf
> > > Of Cullen Jennings
> > > Sent: Friday, June 12, 2009 8:32 PM
> > > To: codec@ietf.org
> > > Subject: [codec] Codec BOF approved, much work needed
> > >
> > >
> > > I have approved the CODEC BOF proposal. However, we need a b= unch of
> > > work to get ready.  Various people on IESG/IAB were not= comfortable
> > > with the current charter and agenda so we need to work on th= eses
> > > before the meeting.
> > >
> > > A draft agenda/charter Jason provided are at
> > >
> > > Agenda: http://svn.resiprocate.org/rep/ietf-drafts/codec-
> bof/agenda.txt
> > >
> > > Charter: http://svn.resiprocate.org/rep/ietf-drafts/codec-
> > > bof/charter.txt
> > >
> > > After discussion with the IESG/IAB:
> > >
> > > I'd like to remove the "as Proposed Standard" from= the charter text
> > > for both milestones and see how the discussion goes in the B= OF
> > before
> > > deciding which way this should go.
> > >
> > > I'd like to see more consideration around the issues of desi= gning a
> > > codec that did a good job of mapping a real time stream onto= IP
> > > packets. The way IP deals with packet loss and congestion ha= s
> > > implications for designing a codec that works well over IP. = I know
> > > some of the discussion I have had off list people talked abo= ut how
> > we
> > > wanted a codec that supported adaptive bit rates that could = change
> > on
> > > the fly to be able to work well on an IP network.
> > >
> > > I will be working the folks to make sure the agenda has time= to
> > > directly address the key topics which include (more may be c= oming):
> > >
> > > Will we be able to get qualified people to do and review the= work?
> > >
> > > Key design goals of a new codec?
> > >
> > > Do we need a new codec or are there already ones defined tha= t meet
> > the
> > > needs?
> > >
> > > I have asked Jason Fischl  and Jean-Marc Valin to co-ch= air this
> BOF.
> > >
> > > Thanks,
> > >
> > > Cullen <RAI AD>
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > codec mailing list
> > > codec@ietf.org
> > > http= s://www.ietf.org/mailman/listinfo/codec
> > _______________________________________________
> > codec mailing list
> > codec@ietf.org
> > https://w= ww.ietf.org/mailman/listinfo/codec

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


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

--_000_C66BDF40461Chsinnreiadobecom_-- From hsinnrei@adobe.com Sat Jun 27 12:47:57 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 3A77B28C102 for ; Sat, 27 Jun 2009 12:47:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.124 X-Spam-Level: X-Spam-Status: No, score=-5.124 tagged_above=-999 required=5 tests=[AWL=-0.209, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083] 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 MYTKzqimeM-m for ; Sat, 27 Jun 2009 12:47:55 -0700 (PDT) Received: from exprod6og105.obsmtp.com (exprod6og105.obsmtp.com [64.18.1.189]) by core3.amsl.com (Postfix) with ESMTP id C54263A69D9 for ; Sat, 27 Jun 2009 12:47:54 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob105.postini.com ([64.18.5.12]) with SMTP ID DSNKSkZ3e1h2InVCnILf/zzXJBgmJzWGxzqL@postini.com; Sat, 27 Jun 2009 12:48:14 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5RJm8WG013760; Sat, 27 Jun 2009 12:48:09 -0700 (PDT) Received: from nahub01.corp.adobe.com (nahub01.corp.adobe.com [10.8.189.97]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5RJm7lT020495; Sat, 27 Jun 2009 12:48:07 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nahub01.corp.adobe.com ([10.8.189.97]) with mapi; Sat, 27 Jun 2009 12:48:07 -0700 From: Henry Sinnreich To: Christer Holmberg , "codec@ietf.org" Date: Sat, 27 Jun 2009 12:48:06 -0700 Thread-Topic: [codec] FW: [AVT] RFC 5574 on RTP Payload Format for the Speex Codec Thread-Index: Acnzlx2AupiQhwLfS7+8oIyFA1upgAAD3XpSAMpiotAAJASm/Q== Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C66BE1A64620hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] FW: [AVT] RFC 5574 on RTP Payload Format for the Speex Codec 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, 27 Jun 2009 19:47:57 -0000 --_000_C66BE1A64620hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Christer, There is more than VoIP audio on the Internet, for example: Telepresence (enterprise) and the Digital Living Room (consumer) are just = emerging. Both require highest quality, stereo, wideband interactive A/V an= d the applications have some very different requirements, for example, inst= ead of cancelling out surrounding noise, people may want to share a concert= during a communication session as well. Henry On 6/26/09 9:47 PM, "Christer Holmberg" wr= ote: Henry, If there already exists an open-source codec, suitable for VoIP, why do you= need a new one? Regards, Christer ________________________________ From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of H= enry Sinnreich Sent: Tuesday, June 23, 2009 5:02 AM To: codec@ietf.org Subject: [codec] FW: [AVT] RFC 5574 on RTP Payload Format for the Speex Cod= ec ------ Forwarded Message From: Date: Mon, 22 Jun 2009 17:09:20 -0700 To: , Cc: , Subject: [AVT] RFC 5574 on RTP Payload Format for the Speex Codec A new Request for Comments is now available in online RFC libraries. RFC 5574 Title: RTP Payload Format for the Speex Codec Author: G. Herlein, J. Valin, A. Heggestad, A. Moizard Status: Standards Track Date: June 2009 Mailbox: gherlein@herlein.com, jean-marc.valin@usherbrooke.ca, aeh@db.org, jack@atosc.org Pages: 14 Characters: 27995 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-avt-rtp-speex-07.txt URL: http://www.rfc-editor.org/rfc/rfc5574.txt Speex is an open-source voice codec suitable for use in VoIP (Voice over IP) type applications. This document describes the payload format for Speex-generated bit streams within an RTP packet. Also included here are the necessary details for the use of Speex with the Session Description Protocol (SDP). [STANDARDS TRACK] This document is a product of the Audio/Video Transport Working Group of th= e IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team USC/Information Sciences Institute _______________________________________________ Audio/Video Transport Working Group avt@ietf.org https://www.ietf.org/mailman/listinfo/avt ------ End of Forwarded Message --_000_C66BE1A64620hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] FW: [AVT] RFC 5574 on RTP Payload Format for the Speex C= odec Christer,

There is more than VoIP audio on the Internet, for example:
 Telepresence (enterprise) and the Digital Living Room (consumer) are = just emerging. Both require highest quality, stereo, wideband interactive A= /V and the applications have some very different requirements, for example,= instead of cancelling out surrounding noise, people may want to share a co= ncert during a communication session as well.

Henry


On 6/26/09 9:47 PM, "Christer Holmberg" <christer.holmberg@ericsson.com> wrote:

Henry,

If there already exists an open-source codec, suitable for VoIP, why do you= need a new one?

Regards,

Christer

________________________________

From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On B= ehalf Of Henry Sinnreich
Sent: Tuesday, June 23, 2009 5:02 AM
To: codec@ietf.org
Subject: [codec] FW: [AVT] RFC 5574 on RTP Payload Format for the Speex Cod= ec



------ Forwarded Message
From: <rfc-editor@rfc-editor.org>
Date: Mon, 22 Jun 2009 17:09:20 -0700
To: <ietf-announce@ietf.org>, = <rfc-dist@rfc-editor.org>
Cc: <avt@ietf.org>, <rfc-editor@rfc-editor.org>
Subject: [AVT] RFC 5574 on RTP Payload Format for the Speex Codec



A new Request for Comments is now available in online RFC libraries.

      
        RFC 5574

        Title:    &n= bsp; RTP Payload Format for the
            &nb= sp;       Speex Codec
        Author:    &= nbsp;G. Herlein, J. Valin,
            &nb= sp;       A. Heggestad, A. Moizard
        Status:    &= nbsp;Standards Track
        Date:    &nb= sp;  June 2009
        Mailbox:    = gherlein@herlein.com,
            &nb= sp;       jean-marc.valin@usherbrooke.ca,
            &nb= sp;       aeh@db.= org, jack@atosc.org
        Pages:    &n= bsp; 14
        Characters: 27995
        Updates/Obsoletes/SeeAlso: =   None

        I-D Tag:    = draft-ietf-avt-rtp-speex-07.txt

        URL:    &nbs= p;   h= ttp://www.rfc-editor.org/rfc/rfc5574.txt

Speex is an open-source voice codec suitable for use in VoIP (Voice
over IP) type applications.  This document describes the payload
format for Speex-generated bit streams within an RTP packet.  Also
included here are the necessary details for the use of Speex with the
Session Description Protocol (SDP).  [STANDARDS TRACK]

This document is a product of the Audio/Video Transport Working Group of th= e IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions=
for improvements.  Please refer to the current edition of the Internet=
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  = http://www.ietf.org/mailman/listinfo/ietf-announce
  http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html.
For downloading RFCs, see ht= tp://www.rfc-editor.org/rfc.html.

Requests for special distribution should be addressed to either the
author of the RFC in question, or to = rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
USC/Information Sciences Institute


_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www.ietf.org/= mailman/listinfo/avt


------ End of Forwarded Message



--_000_C66BE1A64620hsinnreiadobecom_-- From koen.vos@skype.net Sat Jun 27 14:10: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 26B6E3A6ADC for ; Sat, 27 Jun 2009 14:10:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.277 X-Spam-Level: X-Spam-Status: No, score=-6.277 tagged_above=-999 required=5 tests=[AWL=0.322, 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 iegkhxDLwerq for ; Sat, 27 Jun 2009 14:10:34 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id EA7943A68CF for ; Sat, 27 Jun 2009 14:10:33 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id BCF6D2007AAD1 for ; Sat, 27 Jun 2009 23:10:51 +0200 (CEST) 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=1rAVgKjmodn1 u/+0MHv4bzg8Eu8=; b=k1uTaaOuexD3ag+NT4rF1fsKDHKx6uGMxlJJyWgoYL/V 8kEujCOYUEKulNfSz2ivdUqYoYOBeTXUYZjsFAikS0cnbhF/g6mMD7B9FM+fTljE Pg0x7uv6uBA06M2dGEH5yuhlskCBgCPyko7xIr6nvMcDxBDu82tvuPqfdPiRgjQ= 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=GEDT2Fqhj72zyvKhj7Um 2uxa3jYY+623fTU1D6DJJFNuJJBD2j4cNC3EfucWrHcnwL5z1c7SfgB35B3iTWvW SeXxHQPtZHRxYdW+eLWeYtqbyNVQdQaXzRKTJUo7/3MsV455KDFXfNdSf+/rSNQo gY+jxMrlR8YIMTFYArjXqqA= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id BB7DB2007AACA for ; Sat, 27 Jun 2009 23:10:51 +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 K2VNFW53AjID for ; Sat, 27 Jun 2009 23:10:50 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id C1DE62007A948; Sat, 27 Jun 2009 23:10:50 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Sat, 27 Jun 2009 14:10:50 -0700 Message-ID: <20090627141050.72075gnkxrgkelzu@mail.skype.net> Date: Sat, 27 Jun 2009 14:10:50 -0700 From: Koen Vos To: codec@ietf.org References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> In-Reply-To: <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> 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] Codec BOF approved, much work needed 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, 27 Jun 2009 21:10:35 -0000 Quoting stephen botzko: > If you remove the audio and video codec groups from SG16 (ITU), then you'd > find that there is little if any difference in the need to license / pay > royalties on the standards produced by the two organizations. The last time ITU came up with a free speech/audio codec was in 1972 with G.711. Since then, all codecs, including G.722 and G.722.1, were standardized as non-free, royalty-bearing codecs. G.722.1 was only made available free of royalties 7 years after being standardized. > (b) Source code is disclosed very late in the ITU audio standardization > process, making it much more difficult for non-participant attendees to know > exactly how the codec functions. So if it unlikely that someone can > research/patent improvements ahead of the process. The ITU process has a natural tendency to come up with technology that is covered by patents from many of the stakeholders. This lubricates the process of reaching agreement. Take for example G.723.1, which is an inelegant combination of MPC-MLQ 6.3 kbps and ACELP 5.3 kbps. The ACELP mode is so much inferior to the MPC-MLQ mode that it's never used. The only reason it's in there is that the patent owners of ACELP wouldn't agree to the standard unless their technology was part of it. best, koen. From ron.even.tlv@gmail.com Sat Jun 27 15:04: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 253843A6A4F for ; Sat, 27 Jun 2009 15:04:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.777 X-Spam-Level: X-Spam-Status: No, score=-1.777 tagged_above=-999 required=5 tests=[AWL=-0.261, BAYES_00=-2.599, URIBL_RHS_DOB=1.083] 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 OkK54M4IBq3E for ; Sat, 27 Jun 2009 15:04:58 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id D73B43A68E1 for ; Sat, 27 Jun 2009 15:04:57 -0700 (PDT) Received: by fxm18 with SMTP id 18so320537fxm.37 for ; Sat, 27 Jun 2009 15:05:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:references :in-reply-to:subject:date:message-id:mime-version:content-type :content-transfer-encoding:x-mailer:thread-index:content-language; bh=+elxbuQtqm7pyfhdfqcMEfp3JlBRGBaa9MJBFTmwoKQ=; b=MfgQJjsgXLBgYkVoUyIskykqUQxsobGJVaFjeg6jyQHEzTThDqDeUnwgs83Pg57s4z Otn3+d527rbYS++8X/gUHJJuR5U9ZMUoN75Nm+Rz4LylajKYFn9gVNVRDtkmZrVFvkHp linz7zJnd4Y4u9QKwOomxvc268RKSP+o/T8tQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:content-transfer-encoding:x-mailer:thread-index :content-language; b=ByJ1i88xKtvq3/Xe+lFJFJLdVE7c/4u7oiPD1yOcEA8j13JheqyB1oRFm7dQwp4MDW /j6h3s/AFYci+jD1yBPxXLdNN3PBZfGbdrA07tw4KGAotyASuOMvtISnzVnPWDLj2eCX et+FgjA7ogTAGJS/A00cwnX+sEmySyGkTZWMk= Received: by 10.103.1.5 with SMTP id d5mr3105241mui.113.1246140312180; Sat, 27 Jun 2009 15:05:12 -0700 (PDT) Received: from windows8d787f9 (bzq-79-182-68-39.red.bezeqint.net [79.182.68.39]) by mx.google.com with ESMTPS id s11sm13921464mue.11.2009.06.27.15.05.10 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 27 Jun 2009 15:05:11 -0700 (PDT) From: "Roni Even" To: "'Koen Vos'" , References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> In-Reply-To: <20090627141050.72075gnkxrgkelzu@mail.skype.net> Date: Sun, 28 Jun 2009 01:04:49 +0300 Message-ID: <4a469797.0baa660a.1091.ffff9ad0@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn3a8VFnexGafXySi+wnMhjA5P2fAABftSw Content-Language: en-us Subject: Re: [codec] Codec BOF approved, much work needed 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, 27 Jun 2009 22:04:59 -0000 Koen, Standard bodies make decision by consensus, so such compromise like the G.723.1 may happen in the IETF as well if you would want a standard track document (example in AVT is SVC payload specification). This is why I suggested that we need to discuss in the BOF if the result will be an Informational RFC or Standard track RFC. A document can be blocked in the ITU and in the IETF and in this cases the ADs are trying to get some compromise and not to force a solution. A famous quote from Abba Eban on consensus - "A consensus means that everyone agrees to say collectively what no one believes individually." Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Koen Vos > Sent: Sunday, June 28, 2009 12:11 AM > To: codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > Quoting stephen botzko: > > If you remove the audio and video codec groups from SG16 (ITU), then > you'd > > find that there is little if any difference in the need to license / > pay > > royalties on the standards produced by the two organizations. > > The last time ITU came up with a free speech/audio codec was in 1972 > with G.711. Since then, all codecs, including G.722 and G.722.1, were > standardized as non-free, royalty-bearing codecs. G.722.1 was only > made available free of royalties 7 years after being standardized. > > > > (b) Source code is disclosed very late in the ITU audio > standardization > > process, making it much more difficult for non-participant attendees > to know > > exactly how the codec functions. So if it unlikely that someone can > > research/patent improvements ahead of the process. > > The ITU process has a natural tendency to come up with technology that > is covered by patents from many of the stakeholders. This lubricates > the process of reaching agreement. Take for example G.723.1, which is > an inelegant combination of MPC-MLQ 6.3 kbps and ACELP 5.3 kbps. The > ACELP mode is so much inferior to the MPC-MLQ mode that it's never > used. The only reason it's in there is that the patent owners of ACELP > wouldn't agree to the standard unless their technology was part of it. > > best, > koen. > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From christer.holmberg@ericsson.com Sat Jun 27 15:27:47 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 52D1A3A6A21 for ; Sat, 27 Jun 2009 15:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.956 X-Spam-Level: X-Spam-Status: No, score=-4.956 tagged_above=-999 required=5 tests=[AWL=-0.390, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083] 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 P8tGH5E-v1aG for ; Sat, 27 Jun 2009 15:27:45 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id A317A3A6919 for ; Sat, 27 Jun 2009 15:27:44 -0700 (PDT) X-AuditID: c1b4fb3e-b7be1ae000004757-0f-4a469cf1b82f Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 48.10.18263.1FC964A4; Sun, 28 Jun 2009 00:28:01 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Jun 2009 00:28:01 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 28 Jun 2009 00:25:27 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] FW: [AVT] RFC 5574 on RTP Payload Format for the Speex Codec Thread-Index: Acnzlx2AupiQhwLfS7+8oIyFA1upgAAD3XpSAMpiotAADs3C4AAatdcl References: <20090623000920.AFDB52D6515@bosco.isi.edu> <4a45eb85.01b7660a.100e.ffff8499@mx.google.com> From: "Christer Holmberg" To: "Roni Even" , "Henry Sinnreich" , X-OriginalArrivalTime: 27 Jun 2009 22:28:01.0262 (UTC) FILETIME=[87C228E0:01C9F776] X-Brightmail-Tracker: AAAAAA== Subject: Re: [codec] FW: [AVT] RFC 5574 on RTP Payload Format for the Speex Codec 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, 27 Jun 2009 22:27:47 -0000 Hi Roni,=20 I know that the RFC only covers the payload spec. But, the argument has been that there is no suitable open-source codec = available (no matter who has defined it), and that IETF therefor needs = to define one. Regards, Christer -----Alkuper=E4inen viesti----- L=E4hett=E4j=E4: Roni Even [mailto:ron.even.tlv@gmail.com] L=E4hetetty: la 27.6.2009 11:50 Vastaanottaja: Christer Holmberg; 'Henry Sinnreich'; codec@ietf.org Aihe: RE: [codec] FW: [AVT] RFC 5574 on RTP Payload Format for the Speex = Codec =20 Christer, The IETF work only covers the payload specification not the codec = itself. The BOF is to discuss publishing the codec itself as an RFC. I agree = that if it is open source and is already being used and wonder why do we need = the IETF RFC. I am not sure whether the objective there is to define a new = one or publish an existing one or one that being worked by another "open" = group as an IETF RFC, the one I see being pushed is the "CELT" done by = XIPH.org. You are right that it can be published the same as speex as an open = source and the IETF will publish the payload specification. Roni=20 > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Christer Holmberg > Sent: Saturday, June 27, 2009 5:48 AM > To: Henry Sinnreich; codec@ietf.org > Subject: Re: [codec] FW: [AVT] RFC 5574 on RTP Payload Format for the > Speex Codec >=20 > Henry, >=20 > If there already exists an open-source codec, suitable for VoIP, why = do > you need a new one? >=20 > Regards, >=20 > Christer >=20 > ________________________________ >=20 > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Henry Sinnreich > Sent: Tuesday, June 23, 2009 5:02 AM > To: codec@ietf.org > Subject: [codec] FW: [AVT] RFC 5574 on RTP Payload Format for the = Speex > Codec >=20 >=20 >=20 > ------ Forwarded Message > From: > Date: Mon, 22 Jun 2009 17:09:20 -0700 > To: , > Cc: , > Subject: [AVT] RFC 5574 on RTP Payload Format for the Speex Codec >=20 >=20 >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 5574 >=20 > Title: RTP Payload Format for the > Speex Codec > Author: G. Herlein, J. Valin, > A. Heggestad, A. Moizard > Status: Standards Track > Date: June 2009 > Mailbox: gherlein@herlein.com, > jean-marc.valin@usherbrooke.ca, > aeh@db.org, jack@atosc.org > Pages: 14 > Characters: 27995 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-avt-rtp-speex-07.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc5574.txt >=20 > Speex is an open-source voice codec suitable for use in VoIP (Voice > over IP) type applications. This document describes the payload > format for Speex-generated bit streams within an RTP packet. Also > included here are the necessary details for the use of Speex with the > Session Description Protocol (SDP). [STANDARDS TRACK] >=20 > This document is a product of the Audio/Video Transport Working Group > of the IETF. >=20 > This is now a Proposed Standard Protocol. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and > suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see http://www.rfc- > editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > USC/Information Sciences Institute >=20 >=20 > _______________________________________________ > Audio/Video Transport Working Group > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 > ------ End of Forwarded Message >=20 >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From brian@freeswitch.org Sat Jun 27 16:20: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 C2EC83A6A32 for ; Sat, 27 Jun 2009 16:20:53 -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 7yRRUOTrG6Ph for ; Sat, 27 Jun 2009 16:20:53 -0700 (PDT) Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by core3.amsl.com (Postfix) with ESMTP id D72543A67F9 for ; Sat, 27 Jun 2009 16:20:52 -0700 (PDT) Received: by gxk26 with SMTP id 26so2415306gxk.13 for ; Sat, 27 Jun 2009 16:21:08 -0700 (PDT) Received: by 10.90.82.17 with SMTP id f17mr4613018agb.17.1246144867849; Sat, 27 Jun 2009 16:21:07 -0700 (PDT) Received: from air.bkw.org (adsl-70-234-190-89.dsl.tul2ok.sbcglobal.net [70.234.190.89]) by mx.google.com with ESMTPS id 9sm3976487agc.22.2009.06.27.16.21.06 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 27 Jun 2009 16:21:07 -0700 (PDT) Message-Id: <3C44B6E5-1ECF-473F-BADC-79C94AFC3B39@freeswitch.org> From: Brian West To: Koen Vos In-Reply-To: <20090627141050.72075gnkxrgkelzu@mail.skype.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 27 Jun 2009 18:21:05 -0500 References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> X-Mailer: Apple Mail (2.935.3) Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 27 Jun 2009 23:20:53 -0000 As someone that has gone thru the paperwork for G722.1/1C ... If you're going to offer a codec royalty free at the very least drop the paperwork requirement. I had to do the whole process 3 times. Now that we have G722.1/1C in FreeSWITCH its a moot point but anyone else wanting to use either of these codecs would need to go thru the paperwork mess. (which the lib is public domain you can use it if you like its in our SVN tree.) /b On Jun 27, 2009, at 4:10 PM, Koen Vos wrote: > The last time ITU came up with a free speech/audio codec was in 1972 > with G.711. Since then, all codecs, including G.722 and G.722.1, > were standardized as non-free, royalty-bearing codecs. G.722.1 was > only made available free of royalties 7 years after being > standardized. From SRS0+Gk0V+23+rowetel.com=david@internode.on.net Sat Jun 27 17:05: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 B397D3A69A3 for ; Sat, 27 Jun 2009 17:05:35 -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 34Aq-FQJt-va for ; Sat, 27 Jun 2009 17:05:34 -0700 (PDT) Received: from mail.internode.on.net (bld-mail18.adl2.internode.on.net [150.101.137.103]) by core3.amsl.com (Postfix) with ESMTP id 97F713A6800 for ; Sat, 27 Jun 2009 17:05:33 -0700 (PDT) Received: from bunny.lan (unverified [121.45.181.39]) by mail.internode.on.net (SurgeMail 3.8f2) with ESMTP id 1575117-1927428 for ; Sun, 28 Jun 2009 09:35:51 +0930 (CST) From: David Rowe To: codec@ietf.org In-Reply-To: <20090627141050.72075gnkxrgkelzu@mail.skype.net> References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> Content-Type: text/plain Date: Sun, 28 Jun 2009 09:36:18 +0930 Message-Id: <1246147578.7191.58.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit Subject: [codec] introduction and patent free codec thoughts 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: Sun, 28 Jun 2009 00:10:24 -0000 Hello list, My name is David Rowe, I have a PhD in speech codecs and 20 years experience in design and real time implementation of speech codecs and other DSP algorithms. I helped found Speex and have been a minor contributor over the years. I have also run small businesses that uses speech codecs and experienced first hand the pain of trying to use codecs like g729 with $40k license fees. My experience from as both a codec designer and a business entity using codecs is that they are a useless tax on business and telecommunication. They license fees benefit no-one but the people receiving the royalties. Why can I get a first class operating system like Linux for free but have to pay some one to use a tiny bit of software on it like g729? We have the skills in the open source community to build better codecs using open source techniques. The world will be a better place for it. Patent free, competitive DSP algorithms can and should be developed, and there are precedents: 1/ Speex and the various other open codecs. 2/ A patent free, royalty free line echo canceller (Oslec) which is successfully replacing expensive royalty based solutions. I recall much of the same FUD about patents when developing this algorithm. And yet it works, pushing out the royalty-based code in many many thousands of cases, and it's now part of the Linux kernel (try doing that with closed code). What has held Speex adoption back is lack of standardisation - people have been forced to use royalty based codecs like g729. Well, it looks like we have a chance to fix that. Speex has shown it's possible to build a patent free codec. A lot of the algorithms involved in codecs are just well known math, e.g transforms, vector and scalar quantisation. There are many ways to achieve a certain math operation (e.g. time and frequency duality) to get a certain technique done if an annoying patent is in the way. It really is no big deal. Much of this technology was published in the 60's and 70's. Where the patents come in is that some one gets a good quality codec working using some clever technique in 1% of algorithm, then they patent that 1%. I would imagine they explicitly search for a novel technique to lock up their codec. Then when that codec is standardised we are stuck paying them royalties for bit-exact interoperability reasons. g729 does not hold patents on linear prediction, or vector quantisation, or CELP, or Line Spectrum Pairs, or pitch prediction. All these techniques are also in Speex which sounds about the same at 8 kbit/s. It's easy to replace that 1% early in the codec design process - we simply make royalty free a priority rather than maximising royalties. In other worlds design the codec to help as many people as possible, rather than designing it to make a small number of people wealthy. Isn't that what the IETF is all about? I think it's a great ideas to release source code from day 1. Open source development has been shown to be superior to closed, so I am sure we can develop a better codec faster with open source, peer reviewed code. Re funding an open development effort and travel to meetings the $ involved are trivial compared to the cumulative costs of license fees down the track for the closed approach. So it's a great business decision to support an open codec. Thanks, David -- Free Telephony Project open embedded IP-PBX hardware and software http://www.rowetel.com/ucasterisk From brian@freeswitch.org Sat Jun 27 18:39: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 AE02A3A6B5D for ; Sat, 27 Jun 2009 18:39:07 -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 J6bCp3uhGbfd for ; Sat, 27 Jun 2009 18:39:07 -0700 (PDT) Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by core3.amsl.com (Postfix) with ESMTP id E9D143A6A68 for ; Sat, 27 Jun 2009 18:39:06 -0700 (PDT) Received: by gxk26 with SMTP id 26so2494333gxk.13 for ; Sat, 27 Jun 2009 18:39:22 -0700 (PDT) Received: by 10.90.50.5 with SMTP id x5mr1048664agx.43.1246153161885; Sat, 27 Jun 2009 18:39:21 -0700 (PDT) Received: from air.bkw.org (adsl-70-234-190-89.dsl.tul2ok.sbcglobal.net [70.234.190.89]) by mx.google.com with ESMTPS id 39sm5817824agd.46.2009.06.27.18.39.20 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 27 Jun 2009 18:39:21 -0700 (PDT) Message-Id: <0F770F94-3006-4239-B797-E1D611C28D91@freeswitch.org> From: Brian West To: David Rowe In-Reply-To: <1246147578.7191.58.camel@localhost> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 27 Jun 2009 20:39:18 -0500 References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> <1246147578.7191.58.camel@localhost> X-Mailer: Apple Mail (2.935.3) Cc: codec@ietf.org Subject: Re: [codec] introduction and patent free codec thoughts 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: Sun, 28 Jun 2009 01:39:07 -0000 Its actually 20k to get started. In either case its silly. Speex is a great codec as is CELT. With the two you have the complete range 8, 16, 32 and 48kHz. /b On Jun 27, 2009, at 7:06 PM, David Rowe wrote: > codecs like g729 with $40k license fees. From brian@freeswitch.org Sat Jun 27 18:41: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 5B42B3A69A3 for ; Sat, 27 Jun 2009 18:41:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=-0.542, BAYES_00=-2.599, URIBL_RHS_DOB=1.083] 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 WjceEXT5A7Sa for ; Sat, 27 Jun 2009 18:41:04 -0700 (PDT) Received: from mail-yx0-f176.google.com (mail-yx0-f176.google.com [209.85.210.176]) by core3.amsl.com (Postfix) with ESMTP id 986153A695E for ; Sat, 27 Jun 2009 18:41:04 -0700 (PDT) Received: by yxe6 with SMTP id 6so19395yxe.29 for ; Sat, 27 Jun 2009 18:41:22 -0700 (PDT) Received: by 10.90.118.19 with SMTP id q19mr4692463agc.87.1246153282104; Sat, 27 Jun 2009 18:41:22 -0700 (PDT) Received: from air.bkw.org (adsl-70-234-190-89.dsl.tul2ok.sbcglobal.net [70.234.190.89]) by mx.google.com with ESMTPS id 36sm4175416aga.14.2009.06.27.18.41.21 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 27 Jun 2009 18:41:21 -0700 (PDT) Message-Id: <405D39CA-C3C4-427F-8032-2534606F212C@freeswitch.org> From: Brian West To: codec@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sat, 27 Jun 2009 20:41:19 -0500 X-Mailer: Apple Mail (2.935.3) Subject: [codec] Not sure this is on topic.... 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: Sun, 28 Jun 2009 01:41:05 -0000 Aug 4-6th we will have many of the open source voip projects gathered together at ClueCon '09 in Chicago.. http://www.cluecon.com/ If anyone wishes to attend please contact me off list I can offer discount tickets to anyone wanting to attend. Thanks, Brian West FreeSWITCH.org From hsinnrei@adobe.com Sat Jun 27 18:46:52 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 B408B3A69A3 for ; Sat, 27 Jun 2009 18:46:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.416 X-Spam-Level: X-Spam-Status: No, score=-5.416 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083] 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 0v9Y7Ik+Nqo2 for ; Sat, 27 Jun 2009 18:46:51 -0700 (PDT) Received: from psmtp.com (exprod6ob117.obsmtp.com [64.18.1.38]) by core3.amsl.com (Postfix) with ESMTP id 0B9B83A695E for ; Sat, 27 Jun 2009 18:46:50 -0700 (PDT) Received: from source ([192.150.8.22]) by exprod6ob117.postini.com ([64.18.5.12]) with SMTP ID DSNKSkbLmhkDaGNaWYoPwqZSn/eovt1UXSFE@postini.com; Sat, 27 Jun 2009 18:47:11 PDT Received: from inner-relay-2.corp.adobe.com ([153.32.1.52]) by outbound-smtp-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5S1l2WG020869; Sat, 27 Jun 2009 18:47:03 -0700 (PDT) Received: from nacas01.corp.adobe.com (nacas01.corp.adobe.com [10.8.189.99]) by inner-relay-2.corp.adobe.com (8.12.10/8.12.10) with ESMTP id n5S1l2lT012499; Sat, 27 Jun 2009 18:47:02 -0700 (PDT) Received: from nambx05.corp.adobe.com ([10.8.189.124]) by nacas01.corp.adobe.com ([10.8.189.99]) with mapi; Sat, 27 Jun 2009 18:47:02 -0700 From: Henry Sinnreich To: David Rowe , "codec@ietf.org" Date: Sat, 27 Jun 2009 18:47:00 -0700 Thread-Topic: [codec] introduction and patent free codec thoughts Thread-Index: Acn3hOMfYwqaee4rSc+AZDjq+6CpcwADXCs/ Message-ID: In-Reply-To: <1246147578.7191.58.camel@localhost> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C66C35C44631hsinnreiadobecom_" MIME-Version: 1.0 Subject: Re: [codec] introduction and patent free codec thoughts 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: Sun, 28 Jun 2009 01:46:52 -0000 --_000_C66C35C44631hsinnreiadobecom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable David Rowe writes: >In other worlds design the codec to help as many people as possible, >rather than designing it to make a small number of people wealthy. >Isn't that what the IETF is all about? There is large volume of papers in the IETF and ACM on Engineering Ethics t= hat mirror this position. One can do a search or start at http://en.wikipedia.org/wiki/Engineering_et= hics Henry On 6/27/09 7:06 PM, "David Rowe" wrote: In other worlds design the codec to help as many people as possible, rather than designing it to make a small number of people wealthy. Isn't that what the IETF is all about? --_000_C66C35C44631hsinnreiadobecom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [codec] introduction and patent free codec thoughts David Rowe writes:

>In other worlds design the codec to help as many people as possible, >rather than designing it to make a small number of people wealthy.
>Isn't that what the IETF is all about?

There is large volume of papers in the IETF and ACM on Engineering Ethics t= hat mirror this position.
One can do a search or start at http://en.wikipedia.org/wiki/Engineering_ethics

Henry


On 6/27/09 7:06 PM, "David Rowe" <david@rowetel.com> wrote:

In other worlds design the codec to help as= many people as possible,
rather than designing it to make a small number of people wealthy.
Isn't that what the IETF is all about?
--_000_C66C35C44631hsinnreiadobecom_-- From koen.vos@skype.net Sat Jun 27 19:19:22 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 352893A6B41 for ; Sat, 27 Jun 2009 19:19:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 90v+jMOdZV8r for ; Sat, 27 Jun 2009 19:19:21 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 2F6DB3A67E7 for ; Sat, 27 Jun 2009 19:19:21 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id E46852007A783 for ; Sun, 28 Jun 2009 04:19:39 +0200 (CEST) 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=jmsWeMcliegb An6WqaYKGohl3YQ=; b=bkkzCErfspQci6u7/ZmXKupLJFOLttLs538m6R7Pacy1 hxV9caHA1fVSzCdJW5uMxe3wuZ4UPSQe0CStasOnNOIID2b5JZfPGQoJNWFSJy0C HPvwQAbecdL70vYguMJGZlQkuErGW/W3zdS6dB6oBlFVY5hFmx7aN/iRvcoSbmQ= 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=RYGRtAT1Zt4INWx0hk0u eK7D+GMin/fxWFhIUgzT6BITHn/OO+w51YJ6dU+mPltCNyd3nKzJZbjJym5cILnU yj/3x7ZdxTjjlNzUlhc5//HXCgW1M2GLMALbFdIEY/PcaqJqKLLuqxuaGzzm/j0x 1Ceyar0ROyigg7qYqFHiCjo= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id E303B20075C2C for ; Sun, 28 Jun 2009 04:19:39 +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 yPrVXqtKkCdw for ; Sun, 28 Jun 2009 04:19:39 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 2DB112007A782; Sun, 28 Jun 2009 04:19:39 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Sat, 27 Jun 2009 19:19:39 -0700 Message-ID: <20090627191939.180219g7euwi7n7f@mail.skype.net> Date: Sat, 27 Jun 2009 19:19:39 -0700 From: Koen Vos To: codec@ietf.org References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> <4a469797.0baa660a.1091.ffff9ad0@mx.google.com> In-Reply-To: <4a469797.0baa660a.1091.ffff9ad0@mx.google.com> 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] Codec BOF approved, much work needed 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: Sun, 28 Jun 2009 02:19:22 -0000 Quoting Roni Even: > Koen, > Standard bodies make decision by consensus, so such compromise like the > G.723.1 may happen in the IETF as well Roni, the ugly G.723.1 compromise came about solely to protect royalties from a party that would otherwise block the standard. Therefore, such a compromise could *not* happen if the IETF WG were to set out to create a royalty-free codec. ITU serves to protect and generate royalties for its members. koen. From stephen.botzko@gmail.com Sun Jun 28 04:17:19 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 7769C3A689B for ; Sun, 28 Jun 2009 04:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.502 X-Spam-Level: X-Spam-Status: No, score=-1.502 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, HTML_MESSAGE=0.001, URIBL_RHS_DOB=1.083] 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 frhyrdaZoGGg for ; Sun, 28 Jun 2009 04:17:18 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 0F6233A677C for ; Sun, 28 Jun 2009 04:17:17 -0700 (PDT) Received: by fxm18 with SMTP id 18so468507fxm.37 for ; Sun, 28 Jun 2009 04:17: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:message-id:subject:from:to:cc:content-type; bh=s1IkxGU0c/evqPOdNA1ZnC1Oh642SEJ3kkD4gbqsftM=; b=bkeAuyLCGvYBMXEI7q4GgYubWsEhnwuw6eLDkIy3UtPFcqFRpnWetGG7z+pxSOnTan rUpyoVUhryj86TQT9hNt14nPnfITEerJ6l82ENinsHOHRPRpueXnKoLwO71tLyI52/cm Q+a/tAUG+4mmziShi+aKU5N9yXwN3FuPU+Nfo= 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=VsbvJnOrJ2WTr1qHSE9J85UkzymjpnAHs/3+MCP873oD7GZOVtrAzwDQQsdy7TXRF7 dKW1MeOIgM/RbdCpOfKaEQ2s74L5M/dndDK0SIQlDnuXMnscHggjJDtmhV/eP3aWj+RS gd/UdP0UI7FXoRqNiXkWK8HjjcYZjD/mJxrXA= MIME-Version: 1.0 Received: by 10.103.179.1 with SMTP id g1mr3369707mup.57.1246187855087; Sun, 28 Jun 2009 04:17:35 -0700 (PDT) In-Reply-To: <20090627141050.72075gnkxrgkelzu@mail.skype.net> References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> Date: Sun, 28 Jun 2009 07:17:34 -0400 Message-ID: <6e9223710906280417v70b9df39xe94393c3ff9de58e@mail.gmail.com> From: stephen botzko To: Koen Vos Content-Type: multipart/alternative; boundary=001636417c4b6d0cc9046d66b8be Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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: Sun, 28 Jun 2009 11:17:19 -0000 --001636417c4b6d0cc9046d66b8be Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Jun 27, 2009 at 5:10 PM, Koen Vos wrote: > Quoting stephen botzko: > >> If you remove the audio and video codec groups from SG16 (ITU), then you'd >> find that there is little if any difference in the need to license / pay >> royalties on the standards produced by the two organizations. >> > > The last time ITU came up with a free speech/audio codec was in 1972 with > G.711. Since then, all codecs, including G.722 and G.722.1, were > standardized as non-free, royalty-bearing codecs. G.722.1 was only made > available free of royalties 7 years after being standardized. G722.1 Annex C (which is a complete superwideband codec) has always been royalty free, as I indicated in previous posts, G,722,1 (wideband) was made available royalty free shortly afterwards. Though I think you missed the main point of the comment, which was the relative lack of patent burden on the IETF RFCs is partly att least partly a result of their subject matter, and not the process, or that the participants are somehow different. > > > > (b) Source code is disclosed very late in the ITU audio standardization >> process, making it much more difficult for non-participant attendees to >> know >> exactly how the codec functions. So if it unlikely that someone can >> research/patent improvements ahead of the process. >> > > The ITU process has a natural tendency to come up with technology that is > covered by patents from many of the stakeholders. This lubricates the > process of reaching agreement. Take for example G.723.1, which is an > inelegant combination of MPC-MLQ 6.3 kbps and ACELP 5.3 kbps. The ACELP mode > is so much inferior to the MPC-MLQ mode that it's never used. The only > reason it's in there is that the patent owners of ACELP wouldn't agree to > the standard unless their technology was part of it. I wasn't in those meetings, so I can't speak to "the only reason its in there". The current audio ITU process does *not* allow someone to object to a standard because their technology is not in it. Getting concensus might require that the terms of reference include both 6.3 kpbs and 5.3 kbps operating modes, however the terms of reference would not indicate the technology used by those operatoring modes. Obvously most ITU audio codecs require royalties. However, that is not a natural tendency of its process. Candidate codecs can be submitted without regard to IPR, after a competitive selection process the best codec is standardized, and the contributors set the terms. There is nothing I see that is inherent in this process that "naturally tends" to result in royalty-bearing codecs. I'd say the result is due to the companies that have chosen to contribute there, and not the process that is used. Also, I thought the goal was royalty-free, not patent free. Am I mistaken here? > > > best, > koen. > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --001636417c4b6d0cc9046d66b8be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Jun 27, 2009 at 5:10 PM, Koen Vo= s <koen.vos@skyp= e.net> wrote:
Quoting stephen botzko:
If you remove the audio and video codec groups from SG16 (ITU), then you= 9;d
find that there is little if any difference in the need to license / pay royalties on the standards produced by the two organizations.

The last time ITU came up with a free speech/audio codec was in 1972 with G= .711. Since then, all codecs, including G.722 and G.722.1, were standardize= d as non-free, royalty-bearing codecs. G.722.1 was only made available free= of royalties 7 years after being standardized.

G722.1 Annex C (which is a complete superwideband codec) has alway= s been royalty free, as I indicated in previous posts, G,722,1 (wideband) w= as made available royalty free shortly afterwards.

Though I think yo= u missed the main point of the comment, which was the relative lack of pate= nt burden on the IETF RFCs is partly att least partly a result of their sub= ject matter, and not the process, or that the participants are somehow diff= erent.



(b) Source code is disclosed very late in the ITU audio standardization
process, making it much more difficult for non-participant attendees to kno= w
exactly how the codec functions. =A0So if it unlikely that someone can
research/patent improvements ahead of the process.

The ITU process has a natural tendency to come up with technology that is c= overed by patents from many of the stakeholders. This lubricates the proces= s of reaching agreement. Take for example G.723.1, which is an inelegant co= mbination of MPC-MLQ 6.3 kbps and ACELP 5.3 kbps. The ACELP mode is so much= inferior to the MPC-MLQ mode that it's never used. The only reason it&= #39;s in there is that the patent owners of ACELP wouldn't agree to the= standard unless their technology was part of it.

I wasn't in those meetings, so I can't speak to "the = only reason its in there".=A0 The current audio ITU process does no= t allow someone to object to a standard because their technology is not= in it.=A0 Getting concensus might require that the terms of reference incl= ude both 6.3 kpbs and 5.3 kbps operating modes, however the terms of refere= nce would not indicate the technology used by those operatoring modes.

Obvously most ITU audio codecs require royalties.=A0 However, that is n= ot a natural tendency of its process.=A0 Candidate codecs can be submitted = without regard to IPR, after a competitive selection process the best codec= is standardized, and the contributors set the terms.=A0 There is nothing I= see that is inherent in this process that "naturally tends" to r= esult in royalty-bearing codecs. I'd say the result is due to the compa= nies that have chosen to contribute there, and not the process that is used= .

Also, I thought the goal was royalty-free, not patent free.=A0 Am I mis= taken here?


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

--001636417c4b6d0cc9046d66b8be-- From stephen.botzko@gmail.com Sun Jun 28 04:46:01 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 090853A6921 for ; Sun, 28 Jun 2009 04:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.045 X-Spam-Level: X-Spam-Status: No, score=-2.045 tagged_above=-999 required=5 tests=[AWL=0.553, 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 ttwgF+Lusn9l for ; Sun, 28 Jun 2009 04:45:59 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 2E03A3A6896 for ; Sun, 28 Jun 2009 04:45:59 -0700 (PDT) Received: by fxm18 with SMTP id 18so476606fxm.37 for ; Sun, 28 Jun 2009 04:46: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:message-id:subject:from:to:cc:content-type; bh=hju7DdmRwi6BTkHQ/jRWh9t/t+HpMk1UEp70KSGadGU=; b=edntK3vqVdkf8KH4n6RxhUeAWPI1bn7DQdBAXz8VFwa/AMgajzWL5GJtA3hYQq4p1W 7BDXblMR7lWI/EKwUj6pxz37gPh9uP38y7ECUl7pzjn9KSQQHkq4PVUjB+59ERACNMv4 XAAdpz2gwbu5Q/NunmwNH5tjR0M+DGSWP8LkE= 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=YK+XZU50RXqlzMLdqEGvNFMPwcRje0+hTZbqHqpvjUrrJPpLtcxRbb6kpMy0HOqKSZ RjkLg2nxIihKnCSGwPxT/WT+yNNL5ukdhCqiS6YxdbT1+qrekvok284mazp9rRLysw9Z qjRweRJUCWVqaNzJYNg4Y2JhuFfM4f+C0y0HE= MIME-Version: 1.0 Received: by 10.103.224.17 with SMTP id b17mr3413096mur.61.1246189575078; Sun, 28 Jun 2009 04:46:15 -0700 (PDT) In-Reply-To: References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> Date: Sun, 28 Jun 2009 07:46:14 -0400 Message-ID: <6e9223710906280446q21e32c10i9e6f56ab3b1c137f@mail.gmail.com> From: stephen botzko To: Randell Jesup Content-Type: multipart/alternative; boundary=001636a7d93ff2067a046d671e1a Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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: Sun, 28 Jun 2009 11:46:01 -0000 --001636a7d93ff2067a046d671e1a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Jun 27, 2009 at 2:41 PM, Randell Jesup wrote: > stephen botzko writes: > >>>> > >Are you suggesting that ITU could create a royalty free standard? > >>>> > >I believe Stephan is saying that Skype (and others) can create a standard > in > >the ITU for which the proposing companines do not charge royalties. > G.722.1 > >is one proof point that this can be done in the ITU, > > Sure - but that's not what's being proposed/discussed here. That's been > done in IETF as well with iLBC. iLBC is an experimental RFC, I am not proposing/discussing that here. What I was indicating is that royalty-free audio codecs can be standardized in other SDOs, including the ITU, which I think is quite relevant to the question of whether the IETF should also get into that business. I agree that there are not many of these, however that could change if other companies and universities chose to participate in those venues. I agree that individuats would find the IETF more affordable than the ITU, though I am not sure if that is a sufficient reason to form a working group. > > > >I believe he is also saying (in other posts) that developing a codec which > >is guaranteed not to infringe any exisitng patents is not possible in > either > >organization. I would concur with both statements. I would be > particularly > >concerned about a working group that requires participants to research > other > >organization's patents - as Stephan indicates, that is against the > policies > >of many corporations because it can result in liability for triple damages > >in the US. > > Who would do that in ITU, or would it simply be assumed that the > proposing entity had dealt with it (if needed), and the RAND requirement > covered their patents? Wouldn't the issues be pretty much the same? > Even if IETF has not RAND requirement, there are IPR disclosure > requirements, and the (likely) royalty/licensing status can be part of > the evaluation/selection/development. The IPR disclosure processs in both organizations only requires that participants disclose if they have IPR. Neither the IETF nor the ITU requires the participants to determine if any non-participants have IPR, or require participants to attempt to construe patent claims. I think its important to keep i that way. Since many of the proposals here are essentially proposing creating a new IPR process for the proposed WG, I think both the codec standardization question itself and the IPR process need to be discussed at the BoF. > > >>>> > >And bear in mind that the ITU process is very expensive - who is going to > >pay for it if it only means less revenues for the average ITU member? > >>>> > >(d) I don't understand what expense you are talking about here. Audio > codec > >standardization requires the proposers of the each codec candidate to pay > >for the listening tests. ITU membership fees do not depend on what > workiing > >groups you participate in (that is, your membership fees do not go up if > you > >standardize codecs). Are you somehow thinking that ITU members share the > >codec revemues? The ITU is not a patent pool, and does not license > >anything. (Neither does the IETF of course). > > "proposer pays" makes sense for an all-industry, royalty-generating > standards organization where it's a selection group, but it does no > group "development" or testing. The proposer stands to benefit > monetarily in most cases. > > In an organization where individuals often participate, and proposals > may be group efforts or incorporate input from many sources, this may > not be a reasonable way to proceed. > > As for the cost, as I said before, I'm not able/willing to pay the cost > of participating in ITU groups as an individual - even if one of the > groups you have to go through would allow me in. IETF participation is > much more free-form, individual, and without hurdles to participation. > > >There's been no discussion about who bears the expense of codec > >qualitifcation tests in the proposed IETF working group, other than some > >folks expressing a hope that the testimg might be cost less. > > Well worth discussing, not just costs but also what's needed to > accomplish the goals. Agreed. > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS > team > rjesup@wgate.com > "The fetters imposed on liberty at home have ever been forged out of the > weapons > provided for defence against real, pretended, or imaginary dangers from > abroad." > - James Madison, 4th US president (1751-1836) > --001636a7d93ff2067a046d671e1a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Sat, Jun 27, 2009 at 2:41 PM, Randell= Jesup <rjesup@wga= te.com> wrote:
stephen botzko <stephen.botzko@gmail.com> writes:
>>>>
>Are you suggesting that ITU could create a royalty free standard?
>>>>
>I believe Stephan is saying that Skype (and others) can create a standa= rd in
>the ITU for which the proposing companines do not charge royalties. =A0= G.722.1
>is one proof point that this can be done in the ITU,

Sure - but that's not what's being proposed/discussed here. = =A0That's been
done in IETF as well with iLBC.
=A0
iLBC is an e= xperimental RFC, I am not proposing/discussing that here. What I was indica= ting is that royalty-free audio codecs can be standardized in other SDOs, i= ncluding the ITU, which I think is quite relevant to the question of whethe= r the IETF should also get into that business.=A0 I agree that there are no= t many of these, however that could change if other companies and universit= ies chose to participate in those venues.=A0

I agree that individuats would find the IETF more affordable than the I= TU, though I am not sure if that is a sufficient reason to form a working g= roup.
=A0


>I believe he is also saying (in other posts) that developing a codec wh= ich
>is guaranteed not to infringe any exisitng patents is not possible in e= ither
>organization. =A0I would concur with both statements. =A0I would be par= ticularly
>concerned about a working group that requires participants to research = other
>organization's patents - as Stephan indicates, that is against the = policies
>of many corporations because it can result in liability for triple dama= ges
>in the US.

Who would do that in ITU, or would it simply be assumed that the
proposing entity had dealt with it (if needed), and the RAND requirement covered their patents? =A0Wouldn't the issues be pretty much the same?<= br> Even if IETF has not RAND requirement, there are IPR disclosure
requirements, and the (likely) royalty/licensing status can be part of
the evaluation/selection/development.

The IPR disclosu= re processs in both organizations only requires that participants disclose = if they have IPR.=A0 Neither the IETF nor the ITU requires the participants= to determine if any non-participants have IPR, or require participants to = attempt to construe patent claims.=A0 I think its important to keep i that = way.=A0

Since many of the proposals here are essentially proposing creating a n= ew IPR process for the proposed WG, I think both the codec standardization = question itself and the IPR process need to be discussed at the BoF.



>>>>
>And bear in mind that the ITU process is very expensive - who is going = to
>pay for it if it only means less revenues for the average ITU member? >>>>
>(d) I don't understand what expense you are talking about here. =A0= Audio codec
>standardization requires the proposers of the each codec candidate to p= ay
>for the listening tests. =A0ITU membership fees do not depend on what w= orkiing
>groups you participate in (that is, your membership fees do not go up i= f you
>standardize codecs). =A0Are you somehow thinking that ITU members share= the
>codec revemues? =A0The ITU is not a patent pool, and does not license >anything. =A0(Neither does the IETF of course).

"proposer pays" makes sense for an all-industry, royalty-ge= nerating
standards organization where it's a selection group, but it does no
group "development" or testing. =A0The proposer stands to benefit=
monetarily in most cases.


In an organization where individuals often participate, and proposals
may be group efforts or incorporate input from many sources, this may
not be a reasonable way to proceed.

As for the cost, as I said before, I'm not able/willing to pay the cost=
of participating in ITU groups as an individual - even if one of the
groups you have to go through would allow me in. =A0IETF participation is much more free-form, individual, and without hurdles to participation.

>There's been no discussion about who bears the expense of codec
>qualitifcation tests in the proposed IETF working group, other than som= e
>folks expressing a hope that the testimg might be cost less.

Well worth discussing, not just costs but also what's needed to accomplish the goals.
=A0
Agreed.

--
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS te= am
rjesup@wgate.com
"The fetters imposed on liberty at home have ever been forged out of t= he weapons
provided for defence against real, pretended, or imaginary dangers from abr= oad."
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- James Madison, 4th US president (1751-183= 6)

--001636a7d93ff2067a046d671e1a-- From christer.holmberg@ericsson.com Sun Jun 28 06:38:16 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 4FA273A6858 for ; Sun, 28 Jun 2009 06:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.247 X-Spam-Level: X-Spam-Status: No, score=-5.247 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, URIBL_RHS_DOB=1.083] 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 kP9KCBRDAOQ4 for ; Sun, 28 Jun 2009 06:38:15 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 373483A683E for ; Sun, 28 Jun 2009 06:38:14 -0700 (PDT) X-AuditID: c1b4fb3c-b7bdcae0000052f9-5b-4a4772584838 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 63.0F.21241.852774A4; Sun, 28 Jun 2009 15:38:32 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 Jun 2009 15:38:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sun, 28 Jun 2009 15:34:16 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] introduction and patent free codec thoughts Thread-Index: Acn3kUlgdADwMbtWRMavVNY0QUMQLQAY9i33 References: <20090626114355.16720yb6jhzzxxij@mail.skype.net><6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com><20090627141050.72075gnkxrgkelzu@mail.skype.net><1246147578.7191.58.camel@localhost> <0F770F94-3006-4239-B797-E1D611C28D91@freeswitch.org> From: "Christer Holmberg" To: "Brian West" , "David Rowe" X-OriginalArrivalTime: 28 Jun 2009 13:38:31.0951 (UTC) FILETIME=[BA2FC1F0:01C9F7F5] X-Brightmail-Tracker: AAAAAA== Cc: codec@ietf.org Subject: Re: [codec] introduction and patent free codec thoughts 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: Sun, 28 Jun 2009 13:38:16 -0000 Hi, >Its actually 20k to get started. In either case its silly. Speex is =20 >a great codec as is CELT. With the two you have the complete range 8, = >16, 32 and 48kHz. What, in your opinion, is it then that we do NOT have? (Henry gave some examples of applications for which he thinks something = new is needed.) Regards, Christer /b On Jun 27, 2009, at 7:06 PM, David Rowe wrote: > codecs like g729 with $40k license fees. _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From koen.vos@skype.net Sun Jun 28 14:53:22 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 98AAC3A6B99 for ; Sun, 28 Jun 2009 14:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.315 X-Spam-Level: X-Spam-Status: No, score=-6.315 tagged_above=-999 required=5 tests=[AWL=0.284, 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 yyteQEY1O1J2 for ; Sun, 28 Jun 2009 14:53:21 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 1C26B3A6B20 for ; Sun, 28 Jun 2009 14:53:20 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id A19402007A973 for ; Sun, 28 Jun 2009 23:53:39 +0200 (CEST) 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=ejMJmiqpR4gm 3gYE7aTRM9sI5cg=; b=PJ41peOlgrhCPcBFclJzMQ3C7oU4RVqdqfs+Ko0LOwNR 74dON8766BhYQaLt9DnC86pmIlAUwj/IRgxz+HDWPyy6+LCSLAW2r8L4kqR4K/R7 P+jPHDEz4sS+2RPybHrqAYQuOeBhrGK0KAtYatddj4NxfLgpgsheS71IjMt+AvU= 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=r2zkbC2PusFIEQlYXUTf edRPS4/Pf7KSISDhfyrQje+jTUpkyEpX2ZGJ7KZdFejzmCz9cONQSBiCI4pkT34v XUeHROpzeQ4XBozCaEreTcl85zdl4R+iWAWPGkVKma5nUDtp4NBvgVcjb+74uXDW GtJYStU3xHgzjXCuIPJPzhM= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id A039D2007A96D for ; Sun, 28 Jun 2009 23:53:39 +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 VVCjw634WYyj for ; Sun, 28 Jun 2009 23:53:38 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id C596F2007A810; Sun, 28 Jun 2009 23:53:38 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Sun, 28 Jun 2009 14:53:38 -0700 Message-ID: <20090628145338.53835scvb4ieobj6@mail.skype.net> Date: Sun, 28 Jun 2009 14:53:38 -0700 From: Koen Vos To: codec@ietf.org References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> <6e9223710906280417v70b9df39xe94393c3ff9de58e@mail.gmail.com> In-Reply-To: <6e9223710906280417v70b9df39xe94393c3ff9de58e@mail.gmail.com> 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] Codec BOF approved, much work needed 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: Sun, 28 Jun 2009 21:53:22 -0000 Quoting stephen botzko: > Getting concensus might require that the terms of reference include > both 6.3 kpbs and 5.3 kbps operating modes, however the terms of > reference would not indicate the technology used by those > operatoring modes. The 5.3 kbps mode is rarely used in practice because of the poor quality. But it needs to be supported to be compliant to the standard, which increases memory usage and creates a burden when implementing and porting the codec. > Obvously most ITU audio codecs require royalties. However, that is not a > natural tendency of its process. Candidate codecs can be submitted without > regard to IPR, after a competitive selection process the best codec is > standardized, and the contributors set the terms. Even if it were true that ITU standardizes the best codec, this process differs from what the IETF WG is considering. The IETF WG aims to "as much as possible choose technology that does not require paying patent royalties." ITU has never had such a goal when standardizing a codec, to my knowledge. If fact, the G.723.1 example suggests that generating extra royalties has outweighed technical merit in the ITU process. We want the exact opposite: generating *less* royalties should outweigh technical merit. It may be true that annex C of G.722.1 was standardized with the understanding of being royalty free, but G.722.1.C was never a threat to the royalties generated by other ITU standards. koen. From brian@freeswitch.org Sun Jun 28 15:24:18 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 D98CF3A6C46 for ; Sun, 28 Jun 2009 15:24:18 -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 8RfXgXzq5jVp for ; Sun, 28 Jun 2009 15:24:18 -0700 (PDT) Received: from mail-gx0-f226.google.com (mail-gx0-f226.google.com [209.85.217.226]) by core3.amsl.com (Postfix) with ESMTP id F3A893A6B55 for ; Sun, 28 Jun 2009 15:24:17 -0700 (PDT) Received: by gxk26 with SMTP id 26so3213153gxk.13 for ; Sun, 28 Jun 2009 15:24:27 -0700 (PDT) Received: by 10.90.49.8 with SMTP id w8mr5592500agw.42.1246227867554; Sun, 28 Jun 2009 15:24:27 -0700 (PDT) Received: from air.bkw.org (adsl-71-153-129-129.dsl.tul2ok.sbcglobal.net [71.153.129.129]) by mx.google.com with ESMTPS id 8sm210869agd.37.2009.06.28.15.24.26 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 28 Jun 2009 15:24:26 -0700 (PDT) Message-Id: <3D4E6C75-D9CA-4B75-9FD8-15B2CC84EAA8@freeswitch.org> From: Brian West To: Koen Vos In-Reply-To: <20090628145338.53835scvb4ieobj6@mail.skype.net> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Sun, 28 Jun 2009 17:24:24 -0500 References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> <6e9223710906280417v70b9df39xe94393c3ff9de58e@mail.gmail.com> <20090628145338.53835scvb4ieobj6@mail.skype.net> X-Mailer: Apple Mail (2.935.3) Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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: Sun, 28 Jun 2009 22:24:18 -0000 On Jun 28, 2009, at 4:53 PM, Koen Vos wrote: > Quoting stephen botzko: > >> Getting concensus might require that the terms of reference include >> both 6.3 kpbs and 5.3 kbps operating modes, however the terms of >> reference would not indicate the technology used by those >> operatoring modes. > > The 5.3 kbps mode is rarely used in practice because of the poor > quality. But it needs to be supported to be compliant to the > standard, which increases memory usage and creates a burden when > implementing and porting the codec. I have never heard a single problem with 5.3 kbps 723.1... maybe its subjective. > > > >> Obvously most ITU audio codecs require royalties. However, that is >> not a >> natural tendency of its process. Candidate codecs can be submitted >> without >> regard to IPR, after a competitive selection process the best codec >> is >> standardized, and the contributors set the terms. > > Even if it were true that ITU standardizes the best codec, this > process differs from what the IETF WG is considering. The IETF WG > aims to "as much as possible choose technology that does not require > paying patent royalties." ITU has never had such a goal when > standardizing a codec, to my knowledge. > > If fact, the G.723.1 example suggests that generating extra > royalties has outweighed technical merit in the ITU process. We want > the exact opposite: generating *less* royalties should outweigh > technical merit. Doesn't all the patents expire on g723.1 shortly? > > > It may be true that annex C of G.722.1 was standardized with the > understanding of being royalty free, but G.722.1.C was never a > threat to the royalties generated by other ITU standards. > > koen. From stephen.botzko@gmail.com Sun Jun 28 16:32:02 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 AF5F73A68BB for ; Sun, 28 Jun 2009 16:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.931 X-Spam-Level: X-Spam-Status: No, score=-0.931 tagged_above=-999 required=5 tests=[AWL=-0.633, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_WANT=2.3] 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 IpK8OpI2fyMK for ; Sun, 28 Jun 2009 16:32:01 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id C65D03A6824 for ; Sun, 28 Jun 2009 16:32:00 -0700 (PDT) Received: by fxm18 with SMTP id 18so670857fxm.37 for ; Sun, 28 Jun 2009 16:32:18 -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=okl4QshtDqf0z6BWS4KpH2m4V6COeWUoXRRR0hQxZtM=; b=inIorj/cZeQWAgKjYeqo1ESgt6MrVTuHWD5i14ZJKgKMAOYui8GyjuEYUVH9hYy5Xy mWbkouLV3lgaPBmigbVixvFQhRu1aLGFkRKXTfziuHDt2DuEArUXYSO2M6pHtARk+GD9 6Fx2iSJNHiIF/OdAtZqV3USTHsLtkejfw5ZRI= 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=B60d6jIC7y6eU0lhsABrxRGRSXuOFhHeYw6BetlSANG4et7mKwIqI3aYQZWDlVUyix c4UcsqoGFvNcS1jraBcMn1U2qtjBSorhKObC7X/RS8ae+aseJtFLdnAQn/9jwOsxdzAR 2Ey+nOyWSdwIJFRmwbrfdzwKWP2r3mri3PPh4= MIME-Version: 1.0 Received: by 10.103.12.19 with SMTP id p19mr3741824mui.66.1246231938250; Sun, 28 Jun 2009 16:32:18 -0700 (PDT) In-Reply-To: <20090628145338.53835scvb4ieobj6@mail.skype.net> References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> <6e9223710906280417v70b9df39xe94393c3ff9de58e@mail.gmail.com> <20090628145338.53835scvb4ieobj6@mail.skype.net> Date: Sun, 28 Jun 2009 19:32:18 -0400 Message-ID: <6e9223710906281632l2a24e1a2ibaa63e04b4c6f6bd@mail.gmail.com> From: stephen botzko To: Koen Vos Content-Type: multipart/alternative; boundary=0016363ba756fcb6f6046d70fbcf Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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: Sun, 28 Jun 2009 23:32:02 -0000 --0016363ba756fcb6f6046d70fbcf Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Comments in-line Stephen Botzko Polycom On Sun, Jun 28, 2009 at 5:53 PM, Koen Vos wrote: > Quoting stephen botzko: > > Getting concensus might require that the terms of reference include both >> 6.3 kpbs and 5.3 kbps operating modes, however the terms of reference would >> not indicate the technology used by those operatoring modes. >> > > The 5.3 kbps mode is rarely used in practice because of the poor quality. > But it needs to be supported to be compliant to the standard, which > increases memory usage and creates a burden when implementing and porting > the codec. > I really don't know where you are going here. First you say that someone threatened to block the standardization "because their technology wan't in it". I addressed that point, saying that that objection wouldn't be possible under the current ITU audio groups procedures. I agree that the 5.3 kbps mode is poor. Though to my ears, both modes are poor. > > > Obvously most ITU audio codecs require royalties. However, that is not a >> natural tendency of its process. Candidate codecs can be submitted >> without >> regard to IPR, after a competitive selection process the best codec is >> standardized, and the contributors set the terms. >> > > Even if it were true that ITU standardizes the best codec, this process > differs from what the IETF WG is considering. The IETF WG aims to "as much > as possible choose technology that does not require paying patent > royalties." ITU has never had such a goal when standardizing a codec, to my > knowledge. > > If fact, the G.723.1 example suggests that generating extra royalties has > outweighed technical merit in the ITU process. We want the exact opposite: > generating *less* royalties should outweigh technical merit. The fact that one operating mode of one rather old codec sucks does not really suggest anything about royalties. At most it suggests that the ITU-T made a mistake in standardizing that particular mode. > > It may be true that annex C of G.722.1 was standardized with the > understanding of being royalty free, but G.722.1.C was never a threat to the > royalties generated by other ITU standards. Now we are moving into something I can speak to with some authority, since Polycom standardized this. No matter how G.722.1C was perceived by the other participants , the decision to make it royalty free was Polycom's alone. Polycom was under no obligation to inform the ITU ahead of time that it was planning to make it royalty-free, it is sufficient to say that the terms are in accordance with the ITU RAND policy. RAND can include free of course. Again, I am not sure where you are going (if anywhere). It is totally possible to standardize something that is royalty-free in existing SDOs, including the ITU-T. That is a simple fact. The truth as long as you comply with the ITU IPR policy you can charge (or not charge) any royalties you like. The "catch" if you want to call it that, is that you need to (a) get consensus on the terms of reference (the codec requirements), and (b) win the competitive selection process. These things are not easy to do. But it is possible. A second (also simple) fact is that almost ITU-T codecs do involve royalty payments. I am not disputing that. But I am saying that it is *not* a result of their process. It is only because most of the present players there are choosing to charge royalties. The *process* is literally agnostic to the IPR terms. You don't even need to disclose that your RAND terms are free until after the standardization is completed. There is no conspiracy plot here, the ITU-T is not out to get you. The conclusion I have drawn is that the only thing anyone cares about in the proposed IETF WG is the "free" word. As long as there is a guarantee that all resulting RFCs are royalty free, the group will be a success, even if we end up with G.711. I think this is regrettable. Stephen Botzko Polycom > > > koen. > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016363ba756fcb6f6046d70fbcf Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Comments in-line

Stephen Botzko
Polycom

On Sun, Jun 28, 2009 at 5:53 PM, Koen Vos <koen.vos@skype.net> wrote= :
Quoting stephen botzko:

Getting concensus might require that the terms of reference include both 6.= 3 kpbs and 5.3 kbps operating modes, however the terms of reference would n= ot indicate the technology used by those operatoring modes.

The 5.3 kbps mode is rarely used in practice because of the poor quality. B= ut it needs to be supported to be compliant to the standard, which increase= s memory usage and creates a burden when implementing and porting the codec= .

I really don't know where you are going here.= =A0 First you say that someone threatened to block the standardization &quo= t;because their technology wan't in it".=A0 I addressed that point= , saying that that objection wouldn't be possible under the current ITU= audio groups procedures.

I agree that the 5.3 kbps mode is poor.=A0 Though to my ears, both mode= s are poor.
=A0


Obvously most ITU audio codecs require royalties. =A0However, that is not a=
natural tendency of its process. =A0Candidate codecs can be submitted witho= ut
regard to IPR, after a competitive selection process the best codec is
standardized, and the contributors set the terms.

Even if it were true that ITU standardizes the best codec, this process dif= fers from what the IETF WG is considering. The IETF WG aims to "as muc= h as possible choose technology that does not require paying patent royalti= es." ITU has never had such a goal when standardizing a codec, to my k= nowledge.

If fact, the G.723.1 example suggests that generating extra royalties has o= utweighed technical merit in the ITU process. We want the exact opposite: g= enerating *less* royalties should outweigh technical merit.
=A0
The fact that one operating mode of one rather old codec= sucks does not really suggest anything about royalties.=A0 At most it sugg= ests that the ITU-T made a mistake in standardizing that particular mode. =A0

It may be true that annex C of G.722.1 was standardized with the understand= ing of being royalty free, but G.722.1.C was never a threat to the royaltie= s generated by other ITU standards.
=A0
Now we a= re moving into something I can speak to with some authority, since Polycom = standardized this.=A0 No matter how G.722.1C was perceived by the other par= ticipants , the decision to make it royalty free was Polycom's alone.= =A0 Polycom was under no obligation to inform the ITU ahead of time that it= was planning to make it royalty-free, it is sufficient to say that the ter= ms are in accordance with the ITU RAND policy.=A0 RAND can include free of = course.=A0

Again, I am not sure where you are going (if anywhere).

It is to= tally possible to standardize something that is royalty-free in existing SD= Os, including the ITU-T.=A0 That is a simple fact.=A0 The truth as long as = you comply with the ITU IPR policy you can charge (or not charge) any royal= ties you like.=A0 The "catch" if you want to call it that, is tha= t you need to (a) get consensus on the terms of reference (the codec requir= ements), and (b) win the competitive selection process.=A0 These things are= not easy to do.=A0 But it is possible.

A second (also simple) fact is that almost ITU-T codecs do involve roya= lty payments.=A0 I am not disputing that.=A0 But I am saying that it is = not a result of their process.=A0 It is only because most of the presen= t players there are choosing to charge royalties.=A0

The process is literally agnostic to the IPR terms.=A0 You don&#= 39;t even need to disclose that your RAND terms are free until after the st= andardization is completed.=A0 There is no conspiracy plot here, the ITU-T = is not out to get you.

The conclusion I have drawn is that the only thing anyone cares about i= n the proposed IETF WG is the "free" word.=A0 As long as there is= a guarantee that all resulting RFCs are royalty free, the group will be a = success, even if we end up with G.711. I think this is regrettable.

Stephen Botzko
Polycom
=A0


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

--0016363ba756fcb6f6046d70fbcf-- From koen.vos@skype.net Sun Jun 28 23:37: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 E19B93A6ACE for ; Sun, 28 Jun 2009 23:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.33 X-Spam-Level: X-Spam-Status: No, score=-6.33 tagged_above=-999 required=5 tests=[AWL=0.269, 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 5sN4KJLw6PgW for ; Sun, 28 Jun 2009 23:37:06 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [78.141.177.9]) by core3.amsl.com (Postfix) with ESMTP id 372403A68EF for ; Sun, 28 Jun 2009 23:37:06 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 406A12007A95E for ; Mon, 29 Jun 2009 08:37:25 +0200 (CEST) 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=IU3gpo2wDnLa n1CmFm4segL+FHg=; b=T+s5LxC0xXBNLA9Pfr6Ox8MACdzPv2sBEofMngl2HYty uyVqOGk54Ujz1crndcY/ZULZfYPvk1cGBIrH+rYFr+FruUlmuaMbZHATqMLKR3t/ N4Mlg+/5OQrvrpl/kjKCTejGmAlnF81fuqRrGPIWNwBnplUzMPR6lAYWMMsXHcc= 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=rYKD3x+eslmy8y22WFGI wd9MTx9kpA81El8cF2LD/HPutLli315o87rVoRBgnKhfQM7vqiWq1GBjj1rWLPRG MTef2j7+medh0HEEEOOAPQBjx+jJ5Qhv/UC00wiN2MdcCRHVC6llF+skziKu3VZu tk0CudAXmw+cH+278gR4kCo= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 3EE9E2007A959 for ; Mon, 29 Jun 2009 08:37:25 +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 1X4X6B05iRIk for ; Mon, 29 Jun 2009 08:37:24 +0200 (CEST) Received: by mail.skype.net (Postfix, from userid 33) id 8868D2007A790; Mon, 29 Jun 2009 08:37:24 +0200 (CEST) Received: from 71.141.134.226 ([71.141.134.226]) by mail.skype.net (Horde Framework) with HTTP; Sun, 28 Jun 2009 23:37:24 -0700 Message-ID: <20090628233724.1288431u6ln8wwmc@mail.skype.net> Date: Sun, 28 Jun 2009 23:37:24 -0700 From: Koen Vos To: codec@ietf.org References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> <6e9223710906280417v70b9df39xe94393c3ff9de58e@mail.gmail.com> <20090628145338.53835scvb4ieobj6@mail.skype.net> <6e9223710906281632l2a24e1a2ibaa63e04b4c6f6bd@mail.gmail.com> In-Reply-To: <6e9223710906281632l2a24e1a2ibaa63e04b4c6f6bd@mail.gmail.com> 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] Codec BOF approved, much work needed 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, 29 Jun 2009 06:37:08 -0000 Quoting stephen botzko: > The conclusion I have drawn is that the only thing anyone cares about in the > proposed IETF WG is the "free" word. As long as there is a guarantee that > all resulting RFCs are royalty free, the group will be a success, even if we > end up with G.711. I think this is regrettable. I respectfully disagree. I think we've reached the point where "the best codec at any cost" is no longer much superior to "the best free codec". Commoditization is unavoidable, and a good thing. koen. From rjesup@wgate.com Mon Jun 29 07:21: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 BD1873A6D87 for ; Mon, 29 Jun 2009 07:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.657 X-Spam-Level: X-Spam-Status: No, score=-1.657 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, RDNS_DYNAMIC=0.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 7HqM9pUw6HCO for ; Mon, 29 Jun 2009 07:21:36 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id E595028C25B for ; Mon, 29 Jun 2009 07:21:35 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 10:21:55 -0400 To: stephen botzko References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> <6e9223710906280417v70b9df39xe94393c3ff9de58e@mail.gmail.com> From: Randell Jesup Date: Mon, 29 Jun 2009 10:22:53 -0400 Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 29 Jun 2009 14:21:55.0315 (UTC) FILETIME=[F4535430:01C9F8C4] Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup 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, 29 Jun 2009 14:21:36 -0000 stephen botzko writes: >> The ITU process has a natural tendency to come up with technology that is >> covered by patents from many of the stakeholders. This lubricates the >> process of reaching agreement. Take for example G.723.1, which is an >> inelegant combination of MPC-MLQ 6.3 kbps and ACELP 5.3 kbps. The ACELP mode >> is so much inferior to the MPC-MLQ mode that it's never used. The only >> reason it's in there is that the patent owners of ACELP wouldn't agree to >> the standard unless their technology was part of it. >Obvously most ITU audio codecs require royalties. However, that is not a >natural tendency of its process. Candidate codecs can be submitted without >regard to IPR, after a competitive selection process the best codec is >standardized, and the contributors set the terms. There is nothing I see >that is inherent in this process that "naturally tends" to result in >royalty-bearing codecs. I'd say the result is due to the companies that have >chosen to contribute there, and not the process that is used. I disagree strongly - the process you describe, while not focused on royalties, is almost certain to produce specs that generate royalties for the proposer. (They don't *have* to end up that way, if the proposer has some strategic goal that includes bypassing royalties - but that's an outside consideration.) Ironically, the ignoring of IPR other than RAND requirements, when combined with the costs involved (testing, participation, etc) and that it's supposed to be a pure runoff will rarely result in a non-royalty codec. Though I don't know the details of how it happened, look at H.264 baseline. >Also, I thought the goal was royalty-free, not patent free. Am I mistaken >here? Yes, at least to some sub-set of the people on this list. Several people have articulated that they want a codec spec that no one has to worry about licenses or IPR status (not just no royalties owed). That is a point for discussion, since that's not universally agreed to here, and it's a fundamental "what is the goal" question. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From rjesup@wgate.com Mon Jun 29 07:39:14 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 6B8E83A6B28 for ; Mon, 29 Jun 2009 07:39:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.513 X-Spam-Level: X-Spam-Status: No, score=-0.513 tagged_above=-999 required=5 tests=[AWL=-1.079, BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, MANGLED_WANT=2.3, RDNS_DYNAMIC=0.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 OVIql3XydkhY for ; Mon, 29 Jun 2009 07:39:13 -0700 (PDT) Received: from exchange1.wgate.com (pr-66-150-46-254.wgate.com [66.150.46.254]) by core3.amsl.com (Postfix) with ESMTP id 9CA3F28C298 for ; Mon, 29 Jun 2009 07:39:07 -0700 (PDT) Received: from jesup.eng.wgate.com ([10.32.2.26]) by exchange1.wgate.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 10:39:28 -0400 To: stephen botzko References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> <6e9223710906280417v70b9df39xe94393c3ff9de58e@mail.gmail.com> <20090628145338.53835scvb4ieobj6@mail.skype.net> <6e9223710906281632l2a24e1a2ibaa63e04b4c6f6bd@mail.gmail.com> From: Randell Jesup Date: Mon, 29 Jun 2009 10:40:26 -0400 In-Reply-To: <6e9223710906281632l2a24e1a2ibaa63e04b4c6f6bd@mail.gmail.com> (stephen botzko's message of "Sun\, 28 Jun 2009 19\:32\:18 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 29 Jun 2009 14:39:28.0159 (UTC) FILETIME=[67DE92F0:01C9F8C7] Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Randell Jesup 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, 29 Jun 2009 14:39:14 -0000 stephen botzko writes: >> The 5.3 kbps mode is rarely used in practice because of the poor quality. >> But it needs to be supported to be compliant to the standard, which >> increases memory usage and creates a burden when implementing and porting >> the codec. >> >I really don't know where you are going here. First you say that someone >threatened to block the standardization "because their technology wan't in >it". I addressed that point, saying that that objection wouldn't be >possible under the current ITU audio groups procedures. Ah, so you're saying the rules for codec standardization in the ITU changed then? (since g.723.1?) >> It may be true that annex C of G.722.1 was standardized with the >> understanding of being royalty free, but G.722.1.C was never a threat to the >> royalties generated by other ITU standards. > > >Now we are moving into something I can speak to with some authority, since >Polycom standardized this. No matter how G.722.1C was perceived by the >other participants , the decision to make it royalty free was Polycom's >alone. Polycom was under no obligation to inform the ITU ahead of time that >it was planning to make it royalty-free, it is sufficient to say that the >terms are in accordance with the ITU RAND policy. RAND can include free of >course. That's exactly the point of the problem - the ITU truly didn't care (beyond RAND) about the licensing status. That's what makes it likely (not given) that any random ITU standard will be subject to royalties, unless the company(s) that submitted it has a strategic reason to pass on them - they may well still hold the patents and require no-cost licenses or put other restrictions on use. >The *process* is literally agnostic to the IPR terms. You don't even need >to disclose that your RAND terms are free until after the standardization is >completed. There is no conspiracy plot here, the ITU-T is not out to get >you. Correct - it was simply created under the assumption that proposers would be taking royalties. RAND was put in to make the royalty terms reasonable to other players in the industry, so someone couldn't standardize something and then use the licensing as a club (I assume). I believe (without having taken part) the ITU scheme also has the side-effect of discouraging group participation and development, and discouraging melding of ideas during the process - it's more of a "select among company proposals" setup. I'd guess this tendency is less extreme, and in some of the joint groups I think it's been more collaberative than is typical for ITU (i.e. JVC/H.264) from what I hear. But this is all guesswork based on what I'm hearing - I'd guess I'd never be involved in ITU directly due to the monetary and hoop-jumping requirements. -- Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team rjesup@wgate.com "The fetters imposed on liberty at home have ever been forged out of the weapons provided for defence against real, pretended, or imaginary dangers from abroad." - James Madison, 4th US president (1751-1836) From jmh@joelhalpern.com Mon Jun 29 09:48:31 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 0206028C2B3 for ; Mon, 29 Jun 2009 09:48:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.508 X-Spam-Level: X-Spam-Status: No, score=-3.508 tagged_above=-999 required=5 tests=[AWL=0.091, 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 tu4eh4K+dK8P for ; Mon, 29 Jun 2009 09:48:30 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 5C86D3A6BC1 for ; Mon, 29 Jun 2009 09:48:30 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 33296430265 for ; Mon, 29 Jun 2009 09:48:51 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-172.clppva.btas.verizon.net [71.161.52.172]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 92DC44301ED for ; Mon, 29 Jun 2009 09:48:50 -0700 (PDT) Message-ID: <4A48F06F.7080208@joelhalpern.com> Date: Mon, 29 Jun 2009 12:48:47 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: codec@ietf.org References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> <6e9223710906280417v70b9df39xe94393c3ff9de58e@mail.gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] Codec BOF approved, much work needed 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, 29 Jun 2009 16:48:31 -0000 I would agree that agreeing on the goal before starting work. In this case however, I am not sure it matters. Based on experience, and on the known properties of the IETF, it is extremely unlikely that either goal (patent free, or merely royalty free) can be achieved here. Thus, the question seems to become, not "which goal do we want?" but rather "does coming close to, but missing, one or the other of these goals help?" And the collateral question would seem to be "is the IETF process a good way to approach or achieve these goals?" Yours, Joel M. Halpern Randell Jesup wrote: > stephen botzko writes: ... >> Also, I thought the goal was royalty-free, not patent free. Am I mistaken >> here? > > Yes, at least to some sub-set of the people on this list. Several > people have articulated that they want a codec spec that no one has to > worry about licenses or IPR status (not just no royalties owed). That > is a point for discussion, since that's not universally agreed to here, > and it's a fundamental "what is the goal" question. > From jean-marc.valin@octasic.com Mon Jun 29 09:58:14 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 D165B3A6BCF for ; Mon, 29 Jun 2009 09:58:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.353 X-Spam-Level: X-Spam-Status: No, score=-2.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 sYMa-VNFA5UI for ; Mon, 29 Jun 2009 09:58:14 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id C41603A6BE8 for ; Mon, 29 Jun 2009 09:58:13 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 29 Jun 2009 12:58:21 -0400 Message-ID: <4A48F2F4.8090009@octasic.com> Date: Mon, 29 Jun 2009 12:59:32 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: "Joel M. Halpern" References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> <6e9223710906280417v70b9df39xe94393c3ff9de58e@mail.gmail.com> <4A48F06F.7080208@joelhalpern.com> In-Reply-To: <4A48F06F.7080208@joelhalpern.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jun 2009 16:58:21.0093 (UTC) FILETIME=[CEAF6550:01C9F8DA] Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 29 Jun 2009 16:58:14 -0000 Joel M. Halpern wrote: > I would agree that agreeing on the goal before starting work. > In this case however, I am not sure it matters. > Based on experience, and on the known properties of the IETF, it is > extremely unlikely that either goal (patent free, or merely royalty > free) can be achieved here. Thus, the question seems to become, not > "which goal do we want?" but rather "does coming close to, but missing, > one or the other of these goals help?" Considering that these goals have already been achieved for codecs outside of standards organizations (and once at the IETF with iLBC), what makes you think it isn't achievable at the IETF? Cheers, Jean-Marc From ron.even.tlv@gmail.com Mon Jun 29 10:35:33 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 280C33A6B91 for ; Mon, 29 Jun 2009 10:35:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.289 X-Spam-Level: X-Spam-Status: No, score=-2.289 tagged_above=-999 required=5 tests=[AWL=0.310, 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 KdiXBqZThLai for ; Mon, 29 Jun 2009 10:35:32 -0700 (PDT) Received: from mail-fx0-f218.google.com (mail-fx0-f218.google.com [209.85.220.218]) by core3.amsl.com (Postfix) with ESMTP id 23BCC3A6BFF for ; Mon, 29 Jun 2009 10:35:31 -0700 (PDT) Received: by fxm18 with SMTP id 18so1118229fxm.37 for ; Mon, 29 Jun 2009 10:35:37 -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:thread-index:content-language; bh=Ti/MLYVqBPAVqiHNNJZWEklU5IosRMYtfFsPWNW5QF8=; b=Uzo7E45fXIwBGDxe+Qou2kpM2sYk6MrlU6jxL7F68JXsC3bEIfM/Mkojo2iZREu7BM enU5Xc+KdtlCg3U7yeYBTEJOPX2pa5f9KZyUqno+50Zi0wau1HFXA1LbLTMjJ+d+a0sK XTfde9dV8Fjn5PADMdfVWX5aae79gM7a94WT0= 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 :thread-index:content-language; b=qLCEHNKNrDxEwn1i1h4hnynZtei3BSaQUk49XGTAI2ML7F1jOHwuoXBQn/q7xT5qMQ XU3hnKp9ZKyTNNhHn97YzOgzP0aJ93kGiyK4Qv90xIAYZ5g/ldKSEK5HmrNqo0Spnsfe JhQDuuXLTIW1NgK5otmdw8+QFWwNLUqyQibY0= Received: by 10.103.1.17 with SMTP id d17mr4237144mui.60.1246296937426; Mon, 29 Jun 2009 10:35:37 -0700 (PDT) Received: from windows8d787f9 (bzq-79-180-107-118.red.bezeqint.net [79.180.107.118]) by mx.google.com with ESMTPS id j10sm10976611mue.59.2009.06.29.10.35.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 29 Jun 2009 10:35:36 -0700 (PDT) From: "Roni Even" To: "'Jean-Marc Valin'" , "'Joel M. Halpern'" References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> <6e9223710906280417v70b9df39xe94393c3ff9de58e@mail.gmail.com> <4A48F06F.7080208@joelhalpern.com> <4A48F2F4.8090009@octasic.com> In-Reply-To: <4A48F2F4.8090009@octasic.com> Date: Mon, 29 Jun 2009 20:35:18 +0300 Message-ID: <4a48fb68.0aa1660a.1117.7fb0@mx.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Acn42tjDKRBg+KG7S/SKXmj316MSVQABAF8Q Content-Language: en-us Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 29 Jun 2009 17:35:33 -0000 Jean-Marc, RFC 3951 iLBC is not a standard track RFC. It is not an Internet Standard in any sense. See http://www.ietf.org/u/ietfchair/info-exp.html Roni Even > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf > Of Jean-Marc Valin > Sent: Monday, June 29, 2009 8:00 PM > To: Joel M. Halpern > Cc: codec@ietf.org > Subject: Re: [codec] Codec BOF approved, much work needed > > Joel M. Halpern wrote: > > I would agree that agreeing on the goal before starting work. > > In this case however, I am not sure it matters. > > Based on experience, and on the known properties of the IETF, it is > > extremely unlikely that either goal (patent free, or merely royalty > > free) can be achieved here. Thus, the question seems to become, not > > "which goal do we want?" but rather "does coming close to, but > missing, > > one or the other of these goals help?" > > Considering that these goals have already been achieved for codecs > outside > of standards organizations (and once at the IETF with iLBC), what makes > you > think it isn't achievable at the IETF? > > Cheers, > > Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From stephen.botzko@gmail.com Mon Jun 29 10:39: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 B938328C2CE for ; Mon, 29 Jun 2009 10:39:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.042 X-Spam-Level: X-Spam-Status: No, score=-2.042 tagged_above=-999 required=5 tests=[AWL=0.556, 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 WCvnHGmltFkf for ; Mon, 29 Jun 2009 10:39:11 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id D69753A6B53 for ; Mon, 29 Jun 2009 10:38:42 -0700 (PDT) Received: by bwz9 with SMTP id 9so3410529bwz.37 for ; Mon, 29 Jun 2009 10:39:00 -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=ViQ5212m9jufej74rQtOIS7v78U7p6XOjA1tndmZEIU=; b=uhZzPA5OayZgFw8szRDrL1730rlX6hzLnAOHrLF+FLwWgiIv3VnP/MdqzXVw/8e3A5 R5VKgGGXeOyzfQYFI6XMn5seYjA/i0gf2Ex/6+e53sEzN8Y8Tr7Cku2K2uk+JrbyyFmw ao3leNaCQsWkXN82+sZSZrT1JvhCOEWMwPwKQ= 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=E9/lO/1FBYjjpknSKIpRz8T9SExGxe3HKGmKpzPeWaaGmOWKh5e48H/YNPcdXKLc82 Dh28B3/Z4TUp+HQYEygZFSk6JQo7Gf17iaag3AJbOJk9Jquqq7YIsWBwcH4F4pRx8TCa aIuH0X08giClweHSLUHLEgrlKohg9G2zysa4E= MIME-Version: 1.0 Received: by 10.103.175.8 with SMTP id c8mr4221271mup.117.1246297140344; Mon, 29 Jun 2009 10:39:00 -0700 (PDT) In-Reply-To: References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> <6e9223710906280417v70b9df39xe94393c3ff9de58e@mail.gmail.com> Date: Mon, 29 Jun 2009 13:39:00 -0400 Message-ID: <6e9223710906291039l3963ecf8sf75167294aaf778@mail.gmail.com> From: stephen botzko To: Randell Jesup Content-Type: multipart/alternative; boundary=001636b431b455b93e046d802ad3 Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 29 Jun 2009 17:39:12 -0000 --001636b431b455b93e046d802ad3 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Comments in line Stephen Botzko Polycom On Mon, Jun 29, 2009 at 10:22 AM, Randell Jesup wrote: > stephen botzko writes: > >> The ITU process has a natural tendency to come up with technology that > is > >> covered by patents from many of the stakeholders. This lubricates the > >> process of reaching agreement. Take for example G.723.1, which is an > >> inelegant combination of MPC-MLQ 6.3 kbps and ACELP 5.3 kbps. The ACELP > mode > >> is so much inferior to the MPC-MLQ mode that it's never used. The only > >> reason it's in there is that the patent owners of ACELP wouldn't agree > to > >> the standard unless their technology was part of it. > > >Obvously most ITU audio codecs require royalties. However, that is not a > >natural tendency of its process. Candidate codecs can be submitted > without > >regard to IPR, after a competitive selection process the best codec is > >standardized, and the contributors set the terms. There is nothing I see > >that is inherent in this process that "naturally tends" to result in > >royalty-bearing codecs. I'd say the result is due to the companies that > have > >chosen to contribute there, and not the process that is used. > > I disagree strongly - the process you describe, while not focused on > royalties, is almost certain to produce specs that generate royalties > for the proposer. (They don't *have* to end up that way, if the > proposer has some strategic goal that includes bypassing royalties - but > that's an outside consideration.) Ironically, the ignoring of IPR other > than RAND requirements, when combined with the costs involved (testing, > participation, etc) and that it's supposed to be a pure runoff will > rarely result in a non-royalty codec. > > Though I don't know the details of how it happened, look at H.264 baseline. I would say that the proponents here do have a strategic goal of bypassing royalties, and several have the resources to pay for the testing and membership fees. For many (not all), up-front costs to do the standardization would be acceptable, and we've found that there is quite a bit of value in doing scientifically controlled, reproducible, statistically valid listening tests in multiple labs, using native speakers and multiple languages. At this point it isn't obvious how the costs will compare (other than that the membership fees will be lower), since there has not been much discussion on the testing process, let alone consensus on it. If we were talking about a *video* codec group, I would agree that the ITU-T video process could not result in a royalty-free codec. The video group in the ITU uses a totally different process from the audio group. It is a fully collaborative process, where any sufficiently useful compression tool is encorporated into a shared source reference model. In the case of H.264, it was done by JVT,(ITU-T in combination with MPEG/ISO), using MPEG rules as well as ITU-T rules. It is true that the royalty-free H.264 baseline goal failed (Polycom was a strong proponent of that goal BTW). That's because (given the ITU-T video process), any single contributor can destroy the royalty free goal. The entire video group is contributing to the final codec, so there are a lot more contributors. That is quite different from the audio standardization process, where the contributors for each candidate codec control the technology used in their candidate, and can get private agreement on the terms before they collaborate. > > > >Also, I thought the goal was royalty-free, not patent free. Am I mistaken > >here? > > Yes, at least to some sub-set of the people on this list. Several > people have articulated that they want a codec spec that no one has to > worry about licenses or IPR status (not just no royalties owed). That > is a point for discussion, since that's not universally agreed to here, > and it's a fundamental "what is the goal" question. > I think its a quite important point. Patent-free is difficult for many companies to establish (most large companies actually don't know their patent portfolios well enough to know exactly what they cover). Also many companies do not want to risk "disclaiming" what their patents cover. Current IPR reporting in the IETF is focused on terms for the IPR you hold, and is not designed for positive confirmation that you don't hold IPR. If the goal is patent free, then the group would need to infer that from the absense of an IPR declaration, which seems a bit roundabout. Why exclude patented technology if the patent holder is willing to offer it on acceptable royalty-free terms? In my opinion, the ideal would be royalty free, and conditional on reciprocity. That means if someone else sues you, that you could countersue with your patent, but you could not initiate any lawsuit. That permits companies to build a defensive-only patent portfolio, and reduces the risk that some third party (who practices the standard) would initiate a suit. > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS > team > rjesup@wgate.com > "The fetters imposed on liberty at home have ever been forged out of the > weapons > provided for defence against real, pretended, or imaginary dangers from > abroad." > - James Madison, 4th US president (1751-1836) > --001636b431b455b93e046d802ad3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Comments in line

Stephen Botzko
Polycom

On Mon, Jun 29, 2009 at 10:22 AM, Randell Jesup = <rjesup@wgate.com> wro= te:
stephen botzko <stephen.bot= zko@gmail.com> writes:
>> The ITU process has a natural tendency to = come up with technology that is
>> covered by patents from many of the stakeholders. This lubricates = the
>> process of reaching agreement. Take for example G.723.1, which is = an
>> inelegant combination of MPC-MLQ 6.3 kbps and ACELP 5.3 kbps. The = ACELP mode
>> is so much inferior to the MPC-MLQ mode that it's never used. = The only
>> reason it's in there is that the patent owners of ACELP wouldn= 't agree to
>> the standard unless their technology was part of it.

>Obvously most ITU audio codecs require royaltie= s. =A0However, that is not a
>natural tendency of its process. =A0Candidate codecs can be submitted w= ithout
>regard to IPR, after a competitive selection process the best codec is<= br> >standardized, and the contributors set the terms. =A0There is nothing I= see
>that is inherent in this process that "naturally tends" to re= sult in
>royalty-bearing codecs. I'd say the result is due to the companies = that have
>chosen to contribute there, and not the process that is used.

I disagree strongly - the process you describe, while not focused on<= br> royalties, is almost certain to produce specs that generate royalties
for the proposer. =A0(They don't *have* to end up that way, if the
proposer has some strategic goal that includes bypassing royalties - but that's an outside consideration.) =A0Ironically, the ignoring of IPR ot= her
than RAND requirements, when combined with the costs involved (testing,
participation, etc) and that it's supposed to be a pure runoff will
rarely result in a non-royalty codec.

Though I don't know the details of how it happened, look at H.264 basel= ine.

I would say that the proponents here do have a st= rategic goal of bypassing royalties, and several have the resources to pay = for the testing and membership fees.=A0 For many (not all), up-front costs = to do the standardization would be acceptable, and we've found that the= re is quite a bit of value in doing scientifically controlled, reproducible= , statistically valid listening tests in multiple labs, using native speake= rs and multiple languages.=A0 At this point it isn't obvious how the co= sts will compare (other than that the membership fees will be lower), since= there has not been much discussion on the testing process, let alone conse= nsus on it.

If we were talking about a video codec group, I would agree that= the ITU-T video process could not result in a royalty-free codec. The vide= o group in the ITU uses a totally different process from the audio group.= =A0 It is a fully collaborative process, where any sufficiently useful comp= ression tool is encorporated into a shared source reference model. In the c= ase of H.264, it was done by JVT,(ITU-T in combination with MPEG/ISO), usin= g MPEG rules as well as ITU-T rules.

It is true that the royalty-free H.264 baseline goal failed (Polycom wa= s a strong proponent of that goal BTW).=A0 That's because (given the IT= U-T video process), any single contributor can destroy the royalty free goa= l.=A0 The entire video group is contributing to the final codec, so there a= re a lot more contributors.=A0 That is quite different from the audio stand= ardization process, where the contributors for each candidate codec control= the technology used in their candidate, and can get private agreement on t= he terms before they collaborate.

=A0
=

>Also, I thought the goal was royalty-free, not patent free. =A0Am I mis= taken
>here?

Yes, at least to some sub-set of the people on this list. =A0Several<= br> people have articulated that they want a codec spec that no one has to
worry about licenses or IPR status (not just no royalties owed). =A0That is a point for discussion, since that's not universally agreed to here,=
and it's a fundamental "what is the goal" question.

I think its a quite im= portant point.=A0 Patent-free is difficult for many companies to establish = (most large companies actually don't know their patent portfolios well = enough to know exactly what they cover).=A0 Also many companies do not want= to risk "disclaiming" what their patents cover.

Current IPR reporting in the IETF is focused on terms for the IPR you h= old, and is not designed for positive confirmation that you don't hold = IPR.=A0 If the goal is patent free, then the group would need to infer that= from the absense of an IPR declaration, which seems a bit roundabout.

Why exclude patented technology if the patent holder is willing to offe= r it on acceptable royalty-free terms?

In my opinion, the ideal woul= d be royalty free, and conditional on reciprocity.=A0 That means if someone= else sues you, that you could countersue with your patent, but you could n= ot initiate any lawsuit.=A0 That permits companies to build a defensive-onl= y patent portfolio, and reduces the risk that some third party (who practic= es the standard) would initiate a suit.

--
Randell Jesup, Worldgate (develope= rs of the Ojo videophone), ex-Amiga OS team
rjesup@wgate.com
"The fetters imposed on liberty at home have ever been forged out of t= he weapons
provided for defence against real, pretended, or imaginary dangers from abr= oad."
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- James Madison, 4th US president (1751-183= 6)

--001636b431b455b93e046d802ad3-- From stephen.botzko@gmail.com Mon Jun 29 10:58: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 BC1153A6B53 for ; Mon, 29 Jun 2009 10:58:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.075 X-Spam-Level: X-Spam-Status: No, score=-2.075 tagged_above=-999 required=5 tests=[AWL=0.523, 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 h3hR2+kKifSD for ; Mon, 29 Jun 2009 10:58:06 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 43A4D3A6B36 for ; Mon, 29 Jun 2009 10:58:06 -0700 (PDT) Received: by bwz9 with SMTP id 9so3421451bwz.37 for ; Mon, 29 Jun 2009 10:58: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:message-id:subject:from:to:cc:content-type; bh=XqBhHCNkt28bDI0WeAEnU+dz2PjSFoug3gd+HV0uNo8=; b=spTDUJPQi5hV+JgaYJgCp7RVf37g01axDlGZ4cWu5IKvlz1GHIhPBC9cDuj7FmYpa6 6rH3N/qoKO8W0T3oPaTArBvU2hWETgjGtZNH6pVMrJZTmmItXY4jnAzByJWWfm9hI6xU WXYOnkI5lnRKSANy6m4J0rnUKfYw6+XRl8YaQ= 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=QLjCB+hBXy5TG7pdiOnLCLjtZGZ5QNvam1l2wXkO3hqitdL3Mnmfibu/1UkudWPYxI tvdqYMSrySCITRpTqCpBUK91v0LI9ALjV3dys2pFYmYntASlNXOxO56rQFYjdGyvtfYh F3VWyCSqbKPMHXJa/Jrr2TXvjPpB9nVYmvlao= MIME-Version: 1.0 Received: by 10.103.12.19 with SMTP id p19mr4288203mui.66.1246298303561; Mon, 29 Jun 2009 10:58:23 -0700 (PDT) In-Reply-To: <4A48F06F.7080208@joelhalpern.com> References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> <6e9223710906280417v70b9df39xe94393c3ff9de58e@mail.gmail.com> <4A48F06F.7080208@joelhalpern.com> Date: Mon, 29 Jun 2009 13:58:23 -0400 Message-ID: <6e9223710906291058v5780500cyd2e3d45266142bae@mail.gmail.com> From: stephen botzko To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=0016363ba756ab022d046d806f82 Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 29 Jun 2009 17:58:08 -0000 --0016363ba756ab022d046d806f82 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit At this point in the discussion, I would agree with your comment. Though I'd suggest that patent free is less likely than royalty free. I definitely think these goals are easier to achieve in an non-IETF consortium, where all participants agree up front to the IPR rules in play, open-source, etc. In the IETF, the only up front agreement is to the IETF procedures, not the constrained (unwritten?) rules that this proposed group would need. It will be harder in the IETF. Stephen Botzko Polycom On Mon, Jun 29, 2009 at 12:48 PM, Joel M. Halpern wrote: > I would agree that agreeing on the goal before starting work. > In this case however, I am not sure it matters. > Based on experience, and on the known properties of the IETF, it is > extremely unlikely that either goal (patent free, or merely royalty free) > can be achieved here. Thus, the question seems to become, not "which goal > do we want?" but rather "does coming close to, but missing, one or the other > of these goals help?" > > And the collateral question would seem to be "is the IETF process a good > way to approach or achieve these goals?" > > Yours, > Joel M. Halpern > > > Randell Jesup wrote: > >> stephen botzko writes: >> > ... > >> Also, I thought the goal was royalty-free, not patent free. Am I mistaken >>> here? >>> >> >> Yes, at least to some sub-set of the people on this list. Several >> people have articulated that they want a codec spec that no one has to >> worry about licenses or IPR status (not just no royalties owed). That >> is a point for discussion, since that's not universally agreed to here, >> and it's a fundamental "what is the goal" question. >> >> _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0016363ba756ab022d046d806f82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable At this point in the discussion, I would agree with your comment.=A0 Though= I'd suggest that patent free is less likely than royalty free.

= I definitely think these goals are easier to achieve in an non-IETF consort= ium, where all participants agree up front to the IPR rules in play, open-s= ource, etc.=A0 In the IETF, the only up front agreement is to the IETF proc= edures, not the constrained (unwritten?) rules that this proposed group wou= ld need.=A0 It will be harder in the IETF.

Stephen Botzko
Polycom



On = Mon, Jun 29, 2009 at 12:48 PM, Joel M. Halpern <jmh@joelhalpern.com> wrote:<= br>
I would agree tha= t agreeing on the goal before starting work.
In this case however, I am not sure it matters.
Based on experience, and on the known properties of the IETF, it is extreme= ly unlikely that either goal (patent free, or merely royalty free) can be a= chieved here. =A0Thus, the question seems to become, not "which goal d= o we want?" but rather "does coming close to, but missing, one or= the other of these goals help?"

And the collateral question would seem to be "is the IETF process a go= od way to approach or achieve these goals?"

Yours,
Joel M. Halpern



Randell Jesup wrote:
stephen botzko <stephen.botzko@gmail.com> writes:
...

Also, I thought the goal was royalty-free, not patent free. =A0Am I mistake= n
here?

Yes, at least to some sub-set of the people on this list. =A0Several
people have articulated that they want a codec spec that no one has to
worry about licenses or IPR status (not just no royalties owed). =A0That is a point for discussion, since that's not universally agreed to here,=
and it's a fundamental "what is the goal" question.

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

--0016363ba756ab022d046d806f82-- From stephen.botzko@gmail.com Mon Jun 29 11:05:39 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 1516C3A6B6A for ; Mon, 29 Jun 2009 11:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.954 X-Spam-Level: X-Spam-Status: No, score=-0.954 tagged_above=-999 required=5 tests=[AWL=-0.656, BAYES_00=-2.599, HTML_MESSAGE=0.001, MANGLED_WANT=2.3] 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 nZqzWFvlbPhn for ; Mon, 29 Jun 2009 11:05:38 -0700 (PDT) Received: from mail-bw0-f213.google.com (mail-bw0-f213.google.com [209.85.218.213]) by core3.amsl.com (Postfix) with ESMTP id 4DEA03A6895 for ; Mon, 29 Jun 2009 11:05:36 -0700 (PDT) Received: by bwz9 with SMTP id 9so3425941bwz.37 for ; Mon, 29 Jun 2009 11:05: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:message-id:subject:from:to:cc:content-type; bh=K7sACkLrJkLKqiwwWBRGVbDQkHQCTVGwMKtkX8QsTig=; b=tNEbAuFdQ0m/EmuuZqVfL5M+VEiPzNu+6i47yret/2KpY80xyZK51ApANhzCeKSgqa yV+l1WbsysXD/hTZJXWdwAfHSA3zHvj6vylOnpZv6AYEBvUbJF4MdfEjx2wUjPRmszrg fsS5MhKHXoZ4tsSZe3LtSZolDqP+1c+ohGp/g= 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=qCyNL9eiIR99RQORrGr6015MIWVqCYv1WUFQn4R4MjSuez8P7cJnPt5wE+2nWXUkug M0Iqdx6S+DOOEGCqEmsnAnGbOouNfwGJ+COIHwJAbENUBWx8aluHMRyopNu32a+yP4eo WKc8k083J0Cq5DbkMqyQVtSTXTLDk3Y+z3Qcc= MIME-Version: 1.0 Received: by 10.103.24.17 with SMTP id b17mr4244950muj.71.1246298754169; Mon, 29 Jun 2009 11:05:54 -0700 (PDT) In-Reply-To: References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> <6e9223710906280417v70b9df39xe94393c3ff9de58e@mail.gmail.com> <20090628145338.53835scvb4ieobj6@mail.skype.net> <6e9223710906281632l2a24e1a2ibaa63e04b4c6f6bd@mail.gmail.com> Date: Mon, 29 Jun 2009 14:05:54 -0400 Message-ID: <6e9223710906291105t21967228he942ac292b87b056@mail.gmail.com> From: stephen botzko To: Randell Jesup Content-Type: multipart/alternative; boundary=0016e65a0d8686c366046d808a5e Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 29 Jun 2009 18:05:39 -0000 --0016e65a0d8686c366046d808a5e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit >>> Ah, so you're saying the rules for codec standardization in the ITU changed then? (since g.723.1?) >>> No. The process could have changed, but another possibility is that Koen is mistaken on the history. I wasn't in those meetings (13-15 years ago); I will not speculate about what happened and why. Regards, Stephen Botzko Polycom On Mon, Jun 29, 2009 at 10:40 AM, Randell Jesup wrote: > stephen botzko writes: > >> The 5.3 kbps mode is rarely used in practice because of the poor > quality. > >> But it needs to be supported to be compliant to the standard, which > >> increases memory usage and creates a burden when implementing and > porting > >> the codec. > >> > >I really don't know where you are going here. First you say that someone > >threatened to block the standardization "because their technology wan't in > >it". I addressed that point, saying that that objection wouldn't be > >possible under the current ITU audio groups procedures. > > Ah, so you're saying the rules for codec standardization in the ITU > changed then? (since g.723.1?) > > >> It may be true that annex C of G.722.1 was standardized with the > >> understanding of being royalty free, but G.722.1.C was never a threat to > the > >> royalties generated by other ITU standards. > > > > > >Now we are moving into something I can speak to with some authority, since > >Polycom standardized this. No matter how G.722.1C was perceived by the > >other participants , the decision to make it royalty free was Polycom's > >alone. Polycom was under no obligation to inform the ITU ahead of time > that > >it was planning to make it royalty-free, it is sufficient to say that the > >terms are in accordance with the ITU RAND policy. RAND can include free > of > >course. > > That's exactly the point of the problem - the ITU truly didn't care > (beyond RAND) about the licensing status. That's what makes it likely > (not given) that any random ITU standard will be subject to royalties, > unless the company(s) that submitted it has a strategic reason to pass > on them - they may well still hold the patents and require no-cost > licenses or put other restrictions on use. > > >The *process* is literally agnostic to the IPR terms. You don't even need > >to disclose that your RAND terms are free until after the standardization > is > >completed. There is no conspiracy plot here, the ITU-T is not out to get > >you. > > Correct - it was simply created under the assumption that proposers > would be taking royalties. RAND was put in to make the royalty terms > reasonable to other players in the industry, so someone couldn't > standardize something and then use the licensing as a club (I assume). > > I believe (without having taken part) the ITU scheme also has the > side-effect of discouraging group participation and development, and > discouraging melding of ideas during the process - it's more of a > "select among company proposals" setup. I'd guess this tendency is less > extreme, and in some of the joint groups I think it's been more > collaberative than is typical for ITU (i.e. JVC/H.264) from what I hear. > But this is all guesswork based on what I'm hearing - I'd guess I'd > never be involved in ITU directly due to the monetary and hoop-jumping > requirements. > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS > team > rjesup@wgate.com > "The fetters imposed on liberty at home have ever been forged out of the > weapons > provided for defence against real, pretended, or imaginary dangers from > abroad." > - James Madison, 4th US president (1751-1836) > --0016e65a0d8686c366046d808a5e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
Ah, so you're saying the rules for codec standardizatio= n in the ITU
changed then? (since g.723.1?)
>>>

No.=A0 The process co= uld have changed, but another possibility is that Koen is mistaken on the h= istory.=A0 I wasn't in those meetings (13-15 years ago); I will not spe= culate about what happened and why.

Regards,
Stephen Botzko
Polycom

On Mon, Jun 29, 2009 at 10:40 AM, Randell Jesup <rjesup@wgate.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, 2= 04, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
stephen botzko <stephen.botzko@gmail.com> writes:
>> The 5.3 kbps mode is rarely used in practi= ce because of the poor quality.
>> But it needs to be supported to be compliant to the standard, whic= h
>> increases memory usage and creates a burden when implementing and = porting
>> the codec.
>>
>I really don't know where you are going here. =A0First you say that= someone
>threatened to block the standardization "because their technology = wan't in
>it". =A0I addressed that point, saying that that objection wouldn&= #39;t be
>possible under the current ITU audio groups procedures.

Ah, so you're saying the rules for codec standardization in the I= TU
changed then? (since g.723.1?)

>> It may be true that annex C of G.722.1 was standardized with the >> understanding of being royalty free, but G.722.1.C was never a thr= eat to the
>> royalties generated by other ITU standards.
>
>
>Now we are moving into something I can speak to with some authority, si= nce
>Polycom standardized this. =A0No matter how G.722.1C was perceived by t= he
>other participants , the decision to make it royalty free was Polycom&#= 39;s
>alone. =A0Polycom was under no obligation to inform the ITU ahead of ti= me that
>it was planning to make it royalty-free, it is sufficient to say that t= he
>terms are in accordance with the ITU RAND policy. =A0RAND can include f= ree of
>course.

That's exactly the point of the problem - the ITU truly didn'= t care
(beyond RAND) about the licensing status. =A0That's what makes it likel= y
(not given) that any random ITU standard will be subject to royalties,
unless the company(s) that submitted it has a strategic reason to pass
on them - they may well still hold the patents and require no-cost
licenses or put other restrictions on use.

>The *process* is literally agnostic to the IPR terms. =A0You don't = even need
>to disclose that your RAND terms are free until after the standardizati= on is
>completed. =A0There is no conspiracy plot here, the ITU-T is not out to= get
>you.

Correct - it was simply created under the assumption that proposers would be taking royalties. =A0RAND was put in to make the royalty terms
reasonable to other players in the industry, so someone couldn't
standardize something and then use the licensing as a club (I assume).

I believe (without having taken part) the ITU scheme also has the
side-effect of discouraging group participation and development, and
discouraging melding of ideas during the process - it's more of a
"select among company proposals" setup. =A0I'd guess this ten= dency is less
extreme, and in some of the joint groups I think it's been more
collaberative than is typical for ITU (i.e. JVC/H.264) from what I hear. But this is all guesswork based on what I'm hearing - I'd guess I&#= 39;d
never be involved in ITU directly due to the monetary and hoop-jumping
requirements.

--
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS te= am
rjesup@wgate.com
"The fetters imposed on liberty at home have ever been forged out of t= he weapons
provided for defence against real, pretended, or imaginary dangers from abr= oad."
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0- James Madison, 4th US president (1751-183= 6)

--0016e65a0d8686c366046d808a5e-- From xiphmont@gmail.com Mon Jun 29 11:24: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 4A7573A6C17 for ; Mon, 29 Jun 2009 11:24:12 -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 fHkElE6pJqir for ; Mon, 29 Jun 2009 11:24:11 -0700 (PDT) Received: from qw-out-2122.google.com (qw-out-2122.google.com [74.125.92.24]) by core3.amsl.com (Postfix) with ESMTP id 5485B3A689F for ; Mon, 29 Jun 2009 11:24:02 -0700 (PDT) Received: by qw-out-2122.google.com with SMTP id 5so1897900qwd.31 for ; Mon, 29 Jun 2009 11:24: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:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=/rSZe0jjHdMZNTnW6d4aaPVbguLx2XB0BvXTigL/eGk=; b=lPfoVDdLSInrfr16w/9JoneObSbqgWfjJLAPwtQxLhkqZVncmNdLCSBvHCkVE+fyiY EQXS03UXSWjYqAIuEX7/PV7AaBbBQB3VEaCabLHYatRf379SAcDyZlF6IuJv8yUW2X0L wk0aL7/n+lTx/Btil7ilkvQzBS/Q8CMkkAAow= 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:content-transfer-encoding; b=aGTXNYFJyW76L1GQHOJAPuupcUNStgEuOeWp1H7tK6k1W3o/+PqiDAZmZ1Nt/JyhCK xrgIpTN/rBocrAlbOQmIAtB8ovvP+G8beXFfYFQla1R/Zq5ev9O39hxkzCH1LZP2sy97 i6EyhKi44hnULOtAgLIkE1574TFPpOlcZe51E= MIME-Version: 1.0 Received: by 10.231.36.131 with SMTP id t3mr714088ibd.41.1246299860325; Mon, 29 Jun 2009 11:24:20 -0700 (PDT) In-Reply-To: <6e9223710906291058v5780500cyd2e3d45266142bae@mail.gmail.com> References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> <6e9223710906280417v70b9df39xe94393c3ff9de58e@mail.gmail.com> <4A48F06F.7080208@joelhalpern.com> <6e9223710906291058v5780500cyd2e3d45266142bae@mail.gmail.com> Date: Mon, 29 Jun 2009 14:24:20 -0400 Message-ID: <806dafc20906291124r6da61b0l245dcdf655bae5fb@mail.gmail.com> From: Christopher Montgomery To: stephen botzko Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 29 Jun 2009 18:24:12 -0000 On Mon, Jun 29, 2009 at 1:58 PM, stephen botzko w= rote: > At this point in the discussion, I would agree with your comment.=A0 Thou= gh > I'd suggest that patent free is less likely than royalty free. Not so much 'harder' as suffering from a halting problem. There is no equivalent of summary judgement for patents, and as such every product released to the world every day from any company or any group can be litigated against. In most of the world with a US-style patent system, barratry is not in itself illegal, and as such a troll does not even need to have a glimmer of hope if simply lobbing a grenade is itself strategically advantageous. This is true for every piece of software on earth. I for one am not prepared to give up, go home, and become a farmer. First let's seperate the patent threats. There are the 'legitimate' IPR holders, such as the large players in the ITU. Do we expect these players are gaming the system with such recklessness that they will withold discovered knowledge of infringement for years at a time in order to maximize the damages recovered in eventual litigation? Even in the US, this is becoming deeply frowned upon in the courts. So, whether these entities are in a WG that compels disclosure or not, I would expect these entities to be 'good' players, or at least keep within the rules. Then there are the trolls. Trolls are of fully equal danger to IPR-encumbered as well as any attempts at fully unencumbered technology. I'd actually say less... because it makes less sense to sue where money isn't involved. This is a threat entirely outside any groups' control. So the 'main threat' is the large, legitimate players. It's been voiced several times that an open, transparent working group would suffer from IP 'theft'; that is people watching the process and going off to patent immediate improvements. This is an easy one: Publish everything. Anything published is removed from 'theft' risk. Subsequent improvements are still exposed to patents, but this is a legitimate use of the patent system. Monty From tme@americafree.tv Mon Jun 29 15:25:11 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 5E5753A6BEE for ; Mon, 29 Jun 2009 15:25:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.625 X-Spam-Level: X-Spam-Status: No, score=-2.625 tagged_above=-999 required=5 tests=[AWL=-0.026, 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 yyZ8gPySvk68 for ; Mon, 29 Jun 2009 15:25:09 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id B1E3B3A6A89 for ; Mon, 29 Jun 2009 15:25:09 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id 134534200DF5; Mon, 29 Jun 2009 18:25:30 -0400 (EDT) Message-Id: <69963E1E-16B1-413D-AE2A-FAA8C3D547A8@americafree.tv> From: Marshall Eubanks To: stephen botzko In-Reply-To: <6e9223710906291039l3963ecf8sf75167294aaf778@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 29 Jun 2009 18:25:29 -0400 References: <20090626114355.16720yb6jhzzxxij@mail.skype.net> <6e9223710906270338h2f928c30red1b3f9324c8562d@mail.gmail.com> <20090627141050.72075gnkxrgkelzu@mail.skype.net> <6e9223710906280417v70b9df39xe94393c3ff9de58e@mail.gmail.com> <6e9223710906291039l3963ecf8sf75167294aaf778@mail.gmail.com> X-Mailer: Apple Mail (2.935.3) Cc: codec@ietf.org Subject: Re: [codec] Codec BOF approved, much work needed 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, 29 Jun 2009 22:25:11 -0000 On Jun 29, 2009, at 1:39 PM, stephen botzko wrote: > Comments in line > > Stephen Botzko > Polycom > > On Mon, Jun 29, 2009 at 10:22 AM, Randell Jesup > wrote: > stephen botzko writes: > >> The ITU process has a natural tendency to come up with technology > that is > >> covered by patents from many of the stakeholders. This lubricates > the > >> process of reaching agreement. Take for example G.723.1, which is > an > >> inelegant combination of MPC-MLQ 6.3 kbps and ACELP 5.3 kbps. The > ACELP mode > >> is so much inferior to the MPC-MLQ mode that it's never used. The > only > >> reason it's in there is that the patent owners of ACELP wouldn't > agree to > >> the standard unless their technology was part of it. > > >Obvously most ITU audio codecs require royalties. However, that is > not a > >natural tendency of its process. Candidate codecs can be submitted > without > >regard to IPR, after a competitive selection process the best codec > is > >standardized, and the contributors set the terms. There is nothing > I see > >that is inherent in this process that "naturally tends" to result in > >royalty-bearing codecs. I'd say the result is due to the companies > that have > >chosen to contribute there, and not the process that is used. > > I disagree strongly - the process you describe, while not focused on > royalties, is almost certain to produce specs that generate royalties > for the proposer. (They don't *have* to end up that way, if the > proposer has some strategic goal that includes bypassing royalties - > but > that's an outside consideration.) Ironically, the ignoring of IPR > other > than RAND requirements, when combined with the costs involved > (testing, > participation, etc) and that it's supposed to be a pure runoff will > rarely result in a non-royalty codec. > > Though I don't know the details of how it happened, look at H.264 > baseline. > > I would say that the proponents here do have a strategic goal of > bypassing royalties, and several have the resources to pay for the > testing and membership fees. For many (not all), up-front costs to > do the standardization would be acceptable, and we've found that > there is quite a bit of value in doing scientifically controlled, > reproducible, statistically valid listening tests in multiple labs, > using native speakers and multiple languages. At this point it > isn't obvious how the costs will compare (other than that the > membership fees will be lower), since there has not been much > discussion on the testing process, let alone consensus on it. > > If we were talking about a video codec group, I would agree that the > ITU-T video process could not result in a royalty-free codec. The > video group in the ITU uses a totally different process from the > audio group. It is a fully collaborative process, where any > sufficiently useful compression tool is encorporated into a shared > source reference model. In the case of H.264, it was done by JVT, > (ITU-T in combination with MPEG/ISO), using MPEG rules as well as > ITU-T rules. > > It is true that the royalty-free H.264 baseline goal failed (Polycom > was a strong proponent of that goal BTW). That's because (given the > ITU-T video process), any single contributor can destroy the royalty > free goal. Just for my curiosity, would a different SDO approach (say, the IETF's or some other) have resulted in a different outcome vis-a-vis royalties ? Regards Marshall > The entire video group is contributing to the final codec, so > there are a lot more contributors. That is quite different from the > audio standardization process, where the contributors for each > candidate codec control the technology used in their candidate, and > can get private agreement on the terms before they collaborate. > > > > > >Also, I thought the goal was royalty-free, not patent free. Am I > mistaken > >here? > > Yes, at least to some sub-set of the people on this list. Several > people have articulated that they want a codec spec that no one has to > worry about licenses or IPR status (not just no royalties owed). That > is a point for discussion, since that's not universally agreed to > here, > and it's a fundamental "what is the goal" question. > > I think its a quite important point. Patent-free is difficult for > many companies to establish (most large companies actually don't > know their patent portfolios well enough to know exactly what they > cover). Also many companies do not want to risk "disclaiming" what > their patents cover. > > Current IPR reporting in the IETF is focused on terms for the IPR > you hold, and is not designed for positive confirmation that you > don't hold IPR. If the goal is patent free, then the group would > need to infer that from the absense of an IPR declaration, which > seems a bit roundabout. > > Why exclude patented technology if the patent holder is willing to > offer it on acceptable royalty-free terms? > > In my opinion, the ideal would be royalty free, and conditional on > reciprocity. That means if someone else sues you, that you could > countersue with your patent, but you could not initiate any > lawsuit. That permits companies to build a defensive-only patent > portfolio, and reduces the risk that some third party (who practices > the standard) would initiate a suit. > > -- > Randell Jesup, Worldgate (developers of the Ojo videophone), ex- > Amiga OS team > rjesup@wgate.com > "The fetters imposed on liberty at home have ever been forged out of > the weapons > provided for defence against real, pretended, or imaginary dangers > from abroad." > - James Madison, 4th US president (1751-1836) > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec Regards Marshall Eubanks CEO / AmericaFree.TV From thorvald@natvig.com Tue Jun 30 06:48:32 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 35FA63A67CF for ; Tue, 30 Jun 2009 06:48:32 -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 2CGDAnS1E9D7 for ; Tue, 30 Jun 2009 06:48:31 -0700 (PDT) Received: from mix.hive.no (mumble.hive.no [IPv6:2001:700:2300:1e::1:201]) by core3.amsl.com (Postfix) with ESMTP id C30903A6E6F for ; Tue, 30 Jun 2009 06:48:30 -0700 (PDT) Received: from [129.241.189.109] (dhcp-189109.fa-s.ntnu.no [129.241.189.109]) (authenticated bits=0) by mix.hive.no (8.13.8/8.13.8) with ESMTP id n5UDmkgj018202 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 30 Jun 2009 15:48:47 +0200 Message-ID: <4A4A17B0.6080402@natvig.com> Date: Tue, 30 Jun 2009 15:48:32 +0200 From: Thorvald Natvig User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: codec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.92.1/9522/Tue Jun 30 09:55:22 2009 on mix.hive.no X-Virus-Status: Clean Subject: [codec] The need for a open source compatible codec 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, 30 Jun 2009 13:48:32 -0000 Hello, I'm the author of Mumble, an open source VoIP application, and I've been following the discussion here. For me, a codec, even if it's free (as in beer), can't be used if it requires filing paperwork. I code open source applications; I have no desire or possibility to control what users do with my application after they download it. They may change it, rename it and redistribute it either as open source or commercially, and it is important for me that they have this right. So proprietary codecs are useless for me. A standardized and free (as in speech) codec would make it much easier to create interoperable applications, as it will fill the need for a common, high quality codec that everyone can support. Sincerely, Thorvald
<= FONT SIZE=3D"5">Hi Stephen,

With all respect and putting on my Internet engineer hat and as a former IS= P employee, most of the worlds multimedia applications traffic goes o= ver the Internet using protocols and codecs that have been invented not by t= he powerhouses you are referring to (remember their OSI, ATM and H.323?). P2P video and IPTV (The Flicker or YouTube varieties) are just examples of = pure Internet multimedia.
RTP and SIP came from the IETF, and why are all the codec vendors making su= re they get an IETF AVT profile?

I fail to understand (though I do) the opposition to new players in the fie= ld that may include innovators of the sort there are so many on the Internet= .

Last but not least, is not for the market to decide, instead of trying to k= ill the baby before it is even born?

It seems there are here two irreconcilable camps: The established industry = and new Internet players.
Can we please take the Internet view here in the IETF venue?

My strict personal two cents,

Henry


On 6/23/09 7:08 PM, "Stephan Wenger" <stewe@stewe.org> wrote:

Hi Jason,
I don't think I can give you a fixed number.  But if I see at least so= me of
the folks who have worked for a couple of years in the ITU, 3GPP, MPEG, or<= BR> 3GPP2 being committed to this effort, I would feel a lot better.  It's= not
only numbers that count, its also previous experience in standardization of=
speech codecs.  If those people come from known IPR powerhouses (and t= hose
powerhouses thereby show willingness to support an RF effort as it is argue= d
for here), you would find me enthusiastically agreeing to a new WG.
Regards,
Stephan


On 6/23/09 7:41 PM, "Jason Fischl" <jason.fischl@skype.net> wrote:

> On 6/24/09 1:00 AM, "Stephan Wenger" <stewe@stewe.org> wrote:
>> On 6/23/09 6:03 PM, "Christopher Montgomery" <xiphmont@gmail.com> wrote:
>>>
>>> There are plenty of arguments being made against a WG or even = the
>>> sensibility of a BOF here, but aren't they missing the point? =   Broad
>>> interest within the IETF is, of itself, sufficient condition f= or a BOF
>>> or WG is it not?
>>
>> It depends on the definition of "broad interest".  = Broad interest in the
>> IETF in WORKING towards a goal is a necessary condition to form a = WG, no
>> doubt.  I don't think it is sufficient, but never mind that. =  Broad interest
>> in the goal alone, without a critical mass of competent people com= mitted to
>> work towards the goal, IMHO, is insufficient.  And I don't se= e this critical
>> mass, certainly not yet.  I do see this critical mass in the = relevant groups
>> in both 3GPP and in the ITU. But critical mass is precisely what t= he BOF
>> will measure.  Therefore, at present, I would speak against f= orming a WG,
>> but I would not have spoken against a BOF, even if I would have be= en asked.
>>
>
> Could you please define what you think it means to have "broad in= terest" or
> "critical mass"?
>
> How many audio codec experts should we have actively participating in = the
> working group? Is there some other criteria that you are thinking abou= t?
>
> Jason
>


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