Re: [codec] comparitive quality testing
Roman Shpount <roman@telurix.com> Tue, 26 April 2011 22:12 UTC
Return-Path: <roman@telurix.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 70AA0E081F for <codec@ietfa.amsl.com>; Tue, 26 Apr 2011 15:12:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.976
X-Spam-Level:
X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 yoAZC91ea3KU for <codec@ietfa.amsl.com>; Tue, 26 Apr 2011 15:12:05 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by ietfa.amsl.com (Postfix) with ESMTP id 303FDE07B6 for <codec@ietf.org>; Tue, 26 Apr 2011 15:12:04 -0700 (PDT)
Received: by eye13 with SMTP id 13so418111eye.31 for <codec@ietf.org>; Tue, 26 Apr 2011 15:12:04 -0700 (PDT)
Received: by 10.213.28.206 with SMTP id n14mr622327ebc.25.1303855924081; Tue, 26 Apr 2011 15:12:04 -0700 (PDT)
Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by mx.google.com with ESMTPS id u16sm114731eei.9.2011.04.26.15.12.03 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2011 15:12:03 -0700 (PDT)
Received: by eye13 with SMTP id 13so418107eye.31 for <codec@ietf.org>; Tue, 26 Apr 2011 15:12:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.14.8.139 with SMTP id 11mr596039eer.175.1303855922851; Tue, 26 Apr 2011 15:12:02 -0700 (PDT)
Received: by 10.14.48.66 with HTTP; Tue, 26 Apr 2011 15:12:02 -0700 (PDT)
In-Reply-To: <260B5AEE-577C-478B-9335-553C7E9ABD8F@telio.no>
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>
Date: Tue, 26 Apr 2011 18:12:02 -0400
Message-ID: <BANLkTimK=2T_O6z4mO2GBdmhJ+7wiuHTUA@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Alan Duric <Alan.Duric@telio.no>
Content-Type: multipart/alternative; boundary="0016e65aea1a1eaf4c04a1d99d0f"
Cc: "codec@ietf.org" <codec@ietf.org>
Subject: Re: [codec] 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: Tue, 26 Apr 2011 22:12:07 -0000
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 > >
- [codec] comparitive quality testing Gregory Maxwell
- Re: [codec] comparitive quality testing Roman Shpount
- Re: [codec] comparitive quality testing Cullen Jennings
- Re: [codec] comparitive quality testing Roman Shpount
- Re: [codec] comparitive quality testing David Virette
- Re: [codec] comparitive quality testing Roman Shpount
- Re: [codec] comparitive quality testing Steve Underwood
- Re: [codec] comparitive quality testing Roman Shpount
- Re: [codec] comparitive quality testing Cullen Jennings
- Re: [codec] comparitive quality testing Alan Duric
- Re: [codec] comparitive quality testing Anisse Taleb
- Re: [codec] comparitive quality testing Monty Montgomery
- Re: [codec] comparitive quality testing Roman Shpount
- Re: [codec] comparitive quality testing Stephan Wenger
- Re: [codec] comparitive quality testing Steve Underwood
- Re: [codec] comparitive quality testing Roman Shpount
- Re: [codec] comparitive quality testing Roman Shpount
- Re: [codec] comparitive quality testing Cullen Jennings
- Re: [codec] comparitive quality testing Alan Duric
- Re: [codec] comparitive quality testing Roman Shpount
- Re: [codec] comparitive quality testing Roman Shpount
- [codec] iLBC deployment statistics (Re: compariti… Harald Alvestrand
- [codec] Deployment of iLBC Re: comparitive qualit… Cullen Jennings
- Re: [codec] comparitive quality testing: vote to … Jean-Francois Mule
- Re: [codec] comparitive quality testing: vote to … Roman Shpount