[codec] Deployment of iLBC Re: comparitive quality testing

Cullen Jennings <fluffy@cisco.com> Wed, 27 April 2011 15:30 UTC

Return-Path: <fluffy@cisco.com>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0463E07D8 for <codec@ietfa.amsl.com>; Wed, 27 Apr 2011 08:30:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.603
X-Spam-Level:
X-Spam-Status: No, score=-110.603 tagged_above=-999 required=5 tests=[AWL=-0.004, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3SRNB4Qzl1nT for <codec@ietfa.amsl.com>; Wed, 27 Apr 2011 08:30:32 -0700 (PDT)
Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by ietfa.amsl.com (Postfix) with ESMTP id 70414E0751 for <codec@ietf.org>; Wed, 27 Apr 2011 08:30:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=fluffy@cisco.com; l=9308; q=dns/txt; s=iport; t=1303918232; x=1305127832; h=subject:mime-version:from:in-reply-to:date:cc: content-transfer-encoding:message-id:references:to; bh=q65X6pJ7Ajnt5oG6W70GzvqMFr1VEjSHlxsakImWHvI=; b=ErHQHjllMYL8tnoUnZTR0YT0Hu+kxt77h1BMQopxs31RlZPOE0xq0oJg bgfkFztl5m7G1phbj8gfEPn/UYpD6v0r8xk4Zzulxya4GlvIy7544mTqe F+LMhqWJiCFGvDC3LtdmCaj7r5nW8UJo/V2WEfyseN8UVVmAY9jYiIvb2 M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAGA2uE2rRDoH/2dsb2JhbAClbHeIcJ1+nHmFdgSGA4hOhBKKOQ
X-IronPort-AV: E=Sophos;i="4.64,274,1301875200"; d="scan'208";a="303216146"
Received: from mtv-core-2.cisco.com ([171.68.58.7]) by sj-iport-3.cisco.com with ESMTP; 27 Apr 2011 15:30:26 +0000
Received: from [192.168.4.100] (rcdn-fluffy-8712.cisco.com [10.99.9.19]) by mtv-core-2.cisco.com (8.14.3/8.14.3) with ESMTP id p3RFUOCJ003049; Wed, 27 Apr 2011 15:30:25 GMT
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <fluffy@cisco.com>
In-Reply-To: <BANLkTi=8joDGnbe5dNQTeEX4qgTE28vCdw@mail.gmail.com>
Date: Wed, 27 Apr 2011 09:30:24 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <3D79FE66-AA32-4882-9D2F-0B5CA1D23B4C@cisco.com>
References: <BCB3F026FAC4C145A4A3330806FEFDA93BA8B64643@EMBX01-HQ.jnpr.net> <BANLkTimE6EzGY76Lm+-wtWtRTQgOjqhAEw@mail.gmail.com> <DB4DD197-97D2-492C-B896-A720347D3533@cisco.com> <BANLkTin53-nu9XzNi76KRV6npcWHUx4ptA@mail.gmail.com> <6261291B-0CB8-4719-910E-2ED7A7767D82@telio.no> <BANLkTik1DhJjUPYFtNL08gbSjqUB0KkLbQ@mail.gmail.com> <260B5AEE-577C-478B-9335-553C7E9ABD8F@telio.no> <BANLkTimK=2T_O6z4mO2GBdmhJ+7wiuHTUA@mail.gmail.com> <BANLkTi=8joDGnbe5dNQTeEX4qgTE28vCdw@mail.gmail.com>
To: Roman Shpount <roman@telurix.com>
X-Mailer: Apple Mail (2.1084)
Cc: codec@ietf.org
Subject: [codec] Deployment of iLBC Re: comparitive quality testing
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Apr 2011 15:30:33 -0000

Roman - I understand your pain on this. It is really hard to figure out what codecs a company's devices support by looking at their website. I'd love to give you an exact list of exactly what codecs every cisco product supports but I can't figure that out and I work there. Even when you can figure it out for a product, it's hard to know if that product is widely used of barely deployed at all. Even harder to know is how carriers actually configure and use things in their networks. Statistics from sipit are highly skewed towards products early in their development cycle while deployments tend to consist of products late that have been around for awhile. Most of the actually usage statistics in deployments are considered confidential. From my point of view, most major vendors support iLBC in many of their products that do narrowband voip across the internet and they do so because there is a large demand for it in the market place. On one side note about license agreements. In the acquisitions I have been involved with, the acquiring company typically continues to honor all the commitments made by the company they acquired. Given Google's general goals on widespread interoperable codecs, I'd be simply shocked to see them start suing people over iLBC IPR. 


On Apr 26, 2011, at 4:24 PM, Roman Shpount wrote:

> Correction to my previous email: Snom m3 DECT phone supports iLBC according to its data sheet, all the other Snom phones do not mention iLBC. Once again, it is possible that all of their data sheets on the web site are outdated.
> _____________
> Roman Shpount
> 
> 
> On Tue, Apr 26, 2011 at 6:12 PM, Roman Shpount <roman@telurix.com> wrote:
> Alan,
> 
> 1. As far as iLBC implementation is concerned, encoder is not specified to be bit exact. This means you can produce any encoder that you, as an implementer, would consider are close enough and claim that they satisfy the standard. You can take shortcuts, and the resulting audio quality will vary based on that, as will the required computation power. My point is, that the reference implementation, which is part of RFC is much more computationally expensive then G.729A. You can build a version of the codec, that has the same computation requirements as G.729A, but it will probably come at a cost of quality degradation. For instance you will have to change how LPC to LSF conversion is done, since reference implementation computes polynomial values in a lot smaller intervals then G.729A. I am sure there are good iLBC implementations on the market, but those are not the ones measured for quality, and not the ones with which OPUS is going to be compared with. Once again, and this is the main point of this entire discussion, if we choose to compare with iLBC, we need to very clearly define what we are comparing with and keep in mind that this is probably not the version running in production gateways or phones from Cisco or other manufacturers.  
> 
> 2. I agree on iLBC license.
> 
> 3. I said, none of those carriers OFFER iLBC to their customers. I never said that it is not used anywhere within their network, even though I would be very interested to know what it is used for. In the carrier service agreements you have a choice of PCMU or G.729A. You can probably get iLBC from those carriers, but you need to be big enough and convincing enough to get it. Carrier SBCs would definitely be able to convert audio to iLBC if this is something required by the customer, so those carriers definitely have the capability to offer iLBC. The point is, as far as I know, it is not offered.
> 
> 4. The statement about Sonus gateways comes from the Sonus web site, where iLBC is not mentioned as supported codec for their gateways, and from talking to the carriers I use (pretty much the whole list I mentioned in my previous email), that said that Sonus gateways do not support it. They did mention that they are using GSX 6.4, so this information about Sonus can be outdated or the sales engineers can be misinformed.
> 
> 5. Can you tell me when Skype is using iLBC? Is there a way for me to place a call using Skype and see iLBC as a codec used in the technical info? ISAC is still used when calling old (ancient to be precise) Skype clients.
> 
> 6. I would love to hear form somebody from CableLabs or a from a cable operator to tell us how they use iLBC. As a side note, cable operators have no motivation of using low bitrate codec since they have plenty of capacity to the customer.
> 
> 7. My information about phones comes from the manufacturer web sites and the specifications for the phones there. For instance, SNOM 870 datasheet (http://www.snom.com/en/products/ip-phones/snom-870/) or datasheets for any other SNOM phones never mention iLBC.
> 
> I am not trying to spread FUD. I am telling you what I've seen from my personal experience and I clearly state this. If you can show me the examples of the opposite, I would love to see them.
> 
> Regards,
> _____________
> Roman Shpount
> 
> 
> 
> On Tue, Apr 26, 2011 at 5:14 PM, Alan Duric <Alan.Duric@telio.no> wrote:
> Dear Roman,
> 
> unfortunately, You are continuing with "say so" statements ...  Please read my postings before You reply and use facts and sources, rather then throwing FUD!
> 
> Basically, You have expanded our initial conversation about iLBC deployments with 2 additional topics. I would like to focus on iLBC deployments and close on that subject on this thread. As per other newly introduced topics:
> 1) iLBC implementations and quality
> - my response to You is that it depends on how good work is done with the implementation. There is a number of very good and excellent implemenations (e.g by silicon & gateway vendors and a number of ATA/IP Phone vendors), which run in a similar manner as implemented and "advertised" by GIPS at the time.
> 
> 2) iLBC license
> - this new introduced topic I propose that we take as separate thread and discussion point, not confuse it with this thread. However, there is so far no charges pressed to anyone, years after it has been deployed. As per G.729A, I am also very glad that it has been released on royalty free basis to the community, which was also pretty much happened due to availability of iLBC.
> 
> As per iLBC deployments, please find response inline:
> 
> >
> > This discussion is a bit unrelated to the overall discussion in the group, but I would still like to clarify some of my points.
> >
> > As far as iLBC market penetration is concerned, what I know (and please correct me if I am wrong), none of the major US VoIP carriers (AT&T, Verizon, Qwest, Level 3, XO, GlobalCorssing) offer iLBC termination to their customers. It is a choice of G.711 or G.729 A or B only.
> 
> Yes, You are wrong! One of the listed carriers (which is present in Europe) is offering it. According to Sonus there is 8 of major US carriers using iLBC!
> 
> > This is either caused by the luck of market demand, or by them using Sonus gateways which, as far as I know, do not support iLBC.
> 
> Where do You get this info??? Sonus supports iLBC on all of their gateways since GSX 6.5.0R0 (to be more exact under a feature PCR 111). This has been available for a number of years - the best illustration is that this software version is now going out of life ... Source is Sonus and my company, we are Sonus customers since end of 2005 and running billions of minutes of traffic on Sonus.
> >
> > Once again, as far as I know Skype is not using iLBC for anything. It is using Silk, G.711. G.729A, and ISAC.
> 
> And again ... where do You get all this info from??? A number of wrong statements in only one sentence (BTW, SILK has phased out pretty much completely ISAC a long time ago).
> >
> > As far as I know none of the cable VoIP operators in US use iLBC, it is all G.711.
> 
> This is also not true, i trust that someone from CableLabs that follows the list will react on this (providing us with first hand info).
> 
> >
> > As far as hardware vendors are concerned, Cisco does support iLBC on its gateways a quite a few (but I do not think all) of its phones. Sonus only supports iLBC in its SBC, but not in gateways. Polycom, Snom, Aastra do not seem to support iLBC in their phones.
> 
> As Cullen mentioned it is supported by Cisco, some Polycoms and also a whole range of Asian vendors that by now own quite a bit of the market around the world. I know that SNOM 870 also supports iLBC and I trust a number of their phones  ... Where do You get all this??
> 
> As mentioned in my previous email, if You disagree please provide us with facts and sources, otherwise it is just "say so" and should be treated as such ...
> 
> Best regards,
> Alan
> 
> 
> Alan Duric
> CTO and Cofounder
> Telio Holding ASA | Oslo exchange: TELIO
> 
> twitter:        alanduric
> linkedin.com/in/alanduric
> 
> 
>