[asterisk-dev] iLBC packet loss concealment (was: code-cleanup concerns)

[John Todd]

At 2:45 PM +1000 4/16/06, Adrian Sietsma wrote:
>Matt Ranney wrote:
>  > Somehow the jitter buffering or packet loss concealment or whatever
>>magic that Skype uses makes it work better than asterisk/IAX over 
>>the  same WAN link.
>Having done some testing of voip over WAN, I would say it is both. I 
>have seen packet loss of up to 20-30% (using a CDMA wireless card). 
>Skype's codecs, including iLBC, seem very tolerant of packet loss.
>
>Their client also has effective echo suppression, which makes using 
>it without a headset fairly painless.
>
>Asterisk is also very prone to jitter problems, if I understand 
>correctly. Since outgoing RTP packets are triggered by incoming, 
>that would reflect any incoming jitter back to the sender, as well 
>as passing it on. Issue 5374 should solve this.
>
>Adrian


Time to break this out into a thread with a title that matches it's content.

I have not been 100% up-to-date on the implementation of iLBC's 
Packet-Loss-Concealment code within Asterisk.  I know that there is 
basic PLC in Asterisk, but is as good as it could possibly be with 
iLBC's open-source implementation?  Are there any methods by which 
this new asynchronous packet generation could improve the situation, 
or is PLC by definition something that the receiver needs to worry 
about?

Follow-up questions: is the existing PLC only available in IAX2, or 
is it generally available in RTP?

http://voip-info.org/tiki-index.php?page=Asterisk+new+jitterbuffer

Skype has good quality because of several factors: they are primarily 
soft-client based, so they can use better-than-telephony sound 
quality on both sides of the connection to start with, and secondly 
because they are using a patent-encumbered version of iLBC from 
Global IP Sound (GIPS) which I assume has both better PLC as well as 
better compression characteristics.  I'll put my $.02 towards 
Asterisk supporting better codecs at higher bitrates (Speex, notably, 
has the ability to do much better than "MOS 4", or "toll-quality" 
sound - stereo, higher bitrates, etc.)  since this is next-generation 
telephony system implementation, not last-generation telephony system 
design.

I digress... anyone (SteveK?) have comments on generalized iLBC PLC for SIP?

JT