Getting G.729 to work on Windows in the cheapest and most effective way

This is a very common question people ask for G.729: G.729 is the most common codec supported by a variety of VoIP providers and gateways. Though there are lots of better and free codecs around, G.729 is still the most preferred (and expensive) codecs around. The G.729 IPR billing is controlled by a company called SIPRO and if your product is sold with the G.729 codec embedded in it (even if it never gets turned on), you must pay the order of $5-$10 bucks per port to the consortium. SIPRO takes care of disbursing the payments around to the IPR owners. However, this is a well hidden secret for some reason. The common path taken by a lot of product vendors for supporting G.729 is that they license a complete media package from companies like VoiceAge. The media package bundles a voice processing layer which integrates G.729. The cost of the package is in the tens of thousands of $$. Here is an option which is much cheaper and works as good or better since it gives you full control of what is going on at least on Windows:

1) Get the Intel IPP development package from any of the resellers. This costs a few hundered bucks. The IPP is basically a development package which takes the original G.729 code published in the ITU standard and makes it work on Windows with some mods and optimizations.

2) As and when you sell licenses of your product you get a deal done with SIPRO and pay few bucks on a per seat basis. This avoids a lot of fees and proves to be much cheaper.

DI almost forgot to add that its as good voice quality as well!

SIPX on Windows

SIPX was one of the first open source SIP stacks we played around with on Windows. SIPX is supported by a strong community of developers and the code baseline came from Pingtel. There is a company called SIPEZ started by Daniel Petrie, a well known SIP Guru which supports SIPX. SIPX is used in a wide variety of commercial applications and is licensed under LGPL which is very attractive. I knew Daniel from IETF and often contacted and got his help during our evaluation phase. Based on what we found, SIPX is a great choice if you want to build a softphone very quickly since it has a lot of applications built into it and a lot of third party software hooks as well. However, we couldn't hire SIPX developers fast enough to support customer requirements and it proved harder to change and support in a cost effective way. Our next stop was brief and we looked at reSIProcate. reSIProcate, while supported on Windows is really meant for server side applications - at least that is the impression I got by talking to the SIP community at large. My team never really played around with it too much and we moved on to something called PJSIP. PJSIP has a very restrictive license (licensed under GPL) compared with SIPX and reSIProcate. That was one reason it was way down in our list though my gut feeling always was that it would have been a quicker fit (that's a lesson there for me - always feel out your guts properly in this phase :). PJSIP was supported by a much smaller community of developers and was not that widely known or deployed. One of my friends, Dr Henry Sinnreich (now at Adobe) actually introduced PJSIP to me. Overall we found PJSIP to be much more malleable and suitable to what we wanted to do both from a tactical and long term perspective. It also has a much smaller footprint compared to SIPX. However applications are much fewer. Its much more suitable for embedded systems.

Making SIP work on Windows

Few months back I did some research on open source Windows based SIP stacks and the sheer number of options available excited me. We explored several stacks: SIPX, PJSIP, ReSIProcate. In this article and few others I will put down my insight into what we learned during an ordeal which lasted for six months, talking to numerous people, vendors and component providers. Our goal was to have a stable, clean and extendable SIP API in our application well integrated with some good quality sound processing software. That was just 50% of the application. The other 50% was to do with rich GUI and data processing functionality for supporting a SaaS application on Windows. Nothing like this existed in the market. Our application was also a smart SIP client which implemented some new Peer-2-Peer techniques to avoid expensive network components which were inscalable and hard to manage (and thus supported the SaaS based model very well).