From fluffy@cisco.com Thu Sep 3 07:23: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 A99A328C20F for ; Thu, 3 Sep 2009 07:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.491 X-Spam-Level: X-Spam-Status: No, score=-106.491 tagged_above=-999 required=5 tests=[AWL=0.108, 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 t4C10rZnL5hS for ; Thu, 3 Sep 2009 07:23:55 -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 08C0828C201 for ; Thu, 3 Sep 2009 07:23:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALpsn0qrR7O6/2dsb2JhbADCIohBAZAqBYQb X-IronPort-AV: E=Sophos;i="4.44,325,1249257600"; d="scan'208";a="381228581" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 03 Sep 2009 14:15:35 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n83EFZUi013586 for ; Thu, 3 Sep 2009 07:15:35 -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.14.3) with ESMTP id n83EFYtM013719 for ; Thu, 3 Sep 2009 14:15:34 GMT Message-Id: <96C5E411-020C-4447-B920-C46BC97AB887@cisco.com> 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 v936) Date: Thu, 3 Sep 2009 08:15:34 -0600 X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=95; t=1251987335; x=1252851335; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Liaison=20from=203GPP |Sender:=20; bh=AYW9LnEuh1pwj5Awg9RRQQn83UThuF+sH/FD8/AFk6o=; b=nJtHQHx7E1hpO7kSD5uuDBj3K/j4gM1nFpGCxTgARwVpIu77qz12LwcofY 2PDfWG9VjK0g4kzj+lOOp+7d+vZ4NABHDl2omIFm/+aIxQ/YMyW4oEPjxx0h LnZEkLG+MN; Authentication-Results: sj-dkim-2; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: [codec] Liaison from 3GPP 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, 03 Sep 2009 14:23:55 -0000 IETF received the following liaison from 3GPP. https://datatracker.ietf.org/liaison/562/ From swmike@swm.pp.se Thu Sep 3 08:10: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 11DE828C2EA for ; Thu, 3 Sep 2009 08:10:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=0.229, 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 ItyMU9MvZYMo for ; Thu, 3 Sep 2009 08:10:26 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 3BF5128C281 for ; Thu, 3 Sep 2009 08:10:25 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id ADC25AD; Thu, 3 Sep 2009 17:10:27 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id AD2CFAC for ; Thu, 3 Sep 2009 17:10:27 +0200 (CEST) Date: Thu, 3 Sep 2009 17:10:27 +0200 (CEST) From: Mikael Abrahamsson To: codec@ietf.org In-Reply-To: <96C5E411-020C-4447-B920-C46BC97AB887@cisco.com> Message-ID: References: <96C5E411-020C-4447-B920-C46BC97AB887@cisco.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [codec] Liaison from 3GPP 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, 03 Sep 2009 15:10:27 -0000 On Thu, 3 Sep 2009, Cullen Jennings wrote: > https://datatracker.ietf.org/liaison/562/ The point about how important "royalty free" was considered by a lot of the people at the mic at the WG BOF in Stockholm seems to have been missed by 3GPP (at least that is my conclusion after reading point 3 of the liaison). How do we communicate that this is a fundamental requirement for an "Sound over Internet" standard? -- Mikael Abrahamsson email: swmike@swm.pp.se From jmh@joelhalpern.com Thu Sep 3 13:48: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 7D7863A6934 for ; Thu, 3 Sep 2009 13:48:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.745 X-Spam-Level: X-Spam-Status: No, score=-2.745 tagged_above=-999 required=5 tests=[AWL=-0.480, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lflM3gpab0gO for ; Thu, 3 Sep 2009 13:48:52 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by core3.amsl.com (Postfix) with ESMTP id AFE283A692C for ; Thu, 3 Sep 2009 13:48:49 -0700 (PDT) Received: from hgblob.mail.tigertech.net (hgblob.mail.tigertech.net [64.62.209.71]) by morbo.tigertech.net (Postfix) with ESMTP id 1D25EA380A for ; Thu, 3 Sep 2009 13:43:36 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hgblob.tigertech.net (Postfix) with ESMTP id F14B83230F84 for ; Thu, 3 Sep 2009 13:43:05 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hgblob.tigertech.net Received: from [10.10.10.101] (pool-71-161-51-226.clppva.btas.verizon.net [71.161.51.226]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hgblob.tigertech.net (Postfix) with ESMTP id 77D473230F7C for ; Thu, 3 Sep 2009 13:43:05 -0700 (PDT) Message-ID: <4AA02A57.1060200@joelhalpern.com> Date: Thu, 03 Sep 2009 16:43:03 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.23 (Windows/20090812) MIME-Version: 1.0 To: codec@ietf.org References: <96C5E411-020C-4447-B920-C46BC97AB887@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [codec] Liaison from 3GPP 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, 03 Sep 2009 20:48:53 -0000 One obvious path would be to have a process by which the IETF could determine what it considers to be the requirements, and get community confirmation of that agreement. We can then make that avaialble to the ITU, 3GPP, et. al. It would seem likely that the community would adopt wording about the Codec being royalty and license free. (Whether it would adopt as strong wording as you want, or weaker, or even stronger, would be determined by the community.) An IETF working group to define these requirements would seem a practical way to determine the community requirements. Yours, Joel M. Halpern Mikael Abrahamsson wrote: > On Thu, 3 Sep 2009, Cullen Jennings wrote: > >> https://datatracker.ietf.org/liaison/562/ > > The point about how important "royalty free" was considered by a lot of > the people at the mic at the WG BOF in Stockholm seems to have been > missed by 3GPP (at least that is my conclusion after reading point 3 of > the liaison). > > How do we communicate that this is a fundamental requirement for an > "Sound over Internet" standard? > From stpeter@stpeter.im Fri Sep 4 07:27: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 691B03A67F4 for ; Fri, 4 Sep 2009 07:27:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[AWL=-0.432, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, 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 pkK-BYaT39-B for ; Fri, 4 Sep 2009 07:27:30 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 528363A679F for ; Fri, 4 Sep 2009 07:27:28 -0700 (PDT) Received: from leavealone.cisco.com (72-163-0-129.cisco.com [72.163.0.129]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 750374007B for ; Fri, 4 Sep 2009 08:18:43 -0600 (MDT) Message-ID: <4AA121C2.8020508@stpeter.im> Date: Fri, 04 Sep 2009 08:18:42 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "codec@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Subject: [codec] Minutes from IETF 75 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, 04 Sep 2009 14:27:33 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ======================================================================== Minutes for Internet Wideband Audio Codec BOF, IETF 75 Kongresshall C, City Conference Centre, Stockholm, Sweden Thursday, July 30, 2009, 13:00-15:00 local time, 11:00-13:00 UTC CHAIRS: Jason Fischl, Jean-Marc Valin NOTE TAKERS: Olle E. Johansson and Bruce Lowekamp JABBER SCRIBES: Alan Hawrylyshen and Peter Saint-Andre MINUTES EDITOR: Peter Saint-Andre AGENDA: 1. Administrivia (5 minutes) 2. Introduction and Scoping of the BoF (10 minutes) 3. Goals of the Working Group (15 minutes) 4. Engineering Work (25 minutes) 5. Codec Expertise in the IETF (15 minutes) 6. Gauging Likelihood of Success (15 minutes) 7. Call for Consensus on Whether to Form a WG (15 minutes) 8. Charter Discussion (15 minutes) 9. Conclusions and Next Steps (5 minutes) AUDIO: JABBER LOG: EDITOR'S NOTE: This was a very fast-pased BoF with a great many speakers at the mic and much back-and-forth conversation. Although the note-takers have attempted to capture all of the discussion, we cannot guarantee that the minutes are truly complete. Please refer to the audio stream and the Jabber logs for details. Approximate minute markings have been provided for reference, with time in UTC to synchronize with the Jabber logs. ======================================================================== 1. ADMINISTRIVIA (11:06) 1a. Note well slide presented. 1b. Remote logistics, Jabber room, meeting materials, audio, etc. 1c. Volunteers noted for note takers and Jabber scribes. 1d. Agenda bashing. Chairs note one modification: order of items 7 and 8 switched. Roni Even @ mic: The agenda topic "Engineering Work" does not explain what exactly will be discussed. Codecs or requirements? Jason Fischl (Chair): The topic will be the *kind* of work that we would be doing. We will look at some attributes that we would use as a way of evaluating codecs, then show how the 5 codecs that have been submitted would address those attributes. We will have short presentations (5 minutes) about individual codecs that have been submitted to indicate the kinds of work that might be in scope, but these codecs are merely representative. ======================================================================== 2. INTRODUCTION AND SCOPING OF THE BOF (11:11) 2a. Cullen Jennings (AD) presenting * SLIDE 1: Things for the IESG/IAB to Learn - - Is there a well-defined goal? - - Do standardized solutions exist? - - Is it technically feasible to do this work in a reasonable time? - - Are there people that can do this work in the IETF? - - If the work is completed, would it be used? * SLIDE 2: Patent Related IPR at the IETF - - If formed, working group would function within IETF IPR policy. - - Not looking to change IETF IPR policy. * SLIDE 3: BCP 79 - - [quotation from BCP 79] * SLIDE 4: Goal is Royalty Free - - from BCP 79: "In general, IETF working groups prefer technologies with no known IPR claims..." * SLIDE 5: No Mandate of Royalty Free - - from BCP 79: "... working groups have the discretion to adopt technology ... with no licensing commitment, if they feel that this technology is superior..." Xavier Marjou @ mic: Question about overlap of standardization bodies, referring to RFC 2418 (BCP 25). Cullen Jennings @ mic: Yes, it overlaps and we have a procedure for handling this with other liaison SDOs. Generally the IAB focuses on this. We need to make sure that our processes are consistent with that BCP, and we're doing that. We have already received two liason requests from two relevant organizations. New work is discussed on a mailing list read by other SDOs and issues are addressed between SDOs and IAB before deciding to form a working group. Patrik Fältström @ mic (as liaison to the ITU-T): I am the liason to the ITU-T and I am working together with the ITU-T on this. ======================================================================== 3. GOALS OF THE WORKING GROUP (11:18) 3a. Chairs on the goals Jean-Marc Valin presenting... * SLIDE 1: Today's Codec Landscape Jean-Marc (presenting): A representative list of some relevant codecs received from the ITU-T liaison. Henry Sinnreich @ mic: Why is the SILK codec not in the list? Jason Fischl (Chair): The list is not comprehensive. [unidentified] @ mic: There might be others that are royalty-free. Jean-Marc Valin presenting... * SLIDE 2: Applications Ted Hardie @ mic: How fixed is this list? Is this application list comprehensive or might there be others? AppArea might have a different set of requirements. Slava Borilin @ mic: Just an initial list to given an idea of the scope. Defining a list of target applications would be part of the working group's task, if it is approved. Roni Even @ mic: The charter says only doing "interactive" application, but not "streaming" applications (which might be similar). Ted Hardie @ mic: Is this list constraining or not? Jason Fischl (Chair): This list is intended to be a non-constraining list of motivating examples. Roni Even @ mic: I understood from the charter that there are some limitations. Jason Fischl (Chair): There is a slide later that defines what is out of scope. Joe Hildebrand @ mic: There are a number of AppArea people here as well and folks should take requirements from applications into account. Jason Fischl presenting... * SLIDE 3: Goals - - Widely and easily distributable and accessible standard codecs - - Small number of codecs (1 or 2) that cover the operating space Jason Fischl (presenting): Not proposing to start a "codec factory". Stefan Bruhn @ mic: What is so unique with these goals for the IETF? There are other SDOs who do work in this area. Why are we reformulating these goals here in the IETF? Harald Alvestrand @ mic: Is the operating space meant to be interactive voice as opposed to stored voice? Jean-Marc Valin (Chair): The scope is meant to be interactive audio, not just voice. Monty Montgomery @ mic: Within the IETF we would be solving problems that IETFers have. Also gives us an opportunity for cross area review. Feedback from application developers, transport protocol designers, etc. Stefan Bruhn @ mic: I don't understand the motivation. We have the MPEG (system agnostic), ITU-T (fixed line), 3GPP (wireless transports), so we have the whole range, I don't see why we need to address this in the IETF. What is so specific here to the Internet that it can't be addressed in MPEG, ITU-T, or 3GPP? Peter Saint-Andre @ mic: The IETF has an open participation model in which the entire Internet community can participate, many other SDOs and industry consortia do not have that model. Monty Montgomery @ mic: The development model in the IETF culturally matches the way we work in the developer community. BCP 79 avoids an accidental, systemic bias against producing royalty-free codecs. Here we have a fighting chance of doing something truly open. Joe Hildebrand @ mic: It's a valid point that applications considered at the IETF have requirements that applications considered by other SDOs don't have. Colin Perkins @ mic: I was chair of AVT WG. You need to pay attention to the way the Internet works. I don't know if that is an argument about whether to form a codec working group, but it is an argument that those who design codecs need to interact with those who understand Internet protocols. One could potentially make the argument that those who work on codecs should interact heavily with the IETF. Maybe that doesn't happen in other SDOs. Christian Hoehne @ mic: Need to consider other requirements than have traditionally been considered by other SDOs. Colin Perkins @ mic: I'm not saying that other SDOs have not been involved in that kind of interaction with the IETF, but that it doesn't always happen. Roni Even @ mic: IETF should produce requirements for submission to other SDOs, which have the expertise to do the codec work. As to open participation, anyone is welcome at ITU-T rapporteur meetings who is approved by rapporteur (but they cannot vote). Xavier Marjou @ mic: I confirm what Roni just said. I also add that there is a liaison relationship between ITU-T and IETF, and the ITU-T is open to taking on new work. Anisse Taleb @ mic: The ITU-T or even MPEG are not less open than the Internet community. Individuals are invited to submit requirements, and MPEG calls for proposals are open to companies that are not members of MPEG. I agree as well with Stefan Bruhn -- I don't see what is different here in terms of requirements. Joe Hildebrand @ mic: Definition of open used at IETF does not overlap with needing to be invited to participate. Roni Even @ mic: You need to pay to attend an IETF meeting. Joe Hildebrand @ mic: These meetings are not canonical, it is the open mailing lists that are canonical. Roni Even @ mic: It is the same in the ITU-T. Patrik Fältström @ mic (as ITU-T liaison): I'm a bit concerned about the language being used at the mic. We have agreement between ITU-T and IETF on how to communicate and how to cooperate regarding the possibility of doing overlapping work. We are following that process in the IETF and the ITU-T is following its process. It is not part of the process to have the kind of discussion we are having in the room, so please stop and let us move on to more productive topics. Jean-Marc Valin presenting... * SLIDE 4: Technical considerations - - suitability for most fixed-point digital signal processors - - medium- to high-quality speech at moderate bit-rates - - high-quality music encoding at higher bit-rates - - sampling rate profiles from narrow-band to full audio bandwidth - - real-time adaptive bit-rate - - source-controlled variable bit-rate (VBR) - - low algorithmic delay Christian Hoehne @ mic: What's the background behind the choice of the chosen technical considerations? This looks like a description of CELT and SILK. Jean-Marc Valin (presenting): These considerations were originally posted in the first proposed charter and adapted based on feedback. They are by no means final and are open to modification. Roni Even @ mic: This is a typical list for codec requirements, nothing specific here to the Internet. Jason Fischl (Chair): These are technical considerations, there are other Internet-related considerations. Ted Hardie @ mic: Is the goal to "pick a winner" (just one or two). Is there a desire to avoid transcoding? We might want that for technical reasons, such as avoiding delay or preventing fragility. But let's be careful that the way to avoid transcoding is not to pick a winner because then we have a collusion issue. Must be very open about what our needs are to avoid the appearance of collusion. If this is not the issue, they do we really need to avoid the codec factory approach? Colin Perkins @ mic: I agree with Roni Even -- there is nothing here that is particular for the Internet. Surely there must be technical factors from the Internet transport that are relevant here. Francois Audet @ mic: I have a similar point. How does this relate to SIP or SDP? Issues like end-to-end negotiation of SDP parameters are important. In-band or out-of-band? Not good to take the most general approach. What are the IETF specifics? Identify what things IETF is best at and include those in the scope. Monty Montgomery @ mic: Transcoding points are excellent. It would make the system better to avoid transcoding. Second point, those technical considerations are items that are interesting to those of us who want to do the work, and this work is not being done elsewhere. Christian Hoehne @ mic: We haven't discussed transcoding because of the end-to-end principle for IP packets. If you have e2e instead of some other network principle (e.g., circuit-switched), then there's no need for transcoding. Mikael Abrahamsson @ mic: I'm a network engineer. I spend a lot of time debugging VoIP traffic. Jitter, latency, packet reordering, packet drops are Internet issues that are not commonly handled by codecs and that cause codecs to lack robustness. I'm baffled that this is missing from an IETF codec initiative. Jean-Marc (presenting): This is not a complete list. Julien Meuric @ mic: There are existing implementations that meet all these requirements. These considerations are not IETF-specific. Why not use or extend existing standards-based solutions? Jason Fischl (Chair): Could you be more specific? Julien Meuric @ mic: Transcoding not mentioned. There are standardized tools that make this possible. What's the new issue that needs to be solved? Slava Borilin @ mic: Existing codecs don't meet these requirements, either not easily distributable or not high quality. I agree that the Internet-specific requirements need to be included. Those of us who worked on the slides probably assumed that the Internet-specific issues were so obvious that unfortunately we omitted from the slides. New work will potentially be an extension of something existing. Anisse Taleb @ mic: These are kind of default considerations for codec work anywhere. What particular features would an Internet codec have? Be more specific about what requirements existing codecs do not meet. Need evidence. Robustness to frame losses is an important technical consideration, for example. Jean-Marc Valin (presenting): The requirement for robustness to frame losses is in the charter but we cut it off the list to fit on the slides. Anisse Taleb @ mic: Best way to avoid transcoding is to stop standardizing codecs. Keith Drage @ mic: You don't have a slide about non-goals. Jason Fischl (Chair): We do, it's next. Slava Borilin @ mic: Two requirements, easily distributable and good performance. Those are not met now. Jason Fischl (Chair): Let's move on to the next couple of slides, then have more comments. Jean-Marc Valin presenting... * SLIDE 5: What is out of scope? - - Very low bitrate - - Non-interactive music (e.g., MP3, AAC, Vorbis) - - Unlimited number of codecs Jason Fischl presenting... * SLIDE 6: Why do this here? - - IETF is where you find the people who understand the impact of the IP stack on codec design - - Cross-area review - - Whole Internet Community can participate - - IETF will have change control and the resulting codecs will be different and better than the initial candidates Stefan Bruhn @ mic: Are you saying that in other SDOs there are no people who understanding the IP stack? Jason Fischl (presenting): Not saying anything about other SDOs, the only statement is that we have such people at the IETF. Stefan Bruhn @ mic: I don't see what is so unique in the IETF. We have all these things (cross-area review, whole Internet community can participate) in other SDOs. Keith Drage @ mic: I want to make sure there is a non-goal that we're not trying to define the default codec for the Internet, and that the resulting codec is not going to be mandated. Roni Even @ mic: I don't see codec expertise on this slide. Also, IETF doesn't mandate codec, this is done by other forums that create profiles. Free codecs are available. Why do you need a standard codec? Alan Duric @ mic: As an operator, I've been struggling for 6 years to deploy VoIP and none of the vendors want to deploy Speex because it's not a standard. If we don't have this work done as a standard, operators will not be able to convince vendors to deploy it. G.722 is falling apart on IP. Xavier Marjou @ mic: We have already deployed a wideband audio codec over IP. I think IP considerations are important, but other areas come into account in codec design. Alan Duric @ mic: Give me the evidence regarding G.722. Please post to mailing list what these codecs are that meet these requirements. Adam Roach @ mic (quoting from XMPP BoF minutes held at IETF 54): "We should be chartering work based on the number of folks who want to do things, not the number opposed." I think we've heard from a number of people here who want to do the work and have competence in this area. [unidentified] @ mic: [Comment about G.719?] Patrik Fältström @ mic (as liaison to the ITU-T): Regarding the comment that we should start work if there are enough people willing to do the work: there are two different discussions here. One is the IETF/IESG decision about whether to create a working group. There is a separate discussion between the IETF and the ITU-T according to RFC 3356, the agreed-upon procedure between IETF and ITU-T to determine if there is overlapping work. That discussion is happening and will continue after this BoF. Ingemar Johansson @ mic: There is no problem with interaction between SDOs. Let's define payload formats here and leave codec work to the ITU-T. Xavier Marjou @ mic: Why are people in the IETF saying that standards coming from other SDOs a joke? Does putting "IP stack" in the slide make the IETF qualified? Monty Montgomery @ mic: Regarding why to do this within the IETF: there are people who want to do this, are doing this, and who want to do it through the IETF. That's not true elsewhere. Christan Hoene @ mic: Things have to work together. This is a reason to do the work here. Are there enough Internet, codec, and VoIP experts sitting together in the same room? That is the question, and we need to decide whether that can be done in the IETF, between the IETF and ITU-T, or in some other way. I think it can be done in the IETF, but no matter what we need to start this work. Slava Borilin @ mic: Regarding why IETF and why standardized codec: Because IETF management of change control is important for vendors. Once change control moves from corporation / vendor to the IETF it becomes safer for others to implement and deploy. The IETF has a group of people that are willing to contribute, skilled and able to contribute. We have expertise here. The codec has to be developed with all aspects of the transport and IP stack considered for high quality on the Internet. Existing codecs do not address that factor, and the few codecs that are close to meeting those goals can't be freely distributed. We have goals of freely distributable and high quality in the real Internet. The IETF is the best organization that fits meeting both of those goals. Jason Fischl @ mic (as individual): How to we get wideband codecs broadly adopted? G.722 is brought out as an example and is starting to become actively deployed. The trigger is expiration of the patents. We haven't seen widely deployed codecs before. Widely distributed and freely available codecs lead to broad deployment. The IETF can try to achieve that, although there is no guarantee. Wilhelm Wimmtreuter @ mic: We have people willing and able to contribute. It matters who can fund it and support it. Why not let them do it? Stefan Bruhn @ mic: I doubt that you have the expertise in this group. Not traditionally at the IETF. Why are you not proposing this to the ITU-T, even royalty-free, and face competition? Slava Borilin @ mic: Because most of our stakeholders are here in the IETF. Jean-Marc Valin presenting some slides about codecs that have been submitted as Internet-Drafts so far... * SLIDE 7: CELT Codec Characteristics * SLIDE 8: SILK Codec Characteristics * SLIDE 9: IPMR Codec Characteristics * SLIDE 10: BV32 Codec Characteristics * SLIDE 11: A2DP SBC+PLC Dave Oran @ mic: Loss robustness is not a boolean. And it is not a scalar. Loss is a curve, not a scalar value. Colin Perkins @ mic: How is it relevant to the Internet that we have a list of codecs? How do these codecs solve Internet-specific problems? Roni Even @ mic: What is the point of a list of codecs? Jason Fischl (Chair): Trying to point out that there were a number of submissions of real codecs. Roni Even @ mic: That's interesting, but there are no requirements so everyone is qualified. Peter Saint-Andre @ mic (as individual, not Jabber scribe): People say there is no competence in the IETF. The point of the list of codecs is saying that we do have competence among the people who have developed these codecs and contributed them to the Internet Standards Process. Xavier Marjou @ mic: What is really new in terms of new requirements? Jason Fischl (Chair): These have been submitted in the open and intended to be open source. Xavier Marjou @ mic: For a new codec there are likely patents coming. Colin Perkins @ mic: I question the claim that they are royalty free. Jason Fischl (Chair): Claim is not that they are royalty-free, but that they are being provided without royalties on any of the patents. [?] Slava Borilin @ mic: People are contributing codecs that are believed to the best of their knowledge to be royalty free, and these people are contributing / have expertise to contribute royalty free codecs that are superior to existing alternatives. Based on what we know, we stand a good chance of doing better than what is out there, and keeping it freely available. We believe that this can be achieved such that quality is as good or better than existing codecs, and to do so in a way that is freely and easily distributable. Alan Duric @ mic: As to competence, there are people in this room who have developed codecs that run into the hundreds of millions of minutes each day or each week. These codecs are superior to the existing codecs out there and none of those are suitable for Internet or wireless LAN if there is any kind of packet loss. Peter Saint-Andre @ mic (as individual, not Jabber scribe): Could we please try to get through the agenda? ======================================================================== 4. ENGINEERING WORK (12:22) Jason Fischl (Chair): Quick presentations on SILK and CELP... 4a. Koen Vos presenting about the SILK codec (12:22) (draft-vos-silk-00) 4a. Monty Montgomery presenting about the CELT codec (12:24) (draft-valin-celt-codec-00) "If CELT comes out of a proposed working group intact, I will be sorely disappointed." Emphasizes the point that all of these codec developers want to merge their work to produce a best-of-breed codec. ======================================================================== 5. CODEC EXPERTISE IN THE IETF (12:27) Jason Fischl (Chair): These brief presentations were trying to establish that we do have codec expertise among IETF participants, but there are also other kinds of contributions -- requirements, testing, etc. Joel Halpern @ mic: I'm not going to question whether there are enough people here to do the codec work, because that's clearly true. The question is whether the *IETF* has the expertise. It's only sensible for the IETF to do it if it works with the rest of the process. Can the reviewers provide appropriate technical insights? Does the IESG have expertise to provide oversight? If we don't have expertise in those places, we can't do this as an organization. Henny Sinnreich @ mic: I'm willing to contribute with usage scenarios for Rich Internet Applications and the resulting requirements. Slava Borilin @ mic: We definitely have enough people to work on the codecs themselves, but do have enough qualified customers? I think so. Colin Perkins @ mic: I do not believe the wider IETF can meaningfully review the work (IESG and other areas). Bernard Aboba: We have chartered IETF working groups in this kind of situation before. For example, TRILL. We only looked at whether we had people who could do the work. What we put into the charter is review by appropriate outside experts and liaisons (in that case IEEE) to get comments. We have been successful in that approach. The only thing that was relevant is whether people are here with expertise and willing to do work. Roni Even @ mic: It's more complicated. You need to provide information correctly to liaisons and outside experts. For example, need to work on characterization. Christan Hoene @ mic: There need to be experts on judging the quality of the codecs. For example, there are standards for conducting listening tests. Jason Fischl (Chair): I want to make sure we are very focused on the question of whether we have the expertise to do this work in the IETF. Jean-Francois Mule @ mic: I do believe there is expertise. Anyone who has done codec development and testing knows how to define test vectors so that implementers can validate implementations. In this room we have 4-5 companies with codec test bench labs that could validate that the codec has been implemented correctly according to the spec and also that you have met your terms of reference and requirements. Also independent labs. There are plenty of resources, and this is not rocket science. Slava Borilin @ mic: At Spirit DSP have expertise in design and we are engaged on the Internet application side. A working group can serve most of all as an analyst to specify the right tasks for developing the kind of codec that is needed for Internet applications. The major value is identifying the technical and business requirements and developing technical solutions to meet those requirements. The working group might even end up with a decision that G.722 is the best choice. Monty Montgomery @ mic: Two hours ago the argument was that we didn't have the competence. That has shifted to "you are competent to design a codec but you don't have the competence to test". In my experience, testers outnumber implementers 10 to 1. This is irrelevant. Adam Roach @ mic for Eric Rescorla in the Jabber chatroom: I'm not concerned about Joel's point. We have similar problems in security, where the ability to evaluate cryptographic techniques outside the working group is extremely limited. But at least the performance of codecs is measurable, whereas with security even that isn't true. Adam Roach @ mic: At least codecs can be evaluated directly by everyone in the IETF, since we all have working ears. Stefan Bruhn @ mic: Do we have expertise? Depends on the companies sending their experts to this group. Experts are sent to ITU-T and MPEG and 3GPP, are you sure they will be sent here? For experts here, why aren't you at MPEP and ITU-T and 3GPP? Are you afraid of facing competition? Derek McDonald @ mic: It seems that we do have the expertise. But the IETF retains the right to fail. It isn't like we've lost a war if the working group fails. Don't let FUD block us. Mikael Abrahamsson @ mic: The Internet should demand things from the codec rather than the codec demanding things from Internet. We know IP, we know how the Internet works. Alan Duric @ mic: I fully agree, and if we brought this to ITU-T or ETSI, yes these proposals were brought forward 8 years ago and shot down without consideration. Julien Meuric @ mic: People are interested, but do you have any proof that the technical skill is present here? Roni Even @ mic: We are trying to define the whole process, need expertise in defining the whole process. But really need a beauty contest. Either approve all the specs that are submitted or you need to select a few and define how to do that. Xavier Marjou @ mic: IETF documents are good because they are so readable, but a codec RFC would be unreadable. Can't write formulas in an Internet-Draft. Jean-Francois Mule @ mic: Responding to request for evidence, Broadcom is willing to bring expertise and competence. Dr. Chen and his group have worked for many years in ITU-T. Slava Borilin @ mic: Spirit DSP has developed more than 10 proprietary codecs standardized under various bodies like radio standards. We are not going to ITU-T because there are no stakeholders interested in the result (freely distributable, high quality). In IETF there are. Monty Montgomery @ mic: First, we will mix inputs from different contributors. Second, Roni is right that a lot of characterization, testing, and documentation needs to be done. We're aware of that and we have a lot of work to do. Ye-Kui Wang @ mic: Who in IESG is capable of reviewing audio codecs? Ted Hardie @ mic: Please stop talking about stakeholders -- not a useful construct in the IETF. The decision is whether to charter work that would benefit the Internet. Serious question is whether this is the best place and whether this work benefits the Internet. Stakeholders are users, operators, vendors, etc. Please try to take a whole Internet view rather than a particular stakeholder view or we will ask ourselves the wrong question. Cullen Jennings @ mic, as AD who will be asked to evaluate codecs: Do we have competence on this topic? The IESG relies a lot on expert advisers across areas. We try to assess whether things cause harm. We have to listen to other people and try to evaluate whether claims of brokenness are legitimate or not. Often our expertise lies in finding the right people to provide input and in listening to them in order to judge which input is reliable. For example, will have to review IDNAbis (internationalized domain names) but there are no linguistics experts on the IESG, so we will have to rely on other people and work with them and try to integrate their feedback. Another factor is that IESG members are selected based on skills needed to do the work and review it. This codec work is really not different from other work and the important thing is that there's expertise to get the right comments so the IESG can make good decisions. [12:50, T-10 minutes] QUESTION from Chairs: Who here would call themselves codec experts and would be willing to develop codecs? Outcome: 10-12 real hands and 5+ virtual hands from the Jabber room. QUESTION from Chairs: Who is willing to participate in any way listed on slide 1 (guidelines, process, requirements, codec proposals, commenting, evaluation)? Outcome: 40-60 real hands and virtual hands. Lars Eggert @ mic: Of the codec experts, would you still participate if a proposal you contributed is ruled out by the working group? Outcome: Same as for the first question. HUM REQUEST from Chairs: Is or is not the technical scope of the work well defined? [one hum for yes, one hum for no] Outcome: Inconclusive. HUM REQUEST from Chairs: Do we or do we not have enough expertise to form a working group that can meet the goals? [one hum for yes, one hum for no] Outcome: Inconclusive. Ted Hardie @ mic: Large grey area here, what if you have no idea if there's enough expertise to complete the work because you don't know if it's well-scoped in the first place? Perhaps a separate hum is in order. Cullen Jennings @ mic: Could you type the question in a slide? My experience from other BoFs is that the question can get very confusing. [12:58 conclave at front of room among Chairs, AD, BoF Sponsor, etc.] HUM REQUEST from Chairs: Do we or do we not have enough expertise to properly scope the work? [one hum for yes, one hum for no] Outcome: Rough consensus in favor. [conclave continues] Cullen Jennings @ mic as Area Director: - - I think we've identified that it's prematuve to ask whether to form a working group - - We have the information we need from the BoF and will go forward with discussions on the mailing list [meeting adjourned at 13:01] ======================================================================== 6. Gauging Likelihood of Success - - not discussed - ======================================================================== 7. Call for Consensus on Whether to Form a WG - - not discussed - ======================================================================== 8. Charter Discussion - - not discussed - ======================================================================== 9. Conclusions and Next Steps - - not discussed - END -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqhIcIACgkQNL8k5A2w/vwxjgCfTyywrg5qUVPmgI1pn0QpB26Q X50AnR3WlAadkA6A6yfpAmGBM2vlUFp/ =Sebj -----END PGP SIGNATURE----- From jean-marc.valin@octasic.com Fri Sep 4 12:07: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 BA2AC3A681B; Fri, 4 Sep 2009 12:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.444 X-Spam-Level: X-Spam-Status: No, score=-2.444 tagged_above=-999 required=5 tests=[AWL=0.155, 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 UUsqoeidGgmB; Fri, 4 Sep 2009 12:07:48 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id D4BBA3A6814; Fri, 4 Sep 2009 12:07:47 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 15:06:46 -0400 Message-ID: <4AA16546.8050700@octasic.com> Date: Fri, 04 Sep 2009 15:06:46 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: "codec@ietf.org" , "avt@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Sep 2009 19:06:46.0180 (UTC) FILETIME=[D8F39E40:01CA2D92] Subject: [codec] Codec guidelines and requirements drafts 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, 04 Sep 2009 19:07:48 -0000 Hi, As a follow-up to the codec BoF in Stockholm, a group of interested IETF participants has been working on how to move forward regarding this work at the IETF. As a result, today we have submitted two Internet-Drafts: (1) http://www.ietf.org/id/draft-valin-codec-guidelines-00.txt (2) http://www.ietf.org/id/draft-valin-codec-requirements-00.txt We welcome feedback on these drafts on the codec@ietf.org list. Cheers, Jean-Marc From stpeter@stpeter.im Fri Sep 4 12:17: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 6EBAD3A681B for ; Fri, 4 Sep 2009 12:17:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.644 X-Spam-Level: X-Spam-Status: No, score=-2.644 tagged_above=-999 required=5 tests=[AWL=-0.045, 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 WiqUqKeZNXDw for ; Fri, 4 Sep 2009 12:17:35 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 8A43A3A6784 for ; Fri, 4 Sep 2009 12:17:35 -0700 (PDT) Received: from dhcp-64-101-72-216.cisco.com (dhcp-64-101-72-216.cisco.com [64.101.72.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 565A84007B for ; Fri, 4 Sep 2009 12:40:30 -0600 (MDT) Message-ID: <4AA15F1C.4070509@stpeter.im> Date: Fri, 04 Sep 2009 12:40:28 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "codec@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [codec] [Fwd: I-D Action:draft-valin-codec-guidelines-00.txt] 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, 04 Sep 2009 19:17:36 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. /psa - -------- Original Message -------- Subject: I-D Action:draft-valin-codec-guidelines-00.txt Date: Fri, 4 Sep 2009 11:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Guidelines for proposed CODEC working group Author(s) : J. Valin, et al. Filename : draft-valin-codec-guidelines-00.txt Pages : 17 Date : 2009-09-04 This document provides general guidelines for specifying audio codecs within the IETF. These guidelines cover the development process, as well as the evaluation and intellectual property issues. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-valin-codec-guidelines-00.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqhXxwACgkQNL8k5A2w/vw3KQCbBDmV7SZPXLaiHIDKN4UW1sZO ZssAoJMDkNDNGGOXXscj4PoaB0HFWhtG =Al+W -----END PGP SIGNATURE----- From swmike@swm.pp.se Fri Sep 4 12:49: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 9F1D728C120 for ; Fri, 4 Sep 2009 12:49:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.375 X-Spam-Level: X-Spam-Status: No, score=-2.375 tagged_above=-999 required=5 tests=[AWL=0.224, 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 1zWAkYL6fx64 for ; Fri, 4 Sep 2009 12:49:44 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id 922CF28C11A for ; Fri, 4 Sep 2009 12:49:44 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id C26E89F; Fri, 4 Sep 2009 21:50:02 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id C1EE79E for ; Fri, 4 Sep 2009 21:50:02 +0200 (CEST) Date: Fri, 4 Sep 2009 21:50:02 +0200 (CEST) From: Mikael Abrahamsson To: "codec@ietf.org" In-Reply-To: <4AA16546.8050700@octasic.com> Message-ID: References: <4AA16546.8050700@octasic.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Subject: Re: [codec] Codec guidelines and requirements drafts 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, 04 Sep 2009 19:49:45 -0000 On Fri, 4 Sep 2009, Jean-Marc Valin wrote: > Hi, > > As a follow-up to the codec BoF in Stockholm, a group of interested IETF > participants has been working on how to move forward regarding this work at > the IETF. As a result, today we have submitted two Internet-Drafts: > > (1) http://www.ietf.org/id/draft-valin-codec-guidelines-00.txt > (2) http://www.ietf.org/id/draft-valin-codec-requirements-00.txt > > We welcome feedback on these drafts on the codec@ietf.org list. Hi, from my network engineering side these look good apart from the fact that they do not mention adaptive jitter buffer for the transport. Is this an omission done because these drafts are codec and not transport centric, or has this requirement been overlooked? I firmly belive (as I also stated at the mic at IETF75) that any Internet codec+transport needs to gracefully handle initial jitter of 10 ms or less with small (perhaps 20-40 ms) jitter buffer during parts of the call, and then it needs to adapt to jitter going up to multiple seconds (thus inferring multiple second jitter buffer and end-to-end delay), and then when conditions on the IP packet layer improve, it needs to gracefully adapt back to much smaller jitter buffer again. This is because on the packet layer we have packet transport networks that do re-transmits itself and thus can deliver packets quite late (802.11abgn, 2G/3G GSM/UMTS networks, just to name a few), but they still get delivered but with huge delay/jitter spikes (can be for prolonged periods of time as well). I believe these conditions should be in the requrements/guidelines since Packet Loss Concealment is there? (unless people disagree with my opinion that any Internet codec+transport should handle and behave the way I described above, of course) -- Mikael Abrahamsson email: swmike@swm.pp.se From stpeter@stpeter.im Fri Sep 4 12:56: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 2BC933A68A4 for ; Fri, 4 Sep 2009 12:56:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.642 X-Spam-Level: X-Spam-Status: No, score=-2.642 tagged_above=-999 required=5 tests=[AWL=-0.043, 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 3h9KXkk6jO8W for ; Fri, 4 Sep 2009 12:56:41 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 41E2B3A6784 for ; Fri, 4 Sep 2009 12:56:41 -0700 (PDT) Received: from dhcp-64-101-72-216.cisco.com (dhcp-64-101-72-216.cisco.com [64.101.72.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 4B47E40D12 for ; Fri, 4 Sep 2009 13:42:09 -0600 (MDT) Message-ID: <4AA16D90.2040800@stpeter.im> Date: Fri, 04 Sep 2009 13:42:08 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "codec@ietf.org" References: <4AA121C2.8020508@stpeter.im> In-Reply-To: <4AA121C2.8020508@stpeter.im> X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [codec] Minutes from IETF 75 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, 04 Sep 2009 19:56:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 It has been brought to my attention that my previous message was unreadable in certain email user agents. The minutes will eventually be posted on the IETF website, but until then you can find them here: http://www.saint-andre.com/tmp/codec-minutes.txt /psa -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqhbZAACgkQNL8k5A2w/vxm3gCgq8zj2PkvoWEtiWxw3bF8f9QM p3cAoMLAfdzPt11X3qxZmJgnb1Z5sgl3 =ZcDv -----END PGP SIGNATURE----- From jean-marc.valin@octasic.com Fri Sep 4 13:03:28 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 44A673A6A9B for ; Fri, 4 Sep 2009 13:03:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 TdWmNSEXU9UX for ; Fri, 4 Sep 2009 13:03:27 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 389C33A6A72 for ; Fri, 4 Sep 2009 13:03:27 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 16:03:47 -0400 Message-ID: <4AA172A3.6060607@octasic.com> Date: Fri, 04 Sep 2009 16:03:47 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Mikael Abrahamsson References: <4AA16546.8050700@octasic.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Sep 2009 20:03:47.0483 (UTC) FILETIME=[D03506B0:01CA2D9A] Cc: "codec@ietf.org" Subject: Re: [codec] Codec guidelines and requirements drafts 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, 04 Sep 2009 20:03:28 -0000 Hi, Mikael Abrahamsson wrote: > from my network engineering side these look good apart from the fact > that they do not mention adaptive jitter buffer for the transport. Is > this an omission done because these drafts are codec and not transport > centric, or has this requirement been overlooked? I agree that adaptive jitter buffering is a very important aspect of a complete voice transport system. The only reason that this is not mentioned in this particular draft is that we are only addressing codec requirements. In general, an adaptive jitter buffer should be able to work for any codec (you don't want a separate jitter buffer for each codec). The only part that *is* relevant for codec requirements is any aspect that the jitter buffer would want from the codec. For example, when a packet is late or lost, the jitter needs to conceal the loss and make sure to minimise its propagation in time. This is a job for the codec and is part of the requirements. I really do think that there is important work to be done regarding jitter buffers and transport, but I think these should be done in a separate place (AVT WG?). Of course, the people who are working on that can (and should) talk to the codec people and tell them what "services" the codec can provide that would improve the overall audio quality. For example, some people have suggested that codecs should be able to facilitate time stretching/compressing. While this is not something that is currently in the requirements, I could very well imaging adding that (once there is agreement on the details). Jean-Marc From stpeter@stpeter.im Fri Sep 4 13:06: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 6C1CB3A6765 for ; Fri, 4 Sep 2009 13:06:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.641 X-Spam-Level: X-Spam-Status: No, score=-2.641 tagged_above=-999 required=5 tests=[AWL=-0.042, 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 AUuGaJ0ueTSl for ; Fri, 4 Sep 2009 13:06:04 -0700 (PDT) Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id DB0ED3A6A8B for ; Fri, 4 Sep 2009 13:06:04 -0700 (PDT) Received: from dhcp-64-101-72-216.cisco.com (dhcp-64-101-72-216.cisco.com [64.101.72.216]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D84D140D11 for ; Fri, 4 Sep 2009 12:40:49 -0600 (MDT) Message-ID: <4AA15F31.8000108@stpeter.im> Date: Fri, 04 Sep 2009 12:40:49 -0600 From: Peter Saint-Andre User-Agent: Thunderbird 2.0.0.23 (Macintosh/20090812) MIME-Version: 1.0 To: "codec@ietf.org" X-Enigmail-Version: 0.96.0 OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [codec] [Fwd: I-D Action:draft-valin-codec-requirements-00.txt] 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, 04 Sep 2009 20:06:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 FYI. /psa - -------- Original Message -------- Subject: I-D Action:draft-valin-codec-requirements-00.txt Date: Fri, 4 Sep 2009 11:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Codec Requirements Author(s) : J. Valin, et al. Filename : draft-valin-codec-requirements-00.txt Pages : 20 Date : 2009-09-04 This document provides specific requirements for Internet audio codecs. These requirements address quality, sampling rate, bit-rate, and packet loss robustness, as well as other desirable properties. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-valin-codec-requirements-00.txt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqhXzAACgkQNL8k5A2w/vwzxgCg49pFuadaC+EfYzzNunn7UOMV l/gAoKW2KKR09urzsBz9jyc7Mp6VQF9A =XH+G -----END PGP SIGNATURE----- From swmike@swm.pp.se Fri Sep 4 13:14: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 5B8C03A6A8C for ; Fri, 4 Sep 2009 13:14:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.38 X-Spam-Level: X-Spam-Status: No, score=-2.38 tagged_above=-999 required=5 tests=[AWL=0.219, 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 dtKWr1n8J90S for ; Fri, 4 Sep 2009 13:14:00 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by core3.amsl.com (Postfix) with ESMTP id D807F3A6A7A for ; Fri, 4 Sep 2009 13:13:59 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 01D339F; Fri, 4 Sep 2009 22:14:18 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 00E679E for ; Fri, 4 Sep 2009 22:14:17 +0200 (CEST) Date: Fri, 4 Sep 2009 22:14:17 +0200 (CEST) From: Mikael Abrahamsson To: "codec@ietf.org" In-Reply-To: <4AA172A3.6060607@octasic.com> Message-ID: References: <4AA16546.8050700@octasic.com> <4AA172A3.6060607@octasic.com> User-Agent: Alpine 1.10 (DEB 962 2008-03-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII Subject: Re: [codec] Codec guidelines and requirements drafts 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, 04 Sep 2009 20:14:01 -0000 On Fri, 4 Sep 2009, Jean-Marc Valin wrote: > that would improve the overall audio quality. For example, some people have > suggested that codecs should be able to facilitate time > stretching/compressing. While this is not something that is currently in the > requirements, I could very well imaging adding that (once there is agreement > on the details). That sounds good, I think this is a key requirement. I believe stretching/compressing needs to be fairly fast/agressive, to be able to go from 1000 to 40 ms jitter buffer in just a few seconds (and as fast as needed when increasing it). The spatial compression could perhaps also be done via agressive silence suppression (at least for voice communication), but this can't be the only mechanism because it won't work if there is never silence. Does anyone more into AVT WG know if there are already IETF standards/framework to handle this at the transport layer, or is there a lot of development needed there as well? How do we assure that the end-to-end solution works when all is said and done? I'm a bit afraid that unless there is very tight cooperation, the end solution won't be as good as it could be if all of this was done in a single WG doing all the requirements and making sure that everything works together. -- Mikael Abrahamsson email: swmike@swm.pp.se From jean-marc.valin@octasic.com Fri Sep 4 13:27: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 5CB783A6A7A for ; Fri, 4 Sep 2009 13:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 sLci9RO4-oZ2 for ; Fri, 4 Sep 2009 13:27:30 -0700 (PDT) Received: from MAILEXCH.octasic.com (mail.octasic.com [70.54.254.106]) by core3.amsl.com (Postfix) with ESMTP id 70BCE3A6A80 for ; Fri, 4 Sep 2009 13:27:30 -0700 (PDT) Received: from [142.138.24.19] ([142.138.24.19]) by MAILEXCH.octasic.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 4 Sep 2009 16:27:37 -0400 Message-ID: <4AA17839.1010902@octasic.com> Date: Fri, 04 Sep 2009 16:27:37 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) MIME-Version: 1.0 To: Mikael Abrahamsson References: <4AA16546.8050700@octasic.com> <4AA172A3.6060607@octasic.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 04 Sep 2009 20:27:37.0411 (UTC) FILETIME=[2482B930:01CA2D9E] Cc: "codec@ietf.org" Subject: Re: [codec] Codec guidelines and requirements drafts 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, 04 Sep 2009 20:27:31 -0000 Mikael Abrahamsson wrote: > That sounds good, I think this is a key requirement. I believe > stretching/compressing needs to be fairly fast/agressive, to be able to > go from 1000 to 40 ms jitter buffer in just a few seconds (and as fast > as needed when increasing it). Again, it would be the jitter buffer's job to decide how aggressive to be. The only thing the codec (actually just the decoder) would do at this point is "obey" what the jitter buffer tell it to do. > Does anyone more into AVT WG know if there are already IETF > standards/framework to handle this at the transport layer, or is there a > lot of development needed there as well? Actually, an even more fundamental question here is "should there be a standard for jitter buffers?". My *personal* opinion on this is that we probably want to define "best practices" for jitter buffering (possibly with reference code), but we do not need an actual standard because at this point I do not see any inter-operability issue. > How do we assure that the end-to-end solution works when all is said and > done? I'm a bit afraid that unless there is very tight cooperation, the > end solution won't be as good as it could be if all of this was done in > a single WG doing all the requirements and making sure that everything > works together. Well, you can cooperate across groups and in fact all IETF groups *have* to cooperate with other groups. But at the same time, you need to divide the problem otherwise the entire IETF would be a single working group ;-) Cheers, Jean-Marc From Borilin@spiritdsp.com Fri Sep 4 13:30: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 B4E2E3A67EA for ; Fri, 4 Sep 2009 13:30:10 -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 SO3-LsPcTz9h for ; Fri, 4 Sep 2009 13:30:09 -0700 (PDT) Received: from mail3.spiritcorp.com (mail3.spiritcorp.com [85.13.194.167]) by core3.amsl.com (Postfix) with ESMTP id 5016F3A6783 for ; Fri, 4 Sep 2009 13:30:09 -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 n84KU3QE041658; Sat, 5 Sep 2009 00:30: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: Sat, 5 Sep 2009 00:29:54 +0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec guidelines and requirements drafts Thread-Index: AcotnE1hXAtWzq62QXaeahbnPP/G8AAAdSpw References: <4AA16546.8050700@octasic.com><4AA172A3.6060607@octasic.com> From: "Slava Borilin" To: "Mikael Abrahamsson" , X-Scanned-By: MIMEDefang 2.64 on 192.168.125.15 Subject: Re: [codec] Codec guidelines and requirements drafts 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, 04 Sep 2009 20:30:10 -0000 Mikael, As it has been already discussed on the list, the goal is not to design/specify "end-to-end" voice system, but only specify what is MANDATORY for interop (=3Dcodec), and leave the upper layers to proprietary solutions. Of course, codec should be OPTIMIZED for such proprietary solutions as much as possible, and that's why we are working on the requirements from "overall system" perspective, which, however, should not be read that "codec has to do everything", it should be read as "codec has to be good for the systems that do the best practice on upper layers". best regards, Slava Borilin -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of Mikael Abrahamsson Sent: Saturday, September 05, 2009 12:14 AM To: codec@ietf.org Subject: Re: [codec] Codec guidelines and requirements drafts On Fri, 4 Sep 2009, Jean-Marc Valin wrote: > that would improve the overall audio quality. For example, some people have=20 > suggested that codecs should be able to facilitate time=20 > stretching/compressing. While this is not something that is currently in the=20 > requirements, I could very well imaging adding that (once there is agreement=20 > on the details). That sounds good, I think this is a key requirement. I believe=20 stretching/compressing needs to be fairly fast/agressive, to be able to go=20 from 1000 to 40 ms jitter buffer in just a few seconds (and as fast as=20 needed when increasing it). The spatial compression could perhaps also be=20 done via agressive silence suppression (at least for voice communication),=20 but this can't be the only mechanism because it won't work if there is=20 never silence. Does anyone more into AVT WG know if there are already IETF=20 standards/framework to handle this at the transport layer, or is there a lot of development needed there as well? How do we assure that the end-to-end solution works when all is said and done? I'm a bit afraid that unless there is very tight cooperation, the=20 end solution won't be as good as it could be if all of this was done in a=20 single WG doing all the requirements and making sure that everything works=20 together. --=20 Mikael Abrahamsson email: swmike@swm.pp.se _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From simon.perreault@viagenie.ca Fri Sep 4 13:37:20 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 94BC03A6783 for ; Fri, 4 Sep 2009 13:37:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.55 X-Spam-Level: X-Spam-Status: No, score=-2.55 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, NO_RELAYS=-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 Vd4+HB4w3k1F for ; Fri, 4 Sep 2009 13:37:19 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 829323A6877 for ; Fri, 4 Sep 2009 13:37:18 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id B67D314A0001; Fri, 4 Sep 2009 16:37:38 -0400 (EDT) Received: from ringo.viagenie.ca (ringo.viagenie.ca [IPv6:2620:0:230:c000::67]) by jazz.viagenie.ca (Postfix) with ESMTP id AE21829E15BE; Fri, 4 Sep 2009 16:37:38 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: codec@ietf.org Date: Fri, 4 Sep 2009 16:37:37 -0400 User-Agent: KMail/1.11.4 (Linux/2.6.29.6-217.2.3.fc11.x86_64; KDE/4.2.4; x86_64; ; ) References: <4AA16546.8050700@octasic.com> <4AA172A3.6060607@octasic.com> In-Reply-To: <4AA172A3.6060607@octasic.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909041637.38125.simon.perreault@viagenie.ca> Subject: Re: [codec] Codec guidelines and requirements drafts 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, 04 Sep 2009 20:37:20 -0000 On Friday 04 September 2009 16:03:47 Jean-Marc Valin wrote: > For example, some > people have suggested that codecs should be able to facilitate time > stretching/compressing. Does someone have a precise idea of what that means? Thanks, Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From bmschwar@fas.harvard.edu Fri Sep 4 14:11: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 757813A6857 for ; Fri, 4 Sep 2009 14:11:27 -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 64Gf-xxOGKVT for ; Fri, 4 Sep 2009 14:11:26 -0700 (PDT) Received: from us24.unix.fas.harvard.edu (us24.unix.fas.harvard.edu [140.247.35.204]) by core3.amsl.com (Postfix) with ESMTP id 686833A6832 for ; Fri, 4 Sep 2009 14:11:26 -0700 (PDT) Received: from [172.23.141.114] (bwhmaincampuspat25.partners.org [170.223.207.25]) (authenticated bits=0) by us24.unix.fas.harvard.edu (8.14.1/8.14.1) with ESMTP id n84LBYMc005035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 4 Sep 2009 17:11:34 -0400 Message-ID: <4AA18288.2030505@fas.harvard.edu> Date: Fri, 04 Sep 2009 17:11:36 -0400 From: "Benjamin M. Schwartz" User-Agent: Thunderbird 2.0.0.22 (X11/20090714) MIME-Version: 1.0 To: Simon Perreault References: <4AA16546.8050700@octasic.com> <4AA172A3.6060607@octasic.com> <200909041637.38125.simon.perreault@viagenie.ca> In-Reply-To: <200909041637.38125.simon.perreault@viagenie.ca> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig0B9C3077F0A7BC6E46FC6EA0" Cc: codec@ietf.org Subject: Re: [codec] Codec guidelines and requirements drafts X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu 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, 04 Sep 2009 21:11:27 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig0B9C3077F0A7BC6E46FC6EA0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Simon Perreault wrote: > On Friday 04 September 2009 16:03:47 Jean-Marc Valin wrote: >> For example, some >> people have suggested that codecs should be able to facilitate time >> stretching/compressing. >=20 > Does someone have a precise idea of what that means? How precise? Audio data arrives at some apparent rate, which we can measure in samples= per second on the local system sample clock. If the link latency and buffering are constant, and the two endpoints' sample clocks tick at the same rate, then the audio data will arrive at the "right" speed, and can simply be decoded and thrown into the sound card's output buffer. If the buffer has to expand or contract over some period of time, or if one of the endpoints ticks faster than the other, then fewer or more samples will be received than the sound card requires to be played. The codec must provide some mechanism to resolve this discrepancy. Commonly suggested mechanisms include resampling (which bends pitch), smart time-stretching to preserve pitch, and "adjust during silence". To me, the important question here is: what sort of interface does the codec need to expose for time dilation? For example, it might be a function that says "turn the next N coded samples into M decoded samples,= please". --Ben --------------enig0B9C3077F0A7BC6E46FC6EA0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkqhgogACgkQUJT6e6HFtqSfhQCfRlyv+ZDyTWNJlPNkohCZqq5J abEAnRceMRSPn8LN9FLaSQz/a1Ytah4O =B/ut -----END PGP SIGNATURE----- --------------enig0B9C3077F0A7BC6E46FC6EA0-- From ron@debian.org Fri Sep 4 16:10: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 BB7313A68C4 for ; Fri, 4 Sep 2009 16:10:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.422 X-Spam-Level: X-Spam-Status: No, score=-2.422 tagged_above=-999 required=5 tests=[AWL=0.183, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvi4uYyFyVvy for ; Fri, 4 Sep 2009 16:10:20 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by core3.amsl.com (Postfix) with ESMTP id 715553A6873 for ; Fri, 4 Sep 2009 16:10:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvIEAK86oUp5LZcx/2dsb2JhbACBU9hKhBYFgjs X-IronPort-AV: E=Sophos;i="4.44,335,1249223400"; d="scan'208";a="436810957" Received: from ppp121-45-151-49.lns11.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.151.49]) by ipmail05.adl2.internode.on.net with ESMTP; 05 Sep 2009 08:40:40 +0930 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 45A7F4F8F3 for ; Sat, 5 Sep 2009 08:40:39 +0930 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id qFifTuRXgj4s for ; Sat, 5 Sep 2009 08:40:31 +0930 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id B12764F8FD; Sat, 5 Sep 2009 08:40:31 +0930 (CST) Date: Sat, 5 Sep 2009 08:40:31 +0930 From: Ron To: codec@ietf.org Message-ID: <20090904231031.GL4137@audi.shelbyville.oz> References: <4AA16546.8050700@octasic.com> <4AA172A3.6060607@octasic.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4AA172A3.6060607@octasic.com> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [codec] Codec guidelines and requirements drafts 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, 04 Sep 2009 23:10:21 -0000 On Fri, Sep 04, 2009 at 04:03:47PM -0400, Jean-Marc Valin wrote: > For example, some people have suggested that codecs > should be able to facilitate time stretching/compressing. This would be a very attractive feature for the decoder to support directly, as we increasingly move toward transports where it is impossible or impractical to achieve precise clock synchronisation between endpoints. While it's not impossible to do this external to the codec, I'd be quite surprised if gains could not be made to both computational complexity and quality if this were to be factored into the decoder stage and encoded data from the outset. Ron From stephen.botzko@gmail.com Fri Sep 4 18: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 4D4BE3A68F0 for ; Fri, 4 Sep 2009 18:32:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.369 X-Spam-Level: X-Spam-Status: No, score=-1.369 tagged_above=-999 required=5 tests=[AWL=-0.437, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_OBFU_PART_ING=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JNkBgEER10qG for ; Fri, 4 Sep 2009 18:32:55 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id EAB913A69A1 for ; Fri, 4 Sep 2009 18:32:54 -0700 (PDT) Received: by fxm17 with SMTP id 17so1023920fxm.37 for ; Fri, 04 Sep 2009 18:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=QvTcVtNTI/mhB9yiX9CCTcQviKiMw0X0J/wZIigJfs0=; b=AZcoOCIZi8y9qKUBLvE1PxfFjKcIx12U/dGQapfKdrCcVagLeSU4JMtQUapFSs/kf2 2yJXfNEMU5jUgY2vYht6UjaFQH0gjJTCLxt/gr5TPDq2B+hGYDpIg5hAe303AhNbZGan uEXBkrU3oZEwEOUL0FuVPLBJqmoE25jpMybkM= 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=EAD+NLFtr5DU4szvI1c1E2baYj+5iiIvJCtQkFyTolj/XkuQ2Y+vsuZwV/1sGGGBWB hTkeaXSRoIB2uXsDZ0fJ3uPa/lZamt7HjUZVGcuLP1hDbrc93VbR5I0+vkCQGg+ys/fe oddIqoG9/xqKmzi14dOU+3z/5kb5EiWj5+a3c= MIME-Version: 1.0 Received: by 10.223.14.12 with SMTP id e12mr4892474faa.23.1252114392636; Fri, 04 Sep 2009 18:33:12 -0700 (PDT) In-Reply-To: <4AA18288.2030505@fas.harvard.edu> References: <4AA16546.8050700@octasic.com> <4AA172A3.6060607@octasic.com> <200909041637.38125.simon.perreault@viagenie.ca> <4AA18288.2030505@fas.harvard.edu> Date: Fri, 4 Sep 2009 21:33:12 -0400 Message-ID: <6e9223710909041833r7481bc4ag9438266e8e92be90@mail.gmail.com> From: stephen botzko To: bens@alum.mit.edu Content-Type: multipart/alternative; boundary=00151747afa4975d3b0472ca99a7 Cc: codec@ietf.org Subject: Re: [codec] Codec guidelines and requirements drafts 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, 05 Sep 2009 01:32:56 -0000 --00151747afa4975d3b0472ca99a7 Content-Type: text/plain; charset=ISO-8859-1 I agree that there is a need for receivers to resample (or otherwise drop/add samples) in order to match the encoder's A/D clock rate with the receiver's D/A clock rate. If normal commercial crystals are used for clock sources, the A/D and D/A clocks may be mismatched by up to about 10 samples per second (for 48 khz audio). I am puzzled as to why you would want to build this resamplng into the codec however - I see no technical advantage in doing this The resampling is not related to the decoder operation itself, and needs to be done no motter what codec is in use..Some form of fixed resampling is often required anyway, in order to match (for instance) a 32 kHz sample rate used by a codec to the 48 kHz sample rate used by the sampling hardware. Stephen Botzko Polycom On Fri, Sep 4, 2009 at 5:11 PM, Benjamin M. Schwartz < bmschwar@fas.harvard.edu> wrote: > Simon Perreault wrote: > > On Friday 04 September 2009 16:03:47 Jean-Marc Valin wrote: > >> For example, some > >> people have suggested that codecs should be able to facilitate time > >> stretching/compressing. > > > > Does someone have a precise idea of what that means? > > How precise? > > Audio data arrives at some apparent rate, which we can measure in samples > per second on the local system sample clock. If the link latency and > buffering are constant, and the two endpoints' sample clocks tick at the > same rate, then the audio data will arrive at the "right" speed, and can > simply be decoded and thrown into the sound card's output buffer. > > If the buffer has to expand or contract over some period of time, or if > one of the endpoints ticks faster than the other, then fewer or more > samples will be received than the sound card requires to be played. The > codec must provide some mechanism to resolve this discrepancy. Commonly > suggested mechanisms include resampling (which bends pitch), smart > time-stretching to preserve pitch, and "adjust during silence". > > To me, the important question here is: what sort of interface does the > codec need to expose for time dilation? For example, it might be a > function that says "turn the next N coded samples into M decoded samples, > please". > > --Ben > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > --00151747afa4975d3b0472ca99a7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I agree that there is a need for receivers to resample (or otherwise drop/a= dd samples) in order to match the encoder's A/D clock rate with the rec= eiver's D/A clock rate. If normal commercial crystals are used for cloc= k sources, the A/D and D/A clocks may be mismatched by up to about 10 sampl= es per second (for 48 khz audio).

I am puzzled as to why you would want to build this resamplng into the = codec however - I see no technical advantage in doing this=A0

The r= esampling is not related to the decoder operation itself, and needs to be d= one no motter what codec is in use..Some form of fixed resampling is often = required anyway, in order to match (for instance) a 32 kHz sample rate used= by a codec to the 48 kHz sample rate used by the sampling hardware.

Stephen Botzko
Polycom

On Fri, Sep= 4, 2009 at 5:11 PM, Benjamin M. Schwartz <bmschwar@fas.harvard.edu> wr= ote:
Simon Perreault wrote:
> On Friday 04 September 2009 16:03:47 Jean-Marc Valin wrote:
>> For example, some
>> people have suggested that codecs should be able to facilitate tim= e
>> stretching/compressing.
>
> Does someone have a precise idea of what that means?

How precise?

Audio data arrives at some apparent rate, which we can measure in samples per second on the local system sample clock. =A0If the link latency and
buffering are constant, and the two endpoints' sample clocks tick at th= e
same rate, then the audio data will arrive at the "right" speed, = and can
simply be decoded and thrown into the sound card's output buffer.

If the buffer has to expand or contract over some period of time, or if
one of the endpoints ticks faster than the other, then fewer or more
samples will be received than the sound card requires to be played. =A0The<= br> codec must provide some mechanism to resolve this discrepancy. =A0Commonly<= br> suggested mechanisms include resampling (which bends pitch), smart
time-stretching to preserve pitch, and "adjust during silence".
To me, the important question here is: what sort of interface does the
codec need to expose for time dilation? For example, it might be a
function that says "turn the next N coded samples into M decoded sampl= es,
please".

--Ben


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


--00151747afa4975d3b0472ca99a7-- From steveu@coppice.org Fri Sep 4 19:34: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 925673A62C1 for ; Fri, 4 Sep 2009 19:34:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.549 X-Spam-Level: X-Spam-Status: No, score=-1.549 tagged_above=-999 required=5 tests=[AWL=-0.616, BAYES_00=-2.599, SARE_OBFU_PART_ING=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W9LomhZHHQyL for ; Fri, 4 Sep 2009 19:34:26 -0700 (PDT) Received: from cwb.pacific.net.hk (cwb.pacific.net.hk [202.14.67.92]) by core3.amsl.com (Postfix) with ESMTP id 833703A63D3 for ; Fri, 4 Sep 2009 19:34:26 -0700 (PDT) Received: from i7.coppice.org (68.166.17.210.dyn.pacific.net.hk [210.17.166.68]) by cwb.pacific.net.hk with ESMTP id n852XfbW007451; Sat, 5 Sep 2009 10:33:41 +0800 Message-ID: <4AA1CE05.40704@coppice.org> Date: Sat, 05 Sep 2009 10:33:41 +0800 From: Steve Underwood User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.1) Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3 MIME-Version: 1.0 To: stephen botzko References: <4AA16546.8050700@octasic.com> <4AA172A3.6060607@octasic.com> <200909041637.38125.simon.perreault@viagenie.ca> <4AA18288.2030505@fas.harvard.edu> <6e9223710909041833r7481bc4ag9438266e8e92be90@mail.gmail.com> In-Reply-To: <6e9223710909041833r7481bc4ag9438266e8e92be90@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bens@alum.mit.edu, codec@ietf.org Subject: Re: [codec] Codec guidelines and requirements drafts 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, 05 Sep 2009 02:34:27 -0000 Hi Stephen, The subject was not resampling, but time stretching. A time stretcher can become trivial if it is implemented within the codec, and generally produces better sounding results. Steve On 09/05/2009 09:33 AM, stephen botzko wrote: > I agree that there is a need for receivers to resample (or otherwise > drop/add samples) in order to match the encoder's A/D clock rate with > the receiver's D/A clock rate. If normal commercial crystals are used > for clock sources, the A/D and D/A clocks may be mismatched by up to > about 10 samples per second (for 48 khz audio). > > I am puzzled as to why you would want to build this resamplng into the > codec however - I see no technical advantage in doing this > > The resampling is not related to the decoder operation itself, and > needs to be done no motter what codec is in use..Some form of fixed > resampling is often required anyway, in order to match (for instance) > a 32 kHz sample rate used by a codec to the 48 kHz sample rate used by > the sampling hardware. > > Stephen Botzko > Polycom > > On Fri, Sep 4, 2009 at 5:11 PM, Benjamin M. Schwartz > > wrote: > > Simon Perreault wrote: > > On Friday 04 September 2009 16:03:47 Jean-Marc Valin wrote: > >> For example, some > >> people have suggested that codecs should be able to facilitate time > >> stretching/compressing. > > > > Does someone have a precise idea of what that means? > > How precise? > > Audio data arrives at some apparent rate, which we can measure in > samples > per second on the local system sample clock. If the link latency and > buffering are constant, and the two endpoints' sample clocks tick > at the > same rate, then the audio data will arrive at the "right" speed, > and can > simply be decoded and thrown into the sound card's output buffer. > > If the buffer has to expand or contract over some period of time, > or if > one of the endpoints ticks faster than the other, then fewer or more > samples will be received than the sound card requires to be > played. The > codec must provide some mechanism to resolve this discrepancy. > Commonly > suggested mechanisms include resampling (which bends pitch), smart > time-stretching to preserve pitch, and "adjust during silence". > > To me, the important question here is: what sort of interface does the > codec need to expose for time dilation? For example, it might be a > function that says "turn the next N coded samples into M decoded > samples, > please". > From hoene@uni-tuebingen.de Fri Sep 4 21:24: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 500FD3A688B for ; Fri, 4 Sep 2009 21:24:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.583 X-Spam-Level: X-Spam-Status: No, score=-4.583 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, SARE_OBFU_PART_ING=1.666] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XhGdfHzsCSnJ for ; Fri, 4 Sep 2009 21:24: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 C83633A684E for ; Fri, 4 Sep 2009 21:24:02 -0700 (PDT) Received: from hoeneLenovoT60 (dslb-092-074-190-143.pools.arcor-ip.net [92.74.190.143]) (authenticated bits=0) by mx06.uni-tuebingen.de (8.13.6/8.13.6) with ESMTP id n854OG1s015806 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sat, 5 Sep 2009 06:24:22 +0200 From: "Christian Hoene" To: References: <4AA16546.8050700@octasic.com> <4AA172A3.6060607@octasic.com> <200909041637.38125.simon.perreault@viagenie.ca> <4AA18288.2030505@fas.harvard.edu> <6e9223710909041833r7481bc4ag9438266e8e92be90@mail.gmail.com> <4AA1CE05.40704@coppice.org> In-Reply-To: <4AA1CE05.40704@coppice.org> Date: Sat, 5 Sep 2009 06:24:16 +0200 Message-ID: <001601ca2de0$be7cbad0$3b763070$@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: Acot0XlN6xwKqo8XSWm/P1kK6rQWeAAC6jdg Content-Language: de X-AntiVirus: NOT checked by Avira MailGate (version: 3.0.0-4; host: mx06) Subject: Re: [codec] Codec guidelines and requirements drafts 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, 05 Sep 2009 04:24:04 -0000 Hello, We discussed the need for time stretching already three months ago http://www.ietf.org/mail-archive/web/codec/current/msg00090.html May I cite Koen Vos again: " For instance, we've had detailed = discussions about what it takes to make a codec work on the Internet. We seemed to = agree that the codec should support not only packet loss concealment, but also time compression/stretching to handle network jitter. (Incidentally, = such time modification is not supported by any ITU, 3GPP or ETSI codec, which complicates their use for Internet applications.)" http://www.ietf.org/mail-archive/web/codec/current/msg00456.html I never read anything against this requirement on this list. Thus, it = can be seen as a topic of clear consensus.=20 Thus, Jean Marc, I am wondering why the input from this mailing list is ignored in your IETF requirements document- even if it is supported by = one of your coauthors.=20 If the pace of progress on technical issues remains as low as it is, - I = bet - you wouldn't get your codecs standardized in ten years time. Christian -------------------------------------------------------- Dr.-Ing. Christian Hoene Interactive Communication Systems (ICS), University of T=FCbingen Sand 13, 72076 T=FCbingen, Germany, Phone +49 7071 2970532 http://www.net.uni-tuebingen.de/ > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of > Steve Underwood > Sent: Saturday, September 05, 2009 4:34 AM > To: stephen botzko > Cc: bens@alum.mit.edu; codec@ietf.org > Subject: Re: [codec] Codec guidelines and requirements drafts >=20 > Hi Stephen, >=20 > The subject was not resampling, but time stretching. A time stretcher > can become trivial if it is implemented within the codec, and = generally > produces better sounding results. >=20 > Steve >=20 >=20 > On 09/05/2009 09:33 AM, stephen botzko wrote: > > I agree that there is a need for receivers to resample (or otherwise > > drop/add samples) in order to match the encoder's A/D clock rate = with > > the receiver's D/A clock rate. If normal commercial crystals are = used > > for clock sources, the A/D and D/A clocks may be mismatched by up to > > about 10 samples per second (for 48 khz audio). > > > > I am puzzled as to why you would want to build this resamplng into = the > > codec however - I see no technical advantage in doing this > > > > The resampling is not related to the decoder operation itself, and > > needs to be done no motter what codec is in use..Some form of fixed > > resampling is often required anyway, in order to match (for = instance) > > a 32 kHz sample rate used by a codec to the 48 kHz sample rate used = by > > the sampling hardware. > > > > Stephen Botzko > > Polycom > > > > On Fri, Sep 4, 2009 at 5:11 PM, Benjamin M. Schwartz > > > wrote: > > > > Simon Perreault wrote: > > > On Friday 04 September 2009 16:03:47 Jean-Marc Valin wrote: > > >> For example, some > > >> people have suggested that codecs should be able to = facilitate time > > >> stretching/compressing. > > > > > > Does someone have a precise idea of what that means? > > > > How precise? > > > > Audio data arrives at some apparent rate, which we can measure = in > > samples > > per second on the local system sample clock. If the link = latency and > > buffering are constant, and the two endpoints' sample clocks = tick > > at the > > same rate, then the audio data will arrive at the "right" speed, > > and can > > simply be decoded and thrown into the sound card's output = buffer. > > > > If the buffer has to expand or contract over some period of = time, > > or if > > one of the endpoints ticks faster than the other, then fewer or = more > > samples will be received than the sound card requires to be > > played. The > > codec must provide some mechanism to resolve this discrepancy. > > Commonly > > suggested mechanisms include resampling (which bends pitch), = smart > > time-stretching to preserve pitch, and "adjust during silence". > > > > To me, the important question here is: what sort of interface = does the > > codec need to expose for time dilation? For example, it might be = a > > function that says "turn the next N coded samples into M decoded > > samples, > > please". > > >=20 > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From stewe@stewe.org Fri Sep 4 21:42: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 CB9533A67D6 for ; Fri, 4 Sep 2009 21:42:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5FifZGh6OFY for ; Fri, 4 Sep 2009 21:42:44 -0700 (PDT) Received: from stewe.org (stewe.org [85.214.122.234]) by core3.amsl.com (Postfix) with ESMTP id 957D83A67B0 for ; Fri, 4 Sep 2009 21:42:43 -0700 (PDT) Received: from [192.168.1.105] (unverified [71.202.146.15]) by stewe.org (SurgeMail 3.9e) with ESMTP id 414563-1743317 for ; Sat, 05 Sep 2009 06:41:20 +0200 User-Agent: Microsoft-Entourage/12.20.0.090605 Date: Fri, 04 Sep 2009 21:41:11 -0400 From: Stephan Wenger To: "codec@ietf.org" Message-ID: Thread-Topic: [codec] [Fwd: I-D Action:draft-valin-codec-guidelines-00.txt] Thread-Index: Acot4xeV94Rs+yh9QkeQ9loLYdP/xg== In-Reply-To: <4AA15F1C.4070509@stpeter.im> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-Originating-IP: 71.202.146.15 X-Authenticated-User: stewe@stewe.org X-ORBS-Stamp: Your IP (71.202.146.15) was found in the spamhaus database. http://www.spamhaus.net Subject: Re: [codec] [Fwd: I-D Action:draft-valin-codec-guidelines-00.txt] 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, 05 Sep 2009 04:42:46 -0000 Folks, I read through this draft and found it, all in all, a well written document covering a lot of (to me) agreeable aspects. However, as you may expect, I have a number of comments, mostly on certain language aspects :-) If this were a working group effort, I would phrase some of my suggestion below in stronger terms. As things stand, you are, of course, free to ignore them... Regards, Stephan 1. Section 1 speaks in several places of "freely available". I would recommend to be more precise. There are just too many definitions, some of which contradicting, of what constitutes "freedom" in our business. 2. Section 1: the above remark also goes for the definition of "open". A very large part of the standardization people (perhaps a majority) associates "open" exclusively with "open process in the SDO" and not with what the draft implicitly assumes ("open" use, whatever that, in turn, may be). 3. Section 1, first bullet, "has inhibited": really? I don't believe this claim is true---certainly not in the form as made. At least, I have not seen a prove for this rather assertive statement. Suggest softening the language. 4. Section 1, final bullet: suggest replacing "will be freely available" with "may be available without royalties or other undue burden", as none of us has the means to guaranty something like "freely available". 5. Section 2.2, "preferably in the form of I-Ds". I'm not aware of any other form of input but I-Ds on which a WG or a group of people without WG status in the IETF could act on (and that would allow documenting the complexity undoubtly involved). Therefore, I would suggest to remove "preferably". Also, publishing an I-D undoubtly triggers the BCP79 disclosure requirements---unspecified input may not. 6. Section 2.3: I read this section as a license to re-tune the requirements document based on results obtained by tests (or even theoretical analysis) of input proposals. It may be necessary to do this. However, you are certainly aware of that such a procedure can lead to gaming and other evil things (including unfair exclusion of proposals with IPR properties that are within the scope of the IETF's IPR policy). If this were a working group charter, I would voice strong concerns over this vagueness. For an informal activity outside a WG, I only appeal to you to be careful in what you are doing. 7. Section 2.6: to add something positive, I'm thrilled that people will at least attempt to work cooperatively on codecs from very early on: this is IMHO one of the really weak spots traditional codec standardization has had in most of its instances. I'm also very happy to see the "no rubberstamping" sentence. 8. Section 2.7: developments of RTP payload formats happen in AVT. No need to word around that. 9. Section 3: I'm missing a statement on what happens if it turns out that the requirements are NOT met. I think there should be an end criteria of some sort. 10: I can see value in a strategy of not requiring a bit-exact encoder (as I see a value in having such a requirement---in classic telco applications, for example). However, I fail to see a value in not requiring bit-exact decoding. Is this a fixed/floating point issue? The can of worms one the IPR side one is opening by not strictly defining conformance cannot be overestimated. Almost every IPR statement in the IETF (and elsewhere) promises or grants licenses (or makes a non-assert covenant) only for conformant implementations. I would strongly recommend to require bit-exact decoding, for that reason alone. If you truly think that a soft definition of conformance is necessary from a technical viewpoint, then I would strongly recommend to at least define your version of conformance in a normative, permanent document (standard's track RFC) which includes the source code of the testing tool, and the test vectors against which soft conformance is tested. 11: Section 5, first bullet, "open", see remark #2 12: Section 5, first bullet, "conspicuous gap", see remark #3 13: Section 5, second bullet "freely", see remark #1 14: Section 5, fourth bullet, "free" , see remark #1 15: Section 5, "BSD license": it's not a BSD license. It's *currently* a BSD-style license. However, the IETF trust currently has control over this thing and could, in theory, change it. Recommend to read the relevant documents and come up with a precise and future-proof formulation. At this time of writing I do not have access to the documents in question (writing on a plane), but I can help in this. 16: Section 5, "royalty-free". Finally, this reasonably precise term is used. Why not earlier? However, just before that, the subject of open source compatibility is mentioned as well (though not in this formulation). Please note that it is very easy to draft a patent license that is royalty-free and NOT open source compatible. Similarly, I would argue that a good percentage of the RF licensing covenants in IETF IPR disclosures (in contrast to most non-assert covenants) are not compatible with the majority of the open source licenses in practical use. If you wish to express a desire for compatibility with open source models, then you may want to express this early on, in precise terms, and not with ambiguous language such as "free" and "open". 17: Section 5, "20 years": as I have mentioned a number of times before: a novel combination of 20year+ old tools may be patentable in its own right. You may wish to add a sentence in this regard. 18: "infringing": it is in most cases unwise to use the term "infringement" unless you truly know what you are doing---even in combination with "unknowingly". Suggest to replace "infringe" with "incur encumbrance" or something like this. 19: Section 6: I would suggest to remove this section in its entirety. Some information presented may be seen differently in the cited SDOs. For example, arguably, the low delay AAC effort is intended towards interactive work, and not storage. Also, there may be SDOs not mentioned here which have (or have had) viable speech/audio coding efforts that may feel insulted by not being mentioned (3GPP2 come to mind, and some others). As the very minimum, I would strongly suggest to "characterize" the other SDOs efforts using only their own (liaison-)statements or publications as a basis, and not your interpretation. On 9/4/09 2:40 PM, "Peter Saint-Andre" wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > FYI. > > /psa > > - -------- Original Message -------- > Subject: I-D Action:draft-valin-codec-guidelines-00.txt > Date: Fri, 4 Sep 2009 11:00:01 -0700 (PDT) > From: Internet-Drafts@ietf.org > Reply-To: internet-drafts@ietf.org > To: i-d-announce@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Guidelines for proposed CODEC working group > Author(s) : J. Valin, et al. > Filename : draft-valin-codec-guidelines-00.txt > Pages : 17 > Date : 2009-09-04 > > This document provides general guidelines for specifying audio codecs > within the IETF. These guidelines cover the development process, as > well as the evaluation and intellectual property issues. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-valin-codec-guidelines-00.txt > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkqhXxwACgkQNL8k5A2w/vw3KQCbBDmV7SZPXLaiHIDKN4UW1sZO > ZssAoJMDkNDNGGOXXscj4PoaB0HFWhtG > =Al+W > -----END PGP SIGNATURE----- > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec From alexander.chemeris@gmail.com Sat Sep 5 01:21: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 BB5413A6880 for ; Sat, 5 Sep 2009 01:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SEWCeAoPL4K for ; Sat, 5 Sep 2009 01:21:14 -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 970EE3A685D for ; Sat, 5 Sep 2009 01:21:13 -0700 (PDT) Received: by bwz19 with SMTP id 19so690532bwz.37 for ; Sat, 05 Sep 2009 01:21:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=prB+JHXsVUOAt0w6nTeQitDr9JPxoO7SZlfXFvS5qj0=; b=D/VQDZurpGCHkcGjC1t7yP87likQZcNEbkpOUwE/XwNUva72nJG9TtiOvC8/OK52XQ C4dHrutB+7UBUltirHOvdEP40auG9O7Xh6uQ5mC1H8oi5eCFSMommMoXI5SdQzmJW7pt fMMPllGnKQEtNZsZKDAOVxvON8AgRfkxnYweo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=fakgCpb3B80DQBjF4JPEbHmvKN9aP4zBHNd0hILUhyf2h8bCa98uqk7SfbZRa2vKr+ lnkUQbak2c+A4AJjUhLvOYEZ7WCaQQkNyFODXHhmb8XLPjLuyFlxUcYj0rMGU990ip+x jAtrYQL7XbinbFcwBUrX/FnkefyWWDNkIYoPE= MIME-Version: 1.0 Sender: alexander.chemeris@gmail.com Received: by 10.102.249.10 with SMTP id w10mr5154313muh.49.1252138890065; Sat, 05 Sep 2009 01:21:30 -0700 (PDT) In-Reply-To: <4AA16546.8050700@octasic.com> References: <4AA16546.8050700@octasic.com> From: Alexander Chemeris Date: Sat, 5 Sep 2009 12:21:10 +0400 X-Google-Sender-Auth: 7fb71cd02482241e Message-ID: <3d032e5d0909050121k3e327b88k987d82b5f2000f31@mail.gmail.com> To: Jean-Marc Valin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] Codec guidelines and requirements drafts 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, 05 Sep 2009 08:21:14 -0000 Hi, My few notes about the draft. I'll split this into two mails - this one is about technical considerations: 1) I wonder why support for double- or multi-talk is not mentioned. It's usually claimed that CELP codecs have hard time encoding conferences, where there are a lot of double- or multi-talk parts. I believe it should b= e stated as MUST or at least SHOULD for conferencing scenario and included in testing set. 2) I also think we should add an ability to retieve not only signal power, but a more complex VAD decision from the decoder, even without decoding a frame. I believe it sohuld be stressed more, that this is a very desired feature for conferencing and even more for gaming (where you can have 1000s of player and you can't go with decoding every stream). This would allow codec's use in so called tandem-free bridges, where streamsare not decoded at all. 3) It is also usually stated that VBR is bad for speech transport over the Internet, because it leads to higher loss rates then when CBR is used. So I would make more stress on making CBR works better, then requiring VBR. (here I refer to source-controlled VBR, which leads to fast bitrate changes). On Fri, Sep 4, 2009 at 23:06, Jean-Marc Valin wrote: > Hi, > > As a follow-up to the codec BoF in Stockholm, a group of interested IETF > participants has been working on how to move forward regarding this work = at > the IETF. =C2=A0As a result, today we have submitted two Internet-Drafts: > > (1) http://www.ietf.org/id/draft-valin-codec-guidelines-00.txt > (2) http://www.ietf.org/id/draft-valin-codec-requirements-00.txt > > We welcome feedback on these drafts on the codec@ietf.org list. > > Cheers, > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --=20 Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 From alexander.chemeris@gmail.com Sat Sep 5 01:22: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 6A1CE3A685D for ; Sat, 5 Sep 2009 01:22:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGJ0Do8M0rEk for ; Sat, 5 Sep 2009 01:22:18 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id 3E24B3A6880 for ; Sat, 5 Sep 2009 01:22:17 -0700 (PDT) Received: by fxm17 with SMTP id 17so1105181fxm.37 for ; Sat, 05 Sep 2009 01:22:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=uPwwmXCBnN7MD1QTs6OpcDylYeN0ygJAsMBXycSdzFE=; b=d7AwB21GFUTTnA0rKP1x9lIO6Ea9UZPuo32p/XVCTbep7enPoL2eqbK40Btp4zJd2W 7PeU1veOViPNxdxWKiTLswnoCJGbSajfoWLd63CVSGiAEsfyio9nrqqXdLWWSRpRyvkh lQ5JbIr27LoPsFpVISzwo8ERAv3zSuQ1g5WQY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=xQBg/4jImX9xokh2sLtskKCO3d8pGxZhpH665yv3UHG75gP2rm63mnPQOzZ3hDc8V6 PaSL0eLAU9QyXKgQEmmu6mz30rIY4vp3r5kQFpuIJZmmfrgdYrc/XuHvOfuCaWShtmqL Z++ft2Fw6IlqgZt3SRF8UhXQoApP3KCdWZ+m0= MIME-Version: 1.0 Sender: alexander.chemeris@gmail.com Received: by 10.103.125.35 with SMTP id c35mr5163344mun.30.1252138956168; Sat, 05 Sep 2009 01:22:36 -0700 (PDT) In-Reply-To: <4AA16546.8050700@octasic.com> References: <4AA16546.8050700@octasic.com> From: Alexander Chemeris Date: Sat, 5 Sep 2009 12:22:16 +0400 X-Google-Sender-Auth: 1781605edf6f2e4a Message-ID: <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> To: Jean-Marc Valin Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "codec@ietf.org" Subject: Re: [codec] Codec guidelines and requirements drafts 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, 05 Sep 2009 08:22:19 -0000 Hi, Here are the second part of my notes on drafts, non-technical part: 1) It should be clearly defined, that codec evaluation MUST be done for several languages, taking into account diferent types of them - e.g. tonal languages, caucasian languages, etc. If we aim at creating a world-wide codec, it should work good for more then English and few european languages. 2) Section 2, bullet 4: "Once a sufficient number of proposals has been received...". It should be clearly defined when it this "sufficient" number is reached. I actually don't like the word "sufficient", because it's not clean, sufficient for what is meant here. 3) Some time frames must be defined. At least it should be clearly stated that the effort aims at providing working codec in 1yr, 5yrs, 100yrs, etc. Taking into account the size of the goal, it might take indefinite time to achieve and should be limited. 4) In Section 3.1: A more subtle aspect is the information leak that can occur when the codec is used over an encrypted channel (e.g. [SRTP]). For example, it was suggested [wright08] that use of source-controlled VBR may reveal some information about a conversation through the size of the compressed packets. This would have to be investigated when standardizing a codec. At least it sohuld be specified how it's planned to be investigated? What is should be the result of such investigation? Actually I don't see why it should be done in the scope of this effort. On Fri, Sep 4, 2009 at 23:06, Jean-Marc Valin wrote: > Hi, > > As a follow-up to the codec BoF in Stockholm, a group of interested IETF > participants has been working on how to move forward regarding this work = at > the IETF. =C2=A0As a result, today we have submitted two Internet-Drafts: > > (1) http://www.ietf.org/id/draft-valin-codec-guidelines-00.txt > (2) http://www.ietf.org/id/draft-valin-codec-requirements-00.txt > > We welcome feedback on these drafts on the codec@ietf.org list. > > Cheers, > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Jean-Marc > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --=20 Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 From alexander.chemeris@gmail.com Sat Sep 5 01:44: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 883323A67EC for ; Sat, 5 Sep 2009 01:44:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXw-OihjEuJE for ; Sat, 5 Sep 2009 01:44:47 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id 3B2013A6929 for ; Sat, 5 Sep 2009 01:44:47 -0700 (PDT) Received: by fxm17 with SMTP id 17so1110713fxm.37 for ; Sat, 05 Sep 2009 01:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type:content-transfer-encoding; bh=Yww9mZJbVvp32QoUzaLCF7V4nid08FDBB+82Ie7pe5M=; b=njRTlGbQ7cqlvAzDWmj/v1n/i2bFFw+xVwZQ3L7FDHhnv1Lfmu1S2WWDCf6PJ26eyk tCDxg544gYSBhMwMDPlx52/CWVSR+EjNFIpnyF7zo1Wa8uWS/Ofkmruj5OzB9cBCGcvy UpgfPSGj4xIwjGvOYyaww2SyOTnaUdOdG94lE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=XUvqde7YhmGEDR7cT1LUefLKT7lglFEb9a8o40fnOxCSZ9tFtUY9Ur+zkarM+bUw62 DttnWe8u3AT8Tsce+2vywL2GInl750gsZ0/pS8+ei/d1MR87aGtcmNvkGzbyocYMX/xq zNjPV+TI4BVsaBi7fpl8SPEsU2/wMON8dW8WE= MIME-Version: 1.0 Sender: alexander.chemeris@gmail.com Received: by 10.103.84.1 with SMTP id m1mr5138226mul.34.1252140293859; Sat, 05 Sep 2009 01:44:53 -0700 (PDT) In-Reply-To: <4AA18288.2030505@fas.harvard.edu> References: <4AA16546.8050700@octasic.com> <4AA172A3.6060607@octasic.com> <200909041637.38125.simon.perreault@viagenie.ca> <4AA18288.2030505@fas.harvard.edu> From: Alexander Chemeris Date: Sat, 5 Sep 2009 12:44:33 +0400 X-Google-Sender-Auth: 0b5702d9a5f4de8e Message-ID: <3d032e5d0909050144t108e286fm68d92019be33e248@mail.gmail.com> To: bens@alum.mit.edu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: codec@ietf.org Subject: Re: [codec] Codec guidelines and requirements drafts 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, 05 Sep 2009 08:44:48 -0000 On Sat, Sep 5, 2009 at 01:11, Benjamin M. Schwartz wrote: > Audio data arrives at some apparent rate, which we can measure in samples > per second on the local system sample clock. =C2=A0If the link latency an= d > buffering are constant, and the two endpoints' sample clocks tick at the > same rate, then the audio data will arrive at the "right" speed, and can > simply be decoded and thrown into the sound card's output buffer. > > If the buffer has to expand or contract over some period of time, or if > one of the endpoints ticks faster than the other, then fewer or more > samples will be received than the sound card requires to be played. =C2= =A0The > codec must provide some mechanism to resolve this discrepancy. =C2=A0Comm= only > suggested mechanisms include resampling (which bends pitch), smart > time-stretching to preserve pitch, and "adjust during silence". > > To me, the important question here is: what sort of interface does the > codec need to expose for time dilation? For example, it might be a > function that says "turn the next N coded samples into M decoded samples, > please". I also greatly support inclusion of this feature to "SHOULD" as it is alrea= dy done with PLC. This will save a lot of CPU power and considerable increase voice quality in harsh network conditions. As it was already said, there are two kinds of time adjustment - "slow" and "fast". Slow one reflect the need to adjust playback rate to compensate clock skew between end points. Fast adjustment is usually done when you need to increase/decrease jitter buffer length to adopt to network conditio= ns. Slow adjustments may be made with resampling, but this is not suitable for conferencing and gaming cases, so usually slow adjustments are actually done as a set of repeating small fast adjustments. So even in case of LAN you will have to do time adjustments. And it's best made inside of a codec. re: API I've put a lot of time thinking about this when implemented sipX media engi= ne, and I same to conclusion that the best way to express desire of time stretc= h is with three values: 1) Signed number of samples you need to add/remove (e.g. +100 - I need to add 100 samples to the stream to increase JB length; -1200 - I need to remo= ve 1200 samples from the stream to considerably decrease JB length) 2) Some number of enumeration, showing the urgency (e.g. 0 - relax, you can do this during silent period, 1 - hurry up, stretch actual speech, 2 - urge= nt! if you do not stretch, we'll have to drop frames). 3) Next frame, if available. This allows to perform interpolation instead o= f extrapolation, improving quality. Though if stretching is done inside the c= odec, this probably is not needed. --=20 Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 From tme@americafree.tv Sat Sep 5 04:08: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 3A9583A6765 for ; Sat, 5 Sep 2009 04:08:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[AWL=-0.003, 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 nLIdHTEgr4FM for ; Sat, 5 Sep 2009 04:08:04 -0700 (PDT) Received: from mail.americafree.tv (rossini.americafree.tv [63.105.122.34]) by core3.amsl.com (Postfix) with ESMTP id 696FE3A677C for ; Sat, 5 Sep 2009 04:08:04 -0700 (PDT) Received: from [IPv6:::1] (rossini.americafree.tv [63.105.122.34]) by mail.americafree.tv (Postfix) with ESMTP id EE96B4A8670F; Sat, 5 Sep 2009 07:05:49 -0400 (EDT) Message-Id: <49613A2C-4736-4FA4-8B5B-93AF8391958D@americafree.tv> From: Marshall Eubanks To: Stephan Wenger 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 v936) Date: Sat, 5 Sep 2009 07:05:44 -0400 References: X-Mailer: Apple Mail (2.936) Cc: "codec@ietf.org" Subject: Re: [codec] [Fwd: I-D Action:draft-valin-codec-guidelines-00.txt] 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, 05 Sep 2009 11:08:06 -0000 On Sep 4, 2009, at 9:41 PM, Stephan Wenger wrote: > Folks, > I read through this draft and found it, all in all, a well written > document > covering a lot of (to me) agreeable aspects. However, as you may > expect, I > have a number of comments, mostly on certain language aspects :-) > If this > were a working group effort, I would phrase some of my suggestion > below in > stronger terms. As things stand, you are, of course, free to ignore > them... > Regards, > Stephan > > > 1. Section 1 speaks in several places of "freely available". I would > recommend to be more precise. There are just too many definitions, > some of > which contradicting, of what constitutes "freedom" in our business. > 2. Section 1: the above remark also goes for the definition of > "open". A > very large part of the standardization people (perhaps a majority) > associates "open" exclusively with "open process in the SDO" and not > with > what the draft implicitly assumes ("open" use, whatever that, in > turn, may > be). > 3. Section 1, first bullet, "has inhibited": really? I don't > believe this > claim is true---certainly not in the form as made. At least, I have > not > seen a prove for this rather assertive statement. Suggest softening > the > language. > 4. Section 1, final bullet: suggest replacing "will be freely > available" > with "may be available without royalties or other undue burden", as > none of > us has the means to guaranty something like "freely available". > > 5. Section 2.2, "preferably in the form of I-Ds". I'm not aware of > any > other form of input but I-Ds on which a WG or a group of people > without WG > status in the IETF could act on (and that would allow documenting the > complexity undoubtly involved). Therefore, I would suggest to remove > "preferably". Also, publishing an I-D undoubtly triggers the BCP79 > disclosure requirements---unspecified input may not. There is no way to publish an IETF stream RFC without beginning as an Internet-draft and without the contributors agreeing to the IETF IPR rules. This is true of AD sponsored drafts as well as WG sponsored drafts. The disclosure rules definitely apply to all IETF contributions. > 6. Section 2.3: I read this section as a license to re-tune the > requirements > document based on results obtained by tests (or even theoretical > analysis) > of input proposals. It may be necessary to do this. However, you are > certainly aware of that such a procedure can lead to gaming and > other evil > things (including unfair exclusion of proposals with IPR properties > that are > within the scope of the IETF's IPR policy). If this were a working > group > charter, I would voice strong concerns over this vagueness. For an > informal > activity outside a WG, I only appeal to you to be careful in what > you are > doing. > 7. Section 2.6: to add something positive, I'm thrilled that people > will at > least attempt to work cooperatively on codecs from very early on: > this is > IMHO one of the really weak spots traditional codec standardization > has had > in most of its instances. I'm also very happy to see the "no > rubberstamping" sentence. > 8. Section 2.7: developments of RTP payload formats happen in AVT. > No need > to word around that. > 9. Section 3: I'm missing a statement on what happens if it turns > out that > the requirements are NOT met. I think there should be an end > criteria of > some sort. > 10: I can see value in a strategy of not requiring a bit-exact > encoder (as I > see a value in having such a requirement---in classic telco > applications, > for example). However, I fail to see a value in not requiring bit- > exact > decoding. Is this a fixed/floating point issue? > The can of worms one the IPR side one is opening by not strictly > defining > conformance cannot be overestimated. Almost every IPR statement in > the IETF > (and elsewhere) promises or grants licenses (or makes a non-assert > covenant) > only for conformant implementations. I would strongly recommend to > require > bit-exact decoding, for that reason alone. If you truly think that > a soft > definition of conformance is necessary from a technical viewpoint, > then I > would strongly recommend to at least define your version of > conformance in a > normative, permanent document (standard's track RFC) which includes > the > source code of the testing tool, and the test vectors against which > soft > conformance is tested. > 11: Section 5, first bullet, "open", see remark #2 > 12: Section 5, first bullet, "conspicuous gap", see remark #3 > 13: Section 5, second bullet "freely", see remark #1 > 14: Section 5, fourth bullet, "free" , see remark #1 > 15: Section 5, "BSD license": it's not a BSD license. It's > *currently* a > BSD-style license. However, the IETF trust currently has control > over this > thing and could, in theory, change it. That is correct. Of course, licenses are granted to published text. I am not a lawyer, but my understanding is that these licenses, once granted, could not be made more restrictive retroactively. > Recommend to read the relevant > documents and come up with a precise and future-proof formulation. > At this > time of writing I do not have access to the documents in question > (writing > on a plane), but I can help in this. BCP 78 and 79 apply to IETF contributions and IETF publications. Note that IETF licenses explicitly and only refer to copyright, not patent - RFC5378 : 5.5. No Patent License The licenses granted in Section 5.3 shall not be deemed to grant any right under any patent, patent application, or other similar intellectual property right disclosed by the Contributor under BCP 79 [RFC3979] or otherwise. --- So, in the statement : In accordance with BCP 78 [RFC5378], the source code for the reference implementation should be available under the BSD license. I would take out "In accordance with BCP 78 [RFC5378],". If the reference implementation is published in an RFC, then IETF IPR rules will apply. If it is not, they will not. Regards Marshall > 16: Section 5, "royalty-free". Finally, this reasonably precise > term is > used. Why not earlier? However, just before that, the subject of > open > source compatibility is mentioned as well (though not in this > formulation). > Please note that it is very easy to draft a patent license that is > royalty-free and NOT open source compatible. Similarly, I would > argue that > a good percentage of the RF licensing covenants in IETF IPR > disclosures (in > contrast to most non-assert covenants) are not compatible with the > majority > of the open source licenses in practical use. If you wish to > express a > desire for compatibility with open source models, then you may want to > express this early on, in precise terms, and not with ambiguous > language > such as "free" and "open". > 17: Section 5, "20 years": as I have mentioned a number of times > before: a > novel combination of 20year+ old tools may be patentable in its own > right. > You may wish to add a sentence in this regard. > 18: "infringing": it is in most cases unwise to use the term > "infringement" > unless you truly know what you are doing---even in combination with > "unknowingly". Suggest to replace "infringe" with "incur > encumbrance" or > something like this. > 19: Section 6: I would suggest to remove this section in its > entirety. Some > information presented may be seen differently in the cited SDOs. For > example, arguably, the low delay AAC effort is intended towards > interactive > work, and not storage. Also, there may be SDOs not mentioned here > which > have (or have had) viable speech/audio coding efforts that may feel > insulted > by not being mentioned (3GPP2 come to mind, and some others). As > the very > minimum, I would strongly suggest to "characterize" the other SDOs > efforts > using only their own (liaison-)statements or publications as a > basis, and > not your interpretation. > > > > > > > On 9/4/09 2:40 PM, "Peter Saint-Andre" wrote: > >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> >> FYI. >> >> /psa >> >> - -------- Original Message -------- >> Subject: I-D Action:draft-valin-codec-guidelines-00.txt >> Date: Fri, 4 Sep 2009 11:00:01 -0700 (PDT) >> From: Internet-Drafts@ietf.org >> Reply-To: internet-drafts@ietf.org >> To: i-d-announce@ietf.org >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Guidelines for proposed CODEC working group >> Author(s) : J. Valin, et al. >> Filename : draft-valin-codec-guidelines-00.txt >> Pages : 17 >> Date : 2009-09-04 >> >> This document provides general guidelines for specifying audio codecs >> within the IETF. These guidelines cover the development process, as >> well as the evaluation and intellectual property issues. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-valin-codec-guidelines-00.txt >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.8 (Darwin) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ >> >> iEYEARECAAYFAkqhXxwACgkQNL8k5A2w/vw3KQCbBDmV7SZPXLaiHIDKN4UW1sZO >> ZssAoJMDkNDNGGOXXscj4PoaB0HFWhtG >> =Al+W >> -----END PGP SIGNATURE----- >> _______________________________________________ >> 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 Sat Sep 5 06:42: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 1BC623A6823 for ; Sat, 5 Sep 2009 06:42:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.593 X-Spam-Level: X-Spam-Status: No, score=-1.593 tagged_above=-999 required=5 tests=[AWL=1.006, 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 yojQeTtljJrK for ; Sat, 5 Sep 2009 06:42:11 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 2AD493A6765 for ; Sat, 5 Sep 2009 06:42:10 -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 <0KPI00D6R39NVYN0@VL-MH-MR002.ip.videotron.ca> for codec@ietf.org; Sat, 05 Sep 2009 09:39:23 -0400 (EDT) Message-id: <4AA26A0B.7080101@usherbrooke.ca> Date: Sat, 05 Sep 2009 09:39:23 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) To: Alexander Chemeris References: <4AA16546.8050700@octasic.com> <3d032e5d0909050121k3e327b88k987d82b5f2000f31@mail.gmail.com> In-reply-to: <3d032e5d0909050121k3e327b88k987d82b5f2000f31@mail.gmail.com> X-Enigmail-Version: 0.95.2 Cc: "codec@ietf.org" Subject: Re: [codec] Codec guidelines and requirements drafts 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, 05 Sep 2009 13:42:12 -0000 Alexander Chemeris a écrit : > 1) I wonder why support for double- or multi-talk is not mentioned. > It's usually claimed that CELP codecs have hard time encoding conferences, > where there are a lot of double- or multi-talk parts. I believe it should be > stated as MUST or at least SHOULD for conferencing scenario and > included in testing set. Indeed, this is a very good point that we forgot for the conferencing-type applications. Will add that. > 2) I also think we should add an ability to retieve not only signal power, > but a more complex VAD decision from the decoder, even without decoding > a frame. I believe it sohuld be stressed more, that this is a very desired > feature for conferencing and even more for gaming (where you can have > 1000s of player and you can't go with decoding every stream). This would > allow codec's use in so called tandem-free bridges, where streamsare not > decoded at all. Well, the current text reads like this: "the ability to derive sufficient parameters, such as loudness and/or spectral envelope, for estimating voice activity of a compressed frame without fully decoding that frame". I believe that the spectral envelope contains pretty much what you need here. Any other info that you think is important? > 3) It is also usually stated that VBR is bad for speech transport over > the Internet, because it leads to higher loss rates then when CBR is used. > So I would make more stress on making CBR works better, then requiring > VBR. (here I refer to source-controlled VBR, which leads to fast bitrate > changes). Do you have any reference regarding VBR and loss rate? In any case, I think it's clear that both VBR and CBR have valid use cases. Jean-Marc > On Fri, Sep 4, 2009 at 23:06, Jean-Marc > Valin wrote: >> Hi, >> >> As a follow-up to the codec BoF in Stockholm, a group of interested IETF >> participants has been working on how to move forward regarding this work at >> the IETF. As a result, today we have submitted two Internet-Drafts: >> >> (1) http://www.ietf.org/id/draft-valin-codec-guidelines-00.txt >> (2) http://www.ietf.org/id/draft-valin-codec-requirements-00.txt >> >> We welcome feedback on these drafts on the codec@ietf.org list. >> >> Cheers, >> >> Jean-Marc >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> > > > From simon.perreault@viagenie.ca Sat Sep 5 07:15: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 E4A423A67F2 for ; Sat, 5 Sep 2009 07:15:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.047, BAYES_00=-2.599, NO_RELAYS=-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 OIOInHzTC8vT for ; Sat, 5 Sep 2009 07:15:43 -0700 (PDT) Received: from jazz.viagenie.ca (jazz.viagenie.ca [IPv6:2620:0:230:8000::2]) by core3.amsl.com (Postfix) with ESMTP id 9F5603A67C1 for ; Sat, 5 Sep 2009 07:15:42 -0700 (PDT) Received: by jazz.viagenie.ca (Postfix, from userid 8) id 4087A29E1611; Sat, 5 Sep 2009 10:16:02 -0400 (EDT) From: Simon Perreault Organization: =?iso-8859-1?q?Viag=E9nie?= To: Alexander Chemeris Date: Sat, 5 Sep 2009 10:16:00 -0400 User-Agent: KMail/1.11.4 (Linux/2.6.29.6-217.2.8.fc11.x86_64; KDE/4.2.4; x86_64; ; ) References: <4AA16546.8050700@octasic.com> <4AA18288.2030505@fas.harvard.edu> <3d032e5d0909050144t108e286fm68d92019be33e248@mail.gmail.com> In-Reply-To: <3d032e5d0909050144t108e286fm68d92019be33e248@mail.gmail.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200909051016.00735.simon.perreault@viagenie.ca> Cc: bens@alum.mit.edu, codec@ietf.org Subject: Re: [codec] Codec guidelines and requirements drafts 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, 05 Sep 2009 14:15:44 -0000 On Saturday 05 September 2009 04:44:33 Alexander Chemeris wrote: > As it was already said, there are two kinds of time adjustment - "slow" and > "fast". Slow one reflect the need to adjust playback rate to compensate > clock skew between end points. Fast adjustment is usually done when you > need to increase/decrease jitter buffer length to adopt to network > conditions. Slow adjustments may be made with resampling, but this is not > suitable for conferencing and gaming cases, so usually slow adjustments are > actually done as a set of repeating small fast adjustments. So even in case > of LAN you will have to do time adjustments. And it's best made inside of a > codec. This last sentence puzzles me. Care to explain it? Thanks, Simon -- DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca vCard 4.0 --> http://www.vcarddav.org From jean-marc.valin@usherbrooke.ca Sat Sep 5 07:59: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 C57E53A684B for ; Sat, 5 Sep 2009 07:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.928 X-Spam-Level: X-Spam-Status: No, score=-1.928 tagged_above=-999 required=5 tests=[AWL=0.671, 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 MNg8xGTivuEM for ; Sat, 5 Sep 2009 07:59:56 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id E3E7A3A67FE for ; Sat, 5 Sep 2009 07:59:55 -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-MR005.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KPI006W13RPBOD0@VL-MO-MR005.ip.videotron.ca> for codec@ietf.org; Sat, 05 Sep 2009 09:50:14 -0400 (EDT) Message-id: <4AA26C95.8090504@usherbrooke.ca> Date: Sat, 05 Sep 2009 09:50:13 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) To: Alexander Chemeris References: <4AA16546.8050700@octasic.com> <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> In-reply-to: <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> X-Enigmail-Version: 0.95.2 Cc: "codec@ietf.org" Subject: Re: [codec] Codec guidelines and requirements drafts 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, 05 Sep 2009 14:59:56 -0000 Alexander Chemeris a écrit : > Here are the second part of my notes on drafts, non-technical part: > > 1) It should be clearly defined, that codec evaluation MUST be done for > several languages, taking into account diferent types of them - e.g. tonal > languages, caucasian languages, etc. If we aim at creating a world-wide > codec, it should work good for more then English and few european > languages. I think this actually belongs to the requirements, but otherwise I totally agree that this is currently missing. > 2) Section 2, bullet 4: "Once a sufficient number of proposals has been > received...". It should be clearly defined when it this "sufficient" number > is reached. I actually don't like the word "sufficient", because it's not > clean, sufficient for what is meant here. Will try and come up with something clearer. In any case, it's not that much about numbers as it is about having all the "building blocks" required. Any thoughts? > 3) Some time frames must be defined. At least it should be clearly > stated that the effort aims at providing working codec in 1yr, 5yrs, > 100yrs, etc. Taking into account the size of the goal, it might take > indefinite time to achieve and should be limited. Someone more knowledgeable of the IETF process can correct me if I'm wrong here, but my understanding is that the time frame belongs to the charter "milestones" section. > 4) In Section 3.1: > A more subtle aspect is the information leak that can occur when the > codec is used over an encrypted channel (e.g. [SRTP]). For example, > it was suggested [wright08] that use of source-controlled VBR may > reveal some information about a conversation through the size of the > compressed packets. This would have to be investigated when > standardizing a codec. > At least it sohuld be specified how it's planned to be investigated? What > is should be the result of such investigation? Actually I don't see why > it should be done in the scope of this effort. I think this is where cross area review is useful. I assume that in the worst case, we would end up with using only CBR for SRTP. Cheers, Jean-Marc > > On Fri, Sep 4, 2009 at 23:06, Jean-Marc > Valin wrote: >> Hi, >> >> As a follow-up to the codec BoF in Stockholm, a group of interested IETF >> participants has been working on how to move forward regarding this work at >> the IETF. As a result, today we have submitted two Internet-Drafts: >> >> (1) http://www.ietf.org/id/draft-valin-codec-guidelines-00.txt >> (2) http://www.ietf.org/id/draft-valin-codec-requirements-00.txt >> >> We welcome feedback on these drafts on the codec@ietf.org list. >> >> Cheers, >> >> Jean-Marc >> _______________________________________________ >> codec mailing list >> codec@ietf.org >> https://www.ietf.org/mailman/listinfo/codec >> > > > From jason.fischl@skypelabs.com Sat Sep 5 11:15: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 0448E3A6821 for ; Sat, 5 Sep 2009 11:15:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SPkI5FYmCljB for ; Sat, 5 Sep 2009 11:15:55 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id 21ED63A6810 for ; Sat, 5 Sep 2009 11:15:55 -0700 (PDT) Received: by pzk42 with SMTP id 42so148570pzk.31 for ; Sat, 05 Sep 2009 11:15:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.141.42.21 with SMTP id u21mr3095392rvj.174.1252170028211; Sat, 05 Sep 2009 10:00:28 -0700 (PDT) In-Reply-To: <4AA16D90.2040800@stpeter.im> References: <4AA121C2.8020508@stpeter.im> <4AA16D90.2040800@stpeter.im> From: Jason Fischl Date: Sat, 5 Sep 2009 10:00:08 -0700 Message-ID: <1a83ee190909051000w25c3cc33h8e2138fcc9873331@mail.gmail.com> To: "codec@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 X-Mailman-Approved-At: Sat, 05 Sep 2009 11:56:33 -0700 Subject: Re: [codec] Minutes from IETF 75 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: Sat, 05 Sep 2009 18:46:22 -0000 The minutes have been uploaded now: http://www.ietf.org/proceedings/75/minutes/codec.txt Many thanks to Peter for editing them. Jason On Fri, Sep 4, 2009 at 12:42 PM, Peter Saint-Andre wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > It has been brought to my attention that my previous message was > unreadable in certain email user agents. The minutes will eventually be > posted on the IETF website, but until then you can find them here: > > http://www.saint-andre.com/tmp/codec-minutes.txt > > /psa > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.8 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAkqhbZAACgkQNL8k5A2w/vxm3gCgq8zj2PkvoWEtiWxw3bF8f9QM > p3cAoMLAfdzPt11X3qxZmJgnb1Z5sgl3 > =ZcDv > -----END PGP SIGNATURE----- > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > From koen.vos@skype.net Sat Sep 5 15:51: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 660003A67EE for ; Sat, 5 Sep 2009 15:51:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.591 X-Spam-Level: X-Spam-Status: No, score=-3.591 tagged_above=-999 required=5 tests=[AWL=-2.851, BAYES_20=-0.74] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J6CfcGcI3WPk for ; Sat, 5 Sep 2009 15:51:48 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 3EC893A6778 for ; Sat, 5 Sep 2009 15:51:48 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id C434C60327495; Sat, 5 Sep 2009 23:52:10 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=BbdlbcvX3b87 o6PHUduxOdISkJs=; b=expvGWllmCsgAac2nO+zpkKgLW9YXP4LmwWS/AS7x/7d xdve6yOXnOfb9zLR01JSvZJLHrRdss7H9E8os5gUx9aN+hh/t0Jyxpnfuqts1ZUr Wmmt1XOp+lFPxBnBpjEeimElb941mnUR/aVrLah4OkmTmZNH0KUS1b0R5Z7AbC8= 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=kqYviNTHrP9ykw9/l4P/ 4M7M4EKMuBDggNeLV+41IknbTFOBoQWJTvULPjDmG3/2Ziy5kjHKAuWDRwXvTfRY tD7iuOkbsQEW/74mmj9slqk3/RglaDWxgSZ1UBOivOi1q7dkH2YXMJTNweF1kfRS hpkikcj3WZKbRdoT9GsyllU= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id C268860327467; Sat, 5 Sep 2009 23:52:10 +0100 (IST) Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjW24z69LCKr; Sat, 5 Sep 2009 23:52:10 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id AFEC56032746A; Sat, 5 Sep 2009 23:52:10 +0100 (IST) Received: from adsl-71-141-110-218.dsl.snfc21.pacbell.net (adsl-71-141-110-218.dsl.snfc21.pacbell.net [71.141.110.218]) by mail.skype.net (Horde Framework) with HTTP; Sat, 05 Sep 2009 15:52:10 -0700 Message-ID: <20090905155210.143958svqk5c29ay@mail.skype.net> Date: Sat, 05 Sep 2009 15:52:10 -0700 From: Koen Vos To: Alexander Chemeris , Jean-Marc Valin References: <4AA16546.8050700@octasic.com> <3d032e5d0909050121k3e327b88k987d82b5f2000f31@mail.gmail.com> <4AA26A0B.7080101@usherbrooke.ca> In-Reply-To: <4AA26A0B.7080101@usherbrooke.ca> 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 guidelines and requirements drafts 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, 05 Sep 2009 22:51:49 -0000 Quoting Jean-Marc Valin: >> 3) It is also usually stated that VBR is bad for speech transport over >> the Internet, because it leads to higher loss rates then when CBR is used. >> [...] > > Do you have any reference regarding VBR and loss rate? In any case, I > think it's clear that both VBR and CBR have valid use cases. I'm only aware of the opposite relationship between VBR and packet loss: short peaks at higher rate are easily handled by the packet buffer in the bottleneck (e.g. DSL modem). Even temporarily exceeding the network bandwidth only results in a small amount of jitter. On the other hand, constantly exceeding the network bandwidth not only guarantees packet loss, but also keeps the packet buffer filled up, easily adding hundreds of milliseconds of extra delay to the call. Other arguments against using CBR: - At a given quality level, VBR results in fewer total bits (~ half) being sent over the network over the duration of a call. - VBR helps on the receiving end to estimate the available network bandwidth, so that the codec can adjust to it (using a feedback channel). VBR seems better suited for the Internet than CBR. best, koen. From koen.vos@skype.net Sat Sep 5 16:18: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 4915B3A68DD for ; Sat, 5 Sep 2009 16:18:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.57 X-Spam-Level: X-Spam-Status: No, score=-3.57 tagged_above=-999 required=5 tests=[AWL=-0.971, 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 RAOt56SklpcO for ; Sat, 5 Sep 2009 16:18:46 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 00DFB3A6945 for ; Sat, 5 Sep 2009 16:18:46 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 8BAF36046F3B7; Sun, 6 Sep 2009 00:19:09 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=7hagbK7UqSp4 WecB/4E3B2KBp/o=; b=WSF+26eBJcZaE+/yV2i+BvVnVAUOibQjORuYf3biF90Z y9IB8k+A7zJP7BqcyF1bZFtgI/nwUqeFee8/kOSj4CACzkL5XUFSSeWK0SipDRli BtKo55Y660zhjwuJe1OiBSlU7q/0SvqP3skR/AIWBqt7EXDLu4paPMCil0iBZwM= 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=h4FjpWcGPqu+72l8trhw feYx0pbjW1kZdCw3ubUh5/mH9647DBuCAYqOexF8JI/HGm/pG0ZWM+wRbElbHB7h MSoEL2nhjFvyVcjUcSbWF+kk4rXZ5U0SMBj9zWHEG42fvKzoj7MjW5trelZxnQ81 IBEd5gS8uycky/GS0B8EemU= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 89F336040EF52; Sun, 6 Sep 2009 00:19:09 +0100 (IST) Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtgeUaIWkt4w; Sun, 6 Sep 2009 00:19:09 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 7351C6040EF5C; Sun, 6 Sep 2009 00:19:09 +0100 (IST) Received: from adsl-71-141-110-218.dsl.snfc21.pacbell.net (adsl-71-141-110-218.dsl.snfc21.pacbell.net [71.141.110.218]) by mail.skype.net (Horde Framework) with HTTP; Sat, 05 Sep 2009 16:19:09 -0700 Message-ID: <20090905161909.77713cwiggjt4cml@mail.skype.net> Date: Sat, 05 Sep 2009 16:19:09 -0700 From: Koen Vos To: Jean-Marc Valin , Alexander Chemeris References: <4AA16546.8050700@octasic.com> <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> <4AA26C95.8090504@usherbrooke.ca> In-Reply-To: <4AA26C95.8090504@usherbrooke.ca> 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 guidelines and requirements drafts 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, 05 Sep 2009 23:18:47 -0000 Quoting Jean-Marc Valin: >> 4) In Section 3.1: >> A more subtle aspect is the information leak that can occur when the >> codec is used over an encrypted channel (e.g. [SRTP]). For example, >> it was suggested [wright08] that use of source-controlled VBR may >> reveal some information about a conversation through the size of the >> compressed packets. This would have to be investigated when >> standardizing a codec. >> At least it sohuld be specified how it's planned to be investigated? What >> is should be the result of such investigation? Actually I don't see why >> it should be done in the scope of this effort. > > I think this is where cross area review is useful. I assume that in the > worst case, we would end up with using only CBR for SRTP. There's already a draft suggesting that: http://www.ietf.org/id/draft-perkins-avt-srtp-vbr-audio-01.txt The [wright08] reference talks about recognizing whole sentences, from a small "dictionary" of 122 sentences, all read in a controlled environment, with the same TIMIT database being used for training and evaluation. I'm sure that just the *length* of the sentence reveals information about which sentence is being read. So should we also look into hiding the duration of calls? The [wright08] results do not provide any evidence that "free" speech can be recognized by looking at packet sizes. Speech recognition is hard even when the speech signal is available. koen. From jean-marc.valin@usherbrooke.ca Sat Sep 5 18:57: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 874493A683D for ; Sat, 5 Sep 2009 18:57:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[AWL=0.503, 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 5YS-iG3irJoN for ; Sat, 5 Sep 2009 18:57:35 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id C4C9C3A67A1 for ; Sat, 5 Sep 2009 18:57:35 -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 <0KPJ00G7F1GMRC30@VL-MO-MR003.ip.videotron.ca> for codec@ietf.org; Sat, 05 Sep 2009 21:57:59 -0400 (EDT) Message-id: <4AA31726.3040904@usherbrooke.ca> Date: Sat, 05 Sep 2009 21:57:58 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) To: Koen Vos References: <4AA16546.8050700@octasic.com> <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> <4AA26C95.8090504@usherbrooke.ca> <20090905161909.77713cwiggjt4cml@mail.skype.net> In-reply-to: <20090905161909.77713cwiggjt4cml@mail.skype.net> X-Enigmail-Version: 0.95.2 Cc: "codec@ietf.org" Subject: Re: [codec] Codec guidelines and requirements drafts 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, 06 Sep 2009 01:57:36 -0000 Koen Vos a écrit : > The [wright08] reference talks about recognizing whole sentences, from a > small "dictionary" of 122 sentences, all read in a controlled > environment, with the same TIMIT database being used for training and > evaluation. I'm sure that just the *length* of the sentence reveals > information about which sentence is being read. So should we also look > into hiding the duration of calls? I think [wright08] is interesting in that it raises awareness about a *potential* issue with VBR. However, I think its main limitation is that is that it shows a potential information leak in the *Speex* VBR. At this point, I'm not sure whether the results would generalise to a codec other than Speex, which decides on the rate based on very simple heuristics (very unlike SILK). So while I think we need to be careful, I'm not yet ready to say that encrypted VBR is evil. OTOH, I think pure CBR has its advantages as well and see no reason we can't have both. > The [wright08] results do not provide any evidence that "free" speech > can be recognized by looking at packet sizes. Speech recognition is > hard even when the speech signal is available. I can confirm this. The Speex VBR leaks in the order of 50 bits/second. That would make a pretty bad recogniser -- even if the VBR code was specifically optimised for recognition rate. Cheers, Jean-Marc From koen.vos@skype.net Sun Sep 6 16:41: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 025743A677E for ; Sun, 6 Sep 2009 16:41:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[AWL=-1.935, BAYES_40=-0.185] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yFnHd69WJz31 for ; Sun, 6 Sep 2009 16:41:54 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id EACA33A67ED for ; Sun, 6 Sep 2009 16:41:53 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 03BE3604BDB9C; Mon, 7 Sep 2009 00:42:19 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=ndXUu5Mr6IKN QGkHsgfwoF8ZXsM=; b=ZvoI/S0GKZI2rgkIi4k5nDdN9CdLx6hT6SV381ht4/d4 B/8ttiscWSNmHLqs5i9zKltwi+jfoNZMe9+2dWRKtsnlnIrk5ptzu/5CvHoOGnKt JmkpikvDOPy1I0dRV1DLAjN6te22odwo4Tmo1VXerSpFGr4eZNSSTJO6SG5S2Zs= 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=CuBuh3kQlMPUdY7czSrC q9sib8oElfrU2bTtf29IG7Iy8KvzgKEqmF0ZsFLF6rixLFvlEeCDYtFRwGWOdFnn vGhoX+DR6lR65J16mlE8vz9J7G5tfk1y15Zs7Y5Ra4nfdGazuKSEt5ZQg/+Wekmg TIg/iBW0Te4Ehu+Yr12MY9w= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 01E45604BDB9B; Mon, 7 Sep 2009 00:42:19 +0100 (IST) Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMjr-3g6QQpW; Mon, 7 Sep 2009 00:42:18 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id DFF2C604BDB9A; Mon, 7 Sep 2009 00:42:18 +0100 (IST) Received: from adsl-71-141-110-218.dsl.snfc21.pacbell.net (adsl-71-141-110-218.dsl.snfc21.pacbell.net [71.141.110.218]) by mail.skype.net (Horde Framework) with HTTP; Sun, 06 Sep 2009 16:42:18 -0700 Message-ID: <20090906164218.85586qpxwpiv2guy@mail.skype.net> Date: Sun, 06 Sep 2009 16:42:18 -0700 From: Koen Vos To: Jean-Marc Valin References: <4AA16546.8050700@octasic.com> <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> <4AA26C95.8090504@usherbrooke.ca> <20090905161909.77713cwiggjt4cml@mail.skype.net> <4AA31726.3040904@usherbrooke.ca> In-Reply-To: <4AA31726.3040904@usherbrooke.ca> 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 guidelines and requirements drafts 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, 06 Sep 2009 23:41:55 -0000 Quoting Jean-Marc Valin: > OTOH, I think pure CBR has its advantages as well and see no reason > we can't have both. Agree that we can have both. But just out of curiosity, what are specific advantages of CBR (besides the irrational fear that VBR would enable eavesdropping)? I think Internet codecs should be optimized for low average bitrate more than low peak bitrate, because data channels have become shared. Similarly, average complexity is more important than peak complexity, because there are fewer hard real-time requirements in the system (especially on the encoder side). best, koen. From jean-marc.valin@usherbrooke.ca Sun Sep 6 18:06: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 144953A68E5 for ; Sun, 6 Sep 2009 18:06:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.197 X-Spam-Level: X-Spam-Status: No, score=-2.197 tagged_above=-999 required=5 tests=[AWL=0.403, 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 t6pC9zsrx2cF for ; Sun, 6 Sep 2009 18:06:48 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 4405A3A68C1 for ; Sun, 6 Sep 2009 18:06:48 -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 <0KPK00DP4TS1QLX0@VL-MH-MR001.ip.videotron.ca> for codec@ietf.org; Sun, 06 Sep 2009 21:07:14 -0400 (EDT) Message-id: <4AA45CC1.7050500@usherbrooke.ca> Date: Sun, 06 Sep 2009 21:07:13 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) To: Koen Vos References: <4AA16546.8050700@octasic.com> <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> <4AA26C95.8090504@usherbrooke.ca> <20090905161909.77713cwiggjt4cml@mail.skype.net> <4AA31726.3040904@usherbrooke.ca> <20090906164218.85586qpxwpiv2guy@mail.skype.net> In-reply-to: <20090906164218.85586qpxwpiv2guy@mail.skype.net> X-Enigmail-Version: 0.95.2 Cc: "codec@ietf.org" Subject: Re: [codec] Codec guidelines and requirements drafts 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, 07 Sep 2009 01:06:49 -0000 Koen Vos a écrit : > Quoting Jean-Marc Valin: >> OTOH, I think pure CBR has its advantages as well and see no reason we >> can't have both. > > Agree that we can have both. But just out of curiosity, what are > specific advantages of CBR (besides the irrational fear that VBR would > enable eavesdropping)? I wouldn't call the fear of encrypted VBR irrational, even though I believe it is likely blown out of proportion. Actually, to me the main leak involved in VBR is letting an eavesdroper know when there is active speech. This is pretty much the same leak as that caused by a VAD, or even knowing someone is present from the increased video bandwidth. In any case, the fact that some people want CBR justifies including it as a requirement. This is not to say that we shouldn't also have VBR, or even that it shouldn't be optimised for VBR. If we have a very good VBR codec, I don't think it would be that hard to do CBR with it (even if it means doing a bit of padding). > I think Internet codecs should be optimized for low average bitrate more > than low peak bitrate, because data channels have become shared. I agree that for most applications, average bit-rate is probably more important than peak. > Similarly, average complexity is more important than peak complexity, > because there are fewer hard real-time requirements in the system > (especially on the encoder side). I actually disagree about average complexity. Even though average complexity matters, peak complexity is what determines whether (e.g.) an embedded DSP is powerful enough to run the codec in real-time. Cheers, Jean-Marc From bmschwar@fas.harvard.edu Sun Sep 6 18:17: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 250003A6814 for ; Sun, 6 Sep 2009 18:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCTNdjdALaKF for ; Sun, 6 Sep 2009 18:17:15 -0700 (PDT) Received: from us20.unix.fas.harvard.edu (us20.unix.fas.harvard.edu [140.247.35.200]) by core3.amsl.com (Postfix) with ESMTP id D15A23A6828 for ; Sun, 6 Sep 2009 18:17:14 -0700 (PDT) Received: from [192.168.1.100] (c-71-192-160-188.hsd1.nh.comcast.net [71.192.160.188]) (authenticated bits=0) by us20.unix.fas.harvard.edu (8.14.1/8.14.1) with ESMTP id n871HeUk025554 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 6 Sep 2009 21:17:41 -0400 Message-ID: <4AA45F36.60209@fas.harvard.edu> Date: Sun, 06 Sep 2009 21:17:42 -0400 From: "Benjamin M. Schwartz" User-Agent: Thunderbird 2.0.0.22 (X11/20090714) MIME-Version: 1.0 To: Koen Vos References: <4AA16546.8050700@octasic.com> <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> <4AA26C95.8090504@usherbrooke.ca> <20090905161909.77713cwiggjt4cml@mail.skype.net> <4AA31726.3040904@usherbrooke.ca> <20090906164218.85586qpxwpiv2guy@mail.skype.net> In-Reply-To: <20090906164218.85586qpxwpiv2guy@mail.skype.net> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig61F41578465B479F17030FEF" Cc: "codec@ietf.org" , Jean-Marc Valin Subject: Re: [codec] Codec guidelines and requirements drafts X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu 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, 07 Sep 2009 01:17:16 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig61F41578465B479F17030FEF Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Koen Vos wrote: > Quoting Jean-Marc Valin: >=20 >> OTOH, I think pure CBR has its advantages as well and see no reason we= >> can't have both. >=20 > Agree that we can have both. But just out of curiosity, what are > specific advantages of CBR (besides the irrational fear that VBR would > enable eavesdropping)? I can think of many advantages to a codec whose peak bandwidth (in a window of N milliseconds) can easily be limited. For example, there are many places where telephone modems are still the most common form of internet connection. A good mono voice codec capped at 32kbps could easily outperform the underlying telephone system for voice quality, in addition to providing the connectivity advantages of VoIP. If you can limit peak bandwidth, then CBR is trivial. --------------enig61F41578465B479F17030FEF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkqkXzYACgkQUJT6e6HFtqTpHgCbBu6YaqCRvGHLHH4bhtlyTN5I kDIAn3ltWUYghZgGmLu5NnUeGy63+rWn =su7H -----END PGP SIGNATURE----- --------------enig61F41578465B479F17030FEF-- From koen.vos@skype.net Sun Sep 6 21:26: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 071BD3A680D for ; Sun, 6 Sep 2009 21:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.94 X-Spam-Level: X-Spam-Status: No, score=-2.94 tagged_above=-999 required=5 tests=[AWL=-0.341, 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 Jm5aBeMfRewT for ; Sun, 6 Sep 2009 21:26:28 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id E1D3F3A6851 for ; Sun, 6 Sep 2009 21:26:27 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 622EC60327492; Mon, 7 Sep 2009 05:26:54 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=BsylUhrV7CF3 rd/p6e/tBQnTqaE=; b=cc2kI2iXrOwicfrlJfnhxgqtWV0iBMBPxzDo8Dp9Px0y LYIKz1DIp4ll5OmiVA8HTI66FM29QDtMdjPgMkoveiwnpLDPiNJA7Vo9/AIxsFS9 jZ4AHb2Dgt7nqo2s8yB0Cs1uLC5eqf+lK0KvPdeLjJCmhvsh0+fPLV2Yoit8+Rk= 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=fAmhwGR4eV4uFQP2Z2Zh Djrhq9WA+uSW6pvNcwyTs/pDcroqZrlZEH/Zpv9Z/vghnxnHWaGDVZfY3+5ltnEz pJjrXtdpRWomRBbdMlA6Wqwv9nka2HfaiHB+/YT3mqWokGG0sDEdrbFHewUYjLZb mzSY/YfZLhdAtXBnZU65/PE= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 608EE60327466; Mon, 7 Sep 2009 05:26:54 +0100 (IST) Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b19yJy+MccdP; Mon, 7 Sep 2009 05:26:54 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 4DF1660327468; Mon, 7 Sep 2009 05:26:54 +0100 (IST) Received: from adsl-71-141-110-218.dsl.snfc21.pacbell.net (adsl-71-141-110-218.dsl.snfc21.pacbell.net [71.141.110.218]) by mail.skype.net (Horde Framework) with HTTP; Sun, 06 Sep 2009 21:26:54 -0700 Message-ID: <20090906212654.2061286irwdvsbda@mail.skype.net> Date: Sun, 06 Sep 2009 21:26:54 -0700 From: Koen Vos To: Jean-Marc Valin References: <4AA16546.8050700@octasic.com> <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> <4AA26C95.8090504@usherbrooke.ca> <20090905161909.77713cwiggjt4cml@mail.skype.net> <4AA31726.3040904@usherbrooke.ca> <20090906164218.85586qpxwpiv2guy@mail.skype.net> <4AA45CC1.7050500@usherbrooke.ca> In-Reply-To: <4AA45CC1.7050500@usherbrooke.ca> 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 guidelines and requirements drafts: complexity 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, 07 Sep 2009 04:26:29 -0000 Quoting Jean-Marc Valin: > I actually disagree about average complexity. Even though average > complexity matters, peak complexity is what determines whether (e.g.) an > embedded DSP is powerful enough to run the codec in real-time. The hard real-time aspect is part of circuit-switched calls, where payloads have to be ready at guaranteed times in order to be sent in the allocated circuit-switched time slot. For VoIP applications it's ok if a packet is sent a few microseconds, or even milliseconds, behind schedule. More importantly, in the vast majority of cases, the codec will run on a processor with soft real-time constraints, where the processing power is shared with other applications. Minimizing average complexity: - Increases battery life on mobile devices - Enables less powerful devices to run the codec (as long as those devices have soft real-time constraints) - Reduces global energy consumption For voice communications, the trend is away from fixed allocated resources to flexible, shared resources. It's not just about a network protocol. My hope is that IETF will be faster to recognize this than other SDOs. koen. From koen.vos@skype.net Sun Sep 6 21:47: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 69D393A6851 for ; Sun, 6 Sep 2009 21:47:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.883 X-Spam-Level: X-Spam-Status: No, score=-2.883 tagged_above=-999 required=5 tests=[AWL=-0.284, 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 RgBpcIYk0ZzF for ; Sun, 6 Sep 2009 21:47:53 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 2A8DF3A679C for ; Sun, 6 Sep 2009 21:47:53 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 7C7E96032749A; Mon, 7 Sep 2009 05:48:19 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=hTGsPFNBmskq 6Sd+5Lgmh33tJVc=; b=rQxX8LqFd/cBwv5WJtNR+WmCh5yFj1wW7KBhWAD78DDj RCMER0tTGu9Yc/idYizNIjbq5ZIp5dcdjPkalR1KXATYM72JrERCEQtfUSU/P/9L V7RTZdvz+orImzQ3OMWNpHSwzR9HDLr7tGNx9SubK6kh3TrZ5T92A079+w9XaTc= 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=pCQJmPJwv/FwP61p1WpM 1gAP9mNEB8TY17DLLCBDx1AJZ1Kei9OQulfeOyabk4xVDahdI0F0MLWLZuuN3MaY lJ2nkKkhnXAJGga/rz+qbSb2NRV/+rczmyoxhDicJgyNB22JIX6NMLoLrN4RJcRb CWz6eOLNFk9/FtqL2RGSaXc= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 7B01460327492; Mon, 7 Sep 2009 05:48:19 +0100 (IST) Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j0Yb3QuoArs1; Mon, 7 Sep 2009 05:48:19 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 6850860327495; Mon, 7 Sep 2009 05:48:19 +0100 (IST) Received: from adsl-71-141-110-218.dsl.snfc21.pacbell.net (adsl-71-141-110-218.dsl.snfc21.pacbell.net [71.141.110.218]) by mail.skype.net (Horde Framework) with HTTP; Sun, 06 Sep 2009 21:48:19 -0700 Message-ID: <20090906214819.191431jmd444jtlf@mail.skype.net> Date: Sun, 06 Sep 2009 21:48:19 -0700 From: Koen Vos To: Jean-Marc Valin References: <4AA16546.8050700@octasic.com> <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> <4AA26C95.8090504@usherbrooke.ca> <20090905161909.77713cwiggjt4cml@mail.skype.net> <4AA31726.3040904@usherbrooke.ca> <20090906164218.85586qpxwpiv2guy@mail.skype.net> <4AA45CC1.7050500@usherbrooke.ca> In-Reply-To: <4AA45CC1.7050500@usherbrooke.ca> 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 guidelines and requirements drafts: eavesdropping 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, 07 Sep 2009 04:47:54 -0000 Quoting Jean-Marc Valin: > I wouldn't call the fear of encrypted VBR irrational, even though I > believe it is likely blown out of proportion. Actually, to me the main > leak involved in VBR is letting an eavesdroper know when there is active > speech. This is pretty much the same leak as that caused by a VAD, or > even knowing someone is present from the increased video bandwidth. How would people take advantage of that kind of information? Surely the fact there was a call to begin with (and the sending and receiving IP addresses) are much more revealing and incriminating? Does SRTP provide mechanisms to obfuscate those? I'll change my mind when there's an application that transcribes (encrypted, VBR) Skype calls by sniffing the packets. (Writing such an app must be a sure was to get rich and famous.) > In any case, the fact that some people want CBR justifies including it > as a requirement. Some people on this list want steep royalties to be part of the codec.. Don't there need to be rational arguments? The problem is really that eavesdropping (1) was never shown to work and (2) has strong arguments against it based on information theory, yet is almost impossible to disprove. FWIW, Skype cares *a lot* about preventing eavesdropping, and will continue to use VBR. koen. From jean-marc.valin@usherbrooke.ca Sun Sep 6 21:57: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 81C9E3A6848 for ; Sun, 6 Sep 2009 21:57:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.264 X-Spam-Level: X-Spam-Status: No, score=-2.264 tagged_above=-999 required=5 tests=[AWL=0.335, 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 nW5w5NaJji4Z for ; Sun, 6 Sep 2009 21:57:44 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id A492C3A679C for ; Sun, 6 Sep 2009 21:57:44 -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 <0KPL00J5I4GYWVM0@VL-MH-MR002.ip.videotron.ca> for codec@ietf.org; Mon, 07 Sep 2009 00:58:10 -0400 (EDT) Message-id: <4AA492E2.3000902@usherbrooke.ca> Date: Mon, 07 Sep 2009 00:58:10 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) To: Koen Vos References: <4AA16546.8050700@octasic.com> <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> <4AA26C95.8090504@usherbrooke.ca> <20090905161909.77713cwiggjt4cml@mail.skype.net> <4AA31726.3040904@usherbrooke.ca> <20090906164218.85586qpxwpiv2guy@mail.skype.net> <4AA45CC1.7050500@usherbrooke.ca> <20090906212654.2061286irwdvsbda@mail.skype.net> In-reply-to: <20090906212654.2061286irwdvsbda@mail.skype.net> X-Enigmail-Version: 0.95.2 Cc: "codec@ietf.org" Subject: Re: [codec] Codec guidelines and requirements drafts: complexity 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, 07 Sep 2009 04:57:45 -0000 Hi, OK, there's actually a few different issues here. For a decoder, I would argue that the worst-case complexity is the most important because when you're waiting for a packet that hasn't arrived yet, you want to wait as long as possible before choosing to consider it lost. For that, you need to consider the worst-case complexity of the decoder, otherwise you risk an audio underrun. On the encoder side I agree that you can tolerate a bit more "complexity jitter" and I'm certainly in favour of *also* minimising the average complexity. But even then, you have to be careful about two things: 1) How bad the worst case is. This has to be bounded. If it takes an encoder on average 10 ms to encode a 20 ms frame, it's obviously not acceptable to have the worst-case take 200 ms! 2) How correlated the complexity is to the input signal. If the complexity looks random, then it may be OK. However, if speech frames take a lot more CPU than silence/noise frames, your DSP still needs to be able to encode the speech periods in real-time without lagging. So I'm not at all against reducing the average complexity of the codec. I'm just saying that we still have to be very careful about the worst case complexity. Fortunately, I think most algorithms tend to have a worst case that isn't too far from the average. And of course, if we can reduce the average without making the worst case much worse, then we should definitely do it. Cheers, Jean-Marc Koen Vos a écrit : > Quoting Jean-Marc Valin: > The hard real-time aspect is part of circuit-switched calls, where > payloads have to be ready at guaranteed times in order to be sent in the > allocated circuit-switched time slot. For VoIP applications it's ok if a > packet is sent a few microseconds, or even milliseconds, behind > schedule. More importantly, in the vast majority of cases, the codec > will run on a processor with soft real-time constraints, where the > processing power is shared with other applications. > > Minimizing average complexity: > - Increases battery life on mobile devices > - Enables less powerful devices to run the codec (as long as those > devices have soft real-time constraints) > - Reduces global energy consumption > > For voice communications, the trend is away from fixed allocated > resources to flexible, shared resources. It's not just about a network > protocol. My hope is that IETF will be faster to recognize this than > other SDOs. > > koen. > > From koen.vos@skype.net Sun Sep 6 22:01:05 2009 Return-Path: X-Original-To: codec@core3.amsl.com Delivered-To: codec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7A4293A6358 for ; Sun, 6 Sep 2009 22:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.843 X-Spam-Level: X-Spam-Status: No, score=-2.843 tagged_above=-999 required=5 tests=[AWL=-0.244, 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 HhmK1da7Zyuq for ; Sun, 6 Sep 2009 22:01:04 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 6A2383A679C for ; Sun, 6 Sep 2009 22:01:04 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 99AD9604BDB9E; Mon, 7 Sep 2009 06:01:30 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=prmbjP+KAbSs cJqE1P1ZX+Zglnc=; b=R2YrvIsgV99fPnA1SOnphMQq15SIa2ffpOoWDcE7Kql8 7bcTLDKqPKw+Fkal4Jm5+dCJIpNWKB5jLcPiPQPEMQtMSTi/9uiA2zaB+QmeFSZ3 lgvPDvegTqLl5za1lgZHCR8sYVamOdUdKpld33rOjo20Xj6biUA/ByADd0obMZA= 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=LQFYI7lHSxnQ1yDXOj8z ZrVIgm/NHeCT+Kagi2KrXB8pweei3RcP0jj1wzcKkGGQEoSHWzygBzB4yAWWOlBn 28D7OHoZWsMBZvXEgCkAAMD+SOzPs41Ij1TxmX9TOqfpC61E8cXWuCuzbeGx4Z7D 0OR+BvT5gzGklBPaX3qYMuk= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 9622C604BDB8A; Mon, 7 Sep 2009 06:01:30 +0100 (IST) Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6orkJEUL7NU1; Mon, 7 Sep 2009 06:01:30 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 81720604BDB9D; Mon, 7 Sep 2009 06:01:30 +0100 (IST) Received: from adsl-71-141-110-218.dsl.snfc21.pacbell.net (adsl-71-141-110-218.dsl.snfc21.pacbell.net [71.141.110.218]) by mail.skype.net (Horde Framework) with HTTP; Sun, 06 Sep 2009 22:01:30 -0700 Message-ID: <20090906220130.16973ry19lk4q2lm@mail.skype.net> Date: Sun, 06 Sep 2009 22:01:30 -0700 From: Koen Vos To: bens@alum.mit.edu, "Benjamin M. Schwartz" References: <4AA16546.8050700@octasic.com> <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> <4AA26C95.8090504@usherbrooke.ca> <20090905161909.77713cwiggjt4cml@mail.skype.net> <4AA31726.3040904@usherbrooke.ca> <20090906164218.85586qpxwpiv2guy@mail.skype.net> <4AA45F36.60209@fas.harvard.edu> In-Reply-To: <4AA45F36.60209@fas.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" , Jean-Marc Valin Subject: Re: [codec] Codec guidelines and requirements drafts 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, 07 Sep 2009 05:01:05 -0000 Quoting "Benjamin M. Schwartz": > I can think of many advantages to a codec whose peak bandwidth (in a > window of N milliseconds) can easily be limited. For example, there are > many places where telephone modems are still the most common form of > internet connection. A good mono voice codec capped at 32kbps could > easily outperform the underlying telephone system for voice quality, in > addition to providing the connectivity advantages of VoIP. > > If you can limit peak bandwidth, then CBR is trivial. I agree. When a 40 kbps, 20 ms packet is sent over a 32 kbps channel, it will take 25 ms to transport that packet. The packet will thus arrive 5 ms "late", but won't be lost. And the late arrival may not even be noticed because of other jitter from the network. SILK deals with this by defining a maximum delay that can be built up in the network buffer. So if the bitrate is set to 32 kbps, and the maximum delay is 10 ms, that means that one packet may be sent at 48 kbps, or 10 consecutive packets may be sent at 33.6 kbps, but after that the bitrate is no longer allowed to exceed 32 kbps. koen. From jean-marc.valin@usherbrooke.ca Sun Sep 6 22:10: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 AEF873A691F for ; Sun, 6 Sep 2009 22:10:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.312 X-Spam-Level: X-Spam-Status: No, score=-2.312 tagged_above=-999 required=5 tests=[AWL=0.288, 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 Jk70r4JeG8lP for ; Sun, 6 Sep 2009 22:10:28 -0700 (PDT) Received: from relais.videotron.ca (relais.videotron.ca [24.201.245.36]) by core3.amsl.com (Postfix) with ESMTP id 62D5D3A690E for ; Sun, 6 Sep 2009 22:10:28 -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-MR005.ip.videotron.ca (Sun Java(tm) System Messaging Server 6.3-4.01 (built Aug 3 2007; 32bit)) with ESMTP id <0KPL00HUD5262RD0@VL-MO-MR005.ip.videotron.ca> for codec@ietf.org; Mon, 07 Sep 2009 01:10:55 -0400 (EDT) Message-id: <4AA495DD.3060606@usherbrooke.ca> Date: Mon, 07 Sep 2009 01:10:53 -0400 From: Jean-Marc Valin User-Agent: Thunderbird 2.0.0.23 (X11/20090817) To: Koen Vos References: <4AA16546.8050700@octasic.com> <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> <4AA26C95.8090504@usherbrooke.ca> <20090905161909.77713cwiggjt4cml@mail.skype.net> <4AA31726.3040904@usherbrooke.ca> <20090906164218.85586qpxwpiv2guy@mail.skype.net> <4AA45CC1.7050500@usherbrooke.ca> <20090906214819.191431jmd444jtlf@mail.skype.net> In-reply-to: <20090906214819.191431jmd444jtlf@mail.skype.net> X-Enigmail-Version: 0.95.2 Cc: "codec@ietf.org" Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping 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, 07 Sep 2009 05:10:29 -0000 Koen Vos a écrit : > Quoting Jean-Marc Valin: > >> I wouldn't call the fear of encrypted VBR irrational, even though I >> believe it is likely blown out of proportion. Actually, to me the main >> leak involved in VBR is letting an eavesdroper know when there is active >> speech. This is pretty much the same leak as that caused by a VAD, or >> even knowing someone is present from the increased video bandwidth. > > How would people take advantage of that kind of information? Surely the > fact there was a call to begin with (and the sending and receiving IP > addresses) are much more revealing and incriminating? Does SRTP provide > mechanisms to obfuscate those? The only case I can think of is when you have an audio link running all day long, with most of the time nobody talking. Observing the rate would tell you when a meeting starts. I don't mean to say that this is really very bad. I'm just saying it's the only real "threat" I see. > I'll change my mind when there's an application that transcribes > (encrypted, VBR) Skype calls by sniffing the packets. (Writing such an > app must be a sure was to get rich and famous.) Oh, I totally agree with you on this point. I'm not at all concerned about ever having a continuous speech recognizer running from VBR packet sizes -- especially considering that most VBR implementations probably leak much less information than the Speex one. OTOH, I wouldn't be too surprised if you could get a yes/no recognizer to work, although I'm not sure what the use of that would be. > Some people on this list want steep royalties to be part of the codec.. > Don't there need to be rational arguments? > > The problem is really that eavesdropping (1) was never shown to work and > (2) has strong arguments against it based on information theory, yet is > almost impossible to disprove. > > FWIW, Skype cares *a lot* about preventing eavesdropping, and will > continue to use VBR. You don't need to convince my that VBR is good and useful. I'm just trying to understand what would be so bad with *also* supporting CBR. Jean-Marc From ron@debian.org Mon Sep 7 01: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 4BACE3A69ED for ; Mon, 7 Sep 2009 01:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.458 X-Spam-Level: X-Spam-Status: No, score=-2.458 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J+gL4JNZrZWs for ; Mon, 7 Sep 2009 01:01:24 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by core3.amsl.com (Postfix) with ESMTP id 0D2733A69E8 for ; Mon, 7 Sep 2009 01:01:23 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArMEAMBYpEp5LZ/y/2dsb2JhbACBU9YmgiOBdQWCOA X-IronPort-AV: E=Sophos;i="4.44,345,1249223400"; d="scan'208";a="437489115" Received: from ppp121-45-159-242.lns11.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.159.242]) by ipmail05.adl2.internode.on.net with ESMTP; 07 Sep 2009 17:31:48 +0930 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id E58E74F8F3 for ; Mon, 7 Sep 2009 17:31:47 +0930 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id TnJHzSgIjRRb for ; Mon, 7 Sep 2009 17:31:40 +0930 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 49AF14F8FD; Mon, 7 Sep 2009 17:31:40 +0930 (CST) Date: Mon, 7 Sep 2009 17:31:40 +0930 From: Ron To: codec@ietf.org Message-ID: <20090907080140.GR4137@audi.shelbyville.oz> References: <4AA16546.8050700@octasic.com> <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> <4AA26C95.8090504@usherbrooke.ca> <20090905161909.77713cwiggjt4cml@mail.skype.net> <4AA31726.3040904@usherbrooke.ca> <20090906164218.85586qpxwpiv2guy@mail.skype.net> <4AA45CC1.7050500@usherbrooke.ca> <20090906214819.191431jmd444jtlf@mail.skype.net> <4AA495DD.3060606@usherbrooke.ca> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <4AA495DD.3060606@usherbrooke.ca> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping 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, 07 Sep 2009 08:01:25 -0000 On Mon, Sep 07, 2009 at 01:10:53AM -0400, Jean-Marc Valin wrote: > Koen Vos a écrit : > > Quoting Jean-Marc Valin: > > > >> I wouldn't call the fear of encrypted VBR irrational, even though I > >> believe it is likely blown out of proportion. Actually, to me the main > >> leak involved in VBR is letting an eavesdroper know when there is active > >> speech. This is pretty much the same leak as that caused by a VAD, or > >> even knowing someone is present from the increased video bandwidth. > > > > How would people take advantage of that kind of information? Surely the > > fact there was a call to begin with (and the sending and receiving IP > > addresses) are much more revealing and incriminating? Does SRTP provide > > mechanisms to obfuscate those? > > The only case I can think of is when you have an audio link running all > day long, with most of the time nobody talking. Observing the rate would > tell you when a meeting starts. I don't mean to say that this is really > very bad. I'm just saying it's the only real "threat" I see. You can also tell who is talking. Which combined with other sources of information leakage may result in some interesting correlations. If for example you were monitoring a call between me and my stockbroker, you might make a fairly reasonably guess about whether they were giving me tips, or I was giving them instructions, based on who was doing most of the talking. Combine that with other information a MITM might observe about my online or other activity, and it may be possible to tip the balances of probability in the sort of ways that are interesting (in a probably illegally profitable sort of way) in that domain. I'm likewise not utterly paranoid about the conversation itself being decoded precisely, but information leakage has a way of being useful when you least want it to. For the majority of people it may never be an issue, but if the people who do (have to) care have to use a different codec, that can be a form of information leakage too... That may not be a terribly compelling argument, but saying "I can't really see a way to use this either" doesn't really mean a lot unless the person saying that is reporting on the consensus of a group of eminent cryptographers who have made a determined effort to use it :) Cheers, Ron From alexander.chemeris@gmail.com Mon Sep 7 01:08: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 D35453A6A1C for ; Mon, 7 Sep 2009 01:08:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bXC5uiZNXLxQ for ; Mon, 7 Sep 2009 01:08:59 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id E029F28C0E0 for ; Mon, 7 Sep 2009 01:08:58 -0700 (PDT) Received: by fxm17 with SMTP id 17so1823296fxm.37 for ; Mon, 07 Sep 2009 01:09:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=fEXl7Ys4/xL3RxbWlSOqbjSgMJpuCWpi2Y+sZQ8JsTY=; b=r7D6949bULN4Ibls2xsvatBwUeztf5YpLAGc+Ofp4MguWr1eI+0u67qoodem8mWWqz FBxafe91U3QRuY7HN1OAXje05G2z55YSasgKG2BFeeMDaBvRZ9m6yM1ABRABThTmuK8T gp/+8gqiT262iJTB1cXojrcKOtvSemMwyU1vs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=iYESFZzx2Eu7v8+/yDqsrWLO2yXDxKRLk30rmmjFKQ+DrVR9lN0tnYZpdGEpr1Fgwc Z+AJf0P9bcNbtnEsFWGJ0y7+kXCpgk+o4gsqVeR5xVRS9ZbLymidTZCTVcEFY78x3LP6 MtGWjq+T/XCA9I2ghX3gtSYvNjE381vyemO7Y= MIME-Version: 1.0 Sender: alexander.chemeris@gmail.com Received: by 10.102.245.20 with SMTP id s20mr6003485muh.74.1252310961087; Mon, 07 Sep 2009 01:09:21 -0700 (PDT) In-Reply-To: <200909051016.00735.simon.perreault@viagenie.ca> References: <4AA16546.8050700@octasic.com> <4AA18288.2030505@fas.harvard.edu> <3d032e5d0909050144t108e286fm68d92019be33e248@mail.gmail.com> <200909051016.00735.simon.perreault@viagenie.ca> From: Alexander Chemeris Date: Mon, 7 Sep 2009 12:09:01 +0400 X-Google-Sender-Auth: ec3ba2261a860fc0 Message-ID: <3d032e5d0909070109v38ae8811u9c397d218d243ed2@mail.gmail.com> To: Simon Perreault Content-Type: text/plain; charset=UTF-8 Cc: bens@alum.mit.edu, codec@ietf.org Subject: Re: [codec] Codec guidelines and requirements drafts 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, 07 Sep 2009 08:08:59 -0000 On Sat, Sep 5, 2009 at 18:16, Simon Perreault wrote: > On Saturday 05 September 2009 04:44:33 Alexander Chemeris wrote: >> As it was already said, there are two kinds of time adjustment - "slow" and >> "fast". Slow one reflect the need to adjust playback rate to compensate >> clock skew between end points. Fast adjustment is usually done when you >> need to increase/decrease jitter buffer length to adopt to network >> conditions. Slow adjustments may be made with resampling, but this is not >> suitable for conferencing and gaming cases, so usually slow adjustments are >> actually done as a set of repeating small fast adjustments. So even in case >> of LAN you will have to do time adjustments. And it's best made inside of a >> codec. > > This last sentence puzzles me. Care to explain it? I meant that codec usually have all (or most) of the information, needed to perform time stretching - like pitch, envelop, voice activity, etc. -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 From stephen.botzko@gmail.com Mon Sep 7 04:11: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 015153A6987 for ; Mon, 7 Sep 2009 04:11:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.187 X-Spam-Level: X-Spam-Status: No, score=-2.187 tagged_above=-999 required=5 tests=[AWL=0.411, 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 PgP02DzV9keP for ; Mon, 7 Sep 2009 04:11:45 -0700 (PDT) Received: from mail-fx0-f217.google.com (mail-fx0-f217.google.com [209.85.220.217]) by core3.amsl.com (Postfix) with ESMTP id 81B2E3A684E for ; Mon, 7 Sep 2009 04:11:44 -0700 (PDT) Received: by fxm17 with SMTP id 17so1909928fxm.37 for ; Mon, 07 Sep 2009 04:12:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=m4BvL9Dq1IOSvFhE73edpQ1hppVVbypi3KB2WNV578Q=; b=K2kGAAPd7fdmdho88qdoTuvfVaHDqy5HAH9fyJbK5FI00idfK85s34S6mUjqgGi/Zo rGr+VLVDRwMiJVAe8pgKR0JEOK3hl6rW45z20EEQXVx0RIczX9BbfWyc1rsz730JW2C3 eK0IO6LcX7RYf774KZnORxqm0YegGRvYu3IwQ= 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=YPdwrPRh32xFvKBaHAIpIFaZ16zVXorHueYD/EbWnveRt7EAexaFgVWtotAg+ygD1k Sy1AjgJn8mfC/Xg5YrdbkH9ig8G+hO46sAhMqWfJJkd69EIX8UgWiFq9sS1YkII9qx6W eAtx55+IMimmqB+RA7KjP2CehIQjJQFjJwKeg= MIME-Version: 1.0 Received: by 10.223.2.76 with SMTP id 12mr5306694fai.98.1252321927763; Mon, 07 Sep 2009 04:12:07 -0700 (PDT) In-Reply-To: <20090906214819.191431jmd444jtlf@mail.skype.net> References: <4AA16546.8050700@octasic.com> <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> <4AA26C95.8090504@usherbrooke.ca> <20090905161909.77713cwiggjt4cml@mail.skype.net> <4AA31726.3040904@usherbrooke.ca> <20090906164218.85586qpxwpiv2guy@mail.skype.net> <4AA45CC1.7050500@usherbrooke.ca> <20090906214819.191431jmd444jtlf@mail.skype.net> Date: Mon, 7 Sep 2009 07:12:07 -0400 Message-ID: <6e9223710909070412k660cc21egf5595945fa9e4ddf@mail.gmail.com> From: stephen botzko To: Koen Vos Content-Type: multipart/alternative; boundary=00151747bf2ca6177a0472faeb32 Cc: "codec@ietf.org" , Jean-Marc Valin Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping 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, 07 Sep 2009 11:11:46 -0000 --00151747bf2ca6177a0472faeb32 Content-Type: text/plain; charset=ISO-8859-1 >>> How would people take advantage of that kind of information? >>> My understanding is that the security concern is that a third party can determine *when* someone is speaking simply by observing the audio bit rate. . In any event, other VBR codecs (for instance RFC 5404 for G.719) have the same "vulnerability". However, that RFC does not mention VBR as a security issue in the "security considerations" section (or anywhere else), so i don't think it was a signifiant concern to AVT. Providing for a CBR mode would allow the codec to pass through some gateways that require fixed rate transports without transcoding. For instance,G.719 can be carried on H.320 connections, and passed through SIP/H.320 gateways. H.320 happens to require fixed rate audio. In order to allow this scenario to be supported w/o audio transcoding, RFC 5404 includes signaling to negotiate CBR. Of course, any VBR stream can be converted to CBR simply by padding the bitstream. So it would be easy to support it if someone needs it. (I am not proposing that it be added, just observing that it is easy to do). Regards Stephen Botzko Polycom On Mon, Sep 7, 2009 at 12:48 AM, Koen Vos wrote: > Quoting Jean-Marc Valin: > > I wouldn't call the fear of encrypted VBR irrational, even though I >> believe it is likely blown out of proportion. Actually, to me the main >> leak involved in VBR is letting an eavesdroper know when there is active >> speech. This is pretty much the same leak as that caused by a VAD, or >> even knowing someone is present from the increased video bandwidth. >> > > How would people take advantage of that kind of information? Surely the > fact there was a call to begin with (and the sending and receiving IP > addresses) are much more revealing and incriminating? Does SRTP provide > mechanisms to obfuscate those? > > I'll change my mind when there's an application that transcribes > (encrypted, VBR) Skype calls by sniffing the packets. (Writing such an app > must be a sure was to get rich and famous.) > > > In any case, the fact that some people want CBR justifies including it >> as a requirement. >> > > Some people on this list want steep royalties to be part of the codec.. > Don't there need to be rational arguments? > > The problem is really that eavesdropping (1) was never shown to work and > (2) has strong arguments against it based on information theory, yet is > almost impossible to disprove. > > FWIW, Skype cares *a lot* about preventing eavesdropping, and will continue > to use VBR. > > koen. > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --00151747bf2ca6177a0472faeb32 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable >>>
How would people take advantage of that kind of information= ?
>>>

My understanding is that the security concern is t= hat a third party can determine when someone is speaking simply by o= bserving the audio bit rate.=A0 .=A0

In any event, other VBR codecs (for instance RFC 5404 for G.719) have t= he same "vulnerability".=A0 However, that RFC does not mention VB= R as a security issue in the "security considerations" section (o= r anywhere else), so i don't think it was a signifiant concern to AVT.<= br>
Providing for a CBR mode would allow the codec to pass through some gat= eways that require fixed rate transports without transcoding.=A0 For instan= ce,G.719 can be carried on H.320 connections, and passed through SIP/H.320 = gateways.=A0 H.320 happens to require fixed rate audio.=A0 In order to allo= w this scenario to be supported w/o audio transcoding, RFC 5404 includes si= gnaling to negotiate CBR.=A0

Of course, any VBR stream can be converted to CBR simply by padding the= bitstream.=A0 So it would be easy to support it if someone needs it. (I am= not proposing that it be added, just observing that it is easy to do).

Regards
Stephen Botzko
Polycom



On Mon, Sep 7, 2009 at 12:48 AM, Koen Vos <koen.vos@skype.net> wrote:=
Quoting Jean-Marc= Valin:

I wouldn't call the fear of encrypted VBR irrational, even though I
believe it is likely blown out of proportion. Actually, to me the main
leak involved in VBR is letting an eavesdroper know when there is active speech. This is pretty much the same leak as that caused by a VAD, or
even knowing someone is present from the increased video bandwidth.

How would people take advantage of that kind of information? Surely the fac= t there was a call to begin with (and the sending and receiving IP addresse= s) are much more revealing and incriminating? Does SRTP provide mechanisms = to obfuscate those?

I'll change my mind when there's an application that transcribes (e= ncrypted, VBR) Skype calls by sniffing the packets. (Writing such an app mu= st be a sure was to get rich and famous.)


In any case, the fact that some people want CBR justifies including it
as a requirement.

Some people on this list want steep royalties to be part of the codec.. Don= 't there need to be rational arguments?

The problem is really that eavesdropping (1) was never shown to work and (2= ) has strong arguments against it based on information theory, yet is almos= t impossible to disprove.

FWIW, Skype cares *a lot* about preventing eavesdropping, and will continue= to use VBR.

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

--00151747bf2ca6177a0472faeb32-- From Felix.Wyss@inin.com Mon Sep 7 11: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 1D7CE3A69FE for ; Mon, 7 Sep 2009 11:14: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 uaYUpIokPZ1z for ; Mon, 7 Sep 2009 11:14:11 -0700 (PDT) Received: from inin.com (smtpgw.inin.com [209.43.1.24]) by core3.amsl.com (Postfix) with ESMTP id 17CFC3A69F9 for ; Mon, 7 Sep 2009 11:14:10 -0700 (PDT) Received: from ININHUB2 [172.16.1.157] by smtpgw.inin.com - Websense Email Security (6.1.1); Mon, 07 Sep 2009 14:14:36 -0400 Received: from ININMAIL.i3domain.inin.com ([172.16.1.186]) by ininhub2.i3domain.inin.com ([172.16.1.157]) with mapi; Mon, 7 Sep 2009 14:14:37 -0400 From: "Wyss, Felix" To: 'Ron' , "codec@ietf.org" Date: Mon, 7 Sep 2009 14:14:36 -0400 Thread-Topic: [codec] Codec guidelines and requirements drafts: eavesdropping Thread-Index: AcovkXgSx0sW1M2hSEGLoZXUG1sL3AATshwQ Message-ID: References: <4AA16546.8050700@octasic.com> <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> <4AA26C95.8090504@usherbrooke.ca> <20090905161909.77713cwiggjt4cml@mail.skype.net> <4AA31726.3040904@usherbrooke.ca> <20090906164218.85586qpxwpiv2guy@mail.skype.net> <4AA45CC1.7050500@usherbrooke.ca> <20090906214819.191431jmd444jtlf@mail.skype.net> <4AA495DD.3060606@usherbrooke.ca> <20090907080140.GR4137@audi.shelbyville.oz> In-Reply-To: <20090907080140.GR4137@audi.shelbyville.oz> 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 X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1 X-SEF-ZeroHour-RefID: fgs=4 X-SEF-Processed: 6_1_1_105__2009_09_07_14_14_36 Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping 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, 07 Sep 2009 18:14:12 -0000 I agree. Assuming something can't be done because one can't think of a way= today is *very* dangerous when it comes to security. The assumption must = be that if information is leaked, there will be ways to exploit it. There = are many cases where the call content is highly structured, such as your ex= ample of a call to a stockbroker. Many other types of service or IVR calls= tend to be that way. If an attacker knows at what point during a call a p= arty likely speaks their credit card or social security number, the potenti= al search space is greatly reduced. =20 I thus think it is a MUST requirement that the encoder can be run in a mode= where there is no correlation between packet size, packet rate and timing,= and the short and long-term audio being encoded. =20 --Felix > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of > Ron > Sent: Monday, September 07, 2009 04:02 > To: codec@ietf.org > Subject: Re: [codec] Codec guidelines and requirements drafts: > eavesdropping >=20 > On Mon, Sep 07, 2009 at 01:10:53AM -0400, Jean-Marc Valin wrote: > > Koen Vos a =E9crit : > > > Quoting Jean-Marc Valin: > > > > > >> I wouldn't call the fear of encrypted VBR irrational, even though I > > >> believe it is likely blown out of proportion. Actually, to me the > main > > >> leak involved in VBR is letting an eavesdroper know when there is > active > > >> speech. This is pretty much the same leak as that caused by a VAD, o= r > > >> even knowing someone is present from the increased video bandwidth. > > > > > > How would people take advantage of that kind of information? Surely > the > > > fact there was a call to begin with (and the sending and receiving IP > > > addresses) are much more revealing and incriminating? Does SRTP > provide > > > mechanisms to obfuscate those? > > > > The only case I can think of is when you have an audio link running all > > day long, with most of the time nobody talking. Observing the rate woul= d > > tell you when a meeting starts. I don't mean to say that this is really > > very bad. I'm just saying it's the only real "threat" I see. >=20 > You can also tell who is talking. Which combined with other sources > of information leakage may result in some interesting correlations. >=20 > If for example you were monitoring a call between me and my stockbroker, > you might make a fairly reasonably guess about whether they were giving > me tips, or I was giving them instructions, based on who was doing most > of the talking. Combine that with other information a MITM might observe > about my online or other activity, and it may be possible to tip the > balances of probability in the sort of ways that are interesting (in a > probably illegally profitable sort of way) in that domain. > >=20 > I'm likewise not utterly paranoid about the conversation itself being > decoded precisely, but information leakage has a way of being useful > when you least want it to. For the majority of people it may never > be an issue, but if the people who do (have to) care have to use a > different codec, that can be a form of information leakage too... >=20 > That may not be a terribly compelling argument, but saying "I can't > really see a way to use this either" doesn't really mean a lot unless > the person saying that is reporting on the consensus of a group of > eminent cryptographers who have made a determined effort to use it :) >=20 > Cheers, > Ron From koen.vos@skype.net Mon Sep 7 18:47: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 DD51328C0F6 for ; Mon, 7 Sep 2009 18:47:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.812 X-Spam-Level: X-Spam-Status: No, score=-2.812 tagged_above=-999 required=5 tests=[AWL=-0.213, 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 EpWg6xinCTjI for ; Mon, 7 Sep 2009 18:47:11 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 9B79A3A68DE for ; Mon, 7 Sep 2009 18:47:11 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id B11A76050AF2A; Tue, 8 Sep 2009 02:47:38 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=oQQvWfmUOA8K tNMiy/Hmg8tlPr0=; b=DnsMSBATOdB443iiBZawdJbUoRwjVvZ5UXk6qC5pzcQ+ 5xvAotyFrdUCHZE8c13i4cNJK2sFCn2MkTtGmseiOSv1eJdmJVt7vRSVy0F7J/F0 ZFxrDOKafsJY+e3WCUa8HRek1ivsNRjqbAnvJqYu+NhKGbYhbCc8aV0aU1G7da4= 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=NA61CSKAXTG01IRARx0m n67kntLm0HcytJf8hIJmmtc+aw/KNBLU4bTyBJiU0vjnuYWgeJRFBXB5uwuhUX3G 8iyq6EvVEkaRBswG1dFzVXk/7JmFx9L+KoWTaYlfYZ58NhkX771QOp6Byp8jy22K RkNXaHQ7my6Yj3xwry4lLsY= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id AF8D66050AF25; Tue, 8 Sep 2009 02:47:38 +0100 (IST) Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zKCHi+KoGG5e; Tue, 8 Sep 2009 02:47:38 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 9DBBD6050AF27; Tue, 8 Sep 2009 02:47:38 +0100 (IST) Received: from adsl-71-141-110-218.dsl.snfc21.pacbell.net (adsl-71-141-110-218.dsl.snfc21.pacbell.net [71.141.110.218]) by mail.skype.net (Horde Framework) with HTTP; Mon, 07 Sep 2009 18:47:38 -0700 Message-ID: <20090907184738.13294q54pam9tz22@mail.skype.net> Date: Mon, 07 Sep 2009 18:47:38 -0700 From: Koen Vos To: Ron References: <4AA16546.8050700@octasic.com> <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> <4AA26C95.8090504@usherbrooke.ca> <20090905161909.77713cwiggjt4cml@mail.skype.net> <4AA31726.3040904@usherbrooke.ca> <20090906164218.85586qpxwpiv2guy@mail.skype.net> <4AA45CC1.7050500@usherbrooke.ca> <20090906214819.191431jmd444jtlf@mail.skype.net> <4AA495DD.3060606@usherbrooke.ca> <20090907080140.GR4137@audi.shelbyville.oz> In-Reply-To: <20090907080140.GR4137@audi.shelbyville.oz> 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 guidelines and requirements drafts: eavesdropping 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, 08 Sep 2009 01:47:12 -0000 Quoting Ron: > If for example you were monitoring a call between me and my stockbroker, > you might make a fairly reasonably guess about whether they were giving > me tips, or I was giving them instructions, based on who was doing most > of the talking. Why not just look at who initiated the call? koen. From ron@debian.org Mon Sep 7 19:44: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 C55933A69E4 for ; Mon, 7 Sep 2009 19:44:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.483 X-Spam-Level: X-Spam-Status: No, score=-2.483 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C8GrWoAki7U3 for ; Mon, 7 Sep 2009 19:44:32 -0700 (PDT) Received: from ipmail05.adl2.internode.on.net (ipmail05.adl2.internode.on.net [203.16.214.145]) by core3.amsl.com (Postfix) with ESMTP id 90DA03A6900 for ; Mon, 7 Sep 2009 19:44:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AugEAGxgpUp5LZ/y/2dsb2JhbACBU9gYhBgFgjg X-IronPort-AV: E=Sophos;i="4.44,350,1249223400"; d="scan'208";a="437825972" Received: from ppp121-45-159-242.lns11.adl6.internode.on.net (HELO audi.shelbyville.oz) ([121.45.159.242]) by ipmail05.adl2.internode.on.net with ESMTP; 08 Sep 2009 12:14:57 +0930 Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id C3D3C4F8F3 for ; Tue, 8 Sep 2009 12:14:56 +0930 (CST) X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id dTG0qRBv8tlX for ; Tue, 8 Sep 2009 12:14:55 +0930 (CST) Received: by audi.shelbyville.oz (Postfix, from userid 1000) id D9E074F8FD; Tue, 8 Sep 2009 12:14:55 +0930 (CST) Date: Tue, 8 Sep 2009 12:14:55 +0930 From: Ron To: codec@ietf.org Message-ID: <20090908024455.GS4137@audi.shelbyville.oz> References: <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> <4AA26C95.8090504@usherbrooke.ca> <20090905161909.77713cwiggjt4cml@mail.skype.net> <4AA31726.3040904@usherbrooke.ca> <20090906164218.85586qpxwpiv2guy@mail.skype.net> <4AA45CC1.7050500@usherbrooke.ca> <20090906214819.191431jmd444jtlf@mail.skype.net> <4AA495DD.3060606@usherbrooke.ca> <20090907080140.GR4137@audi.shelbyville.oz> <20090907184738.13294q54pam9tz22@mail.skype.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090907184738.13294q54pam9tz22@mail.skype.net> User-Agent: Mutt/1.5.20 (2009-06-14) Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping 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, 08 Sep 2009 02:44:32 -0000 On Mon, Sep 07, 2009 at 06:47:38PM -0700, Koen Vos wrote: > Quoting Ron: > > >If for example you were monitoring a call between me and my stockbroker, > >you might make a fairly reasonably guess about whether they were giving > >me tips, or I was giving them instructions, based on who was doing most > >of the talking. > > Why not just look at who initiated the call? Obviously you'd look at that too, but either of us may be returning a missed call, or initiating the call based on an out of band signal, or some prearranged schedule. The originator alone doesn't tell you which party has important information for the other, but the extra information you could obtain in this manner from the _content_ of the call about the direction of information flow might well hint that better. Anyhow, we shouldn't get bogged down in this, that's a job for crypto people and I'm sure they could come up with better examples than I did. I'm pretty sure they have similar correlation techniques already deployed. I don't think anyone disputes there _is_ information leakage here, so if privacy is a factor in the codec requirements, then there should be a way to cork that leakage. We aren't the right people to be judging its importance. Whether that is done in the codec itself or in the security wrapper that transports its packets is an open question to consider. All I'm saying is that we shouldn't handwave it away because _we_ have no use for the information we see being leaked. Recognising that CBR vs VBR is a tradeoff is good engineering, one may be better than the other in more of the cases we are considering, but neither is universally better than the other for all use cases. Ron From koen.vos@skype.net Mon Sep 7 19:48: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 92C983A6778 for ; Mon, 7 Sep 2009 19:48:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.789 X-Spam-Level: X-Spam-Status: No, score=-2.789 tagged_above=-999 required=5 tests=[AWL=-0.190, 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 WKhD7devDyYn for ; Mon, 7 Sep 2009 19:48:40 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 6CF593A684D for ; Mon, 7 Sep 2009 19:48:40 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id C69396050AF29; Tue, 8 Sep 2009 03:49:08 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=TjiMH+I8UD83 58WbRouSW5nPSME=; b=KNwbGBtp28pxwbUhm0nWAnG4CkuOTH9MwikE2qMdZKa3 w29Y8335hMmgaVjnoofjEW3T8O2//xk/1mxd9jMSd6LfaDgv2XEhqXxVsLQUxsl8 eHG253AVObub1JLwbRJa12jUEtmUM+o0EfkO2L+eTHvN0L7bNdRbGyjXAUiAXGQ= 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=kB6HbDcAOMqrp3sCObHA CyKv84MICzxk/rd8sxTWv0TJ5rCAEbzaiQGlCPPBeEX2K83MQDZY19iEdr48Asvn A1MASggcSMIoaEexz37HnrgEhpXCON6pdr5gJ+sIZyq6cCiiVfmZDkexvVlgow2i 2Dk3qp06qSilm08o4QLd32o= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id C39BC6050AF1A; Tue, 8 Sep 2009 03:49:08 +0100 (IST) Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OIsKYBh68gQa; Tue, 8 Sep 2009 03:49:08 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id B03256050AF25; Tue, 8 Sep 2009 03:49:08 +0100 (IST) Received: from adsl-71-141-110-218.dsl.snfc21.pacbell.net (adsl-71-141-110-218.dsl.snfc21.pacbell.net [71.141.110.218]) by mail.skype.net (Horde Framework) with HTTP; Mon, 07 Sep 2009 19:49:08 -0700 Message-ID: <20090907194908.161459bhbyrnn0o4@mail.skype.net> Date: Mon, 07 Sep 2009 19:49:08 -0700 From: Koen Vos To: "Wyss, Felix" References: <4AA16546.8050700@octasic.com> <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> <4AA26C95.8090504@usherbrooke.ca> <20090905161909.77713cwiggjt4cml@mail.skype.net> <4AA31726.3040904@usherbrooke.ca> <20090906164218.85586qpxwpiv2guy@mail.skype.net> <4AA45CC1.7050500@usherbrooke.ca> <20090906214819.191431jmd444jtlf@mail.skype.net> <4AA495DD.3060606@usherbrooke.ca> <20090907080140.GR4137@audi.shelbyville.oz> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: "codec@ietf.org" Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping 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, 08 Sep 2009 02:48:41 -0000 Quoting "Wyss, Felix": > If an attacker knows at what point during a call a party likely > speaks their credit card or social security number, the potential > search space is greatly reduced. Compelling example. Recognizing spoken digits from packet sizes would be an interesting study. > I thus think it is a MUST requirement that the encoder can be run in > a mode where there is no correlation between packet size, packet > rate and timing, and the short and long-term audio being encoded. Calls of an agreeing nature are on average shorter than calls with lots of discussion. And without trying to be sexist, I have a suspicion there is a correlation between call duration and gender. Should a signaling stack have a mode without termination? Anyway, I absolutely agree there is an information leak with VBR. I am not aware of any evidence that it is practically exploitable, but concede it's dangerous to just rule that out. But I also think the "market" for a codec without such a leak is small and unproven. If we make a MUST out of every niche market requirement, we will have a hard time getting things done. And anyone capable of implementing a reasonably secure communications tool will know how to pad a VBR codec. In this case there's no problem as most proposals so far have a CBR mode anyway. I do however object to the basis for the requirement. koen. From Felix.Wyss@inin.com Wed Sep 9 06:29: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 A9AF53A699C for ; Wed, 9 Sep 2009 06:29: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 sPSfmyj7Y7wY for ; Wed, 9 Sep 2009 06:29:44 -0700 (PDT) Received: from inin.com (smtpgw.inin.com [209.43.1.24]) by core3.amsl.com (Postfix) with ESMTP id D44EA3A6965 for ; Wed, 9 Sep 2009 06:29:43 -0700 (PDT) Received: from ININHUB2 [172.16.1.157] by smtpgw.inin.com - Websense Email Security (6.1.1); Wed, 09 Sep 2009 09:30:15 -0400 Received: from ININMAIL.i3domain.inin.com ([172.16.1.186]) by ininhub2.i3domain.inin.com ([172.16.1.157]) with mapi; Wed, 9 Sep 2009 09:30:15 -0400 From: "Wyss, Felix" To: 'Koen Vos' Date: Wed, 9 Sep 2009 09:30:15 -0400 Thread-Topic: [codec] Codec guidelines and requirements drafts: eavesdropping Thread-Index: AcowLvGbX5ZjidpeThOxtyNNWlpUfQBH0GUg Message-ID: References: <4AA16546.8050700@octasic.com> <3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com> <4AA26C95.8090504@usherbrooke.ca> <20090905161909.77713cwiggjt4cml@mail.skype.net> <4AA31726.3040904@usherbrooke.ca> <20090906164218.85586qpxwpiv2guy@mail.skype.net> <4AA45CC1.7050500@usherbrooke.ca> <20090906214819.191431jmd444jtlf@mail.skype.net> <4AA495DD.3060606@usherbrooke.ca> <20090907080140.GR4137@audi.shelbyville.oz> <20090907194908.161459bhbyrnn0o4@mail.skype.net> In-Reply-To: <20090907194908.161459bhbyrnn0o4@mail.skype.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-SEF-7853D99-ADF1-478E-8894-213D316B8FFA: 1 X-SEF-ZeroHour-RefID: fgs=4 X-SEF-Processed: 6_1_1_105__2009_09_09_09_30_15 Cc: "codec@ietf.org" Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping 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, 09 Sep 2009 13:29:44 -0000 > > I thus think it is a MUST requirement that the encoder can be run in > > a mode where there is no correlation between packet size, packet > > rate and timing, and the short and long-term audio being encoded. > > Calls of an agreeing nature are on average shorter than calls with > lots of discussion. And without trying to be sexist, I have a > suspicion there is a correlation between call duration and gender. > Should a signaling stack have a mode without termination? This is not relevant to the codec, though. If the parties see the need to = disguise the duration of the interaction, they can keep the streams up long= er, for example to some fixed length. > Anyway, I absolutely agree there is an information leak with VBR. I am > not aware of any evidence that it is practically exploitable, but > concede it's dangerous to just rule that out. But I also think the > "market" for a codec without such a leak is small and unproven. If we > make a MUST out of every niche market requirement, we will have a hard > time getting things done. And anyone capable of implementing a > reasonably secure communications tool will know how to pad a VBR codec. I believe content privacy is pretty fundamental and not just some "niche ma= rket requirement". Isn't the goal of this Internet audio codec to avoid having proprietary and= likely incompatible extensions? Anything not clearly spelled out in the R= FC is basically fair game and good luck getting devices from different vend= ors to play well together. In our experience, it's hard enough to get devi= ces that implement what's in the RFCs correctly and anything slightly unusu= al greatly increases the likelihood of incompatibilities and problems. For= example, I'd be reluctant to use RTP padding here for this very reason and= because it's up to the sender and not part of the media type negotiation. --Felix From stephen.botzko@gmail.com Wed Sep 9 07:56: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 2D8FF3A680C for ; Wed, 9 Sep 2009 07:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=0.419, 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 xaw+02Bvl4hG for ; Wed, 9 Sep 2009 07:56:34 -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 9AF303A6861 for ; Wed, 9 Sep 2009 07:56:33 -0700 (PDT) Received: by bwz19 with SMTP id 19so479987bwz.37 for ; Wed, 09 Sep 2009 07:57: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; bh=X4lU+JDvnGzp6aGhAROOiencwCgZ4Cvlv52v22BY7Hc=; b=av6YIsHC2vXPRpyRcECCA9oktmNUpRXGxpzEYR0zKMju9WEWGIVGSwZmixiHGofAPK 8Uo8JNs5u0kxdMhxLwP+eKHA5CxHqdBjMUA89ykVVQytmdWksACRr3NsPrGJ2zorZ1WS XdJD2FCgKAOffeTZIog7iuCXZzoA4PSq1wG2A= 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=KE/61rs9gdN3pshUZhOA1bfVkCORItbJQRiih8j1Zhif0hnwKN06r1ujZCvzsG+hf6 fxiA2PkgIPoY4O7iklzPiBJHZFNEGKTDwPmFz7KyAh3hA3TaH8NIhcWb9fW7iwAVyaKw DS1b0DrKkGcLFAiQnlrwPQdhJWZROZIwwIJbY= MIME-Version: 1.0 Received: by 10.223.23.80 with SMTP id q16mr477760fab.8.1252508221473; Wed, 09 Sep 2009 07:57:01 -0700 (PDT) In-Reply-To: References: <4AA16546.8050700@octasic.com> <4AA31726.3040904@usherbrooke.ca> <20090906164218.85586qpxwpiv2guy@mail.skype.net> <4AA45CC1.7050500@usherbrooke.ca> <20090906214819.191431jmd444jtlf@mail.skype.net> <4AA495DD.3060606@usherbrooke.ca> <20090907080140.GR4137@audi.shelbyville.oz> <20090907194908.161459bhbyrnn0o4@mail.skype.net> Date: Wed, 9 Sep 2009 10:57:01 -0400 Message-ID: <6e9223710909090757k2e3afdf1r7bb1baa33aa42a86@mail.gmail.com> From: stephen botzko To: "Wyss, Felix" Content-Type: multipart/alternative; boundary=0015174769c89e83940473264bca Cc: "codec@ietf.org" Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping 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, 09 Sep 2009 14:56:35 -0000 --0015174769c89e83940473264bca Content-Type: text/plain; charset=ISO-8859-1 All VBR codecs are potentially vulnerable to traffic analysis. There is at least one active draft in AVT on the subject already ( http://www.ietf.org/id/draft-perkins-avt-srtp-vbr-audio-01.txt). IMHO, the best way to handle this right now is to let the AVT discussions develop. It might also be wise to limit the use of VBR to adaptation to network conditions. Alternatively, the VAD guidelines in the Perkin's draft (section 3) might also be relevant (and could be adapted to the use of VBR to minimize average bandwidth use). Though I think those guidelines need more scrutiny. Either way, this is a reason for standardizing both the encoder and the decoder - as this particular vulnerability is in the encoder. Stephen Botzko Polycom On Wed, Sep 9, 2009 at 9:30 AM, Wyss, Felix wrote: > > > I thus think it is a MUST requirement that the encoder can be run in > > > a mode where there is no correlation between packet size, packet > > > rate and timing, and the short and long-term audio being encoded. > > > > Calls of an agreeing nature are on average shorter than calls with > > lots of discussion. And without trying to be sexist, I have a > > suspicion there is a correlation between call duration and gender. > > Should a signaling stack have a mode without termination? > > This is not relevant to the codec, though. If the parties see the need to > disguise the duration of the interaction, they can keep the streams up > longer, for example to some fixed length. > > > > Anyway, I absolutely agree there is an information leak with VBR. I am > > not aware of any evidence that it is practically exploitable, but > > concede it's dangerous to just rule that out. But I also think the > > "market" for a codec without such a leak is small and unproven. If we > > make a MUST out of every niche market requirement, we will have a hard > > time getting things done. And anyone capable of implementing a > > reasonably secure communications tool will know how to pad a VBR codec. > > I believe content privacy is pretty fundamental and not just some "niche > market requirement". > > Isn't the goal of this Internet audio codec to avoid having proprietary and > likely incompatible extensions? Anything not clearly spelled out in the RFC > is basically fair game and good luck getting devices from different vendors > to play well together. In our experience, it's hard enough to get devices > that implement what's in the RFCs correctly and anything slightly unusual > greatly increases the likelihood of incompatibilities and problems. For > example, I'd be reluctant to use RTP padding here for this very reason and > because it's up to the sender and not part of the media type negotiation. > > --Felix > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > --0015174769c89e83940473264bca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable All VBR codecs are potentially vulnerable to traffic analysis.=A0 There is = at least one active draft in AVT on the subject already (http://www.ietf.or= g/id/draft-perkins-avt-srtp-vbr-audio-01.txt).

IMHO, the best way to handle this right now is to let the AVT discussio= ns develop.=A0

It might also be wise to limit the use of VBR to ada= ptation to network conditions.=A0 Alternatively, the VAD guidelines in the = Perkin's draft (section 3) might also be relevant (and could be adapted= to the use of VBR to minimize average bandwidth use).=A0 Though I think th= ose guidelines need more scrutiny.

Either way, this is a reason for standardizing both the encoder and the= decoder - as this particular vulnerability is in the encoder.

Steph= en Botzko
Polycom

On Wed, Sep 9, 2009 = at 9:30 AM, Wyss, Felix <Felix.Wyss@inin.com> wrote:
> > I thus think it is a MUST requirement that the encoder can be ru= n in
> > a mode where there is no correlation between packet size, packet<= br> > > rate and timing, and the short and long-term audio being encoded.=
>
> Calls of an agreeing nature are on average shorter than calls with
> lots of discussion. =A0And without trying to be sexist, I have a
> suspicion there is a correlation between call duration and gender.
> Should a signaling stack have a mode without termination?

This is not relevant to the codec, though. =A0If the parties see the = need to disguise the duration of the interaction, they can keep the streams= up longer, for example to some fixed length.


> Anyway, I absolutely agree there is an information leak with VBR. I am=
> not aware of any evidence that it is practically exploitable, but
> concede it's dangerous to just rule that out. But I also think the=
> "market" for a codec without such a leak is small and unprov= en. If we
> make a MUST out of every niche market requirement, we will have a hard=
> time getting things done. And anyone capable of implementing a
> reasonably secure communications tool will know how to pad a VBR codec= .

I believe content privacy is pretty fundamental and not just some &qu= ot;niche market requirement".

Isn't the goal of this Internet audio codec to avoid having proprietary= and likely incompatible extensions? =A0Anything not clearly spelled out in= the RFC is basically fair game and good luck getting devices from differen= t vendors to play well together. =A0In our experience, it's hard enough= to get devices that implement what's in the RFCs correctly and anythin= g slightly unusual greatly increases the likelihood of incompatibilities an= d problems. =A0For example, I'd be reluctant to use RTP padding here fo= r this very reason and because it's up to the sender and not part of th= e media type negotiation.

--Felix


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

--0015174769c89e83940473264bca-- From mramalho@cisco.com Wed Sep 9 08:11: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 C29943A6BD3 for ; Wed, 9 Sep 2009 08:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.518 X-Spam-Level: X-Spam-Status: No, score=-6.518 tagged_above=-999 required=5 tests=[AWL=0.080, 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 OMu6Im4yDK9j for ; Wed, 9 Sep 2009 08:11:31 -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 21BF13A6870 for ; Wed, 9 Sep 2009 08:11:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIEACdip0qrR7O6/2dsb2JhbACCKS3DFYhDAZBgBYI4gWA X-IronPort-AV: E=Sophos;i="4.44,358,1249257600"; d="scan'208,217";a="239312213" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 09 Sep 2009 15:12:03 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n89FC36g016414; Wed, 9 Sep 2009 08:12:03 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n89FC3Bn003697; Wed, 9 Sep 2009 15:12:03 GMT Received: from xmb-rtp-219.amer.cisco.com ([64.102.31.101]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 11:12:03 -0400 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_01CA315F.E2C4207B" Date: Wed, 9 Sep 2009 11:12:02 -0400 Message-ID: In-Reply-To: <6e9223710909090757k2e3afdf1r7bb1baa33aa42a86@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec guidelines and requirements drafts: eavesdropping Thread-Index: AcoxXe23tcTsZd0KTKGLDoSinLBXuwAALu2A X-Priority: 5 Priority: Non-Urgent Importance: low References: <4AA16546.8050700@octasic.com> <4AA31726.3040904@usherbrooke.ca><20090906164218.85586qpxwpiv2guy@mail.skype.net><4AA45CC1.7050500@usherbrooke.ca><20090906214819.191431jmd444jtlf@mail.skype.net><4AA495DD.3060606@usherbrooke.ca><20090907080140.GR4137@audi.shelbyville.oz><20090907194908.161459bhbyrnn0o4@mail.skype.net> <6e9223710909090757k2e3afdf1r7bb1baa33aa42a86@mail.gmail.com> From: "Michael Ramalho (mramalho)" To: "stephen botzko" , "Wyss, Felix" X-OriginalArrivalTime: 09 Sep 2009 15:12:03.0413 (UTC) FILETIME=[E308A850:01CA315F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=15130; t=1252509123; x=1253373123; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mramalho@cisco.com; z=From:=20=22Michael=20Ramalho=20(mramalho)=22=20 |Subject:=20RE=3A=20[codec]=20Codec=20guidelines=20and=20re quirements=20drafts=3A=20eavesdropping |Sender:=20; bh=uKN1uN8OjIF73IGFJoVjt8nVorizqxPZZKgNS6JDyVg=; b=vQ5hdMNf0KvfWqZ/EPBm1vOnCu6rxw5R2t4uX5k8ikc12R4Do9l5bcuMkq vBt6liSaWFEKfZUCmD1QO4q9oJV5DdosARmFKPU5mEpuOVjDSZYYoj+JcTy5 O1tmHit/gv; Authentication-Results: sj-dkim-2; header.From=mramalho@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: codec@ietf.org Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping 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, 09 Sep 2009 15:11:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA315F.E2C4207B Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: "It might also be wise to limit the use of VBR to adaptation to network conditions." =20 Huh? I think I might understand if you equated VAD/DTX (of a CBR codec) or layered codec with VBR ... but in general? =20 For example, lossless codecs (data compression algorithms) have the property that their output entropy is a function of the input signal entropy. In other words, they are VBR by design. =20 To "pad" (or obfuscate) such codec operation is tantamount to wasting information for a criteria (lack of information leakage) that might not be important to the particular session. =20 I fail to see that this is a MUST requirement. The people looking for exploitable and classifiable differences in the output (i.e., information leakage) will just have to look harder/longer (just ask NSA). =20 Michael Ramalho =20 From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of stephen botzko Sent: Wednesday, September 09, 2009 10:57 AM To: Wyss, Felix Cc: codec@ietf.org Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping =20 All VBR codecs are potentially vulnerable to traffic analysis. There is at least one active draft in AVT on the subject already (http://www.ietf.org/id/draft-perkins-avt-srtp-vbr-audio-01.txt). IMHO, the best way to handle this right now is to let the AVT discussions develop. =20 It might also be wise to limit the use of VBR to adaptation to network conditions. Alternatively, the VAD guidelines in the Perkin's draft (section 3) might also be relevant (and could be adapted to the use of VBR to minimize average bandwidth use). Though I think those guidelines need more scrutiny. Either way, this is a reason for standardizing both the encoder and the decoder - as this particular vulnerability is in the encoder. Stephen Botzko Polycom On Wed, Sep 9, 2009 at 9:30 AM, Wyss, Felix wrote: > > I thus think it is a MUST requirement that the encoder can be run in > > a mode where there is no correlation between packet size, packet > > rate and timing, and the short and long-term audio being encoded. > > Calls of an agreeing nature are on average shorter than calls with > lots of discussion. And without trying to be sexist, I have a > suspicion there is a correlation between call duration and gender. > Should a signaling stack have a mode without termination? This is not relevant to the codec, though. If the parties see the need to disguise the duration of the interaction, they can keep the streams up longer, for example to some fixed length. > Anyway, I absolutely agree there is an information leak with VBR. I am > not aware of any evidence that it is practically exploitable, but > concede it's dangerous to just rule that out. But I also think the > "market" for a codec without such a leak is small and unproven. If we > make a MUST out of every niche market requirement, we will have a hard > time getting things done. And anyone capable of implementing a > reasonably secure communications tool will know how to pad a VBR codec. I believe content privacy is pretty fundamental and not just some "niche market requirement". Isn't the goal of this Internet audio codec to avoid having proprietary and likely incompatible extensions? Anything not clearly spelled out in the RFC is basically fair game and good luck getting devices from different vendors to play well together. In our experience, it's hard enough to get devices that implement what's in the RFCs correctly and anything slightly unusual greatly increases the likelihood of incompatibilities and problems. For example, I'd be reluctant to use RTP padding here for this very reason and because it's up to the sender and not part of the media type negotiation. --Felix _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec =20 ------_=_NextPart_001_01CA315F.E2C4207B Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Re: “It might also be wise to limit the use = of VBR to adaptation to network conditions.”

 

Huh? I think I might understand if you equated = VAD/DTX (of a CBR codec) or layered codec with VBR … but in = general?

 

For example, lossless codecs (data compression = algorithms) have the property that their output entropy is a function of the input = signal entropy. In other words, they are VBR by design.

 

To “pad” (or obfuscate) such codec = operation is tantamount to wasting information for a criteria (lack of information = leakage) that might not be important to the particular session.

 

I fail to see that this is a MUST requirement. The = people looking for exploitable and classifiable differences in the output = (i.e., information leakage) will just have to look harder/longer (just ask = NSA).

 

Michael Ramalho

 

From:= codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf Of = stephen botzko
Sent: Wednesday, September 09, 2009 10:57 AM
To: Wyss, Felix
Cc: codec@ietf.org
Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping

 

All VBR codecs are = potentially vulnerable to traffic analysis.  There is at least one active draft = in AVT on the subject already (h= ttp://www.ietf.org/id/draft-perkins-avt-srtp-vbr-audio-01.txt).

IMHO, the best way to handle this right now is to let the AVT = discussions develop. 

It might also be wise to limit the use of VBR to adaptation to network conditions.  Alternatively, the VAD guidelines in the Perkin's = draft (section 3) might also be relevant (and could be adapted to the use of = VBR to minimize average bandwidth use).  Though I think those guidelines = need more scrutiny.

Either way, this is a reason for standardizing both the encoder and the = decoder - as this particular vulnerability is in the encoder.

Stephen Botzko
Polycom

On Wed, Sep 9, 2009 at 9:30 AM, Wyss, Felix <Felix.Wyss@inin.com> = wrote:

> > I thus = think it is a MUST requirement that the encoder can be run in
> > a mode where there is no correlation between packet size, = packet
> > rate and timing, and the short and long-term audio being = encoded.
>
> Calls of an agreeing nature are on average shorter than calls = with
> lots of discussion.  And without trying to be sexist, I have = a
> suspicion there is a correlation between call duration and = gender.
> Should a signaling stack have a mode without = termination?

This is not relevant to the codec, though.  If = the parties see the need to disguise the duration of the interaction, they = can keep the streams up longer, for example to some fixed length.



> Anyway, I absolutely agree there is an information leak with VBR. I = am
> not aware of any evidence that it is practically exploitable, = but
> concede it's dangerous to just rule that out. But I also think = the
> "market" for a codec without such a leak is small and = unproven. If we
> make a MUST out of every niche market requirement, we will have a = hard
> time getting things done. And anyone capable of implementing a
> reasonably secure communications tool will know how to pad a VBR = codec.

I believe content privacy is pretty fundamental and = not just some "niche market requirement".

Isn't the goal of this Internet audio codec to avoid having proprietary = and likely incompatible extensions?  Anything not clearly spelled out = in the RFC is basically fair game and good luck getting devices from different = vendors to play well together.  In our experience, it's hard enough to get = devices that implement what's in the RFCs correctly and anything slightly = unusual greatly increases the likelihood of incompatibilities and problems. =  For example, I'd be reluctant to use RTP padding here for this very reason = and because it's up to the sender and not part of the media type = negotiation.

--Felix



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

 

------_=_NextPart_001_01CA315F.E2C4207B-- From stephen.botzko@gmail.com Wed Sep 9 08:36: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 39D023A69AC for ; Wed, 9 Sep 2009 08:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.192 X-Spam-Level: X-Spam-Status: No, score=-2.192 tagged_above=-999 required=5 tests=[AWL=0.406, 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 f6Gjw8CdLbKj for ; Wed, 9 Sep 2009 08:36:02 -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 2F4A53A6870 for ; Wed, 9 Sep 2009 08:36:02 -0700 (PDT) Received: by bwz19 with SMTP id 19so509716bwz.37 for ; Wed, 09 Sep 2009 08:36:30 -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=P5kYdyYOJYn74Wtq8RTnTvrjsf8Kkq7WO+8szRdvtEE=; b=TSC9m1f0p+HEReWY11Ae2a47Kx7D4j9LVDZFf1JQQvoahdeEbTU+WoWaqWvnS6r6p1 nzhCoKF9nzuIPbyR1HRhkPtbu3cjYPXrf/+cJGpZZlecU69253dZzmOXdM9hj1odTEK+ 8FdNzoRko43YX1u4i+T//O0eGpc/J1tq9Xw9c= 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=ISd/TLhFrz+qsTNrEzvvLo5Wy+M2aXo7VQMCLP+2RF1+RVvSVdDD1SEKQ7kCs7kxT0 zs3h9rJcOU3x2/kPPQ+gPKyze5xHRYbe+otzxiZCY0NC1QLrEicenlduZHklhXlEX1di Q7HwRBxWLJ1WWVGGXP1hDTCFhuUY0KbhQpTPY= MIME-Version: 1.0 Received: by 10.223.143.15 with SMTP id s15mr476133fau.77.1252510589741; Wed, 09 Sep 2009 08:36:29 -0700 (PDT) In-Reply-To: References: <4AA16546.8050700@octasic.com> <4AA45CC1.7050500@usherbrooke.ca> <20090906214819.191431jmd444jtlf@mail.skype.net> <4AA495DD.3060606@usherbrooke.ca> <20090907080140.GR4137@audi.shelbyville.oz> <20090907194908.161459bhbyrnn0o4@mail.skype.net> <6e9223710909090757k2e3afdf1r7bb1baa33aa42a86@mail.gmail.com> Date: Wed, 9 Sep 2009 11:36:29 -0400 Message-ID: <6e9223710909090836w13ba5986q35d66ebb1dd8ccb3@mail.gmail.com> From: stephen botzko To: "Michael Ramalho (mramalho)" Content-Type: multipart/alternative; boundary=0023545bdb80c76c6b047326d87f Cc: codec@ietf.org, "Wyss, Felix" Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping 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, 09 Sep 2009 15:36:04 -0000 --0023545bdb80c76c6b047326d87f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >>> It might also be wise to limit the use of VBR to adaptation to network conditions. >>> The Perkins draft (section 2) is suggesting that To avoid the potential information leaks that might enable traffic analysis, VBR audio codecs that alter the size or spacing of their output according to the characteristics of the input speech signal SHOULD NOT be used with encrypted SRTP sessions. My comment was not intended to be general (for all time), just that it *mig= ht *be wise to limit the use of VBR in the requirements for the *first* codec. Although this is perhaps needlessly conservative from a bandwidth perspective, it does prevent traffic analysis, and also ensures that the codec does not need to have a distinct operating mode for SRTP. Again, my view is that the AVT should take the lead on this, and I also not= e that the Perkins draft is a recent submission. MUSTs (and SHOULD NOTs) related to security are important, and in my view any codec work in the IETF should conform to best practices as far as security is concerned. It would be particularly embarrassing if the AVT published a BCP that the IETF codec group did not follow. Regards, Stephen Botzko Polycom On Wed, Sep 9, 2009 at 11:12 AM, Michael Ramalho (mramalho) < mramalho@cisco.com> wrote: > Re: =93It might also be wise to limit the use of VBR to adaptation to > network conditions.=94 > > > > Huh? I think I might understand if you equated VAD/DTX (of a CBR codec) o= r > layered codec with VBR =85 but in general? > > > > For example, lossless codecs (data compression algorithms) have the > property that their output entropy is a function of the input signal > entropy. In other words, they are VBR by design. > > > > To =93pad=94 (or obfuscate) such codec operation is tantamount to wasting > information for a criteria (lack of information leakage) that might not b= e > important to the particular session. > > > > I fail to see that this is a MUST requirement. The people looking for > exploitable and classifiable differences in the output (i.e., information > leakage) will just have to look harder/longer (just ask NSA). > > > > Michael Ramalho > > > > *From:* codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] *On Behalf > Of *stephen botzko > *Sent:* Wednesday, September 09, 2009 10:57 AM > *To:* Wyss, Felix > *Cc:* codec@ietf.org > *Subject:* Re: [codec] Codec guidelines and requirements drafts: > eavesdropping > > > > All VBR codecs are potentially vulnerable to traffic analysis. There is = at > least one active draft in AVT on the subject already ( > http://www.ietf.org/id/draft-perkins-avt-srtp-vbr-audio-01.txt). > > > IMHO, the best way to handle this right now is to let the AVT discussions > develop. > > It might also be wise to limit the use of VBR to adaptation to network > conditions. Alternatively, the VAD guidelines in the Perkin's draft > (section 3) might also be relevant (and could be adapted to the use of VB= R > to minimize average bandwidth use). Though I think those guidelines need > more scrutiny. > > Either way, this is a reason for standardizing both the encoder and the > decoder - as this particular vulnerability is in the encoder. > > Stephen Botzko > Polycom > > On Wed, Sep 9, 2009 at 9:30 AM, Wyss, Felix wrote: > > > > I thus think it is a MUST requirement that the encoder can be run in > > > a mode where there is no correlation between packet size, packet > > > rate and timing, and the short and long-term audio being encoded. > > > > Calls of an agreeing nature are on average shorter than calls with > > lots of discussion. And without trying to be sexist, I have a > > suspicion there is a correlation between call duration and gender. > > Should a signaling stack have a mode without termination? > > This is not relevant to the codec, though. If the parties see the need t= o > disguise the duration of the interaction, they can keep the streams up > longer, for example to some fixed length. > > > > > Anyway, I absolutely agree there is an information leak with VBR. I am > > not aware of any evidence that it is practically exploitable, but > > concede it's dangerous to just rule that out. But I also think the > > "market" for a codec without such a leak is small and unproven. If we > > make a MUST out of every niche market requirement, we will have a hard > > time getting things done. And anyone capable of implementing a > > reasonably secure communications tool will know how to pad a VBR codec. > > I believe content privacy is pretty fundamental and not just some "niche > market requirement". > > Isn't the goal of this Internet audio codec to avoid having proprietary a= nd > likely incompatible extensions? Anything not clearly spelled out in the = RFC > is basically fair game and good luck getting devices from different vendo= rs > to play well together. In our experience, it's hard enough to get device= s > that implement what's in the RFCs correctly and anything slightly unusual > greatly increases the likelihood of incompatibilities and problems. For > example, I'd be reluctant to use RTP padding here for this very reason an= d > because it's up to the sender and not part of the media type negotiation. > > --Felix > > > > _______________________________________________ > codec mailing list > codec@ietf.org > https://www.ietf.org/mailman/listinfo/codec > > > --0023545bdb80c76c6b047326d87f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable >>>
<= /span>=A0=A0 It might also be wise to limit the use of VBR to adaptation to network conditions.
>>>

The Perkins dra= ft (section 2) is suggesting that=A0 
=
  To av=
oid the potential information leaks that might enable traffic

   analysis, VBR audio codecs that alter the size or spacing of their
  =
 output according to the characteristics of the input speech signal
   S=
HOULD NOT be used with encrypted SRTP sessions.
My comment = was not intended to be general (for all time), just that it might be= wise to limit the use of VBR in the requirements for the first code= c.=A0 Although this is perhaps needlessly conservative from a bandwidth per= spective, it does prevent traffic analysis, and also ensures that the codec= does not need to have a distinct operating mode for SRTP.

Again, my view is that the AVT should take the lead on this, and I also= note that the Perkins draft is a recent submission.

MUSTs (and SHO= ULD NOTs) related to security are important, and in my view any codec work = in the IETF should conform to best practices as far as security is concerne= d.=A0 It would be particularly embarrassing if the AVT published a BCP that= the IETF codec group did not follow.

Regards,
Stephen Botzko
Polycom

On Wed, Sep 9, 2009 at 11:12 AM, Michael Ramalho (mramalho) <mramalho@cisco.com> wrote:

Re: =93= It might also be wise to limit the use of VBR to adaptation to network conditions.=94

=A0

Huh? I think I might understand if you equated VAD/DTX (of a CBR codec) or layered codec with VBR =85 but in general?

=A0

For example, lossless codecs (data compression algorithms) have the property that their output entropy is a function of the input sign= al entropy. In other words, they are VBR by design.

=A0

To =93pad=94 (or obfuscate) such codec operation is tantamount to wasting information for a criteria (lack of information leaka= ge) that might not be important to the particular session.

=A0

I fail to see that this is a MUST requirement. The people looking for exploitable and classifiable differences in the output (i.e., information leakage) will just have to look harder/longer (just ask NSA).

=A0

Michael Ramalho

=A0

From: codec-bounces@i= etf.org [mailto:codec-bounces@ietf.org] On Behalf Of stephen botzko
Sent: Wednesday, September 09, 2009 10:57 AM
To: Wyss, Felix
Cc: codec@ietf.o= rg


Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping

=A0

All VBR codecs are potentially vulnerable to traffic analysis.=A0 There is at least one active draft in AV= T on the subject already (http://www.ietf.org/id/draft-perk= ins-avt-srtp-vbr-audio-01.txt).


IMHO, the best way to handle this right now is to let the AVT discussions develop.=A0

It might also be wise to limit the use of VBR to adaptation to network conditions.=A0 Alternatively, the VAD guidelines in the Perkin's draft (section 3) might also be relevant (and could be adapted to the use of VBR = to minimize average bandwidth use).=A0 Though I think those guidelines need more scrutiny.

Either way, this is a reason for standardizing both the encoder and the dec= oder - as this particular vulnerability is in the encoder.

Stephen Botzko
Polycom

On Wed, Sep 9, 2009 at 9:30 AM, Wyss, Felix <Felix.Wyss@inin.com> wrote:

> > I thus think it is a MUST requirement that the encoder can be run in
> > a mode where there is no correlation between packet size, packet<= br> > > rate and timing, and the short and long-term audio being encoded.=
>
> Calls of an agreeing nature are on average shorter than calls with
> lots of discussion. =A0And without trying to be sexist, I have a
> suspicion there is a correlation between call duration and gender.
> Should a signaling stack have a mode without termination?

This is not relevant to the codec, though. =A0If the parties see the need to disguise the duration of the interaction, they can = keep the streams up longer, for example to some fixed length.



> Anyway, I absolutely agree there is an information leak with VBR. I am=
> not aware of any evidence that it is practically exploitable, but
> concede it's dangerous to just rule that out. But I also think the=
> "market" for a codec without such a leak is small and unprov= en. If we
> make a MUST out of every niche market requirement, we will have a hard=
> time getting things done. And anyone capable of implementing a
> reasonably secure communications tool will know how to pad a VBR codec= .

I believe content privacy is pretty fundamental and not just some "niche market requirement".

Isn't the goal of this Internet audio codec to avoid having proprietary= and likely incompatible extensions? =A0Anything not clearly spelled out in the RFC is basically fair game and good luck getting devices from different ven= dors to play well together. =A0In our experience, it's hard enough to get de= vices that implement what's in the RFCs correctly and anything slightly unusu= al greatly increases the likelihood of incompatibilities and problems. =A0For example, I'd be reluctant to use RTP padding here for this very reason = and because it's up to the sender and not part of the media type negotiatio= n.

--Felix



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

=A0


--0023545bdb80c76c6b047326d87f-- From Jean-Marc.Valin@USherbrooke.ca Wed Sep 9 08:47: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 DB0453A69AC for ; Wed, 9 Sep 2009 08:47:17 -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 N6m0S7WiHMuK for ; Wed, 9 Sep 2009 08:47:17 -0700 (PDT) Received: from smtpi5.usherbrooke.ca (smtpi5.usherbrooke.ca [132.210.236.1]) by core3.amsl.com (Postfix) with ESMTP id D5DD628C2A6 for ; Wed, 9 Sep 2009 08:47:16 -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 n89Fl9Mp006588; Wed, 9 Sep 2009 11:47:09 -0400 Received: from mail.octasic.com (mail.octasic.com [70.54.254.106]) by www.usherbrooke.ca (IMP) with HTTP for ; Wed, 9 Sep 2009 11:47:09 -0400 Message-ID: <1252511229.4aa7cdfda646d@www.usherbrooke.ca> Date: Wed, 9 Sep 2009 11:47:09 -0400 From: Jean-Marc Valin To: "Michael Ramalho (mramalho)" References: <4AA16546.8050700@octasic.com> <4AA31726.3040904@usherbrooke.ca><20090906164218.85586qpxwpiv2guy@mail.skype.net><4AA45CC1.7050500@usherbrooke.ca><20090906214819.191431jmd444jtlf@mail.skype.net><4AA495DD.3060606@usherbrooke.ca><20090907080140.GR4137@audi.shelbyville.oz><20090907194908.161459bhbyrnn0o4@mail.skype.net> <6e9223710909090757k2e3afdf1r7bb1baa33aa42a86@mail.gmail.com> 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: n89Fl9Mp006588 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, "Wyss, Felix" , stephen botzko Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping 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, 09 Sep 2009 15:47:17 -0000 Quoting "Michael Ramalho (mramalho)" : > For example, lossless codecs (data compression algorithms) have the > property that their output entropy is a function of the input signal > entropy. In other words, they are VBR by design. I think (well, I hope!) we all agree that asking a lossless codec to be CBR doesn't make any sense. > To "pad" (or obfuscate) such codec operation is tantamount to wasting > information for a criteria (lack of information leakage) that might not > be important to the particular session. > > I fail to see that this is a MUST requirement. The people looking for > exploitable and classifiable differences in the output (i.e., > information leakage) will just have to look harder/longer (just ask > NSA). I don't think anyone said that VBR should be ruled out. The only thing that was mentioned was having a CBR option in the codec for the cases where the user *does* care. Of course, all of this only applies to lossy codecs (I'm still waiting for a lossless codec that is guaranteed to always reduce the size!). Cheers, Jean-Marc From mramalho@cisco.com Wed Sep 9 08:54: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 14DE528C45E for ; Wed, 9 Sep 2009 08:54:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.528 X-Spam-Level: X-Spam-Status: No, score=-6.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 mr3CiO798DhV for ; Wed, 9 Sep 2009 08:54:25 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 4DEE328C495 for ; Wed, 9 Sep 2009 08:53:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAO9sp0qrR7MV/2dsb2JhbADFWodvVAGQYgWCIwqBa4sH X-IronPort-AV: E=Sophos;i="4.44,359,1249257600"; d="scan'208";a="202985765" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 09 Sep 2009 15:54:20 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n89FsKGm024671; Wed, 9 Sep 2009 08:54:20 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n89FsHxV023447; Wed, 9 Sep 2009 15:54:20 GMT Received: from xmb-rtp-219.amer.cisco.com ([64.102.31.101]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 9 Sep 2009 11:54:19 -0400 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, 9 Sep 2009 11:54:18 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [codec] Codec guidelines and requirements drafts: eavesdropping Thread-Index: AcovkXgSx0sW1M2hSEGLoZXUG1sL3AATshwQAGDaRCA= X-Priority: 5 Priority: Non-Urgent Importance: low References: <4AA16546.8050700@octasic.com><3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com><4AA26C95.8090504@usherbrooke.ca><20090905161909.77713cwiggjt4cml@mail.skype.net><4AA31726.3040904@usherbrooke.ca><20090906164218.85586qpxwpiv2guy@mail.skype.net><4AA45CC1.7050500@usherbrooke.ca><20090906214819.191431jmd444jtlf@mail.skype.net><4AA495DD.3060606@usherbrooke.ca><20090907080140.GR4137@audi.shelbyville.oz> From: "Michael Ramalho (mramalho)" To: "Wyss, Felix" , "Ron" , X-OriginalArrivalTime: 09 Sep 2009 15:54:19.0481 (UTC) FILETIME=[CAA5EC90:01CA3165] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5765; t=1252511660; x=1253375660; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mramalho@cisco.com; z=From:=20=22Michael=20Ramalho=20(mramalho)=22=20 |Subject:=20RE=3A=20[codec]=20Codec=20guidelines=20and=20re quirements=20drafts=3A=20eavesdropping |Sender:=20; bh=WGamA/DrEiRk3T+mA7sI9Av46KAMaoKnDLBSisoTPoU=; b=fnaPIU35cGDL1sNYIvg3mzjtSLO8Pg+EbwsERT+ASCJUrtEfmiau/ELXKO m5EFt4X6HEynVjsR//m57pDrEAS5Nmr2njL1EH0HRP9a3qI6PpwCofGF4pyw 5KQFsW47dsd6m4Ch67V2k/RZ3M2MhIhYJ51OXJueUAiyjC8qew2QY=; Authentication-Results: sj-dkim-1; header.From=mramalho@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping 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, 09 Sep 2009 15:54:27 -0000 Re:" I thus think it is a MUST requirement that the encoder can be run = in a mode where there is no correlation between packet size, packet rate = and timing, and the short and long-term audio being encoded." What is your definition of "no correlation"? I can more or less guarantee you that humans can design a system that = they believe has "no correlations" .... but if you train a classifier = with enough training data with similar sessions .... that you can with = high probability ascertain the use (or uses) of the channel. As we speak, bittorrent (and other applications) are being classified = (i.e., accurately identified) inside of IPSec tunnels (or TLS sessions) = as I type this. We may not know what is going on inside those channels = at any given instant - but we have some information (i.e., some = information leakage!). So this whole discussion is a matter of degree. Again, ask NSA or people = applying decades-old classification techniques (VQ, HMMs, etc.) to = unstructured data communications. So while I may agree that *some effort* should/may be made to obfuscate = what is going on (just to make it a little harder for the bad guys), it = is asymptotically hard to design a system with "no correlations" .... as = classification machines can see very small differences in channel = behavior characteristics. I think voice and video transmissions are = pretty easy to identify (as their entropy ranges and rates of change are = well known). I wouldn't like to see us go down this path only to find that some = relatively unintelligent undergraduate student uses a MATLAB = classification function to successfully identify our session with less = than a few hours of effort. Michael Ramalho -----Original Message----- From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of Wyss, Felix Sent: Monday, September 07, 2009 2:15 PM To: 'Ron'; codec@ietf.org Subject: Re: [codec] Codec guidelines and requirements drafts: = eavesdropping I agree. Assuming something can't be done because one can't think of a = way today is *very* dangerous when it comes to security. The assumption = must be that if information is leaked, there will be ways to exploit it. = There are many cases where the call content is highly structured, such = as your example of a call to a stockbroker. Many other types of service = or IVR calls tend to be that way. If an attacker knows at what point = during a call a party likely speaks their credit card or social security = number, the potential search space is greatly reduced. =20 I thus think it is a MUST requirement that the encoder can be run in a = mode where there is no correlation between packet size, packet rate and = timing, and the short and long-term audio being encoded. =20 --Felix > -----Original Message----- > From: codec-bounces@ietf.org [mailto:codec-bounces@ietf.org] On Behalf = Of > Ron > Sent: Monday, September 07, 2009 04:02 > To: codec@ietf.org > Subject: Re: [codec] Codec guidelines and requirements drafts: > eavesdropping >=20 > On Mon, Sep 07, 2009 at 01:10:53AM -0400, Jean-Marc Valin wrote: > > Koen Vos a =E9crit : > > > Quoting Jean-Marc Valin: > > > > > >> I wouldn't call the fear of encrypted VBR irrational, even though = I > > >> believe it is likely blown out of proportion. Actually, to me the > main > > >> leak involved in VBR is letting an eavesdroper know when there is > active > > >> speech. This is pretty much the same leak as that caused by a = VAD, or > > >> even knowing someone is present from the increased video = bandwidth. > > > > > > How would people take advantage of that kind of information? = Surely > the > > > fact there was a call to begin with (and the sending and receiving = IP > > > addresses) are much more revealing and incriminating? Does SRTP > provide > > > mechanisms to obfuscate those? > > > > The only case I can think of is when you have an audio link running = all > > day long, with most of the time nobody talking. Observing the rate = would > > tell you when a meeting starts. I don't mean to say that this is = really > > very bad. I'm just saying it's the only real "threat" I see. >=20 > You can also tell who is talking. Which combined with other sources > of information leakage may result in some interesting correlations. >=20 > If for example you were monitoring a call between me and my = stockbroker, > you might make a fairly reasonably guess about whether they were = giving > me tips, or I was giving them instructions, based on who was doing = most > of the talking. Combine that with other information a MITM might = observe > about my online or other activity, and it may be possible to tip the > balances of probability in the sort of ways that are interesting (in a > probably illegally profitable sort of way) in that domain. > >=20 > I'm likewise not utterly paranoid about the conversation itself being > decoded precisely, but information leakage has a way of being useful > when you least want it to. For the majority of people it may never > be an issue, but if the people who do (have to) care have to use a > different codec, that can be a form of information leakage too... >=20 > That may not be a terribly compelling argument, but saying "I can't > really see a way to use this either" doesn't really mean a lot unless > the person saying that is reporting on the consensus of a group of > eminent cryptographers who have made a determined effort to use it :) >=20 > Cheers, > Ron _______________________________________________ codec mailing list codec@ietf.org https://www.ietf.org/mailman/listinfo/codec From gmaxwell@juniper.net Wed Sep 9 13:59: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 38D713A69C0 for ; Wed, 9 Sep 2009 13:59:00 -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 9aMLBLT7n5Ss for ; Wed, 9 Sep 2009 13:58:59 -0700 (PDT) Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id C89363A682D for ; Wed, 9 Sep 2009 13:58:55 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSqgXLqe3JLGnoEJmMoTCVdnl2IchNomq@postini.com; Wed, 09 Sep 2009 13:59:32 PDT Received: from EMBX01-HQ.jnpr.net ([fe80::c821:7c81:f21f:8bc7]) by P-EMHUB02-HQ.jnpr.net ([fe80::88f9:77fd:dfc:4d51%11]) with mapi; Wed, 9 Sep 2009 13:57:53 -0700 From: Gregory Maxwell To: "Michael Ramalho (mramalho)" , "Wyss, Felix" , Ron , "codec@ietf.org" Date: Wed, 9 Sep 2009 13:57:52 -0700 Thread-Topic: [codec] Codec guidelines and requirements drafts: eavesdropping Thread-Index: AcovkXgSx0sW1M2hSEGLoZXUG1sL3AATshwQAGDaRCAACinUOA== Message-ID: References: <4AA16546.8050700@octasic.com><3d032e5d0909050122l7d0163ecyd9f2683c27f1e5eb@mail.gmail.com><4AA26C95.8090504@usherbrooke.ca><20090905161909.77713cwiggjt4cml@mail.skype.net><4AA31726.3040904@usherbrooke.ca><20090906164218.85586qpxwpiv2guy@mail.skype.net><4AA45CC1.7050500@usherbrooke.ca><20090906214819.191431jmd444jtlf@mail.skype.net><4AA495DD.3060606@usherbrooke.ca><20090907080140.GR4137@audi.shelbyville.oz> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping 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, 09 Sep 2009 20:59:00 -0000 Michael Ramalho (mramalho) [mramalho@cisco.com] wrote: > What is your definition of "no correlation"? > I can more or less guarantee you that humans can design a system that the= y believe has "no correlations" . > ... but if you train a classifier with enough training data with similar = sessions .... that you can with high probability ascertain the use (or uses= ) of the channel. [snip] No information =3D no correlation. I'm a little surprised to see this CBR = issue being debated. First please take a moment to look at this: http://www.cs.jhu.edu/~cwright/voip-vbr.pdf In this paper they perform blind language identification using only VBR pac= ket size sequences from speex. While many people don't care if an evesdrop= per could identify their language from the coded packets, I think we'd all = be surprised to have this happen (*but it's encrypted!*) and I hope we can = understand that it might be a real security problem for some people. Of course, it may be that other codecs don't suffer from this as badly as s= peex does=97 but we have no way to tell. Like many things in security we ca= n try and fail, only to have an attacker show up later with a more powerful= tool. The ability to use a constant frame size kills that leak dead. You= are either leaking information about the interior channel or you are not, = and if you are there is a great big uncertainty about how much of a leak th= e user can tolerate and how strong the attacker's statistical analysis is.= =20 True=97 there are other risks: Third parties are able to analyize the times= and durations, look at who talks to who. These leak information too, but = these leaks are very difficult to cure even at an enormous cost and they ex= ist for most secure communication systems. They are obvious and intuitive w= eaknesses which should not catch users of secure systems by surprise. The = same is not true of VBR: For VBR the possible leak is surprising and the le= ak can be completely closed at a low cost. We do not reject SSL and SSH because it's possible that an attacker has ins= talled a keylogger or because of the prevalence of malware may sometimes ma= ke them moot. The magnitude of the leak presented by VBR, if the paper on speex is anythi= ng to go by, is significantly greater than the magnitude of weaknesses in s= ome cryptosystems which were considered absolutely fatal. If you ask a cry= pto/security focused person to build a secure system out of a data-dependan= t VBR codec they are going to pad it to a constant size. It's so inexpensiv= e to close that weakness (even just using transport padding to a constant s= ize) that even with the most conservative estimate of the leak amount it is= obviously worth doing if your goal is security. So *given* that some users are going to demand constant length output for s= ecurity reasons or for frame-filling reasons wouldn't it be a good engineer= ing criteria for the codec to be able fill constant size buffers exactly an= d have a chance to make some good use of the space provided rather than was= te it with useless zeros? Wouldn't it be a win for interoperability to not = have to contend with a multitude of external padding systems? From alexander.chemeris@gmail.com Wed Sep 9 14:52: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 6E83F3A68B4 for ; Wed, 9 Sep 2009 14:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FG2QGhOrcj48 for ; Wed, 9 Sep 2009 14:52:09 -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 2B99F3A68A3 for ; Wed, 9 Sep 2009 14:52:09 -0700 (PDT) Received: by bwz19 with SMTP id 19so763453bwz.37 for ; Wed, 09 Sep 2009 14:52:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:from:date:x-google-sender-auth:message-id:subject:to:cc :content-type; bh=taY6KxhdmnQ5y4Ete8F6Otx39bzEfgw7T9OA3lrnwaw=; b=nQM3KaFmq6zPY7ZkMgMQovGE0U8/6XA0FA3rMO1V8RND+5v0Rz6yi04phk7tlhrF46 1bXIYqdy7y7x37aj3e/b1QeuoSNdBKpztIgzw02JqWPJC7+pyfwAGTJF6M4xeNVHHxgM XTV9zvOzWavcPJq0FX0EVWXVsPGwYjM/DGNQs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=Av0MY/nygx2KyNgCf1oiWA12Nh94oqJeEtavIsRbv+IyxRtd3671fxCGLj3BCrqUpN 5VPKKZWLkDu2g2RbGHNl6g29m1UqwGS7pBbgwBR9g/HjOvFCPeyzkmXTBNdFqke+hmkB 4kw1vhR9dyItqi0LJjCJaJ6rFL2lfBXB1Q3c4= MIME-Version: 1.0 Sender: alexander.chemeris@gmail.com Received: by 10.103.86.13 with SMTP id o13mr567634mul.6.1252533159074; Wed, 09 Sep 2009 14:52:39 -0700 (PDT) In-Reply-To: <3d032e5d0909050121k3e327b88k987d82b5f2000f31@mail.gmail.com> References: <4AA16546.8050700@octasic.com> <3d032e5d0909050121k3e327b88k987d82b5f2000f31@mail.gmail.com> From: Alexander Chemeris Date: Thu, 10 Sep 2009 01:52:19 +0400 X-Google-Sender-Auth: 25809261ae721c4d Message-ID: <3d032e5d0909091452y138467b5q5c1efa0112b82b36@mail.gmail.com> To: Jean-Marc Valin Content-Type: text/plain; charset=UTF-8 Cc: "codec@ietf.org" Subject: Re: [codec] Codec guidelines and requirements drafts 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, 09 Sep 2009 21:52:10 -0000 Hi, A few afterthoughts to add to my previous notes: On Sat, Sep 5, 2009 at 12:21, Alexander Chemeris wrote: > 1) I wonder why support for double- or multi-talk is not mentioned. > It's usually claimed that CELP codecs have hard time encoding conferences, > where there are a lot of double- or multi-talk parts. I believe it should be > stated as MUST or at least SHOULD for conferencing scenario and > included in testing set. Also test set should include double-encoding for the same purpose of conferencing. It's likely that conference bridge will decode speech, and then encode it again and this should not introduce big degradation of quality. Also re: CBR support. >From what I know, CBR mode is usually less CPU intensive and less memory hungry, and thus is much better suited for very small and dumb chips. So ability to support true CBR (not the one with padding, but the one with just one mode) is very much wanted. For such devices it's usually required to have low-complexity codec with *acceptable* qulity, i.e. it is not required to be perfect. I think we should add this point of low CPU and memory consumption to the wanted list of CBR features in requirements I-D. -- Regards, Alexander Chemeris. SIPez LLC. SIP VoIP, IM and Presence Consulting http://www.SIPez.com tel: +1 (617) 273-4000 From koen.vos@skype.net Wed Sep 9 15:15: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 D9E123A6B1F for ; Wed, 9 Sep 2009 15:15:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.77 X-Spam-Level: X-Spam-Status: No, score=-2.77 tagged_above=-999 required=5 tests=[AWL=-0.171, 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 1mmj0EB8R41N for ; Wed, 9 Sep 2009 15:15:14 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 965E33A6940 for ; Wed, 9 Sep 2009 15:15:14 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 0561F603273E2; Wed, 9 Sep 2009 23:15:47 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=LxpS5KUZhsAt zHkW72I3BNtwu78=; b=ety2b6qCoiVrViXZ+u7PHoLCGZ5Cm7PQ51wxUAgjf+Do 60LjOAMeP/4kacLkSDL6PBC+0IEUCRxz1iwj3q0XtojiW9x7HP5MVLmci0ouKOnG HOwLS5A5eS7RcZgaZA2wpkGUxPsiDY3P5UxQOEPBL/uY7SaUkdjoSc6SUwdMbL8= 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=SFxxSS/Oj59rEmOsGv9F FbApK0tCKUeZP3y/k6qSM7jYI8WbMglSGN9ZPlzlg4e9JWLAAYpTN6U96g/yrKso N9QxdWZzT2f/YQMW17iqltZaIYUoh+vPrBtIr5ZA7/oBsto3bOkqHlKr0DBRSlL5 B4Tl3RDvXsImSAtarGtIo1A= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 029D860229D3C; Wed, 9 Sep 2009 23:15:47 +0100 (IST) Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpMroXofG0eP; Wed, 9 Sep 2009 23:15:46 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id E253D603273E0; Wed, 9 Sep 2009 23:15:46 +0100 (IST) Received: from adsl-71-141-110-218.dsl.snfc21.pacbell.net (adsl-71-141-110-218.dsl.snfc21.pacbell.net [71.141.110.218]) by mail.skype.net (Horde Framework) with HTTP; Wed, 09 Sep 2009 15:15:46 -0700 Message-ID: <20090909151546.17786udb93pizklu@mail.skype.net> Date: Wed, 09 Sep 2009 15:15:46 -0700 From: Koen Vos To: Jean-Marc Valin References: <4AA16546.8050700@octasic.com> <4AA31726.3040904@usherbrooke.ca><20090906164218.85586qpxwpiv2guy@mail.skype.net><4AA45CC1.7050500@usherbrooke.ca><20090906214819.191431jmd444jtlf@mail.skype.net><4AA495DD.3060606@usherbrooke.ca><20090907080140.GR4137@audi.shelbyville.oz><20090907194908.161459bhbyrnn0o4@mail.skype.net> <6e9223710909090757k2e3afdf1r7bb1baa33aa42a86@mail.gmail.com> <1252511229.4aa7cdfda646d@www.usherbrooke.ca> In-Reply-To: <1252511229.4aa7cdfda646d@www.usherbrooke.ca> 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 guidelines and requirements drafts: eavesdropping 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, 09 Sep 2009 22:15:16 -0000 Quoting Jean-Marc Valin: > I don't think anyone said that VBR should be ruled out. The only > thing that was mentioned was having a CBR option in the codec for > the cases where the user *does* care. The privacy problem can easily be solved at a higher layer than the codec, by padding a VBR codec in conjunction with encryption. We can definitely help the SRTP guys figure out how to do that (padding with zeros would obviously be bad for the encryption). And I also have no problem with providing a CBR mode that they can prescribe. Most users and applications will be fine with VBR however, because the information leak from VBR is small compared to other leaks (including IP addresses, which are easy to extract, can be used as evidence in court, etc). PSTN and GSM phones are far more "leaky" than well-encrypted VBR, and few people shun these because of privacy concerns. Above all, using CBR for all modes would come at a high cost in bitrate, which would roughly double. That would hurt adoption of the codec, as many developers would simply choose a more efficient codec, and IWAC risks becoming irrelevant. koen. From koen.vos@skype.net Wed Sep 9 15:24: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 B250A3A6831 for ; Wed, 9 Sep 2009 15:24:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.754 X-Spam-Level: X-Spam-Status: No, score=-2.754 tagged_above=-999 required=5 tests=[AWL=-0.155, 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 eyBWzOjjYYeZ for ; Wed, 9 Sep 2009 15:23:59 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id A79913A6810 for ; Wed, 9 Sep 2009 15:23:59 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 8E6F7603273E0; Wed, 9 Sep 2009 23:24:32 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=k24+UhitlVZK mfNZsW5mbyDHzEY=; b=rajPFZM+J9M/YEknAQGtmjEDMXisuJmW/q2cynw25gjk haaCWsmed9CB5zrXBbRZIhm9bBzrAFT1ebniUGiTyL3LN/IMpRQVGkni848nMCUd A5NT2Dev9bBELbELBw2dcPge1uF0JxeRRIlR1KgkelTjnsBcC6jVMWA64qTLpK0= 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=J+IQ9X8SICdk8y0nDFCl bKMWHGd6+nZlFak5HzALZjyLslIOVeWGaiZw24MP0q35OMuH8OPRhbntPGRwXY/y +qYvfmFDDJ0q+IIL4Sd/SOQaeRCj2KUgSM6AvIE91RhLo7iDmheEfmso7DO/JK7J 8mhj9ipE5Q1m+XlD/iZLBqM= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id 8C88660229D2D; Wed, 9 Sep 2009 23:24:32 +0100 (IST) Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k1rz3jJgpfrV; Wed, 9 Sep 2009 23:24:32 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id 7A0DF60229D35; Wed, 9 Sep 2009 23:24:32 +0100 (IST) Received: from adsl-71-141-110-218.dsl.snfc21.pacbell.net (adsl-71-141-110-218.dsl.snfc21.pacbell.net [71.141.110.218]) by mail.skype.net (Horde Framework) with HTTP; Wed, 09 Sep 2009 15:24:32 -0700 Message-ID: <20090909152432.97693kngyi9wkxls@mail.skype.net> Date: Wed, 09 Sep 2009 15:24:32 -0700 From: Koen Vos To: Alexander Chemeris References: <4AA16546.8050700@octasic.com> <3d032e5d0909050121k3e327b88k987d82b5f2000f31@mail.gmail.com> <3d032e5d0909091452y138467b5q5c1efa0112b82b36@mail.gmail.com> In-Reply-To: <3d032e5d0909091452y138467b5q5c1efa0112b82b36@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 guidelines and requirements drafts 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, 09 Sep 2009 22:24:00 -0000 Quoting Alexander Chemeris: > Also re: CBR support. > From what I know, CBR mode is usually less CPU intensive and less > memory hungry, and thus is much better suited for very small and dumb > chips. Haven't heard that before, any references? I would say the CPU and memory consumption depend mostly on coding efficiency (ie, quality/bitrate). If anything, VBR has an advantage by not spending as many cycles encoding background noise. koen. From bmschwar@fas.harvard.edu Wed Sep 9 21:23: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 18F713A672E for ; Wed, 9 Sep 2009 21:23:31 -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 XOqn1nZcj6Kd for ; Wed, 9 Sep 2009 21:23:30 -0700 (PDT) Received: from us17.unix.fas.harvard.edu (us17.unix.fas.harvard.edu [140.247.35.197]) by core3.amsl.com (Postfix) with ESMTP id 1355D3A6818 for ; Wed, 9 Sep 2009 21:23:27 -0700 (PDT) Received: from [192.168.1.100] (c-71-192-160-188.hsd1.nh.comcast.net [71.192.160.188]) (authenticated bits=0) by us17.unix.fas.harvard.edu (8.14.1/8.14.1) with ESMTP id n8A4O0fN021876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 10 Sep 2009 00:24:01 -0400 Message-ID: <4AA87F60.8030602@fas.harvard.edu> Date: Thu, 10 Sep 2009 00:24:00 -0400 From: "Benjamin M. Schwartz" User-Agent: Thunderbird 2.0.0.22 (X11/20090714) MIME-Version: 1.0 To: Koen Vos References: <4AA16546.8050700@octasic.com> <4AA31726.3040904@usherbrooke.ca><20090906164218.85586qpxwpiv2guy@mail.skype.net><4AA45CC1.7050500@usherbrooke.ca><20090906214819.191431jmd444jtlf@mail.skype.net><4AA495DD.3060606@usherbrooke.ca><20090907080140.GR4137@audi.shelbyville.oz><20090907194908.161459bhbyrnn0o4@mail.skype.net> <6e9223710909090757k2e3afdf1r7bb1baa33aa42a86@mail.gmail.com> <1252511229.4aa7cdfda646d@www.usherbrooke.ca> <20090909151546.17786udb93pizklu@mail.skype.net> In-Reply-To: <20090909151546.17786udb93pizklu@mail.skype.net> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig647B62A22FB5CF935A1A6635" Cc: codec@ietf.org, Jean-Marc Valin Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping X-BeenThere: codec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: bens@alum.mit.edu 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, 10 Sep 2009 04:23:31 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig647B62A22FB5CF935A1A6635 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Koen Vos wrote: > Above all, using CBR for all modes would come at a high cost in bitrate= , > which would roughly double. That would hurt adoption of the codec, as > many developers would simply choose a more efficient codec, and IWAC > risks becoming irrelevant. No one is suggesting that CBR be the default. In fact, the requirements list VBR specifically as a required codec feature, with the implication that the great majority of users will operate in a VBR mode. The only requirement in the draft is that the reference encoder offer a CBR mode, if the client requests it. This hardly seems controversial, an= d I can't imagine how such an optional encoder feature could hurt adoption of the codec. This CBR mode need not be particularly efficient, though efficiency is always nice. Even a padding scheme would satisfy the requirements. --Ben --------------enig647B62A22FB5CF935A1A6635 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.11 (GNU/Linux) iEYEARECAAYFAkqof2AACgkQUJT6e6HFtqShzACeJgm5qqTF5ATiYDYaIzqPgX6u 5HIAn3x8WSg61AJNme6a2X6houeTm9uh =G9AM -----END PGP SIGNATURE----- --------------enig647B62A22FB5CF935A1A6635-- From koen.vos@skype.net Wed Sep 9 22:03: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 B7E493A6838 for ; Wed, 9 Sep 2009 22:03:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.741 X-Spam-Level: X-Spam-Status: No, score=-2.741 tagged_above=-999 required=5 tests=[AWL=-0.142, 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 sV+xsWB4ARrX for ; Wed, 9 Sep 2009 22:03:42 -0700 (PDT) Received: from mail.skype.net (mail.skype.net [212.187.172.39]) by core3.amsl.com (Postfix) with ESMTP id 6E3323A6862 for ; Wed, 9 Sep 2009 22:03:42 -0700 (PDT) Received: from mail.skype.net (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id C7797603273EB; Thu, 10 Sep 2009 06:04:14 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=skype.net; h=message-id :date:from:to:cc:subject:references:in-reply-to:mime-version :content-type:content-transfer-encoding; s=mail; bh=3L9j0VLng5mx ieamxZ8ULfSkDpg=; b=meC0Fk6FMYqp6q29tlytn7lcVIdhHlvtLI/ffAbOZ7K9 HFsG4WQZ2sAogLmW6GuvH9RDB+YuTE7kqUysH+/+xMOx3eEoYKpK42SafkKKW9NI SFW6F1wilCFJvb5FKHIFrkLmICaLRE9hfJIGTnkdTqdhSay0mPjkjkIyafmCHFU= 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=FV3qoUduXpvL1I8/g0q1 Poj6f2Z47Ynkb1Rz5mMTRtWmzAP7XL9w+BpQhuq0zoUGA30jJpUfRlWYiwxbUcu2 5ncnrDNsLmk61PAjXezt32a8ydX15B0JTKd+slQkzQzsz3B1IrhiYoMRYec5ZJ8N 9bdN/1sqZDTROGU1A8vi4H8= Received: from localhost (localhost [127.0.0.1]) by mail.skype.net (Postfix) with ESMTP id C563260229D2C; Thu, 10 Sep 2009 06:04:14 +0100 (IST) Received: from mail.skype.net ([127.0.0.1]) by localhost (dub-mail.skype.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UMxN2K+gXpJ6; Thu, 10 Sep 2009 06:04:14 +0100 (IST) Received: by mail.skype.net (Postfix, from userid 33) id B1D53603273EA; Thu, 10 Sep 2009 06:04:14 +0100 (IST) Received: from adsl-71-141-110-218.dsl.snfc21.pacbell.net (adsl-71-141-110-218.dsl.snfc21.pacbell.net [71.141.110.218]) by mail.skype.net (Horde Framework) with HTTP; Wed, 09 Sep 2009 22:04:14 -0700 Message-ID: <20090909220414.32865aofrc1aieoe@mail.skype.net> Date: Wed, 09 Sep 2009 22:04:14 -0700 From: Koen Vos To: bens@alum.mit.edu, "Benjamin M. Schwartz" References: <4AA16546.8050700@octasic.com> <4AA31726.3040904@usherbrooke.ca><20090906164218.85586qpxwpiv2guy@mail.skype.net><4AA45CC1.7050500@usherbrooke.ca><20090906214819.191431jmd444jtlf@mail.skype.net><4AA495DD.3060606@usherbrooke.ca><20090907080140.GR4137@audi.shelbyville.oz><20090907194908.161459bhbyrnn0o4@mail.skype.net> <6e9223710909090757k2e3afdf1r7bb1baa33aa42a86@mail.gmail.com> <1252511229.4aa7cdfda646d@www.usherbrooke.ca> <20090909151546.17786udb93pizklu@mail.skype.net> <4AA87F60.8030602@fas.harvard.edu> In-Reply-To: <4AA87F60.8030602@fas.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.4) Cc: codec@ietf.org, Jean-Marc Valin Subject: Re: [codec] Codec guidelines and requirements drafts: eavesdropping 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, 10 Sep 2009 05:03:43 -0000 Quoting Benjamin M. Schwartz: > No one is suggesting that CBR be the default. In fact, the requirements > list VBR specifically as a required codec feature, with the implication > that the great majority of users will operate in a VBR mode. > > The only requirement in the draft is that the reference encoder offer a > CBR mode, if the client requests it. This hardly seems controversial, and > I can't imagine how such an optional encoder feature could hurt adoption > of the codec. This CBR mode need not be particularly efficient, though > efficiency is always nice. Even a padding scheme would satisfy the > requirements. You're right, there is no controversy: we'll have both CBR and VBR. (My unhappiness is really with the SRTP draft suggesting that SRTP should not be used with VBR - I'll take it to the AVT list.) koen. From fluffy@cisco.com Sun Sep 27 21:20:20 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 581AA3A6859 for ; Sun, 27 Sep 2009 21:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.52 X-Spam-Level: X-Spam-Status: No, score=-106.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 huS6soTXxn3y for ; Sun, 27 Sep 2009 21:20:19 -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 9BFA43A683A for ; Sun, 27 Sep 2009 21:20:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE/Wv0qrR7PE/2dsb2JhbAC8IYhTAY1nBYQe X-IronPort-AV: E=Sophos;i="4.44,463,1249257600"; d="scan'208";a="397455995" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 28 Sep 2009 04:21:37 +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 n8S4LbY4001236 for ; Sun, 27 Sep 2009 21:21:37 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n8S4LaxI020590 for ; Mon, 28 Sep 2009 04:21:36 GMT Message-Id: <67F43778-8978-47D0-90C4-4AC45F466C9C@cisco.com> From: Cullen Jennings To: codec@ietf.org Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Sun, 27 Sep 2009 22:21:35 -0600 X-Mailer: Apple Mail (2.936) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=297; t=1254111697; x=1254975697; 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:=20BOF=20at=20next=20IETF=20meeting=20approved |Sender:=20; bh=SAjxiZLglRN3RxtXcG9711/n2LnmDqEzrJvUQlK3OP0=; b=Kh1cy+IAQx/LJ62jklbTMQ3cBd4gPX+Ed9SAy+7Nof8heZdHSEXrpbJxoq TKasFfPrT2hXij8/DL0shQqZHG0viAvB218ugpG6xKtLYVSw02dh3gYSlK78 /Cyz3oRCKA; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [codec] BOF at next IETF meeting approved 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, 28 Sep 2009 04:20:20 -0000 Just wanted to drop folks a quick note to let them know that after the IAB/IESG BOF call last friday, the CODEC BOF at the next IETF meeting has been approved. I'll work with folks to help sort out what are the key issues we need to resolve at the next BOF. Thanks, Cullen