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