Alsuren

April 13, 2010

Gateway to the West

Filed under: collabora — Tags: , , , , , , , , , , — alsuren @ 12:16 pm

It has occurred to me that I should probably write a blog about the project that I’ve been working on recently. We have named it Fargo. Its job is to act as a gateway between the XMPP and SIP networks. The aim is to let you make voice calls from your XMPP client to your SIP contacts without needing to run a SIP-capable client on your local machine. It also allows you to receive incoming calls from SIP contacts from your XMPP client.

The program runs as a standard gateway, so if Fargo were running on sip.fargo.im, then you would tell the details of your SIP account to sip.fargo.im. Once registered, whenever you log into your XMPP account, the gateway will sign you into your SIP account so that you can send/receive calls. For example, if I were to call you, you would see an incoming call from alsuren%opensips.org@sip.fargo.im, and it would behave exactly like a call from one of your XMPP contacts. If you wanted to call me then you would just add “alsuren%opensips.org@sip.fargo.im” to your XMPP contacts, and then click the call button.

Now, if you wanted to make a one-off call to me, but you didn’t want to have to add me to to your contact list and then remove me again afterwards, Empathy/Gabble already lets you do this (thanks to an extension that we wrote). Just open up the “New Call” dialog, and type in alsuren%opensips.org@sip.fargo.im.

So what goes on behind the scenes? When you make a call, your XMPP client opens up a pair of ports in your router (most likely using STUN or UPnP). It then sends your public IP address and port numbers to alsuren%opensips.org@sip.fargo.im along with a list of which codecs it supports (this is pretty much the same as what it would do if you were calling someone who is using Google’s official client, or the echo@test.collabora.co.uk echo service). Fargo then reads this information and sends it over dbus to telepathy-sofiasip, which forwards it on to me via SIP. My SIP client then sends back some IP/port pairs, and a list of supported codecs (as if it were talking to an X-Lite user, or the echo@iptel.org echo service).

Once both sides are aware of each other’s addresses and codecs, they can start sending media directly to each other using theReal-time Transport Protocol. The gateway is only involved in setting up and tearing down the call, so I can keep you on the phone chatting about the meaning of life for an hour, and the gateway will only be woken up to say “bye” when one of us hangs up. This means that the cost of making an hour long call through the gateway is remarkably small.

Fargo has been extensively tested with telepathy-gabble, both on the n900 and under Empathy. There are some corner cases which don’t always work as well as they could (eg NAT boxes which don’t support hairpin routing, which only work if the SIP server provides a media relay) because many SIP implementations (including telepathy-sofiasip) don’t support ICE candidate negotiation. Also, if there are no compatible codecs between the XMPP client and the SIP client then the call will fail. All other cases which we tested seem to work fine though.

In addition, have some test scripts which demonstrate a Fargo + ejabberd combination comfortably sustaining a rate of two new logins and two new calls per second on a single-core VM. Calls were limited to 10 seconds each in our tests, but since Fargo is only involved in setup and teardown, the length of calls shouldn’t be very important anyway. Fargo also plays nicely with ejabberd’s “bare_source” load balancing method, so if your gateway becomes too popular, you can just add a few servers and cluster.

Currently, Fargo doesn’t relay IMs, and only supports negotiating raw-udp transports, so it’s probably best used in conjunction with a SIP server that includes a media relay. It also relies on your XMPP server to store your roster rather than trying to store one itself. The program is written in Python (using twisted) and utilises telepathy-sofiasip for the SIP side of things (this could in theory be replaced with another connection manager to handle other protocols). Don’t hesitate to get in touch if you want to know more, or get involved.

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: