Re: [codec] comparitive quality testing

Roman Shpount <roman@telurix.com> Tue, 26 April 2011 22:24 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 40319E076F for <codec@ietfa.amsl.com>; Tue, 26 Apr 2011 15:24:38 -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 2tl8Ev7SH9AB for <codec@ietfa.amsl.com>; Tue, 26 Apr 2011 15:24:36 -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 27D7EE07DA for <codec@ietf.org>; Tue, 26 Apr 2011 15:24:36 -0700 (PDT)
Received: by eye13 with SMTP id 13so420820eye.31 for <codec@ietf.org>; Tue, 26 Apr 2011 15:24:35 -0700 (PDT)
Received: by 10.14.146.201 with SMTP id r49mr625666eej.152.1303856673699; Tue, 26 Apr 2011 15:24:33 -0700 (PDT)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by mx.google.com with ESMTPS id u16sm114572eei.23.2011.04.26.15.24.32 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 26 Apr 2011 15:24:33 -0700 (PDT)
Received: by ewy19 with SMTP id 19so419915ewy.31 for <codec@ietf.org>; Tue, 26 Apr 2011 15:24:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.14.38.7 with SMTP id z7mr564284eea.207.1303856672505; Tue, 26 Apr 2011 15:24:32 -0700 (PDT)
Received: by 10.14.48.66 with HTTP; Tue, 26 Apr 2011 15:24:32 -0700 (PDT)
In-Reply-To: <BANLkTimK=2T_O6z4mO2GBdmhJ+7wiuHTUA@mail.gmail.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>
Date: Tue, 26 Apr 2011 18:24:32 -0400
Message-ID: <BANLkTi=8joDGnbe5dNQTeEX4qgTE28vCdw@mail.gmail.com>
From: Roman Shpount <roman@telurix.com>
To: Alan Duric <Alan.Duric@telio.no>
Content-Type: multipart/alternative; boundary="000e0cdf960ccd7f1f04a1d9c947"
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:24:38 -0000

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
>>
>>
>