Successful VOIP Over DSL, Part 4: Traffic Shaping

My experience has been that the QoS mechanisms covered previously don’t provide a complete solution to the need for assured bandwidth when using VOIP over DSL. When the connection to the ISP becomes saturated for any reason VOIP traffic can be delayed which is always a problem. When managed QoS was combined with “traffic shaping” our VOIP phone service became much more reliable. This has proven to be true even on a very busy connection to my ISP.

Like the QoS mechanisms covered previously, traffic shaping is an edge process that occurs in your router. Traffic shaping is actually a process of reserving bandwidth specifically for selected applications. That bandwidth will not be used for other forms of internet access. As before, this tends to be most critical with outbound traffic where available bandwidth is most limited. It’s also true with inbound traffic, but this tends to be less of an issue.

Continue reading “Successful VOIP Over DSL, Part 4: Traffic Shaping”

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.