Re: [codec] comparitive quality testing: vote to add iLBC in

[Jean-Francois Mule <[e-mail]>]

Hi, Alan and Roman,

   I am not sure what this thread leads the working group but I'd like to
say a few points about iLBC.

Roman wrote:
> One can argue that we should also compare Opus with patent free codecs,
> which adds iLBC and Speex to the list, but I personally see this as
> less of a requirement. iLBC never managed to get market traction
> outside of the open source world,
Doing comparative quality testing against G.711, iLBC, G.729, G.722, and
G.722.2 AMR-WB provides considerable values to many vendor companies that
have implemented these codecs and to numerous service providers that have
deployed them (or are considering to).  I'd like to see iLBC added to the
list.


My team at CableLabs did quite a bit of work on iLBC and other codecs
almost 10 years ago.
Around 2002, we launched a project to find a royalty-free, narrowband
codec that could be implemented in PacketCable(tm) networks and that could
be submitted to our IPR pool including codec implementation references.
All we had when we started was G.711.  I'll skip the multi-year process...
iLBC was selected by CableLabs after some extensive testing outsourced to
two well-known and independent testing labs staffed with what I considered
at the time worldwide codec experts having worked on many codecs and
implementations (including some well-known standard codecs).  iLBC became
part of our PacketCable 1.1 now called PacketCable 1.5 specifications
prior to the codec becoming an IETF Experimental RFC.
In terms of voice codec deployments in cable networks, the fact is that it
is mostly G.711 today in the field - no questions there. Each cable
operator makes its own decision. The reasons for this lack of iLBC
deployments in cable networks are numerous and for the most part, outside
codec considerations.

That said, iLBC has been implemented by many as noted on the list.
I'm not sure if this was mentioned but my wireshark capture of an Apple
Facetime call shows a SIP invite with support for iLBC in addition to
X-AAC_ELD, X-G722 and PCMU.
--- Facetime call capture done in Oct 2010
User-Agent: Viceroy 1.4.1/GK
        Content-Type: application/sdp
        Content-Length: 587
    Message Body
        Session Description Protocol
            Session Description Protocol Version (v): 0
            Owner/Creator, Session Id (o): GKVoiceChatService 0 0 IN IP4
192.160.73.209
                Owner Username: GKVoiceChatService
                Session ID: 0
                Session Version: 0
 
...

Media Attribute (a): rtpmap:124 iLBC/8000



Jean-Francois.
[e-mail]


On 04/26/2011 23:14, "Alan Duric" <[e-mail]> 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
>