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

October 9, 2009

Telepathic Reverberations

Filed under: collabora, facebook — Tags: , , , , , , , , , , , , — alsuren @ 4:05 pm

If you have ever had a call with someone where something wasn’t working, and you’ve wondered whether it was your computer or your contact’s that was broken, I have the answer for you. It takes the form of a user that you can add to your contact list, and call to test your setup. If your contact does the same, then it should be very simple to narrow down where the problem lies.

If you are using XMPP (or Google Talk or Jabber if you hate acronyms), then gabble.echo@test.collabora.co.uk is the user you want. You can add it to your contact list and it will add you back. You can send it a message and it will send it back to you. If you call it, it will send your audio/video straight back to you. It might be a good idea to put headphones in before you do this though, to avoid feedback loops.

The bot is written in Python, and source can be found at http://git.collabora.co.uk/?p=user/alsuren/telepathy-ashes.git. It uses telepathy-gabble to connect to the server and Farsight for the streaming. This means that it has all of the same capabilities and limitations as Empathy on Linux. This makes it good for testing interoperability. If you try it out and have problems, feel free to leave a comment here, or join us in #telepathy on freenode and I (alsuren) will be happy to help you out.

A few things to note if you are having problems:

Users of the Google Mail interface are currently limited to audio only, because Google only uses the h.264 video codec, which cannot legally be distributed with Empathy. If enough people report this problem to them, then maybe they will include Theora as a fallback. There are ways that I could work around this problem for the echo service, but then it wouldn’t be a very good tool for testing whether you’re capable of calling Empathy users ;-).

If you are using Ubuntu Jaunty and pulseaudio, you may notice high CPU usage and a really long lag in your audio. This is a known issue and is fixed in the pulseaudio that ships with Karmic.

Watch this space for an MSN echo service (since telepathy-butterfly now supports voice/video for MSN). Also, if you are interested in writing multi-protocol chat bots, I’m planning to re-factor the code and distribute it as part of telepathy-python. If you want a say in the new API, speak now.

Blog at WordPress.com.