How To: HDVoice In PBX-In-A-Flash

I recently received an email from someone asking about enabling HDVoice in PBX-In-A-Flash.

I’m about to implement a PBXact for our small company, and I have a nicely running PBX in a Flash in my home. I’m wondering if I can HD-Audio-ize the home rig.

Here’s why I ask. We currently run a SIPX PBX in my company. Everything in that box, all the sound files, are all HD. When you talk to it with an HD endpoint, everything just talks HD. It’s a no brainer.

In my home PIAF/FreePBX/Asterisk, nothing is HD. How do I go about HD-izing it? I have the G.722 codecs all turned on, but I’m wondering if there is an easy way to make all HD-capable endpoints automatically talk HD to each other, and to talk HD to the PBX itself.

Any help is appreciated!


Fort Collins, Colorado

Since PBX-In-A-Flash is built upon Asterisk there’s a a good chance that this is possible, but its way outside of my scope. Given my employers migration to the OnSIP Hosted PBX I haven’t run Asterisk seriously for some time.

Continue reading “How To: HDVoice In PBX-In-A-Flash”

CPU Requirements For Transcoding To/From G.729a

During the VOIP Users Conference call on December 14th someone made some claims about the ability to handle G.729a encoded calls on various platforms. The comments revolved around the significance of cpu cache when dealing with the G.729a codec. Also some claims of the ability to deal with very high numbers of calls. The claim about the numbers of simultaneous transcodes possible were troubling to me.

G.729a is one of the more complex codecs in the VOIP universe. It puts considerable load on the CPU of the system that must for whatever reason transcode the call. In particular it’s FPU intensive. While CPU architectures are deeply interesting to me, suffice it to say that on some hardware platforms floating point operations are amongst the slowest operations that a CPU may perform.

Of course transcoding is not always necessary. A call may be placed from a phone that is itself G.729a capable, through the local Asterisk instance to an ITSP and on to the recipient…all of which are also G.729a capable. The call can thus be made without any transcoding at all. However, at any point along the path the a stage may not accept G.729a stream and so the call gets transcoded into something more acceptable, perhaps G.711 or GSM. Most typically calls that get routed to voicemail are transcoded to G.711 for the VM subsystem, although not always. Asterisk always transcodes into G.711 for MeetMe conferences.

I know for a fact that the Soekris Net4801 embedded platform can handle two G.729a transcodes when suitable licenses are installed. I used this very arrangement for over a year, and even wrote an article about it here.

Soekris Net4801 with the cover removed
Soekris Net4801 with the cover removed

The Net4801 features a National Semiconductor Geode SC1100 CPU running at 266 MHz with an unspecified amount of cache. When I first started using G.729a on the Net4801 I inquired with Kristian Keilhofner, the lead author of Astlinux, about his experience with the board. Kristian told me that 2-3 simultaneous transcoded calls was the most I could expect due to CPU limitations. My own experience supports his assertion.

T5700 Internals
T5700 Internals

More recently I’m using a HP T5700 thin client which features a Transmeta Crusoe CPU running at 1 GHz and with 512 kb of L2 cache. Under test conditions I’ve had four G.729a transcodes ongoing on this platform, but my test was limited to having only four licenses installed. I suspect that it could handle a few more channels, but the CPU use with even four concurrent channels points to a hard limit perhaps around 10 channels. I may well test this myself some day soon should the need arise.

Finally, Digium’s TC400b PCI card is specifically built to accelerate transcoding and offload that task from the host CPU. According to Digium, “The TC400B is rated to handle up to 96 bi-directional G.729a transformations or 92 bi-directional G.723.1 transformations.” If this is the stated capability of their accelerator then it seems unreasonable to expect similar or greater performance from a small format embedded platform, whatever the CPU cache might be.

The statements mentioned previously indicated the potential for a dramatically larger number of transcoded calls than would seem to be possible on the given platform. I find this unlikely on the basis of personal experience, the opinion of others whom I respect and Digium’s own statements about their transcoding hardware.

If you need transcoding capability on a low cost embedded platform it can’t hurt to consult with sources you trust. Ultimately you should conduct your own testing to be certain that the hardware supports your requirements reliably under real-world circumstances.