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
_______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
