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