[Asterisk-Users] GSM v iLBC for low bandwidth connections

[Steve Kann]

On May 14, 2004, at 7:40 AM, Andrew Kohlsmith wrote:

>> I've been playing with GSM and iLBC over low bandwidth connections
>> (central Asterisk box with 2mbps, to ADSL users on 512/256) and both
>> seem to perform well. Based upon what I've read in the archives and
>> at voip-info.org iLBC should perform a little better if packets are
>> lost, than compared to GSM. Do you find this to be true in practice,
>> or is GSM just as robust?
>
> I believe that iLBC has better MOS in lossy environments than all other
> protocols, period.  I use it exclusively now with the VOIP providers I 
> use
> for LD.

This wasn't always true; it was true when the other formats didn't use 
any redundant data, which they have support for (i.e. interleaving 
data, etc).  Since some of the proprietary codecs use much less 
bandwidth than iLBC, you can add redundant data in the same bandwidth.

_however_  asterisk doesn't use any codec's interleaving features in 
order to have the codec try to reconstruct lost frames;  most 
applications/bridges will probably just insert silence during the lost 
frame period.  I've been thinking about how to handle this, and it is 
related to the issue of handling VAD:  You need some way for channel 
readers to know, when there's no frame available to read, whether this 
is due to:

a) jitter buffer growing
b) frame lost in transmission
c) actual silence.

For (a), (b), you want the codec to interpolate the lost frame 
(generally, this will mean repeating most of the energy from the 
previous frame).  For (c), you want silence, or comfort noise of some 
kind.

GSM does not support interpolation, speex (and I would assume iLBC) 
does.


>
>> Whilst I'm asking questions, in terms of sound quality would there be
>> a significant benefit in switching to g.729?
>
> I have had *zero* voice quality issues with iLBC.  I have had voice 
> quality
> issues due to links that were full, but that's not iLBC's fault.  The 
> only
> reason I can see using g.729 these days is for low-bandwidth 
> interoperability
> with commercial VOIP equipment that doesn't use iLBC.  Seriously.  The
> difference between 11-13kbps for an iLBC conversation vs 8kbps for 
> g.729 is
> negligable to me.  Maybe if you had a thousand calls pumping out your
> connection, but then again the $10k you spent on g.729 licenses can 
> probably
> buy a slightly faster link.  :-)

For a single IAX link, the actual bandwidth usage is much higher than 
that, and it such that the codec itself doesn't matter that much:  
while typical IAX overhead is just 4 bytes per miniframe, UDP adds 8 
bytes, IP adds 20 bytes, and ethernet adds 14 bytes.  So that's 46 
bytes of overhead per IAX miniframe on ethernet.  Compare that to 33 
bytes for GSM payload, or whatnot, and you see that for individual IAX 
calls, even if you found a 0 bits/sec codec, you still wouldn't make a 
50% reduction in actual bandwidth.

IAX trunking helps a _lot_ and more the more calls you have using it.  
But for single iax calls, the only way to really lower bandwidth is to 
use longer frame sizes, so you have more data per frame.  iLBC is 30ms 
frames, versus 20ms frames for GSM, so that helps a bunch.

For GSM with 20ms frames: DATA RATE: 79*8*50 = 31.6kbit/sec.
40ms frames: 46 bytes overhead + 66 bytes data = 112 bytes; 22.4 kbps
80ms frames: 46 bytes overhead + 132 bytes data = 17.8 kbps

Of course with larger frames, lost frames will make more noticeable 
audio problems...

-SteveK