Tuesday, January 29, 2008

How to use a third party SIP softphone with your Vonage Account

This is real easy. The Vonage server uses SIP in a very standards compliant way and makes use of SIP forking etc which allows multiple phones to register as well.

Here are some pointers to help:

1) The vonage SIP Proxy is basically or sphone.vopr.vonage.net
2) You will need to get a userid and password for your softphone account from Vonage.

That's pretty much it. After that you can register any standards compliant SIP Softphone like SJPhone or a more sophisticated solution like WebAstra to work with your Vonage account!

Turning on Signaling NAT Traversal in OpenSER

loadmodule "nathelper.so"
modparam("nathelper", "rtpproxy_disable", 1)

if (uri==myself) {

if (method=="INVITE") {

if (nat_uac_test("7")) {

route[1] {


# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {

onreply_route[1] {

if (nat_uac_test("1")) {

Friday, January 25, 2008

STUN Servers

Does anyone know of a stable STUN server which can handle lots of load (ie., STUN transactions per second)? We have tried the Vovida STUN Server, but it gets hosed up intermittently. Not sure what is the problem behind that yet. We are looking into it though. If anyone has similar problems, please ping me...

There is another STUN server which is in Alpha state. We tested this server and preliminary testing seems to yield good results.

From a service standpoint, the XTEN STUN Server (stun.xten.com) seems pretty stable. I am not sure what they are using though. Is that a commercial or open source server?

Wednesday, January 23, 2008

Getting a free U.S number?

I have known this for a while now, but I realize many people do not know about this cool service from IPKall: You can get a free number in 4-5 washington state area codes for the U.S from IPKall. So what do you do with that? Ok, here is what we do - we take that number and tell IPKall to pass it as a SIP call to our system which then distributed it to a bunch of people like agents in a call center. Cool. Isn't it?

Tuesday, January 22, 2008

Ads Layout which makes sense

Here is a good "Hot Areas" diagram from Google which draws attention to common hot areas where ads placed on Blogs work. Take a look since this may be important to a few of you who want to blog for money!

Monday, January 21, 2008

LOTS = A LAMP for Voice 2.0?

If LAMP is the fundamental building block of Web 2.0, then what is the fundamental building block for Voice 2.0? I firmly believe that building block is LOTS (Linux+OpenSER+sip Tunks+STUN).

Most folks who are doing voice on the net are quite close to a LOTS based architecture and they probably don't realize the pure generality of how they arrived at it and how much time it took. I believe today getting LOTS to work is still a *LOT* harder than getting LAMP to work for an internet website. Just like there are a lot of ways apart from LAMP to build a website, but if you use LAMP, you can do it in half an hour and find hundreds of other people who will support you, there are a dozen different ways of doing voice on the internete. It just happens that it seems a lot easier to work with LOTS. So how does a LOTS based architecture work for voice and what are all the components involved? How simple is it to put it together? How much time does it take - half an hour? I will provide some more details on that in this blog...

A fail-safe architecture for Voice on the Internet

Innovation on the internet has extremely low barriers to entry. If you know LAMP very well, you have a basic start. Familiarity with a few extra tools for web site creation should be enough. You can have content or other applications on your site. However, if you are thinking of providing voice or any other real-time application intergrated on your site, you need to stack up on your mountaineering gear.

Voice can come in different forms. Let look at a few very different examples: Skype, Jajah, Jaxtr provide some basic coverage. Skype is the only one which offers PC to PC calling I believe and for that it requires you to download a special client. The client has lots of specialized codecs embedded inside it which utilize the PC Operating system as a phone and require the use of handsets and other devices. Jajah and Jaxtr on the other hand are more "hands-off" applications of voice. They don't use the PC for the voice and instead rely on existing handsets or mobile phones. The web or internet part comes when you use their widgets or web interfaces to configure or initiate the whole calling process.

On another end are applications which utilize the Adobe Media Server framework for voice processing using Adobe flash. Flash is quite unique since it utilizes the browser as a place to embed itself and do voice processing. There are some other services which use ActiveX instead of flash to do similar things.

Note that almost all services offer other forms of browser integration like browser based calling, monitoring etc.

There are a lot of pros and cons of all three methods when it comes to the functionality and utility they deliver and the cost they have to operate the network. The ultimate web based voice application really needs to utilize the browser and should be standards based like the rest of the internet is. And there are issues there as well...

Lets dive into some details.

Skype's infrastructure utilizes P2P. Comparable services from Google and Yahoo! utilize more network infrastructure, but I believe they have costs in the same ballpark as long as the are not routing voice through their own network (which I am guessing they don't do). Passing real-time voice through your own network can impose significant costs to manage and deliver the quality and can require a lot of staffing on your side. Its really easy to get a VoIP infrastructure up and running without having to actually route the real-time voice on your own and just hand it over to more capable and mature partners. We will get into that in this blog (maybe not in this post!).

Note that services like Jajah and Jaxtr can easily be erected by deploying VoIP servers like Asterisk. Since they actually bring the voice call off the internet, the costs of doing these hand-offs can be extremely high on a per minute basis (since that's how third parties called carriers will charge you for putting your internet call over to a mobile or landline phone). The only problem with any Asterisk based system is its high cost of ownership.

Solutions based on Adobe Media Servers are very high utility to the user, but extremely expensive to operate and maintain. The voice media gets routed through a centralized Adobe server in all cases (for no reason at all!) which becomes a huge scalability bottleneck. Adobe servers are designed for playing static media and my guess is Adobe never actually intended to use them for making normal run of the mill voice calls for which they become very inefficient. However flash is still the king of the land and possibly the only browser based voice solution which does not require any installation or software downloads! Its voice codec is proprietary (NellyMoser) as well. Good news is that its not illegal to reverse engineer Flash Server based on observing how Flash client works. Some people have done it and the result is the red5 Flash open source project.

Sunday, January 20, 2008

An interesting tool to measure ranks

There are several sites on the internet which will give you your Google rank, Yahoo! rank etc. Here is one site which combines them all and after a lot of testing I highly recommend it!


A good "Recent Comments" widget

This widget adds to your blog by creating a small window on comments someone else posted on your blog in an aggregate format. This really shows overall activity on your blog to your viewers. I think it is great and worth a try...

Friday, January 18, 2008

Blogger: Traffic building

If your blog or site is new, you will need to understand the mechanics and rules of engagement on the internet first. Especially if you are a firm believer like me in "no fee advertising"...

1) The average blogger on the internet may make a few pennies or upwards of a few thousand $$ from the website. There is nothing weird about it. You need to decide why you are building your website. If your site gets the traffic it warrants, fame will come anyway. You need to decide whether you want to money or not. If you do want it, then you can move on. O/w skip through the rest of this post...

2) The nature of the content will decide almost all factors which determine whatever money you make. The content will determine the audience, viewership and their tendency to click on ads, buy stuff etc. Content will also determine the "freshness" of the blog which eventually determines the frequency at which certain events happen. For example, if the content doesnt change fast enough or you dont update the blog too often, then you will be in a totally different money bucket than you should be. Also, the theme of the website will give you some idea of what bucket you should be in and how much time you should dedicate on your blog.

3) There is no chicken and egg problem with a blog. Content always has to come first and the website should look appeasing. Any form of advertising is focus of a later stage. So don't spend too many cycles looking at where you need to get that from

4) Getting indexed and your popularity high is important. Google determines your rank from ranks of other websites pointing to yours. So cross indexing with other established sites (getting your blog listed in directories, rating systems, forums etc) is very important.

5) Again, I cannot stress the importance of good content. Getting viewers in first time may happen by luck. But you need to make sure viewers are second time visitors or third time visitors etc. There are basically two kinds of users - casual browsers and power browsers. You need to see how you can get power browsers hooked onto your content. If you build viewership, everything else is easy...

Tuesday, January 8, 2008

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).