[Asterisk-Users] Low bit rate codec (speex)

[John Todd]

At 11:42 AM -0500 9/2/03, Brian West wrote:
>
>http://bugs.digium.com/bug_view_page.php?bug_id=0000149
>
>bkw
>
>On Tue, 2 Sep 2003, Eduardo Goncalves wrote:
>
>>  On Tue, 2 Sep 2003 10:27:53 -0500 (CDT)
>>  Brian West <brian at bkw.org> wrote:
>>
>>  > I opened a request on bugs.digium.com for this feature.  The 6k and 8k
>>  > codecs are very impressive also.
>>  >
>  > > bkw
>  >
>>	Where can I see the status of this request?
>>
>>  []'s
>  > Eduardo

Spoiler: Read to the bottom about how to get 400 calls into a megabit.  Maybe.

I'm ashamed to say I had not actually looked at the lower-bandwidth 
encoding options of Speex in the past, and skipped right over that 
section of the text in favor of the high bandwidth bitrates.  What a 
mistake!  I am extremely impressed with the 4kbps VBR rate for Speex, 
at least from the samples on the Speex website.

If the sound quality is as good as advertised at the low bitrates, 
the addition of selectable features for Speex would truly be an asset 
to Asterisk on a per-call basis (heck, even just per-peer.)  I have 
several clients who need to move traffic across international IP 
capacity, and the low-bandwidth option of choice to them is G.729 
(LPC10 is not an option due to sound quality issues.)  The very 
interesting features of VAD and VBR look to be (on paper, at least) a 
real win as well, with the channel bitrate being reduced even further 
by silence and sound complexity compression.

Exposing codec feature selections to the dialplan would be 
interesting, but I expect Mark will want to (correctly) implement a 
generic method for doing this.  However, are there any other codecs 
that Asterisk supports that have the ability to use different options 
(bitrate, VBR, VAD)?  Is it worthwhile to make this a generic 
function of some sort, or is it sufficient to make specific 
techniques just for Speex? (${SPEEX-BITRATE}, or ${SPEEX-VBR} to give 
crude examples.)

Why am I so excited about this?  The point of VoIP for most of my 
customers is twofold: the first point is the addition of new and 
novel services that they would not be able to offer previously 
without investing a lot in hardware.  The second (and for some, the 
primary) point is that VoIP allows the transmission of voice packets 
over a less expensive packetized path than TDM.  Thus, the biggest 
number on their minds is "Cost of Bandwidth!"   The more voice 
streams you can pack into the bandwidth, the less they pay for 
bandwidth, and thus the larger the profit margin - very simple 
equation.  So, they're really REALLY interested in any way to get 
more calls into the same number of bits per second, and Speex seems 
to have some interesting options in that arena.

Combined with the clever use of trunking with IAX2, I could possibly 
see (looking at back-of-napkin, totally theoretical numbers) 
something like 400 calls in a megabit between two Asterisk servers. 
That number seems wrong to me, and I expect my first impression is 
correct, but here's the math: with my IAX2 tests which I documented 
previously on this list, I got a theoretical 103 calls into a megabit 
of bandwidth with G.729 at 9.6kbps per additional call.  Now, the 
Speex codec can be turned down to 4kbps, so I can get 2.4 Speex calls 
into the same space that I fit one G.729 call.  So, (2.4 * 103 = 247) 
into a megabit.  Now, usually only one person is talking at a time. 
This means VAD would be active on 50% of the channels, thus 
eliminating traffic in one way for all calls.  I'm sure that's not 
quite accurate due to background noise and overtalk, so let's say 
that only 30% of the legs are empty at any one time due to VAD.  So, 
that's an additional few channels, so now we're at (247 + (247 * .3) 
= 321) total channels.  Now I move into the really unstable math 
(i.e.: I'm making this up based on wild fantasy.)   If VBR is 
implemented, maybe/hopefully/possibly that permits us another 25% 
savings on bits per second, so that turns into (321 + (321 * .25) = 
401) channels in a single megabit.  This seems impossible.  Anyone 
care to shoot holes in these numbers?

JT