[Asterisk-Users] Low bit rate codec (speex)
Brian West
brian at bkw.org
Tue Sep 2 11:28:09 MST 2003
Well put.
On Tue, 2 Sep 2003, John Todd wrote:
> 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
>
>
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com
> http://lists.digium.com/mailman/listinfo/asterisk-users
>
More information about the asterisk-users
mailing list