[Asterisk-Dev] Increasing reliability on lossy connections (iLBC, etc.)

Steve Kann stevek at stevek.com
Wed Jan 12 18:17:07 MST 2005


On Jan 12, 2005, at 2:49 PM, John Todd wrote:

> At 1:22 PM -0600 1/12/05, Michael Giagnocavo wrote:
>>
>>> The better solution would be to implement iLBC's packet concealment
>>> methods, and then use that codec for your IAX2 trunking.  I am
>>> currently under the impression (someone correct me if I'm wrong!
>>> It's been a while since this was discussed...) that the iLBC code in
>>> * is not completely implemented due to timing issues, so that iLBC's
>>> great packet concealment methods are unused.
>>>
>>> Sending packets twice is... a frightening hack.
>>>
>>> JT
>>
>> Yes, but that won't work at all with my IAX2 hardphones since they 
>> don't
>> support iLBC :S. I'm just wondering if resending would work, as 
>> hackish as
>> it is. And... will iLBC handle 8% packet loss gracefully? Apart from 
>> the
>> packet loss, the lines will do G711 fine (even sending duplicates).
>>
>> -Michael
>
> If you have an Asterisk server at both ends (one in North 
> America/Europe/wherever, one in Central America) then you can just 
> convert from iLBC to G.711 at the "far end".  However, if you're 
> talking about problems with the last mile, then yes, the awful hack 
> seems like the only method you might have.  Doesn't make it any less 
> of a frightening hack.  :-)
>
> Yes, iLBC handles losses of that large reasonably well; looks to be an 
> MOS of around 3 at 8% loss rate.  Look at the graph on the main 
> page...
>
> http://www.ilbcfreeware.org/
>
> I assume you're using IAXy's?  It's kind of a crime that something 
> that talks IAX doesn't have iLBC; they work so well together... but I 
> suppose there is a cost/processing power limit, and iLBC requires some 
> horsepower.  Maybe pony-power; it's only a single channel...
>
>
>
> To put us back on the -dev charter here: there was discussion some 
> months ago about throwing out the receive-based timing mechanisms and 
> using system clock or the USB Zap-like timers for packet tx/rx timers. 
>  I was under the impression that these patches would allow the use of 
> the iLBC loss-suppression features.  Did anyone ever start working on 
> that, or complete it?  It's Yet Another Worthy Project.
>

In order to do PLC, you need a jitterbuffer which can detect lost 
packets.  This is presently implemented in iaxclient, and there is 
already a bug in the tracker to add the same thing to asterisk.  iLBC 
and speex (and possibly G.729, though I don't know the API) all have 
native PLC code.  Steve Underwood has written generic PLC which we can 
use for u/alaw, GSM, and other codecs that don't natively support PLC.

It isn't a matter of using a different timing mechanism, just a 
jitterbuffer which can operate on packets both when they arrive, and 
just before they should be rendered (played, recorded, etc).

For speex and iLBC, this is fully implemented in iaxclient already.  
For ulaw, alaw, and GSM, the PLC mechanism in iaxclient is presently 
sub-par.  When I get back from vacation next week, I plan to implement 
Steve U's methods, assuming the licensing works out.  (he has licensed 
his code GPL, iaxclient needs LGPL, asterisk needs disclaimed code).

As far as the IAXy, I dunno how digium has implemented their firmware, 
but I'm guessing it's not a completely straight port of libiax2 -- if 
it is, integrating my jitterbuffer there shouldn't be hard, but the 
IAXy probably doesn't have the horsepower for PLC..


-SteveK




More information about the asterisk-dev mailing list