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

February 11, 2010

FOSDEM

Filed under: collabora, facebook — Tags: , , , , , , — alsuren @ 10:03 pm

I went to FOSDEM over the weekend in Brussels. My mum texted me when I arrived, with a thinly veiled request for me to bring back some Belgian Chocolates. Annoyingly, my touristing extended only as far as an hour wandering down to the Palace of Justice and back, and the only chocolate shops I passed seemed to be geared up for Valentine’s Day so I gave them a miss.

Getting back in touch with what’s going on in KDE-land was good, and finally pushed me to switch back from GNOME to KDE. I’m currently still running gnome-panel because I use a gnome-panel applet for reporting how many hours I’ve been working on different things.

I wrote down my conclusions from the conference for other people from Collabora to read, but I thought I might as well share them here too:

  • KMail in KDE 4.5 is finally going to be worth using, but that’s 6 months away.
  • RDF/SPARQL is actually kinda nice, but writing raw queries without any tools is a trap.
    • The KDE guys haven’t really been talking to the Tracker guys, so while their frameworks are theoretically compatible (using the same schemas) they haven’t made very much effort to share things like their databases or tools for writing metadata back to MP3/image tags (a feature which KDE currently lacks).
  • CouchDB is secretly mostly hype and while it’s possible to use from any language without any tools, it’s got too many sharp edges to be very useful when you start trying to use it for non-trivial applications (a bit like dbus-python in that sense?).
  • SIP-Communicator is actually kinda kickass. We really need to improve our SIP stack.
  • I hear Daniel Stone’s talk was really good but it was full by the time I got there. He says that it was recorded, and that he would post to Planet Collabora when they put it online.
  • I’m not going to go into too much detail about XMPP (A few of the other guys on Planet Collabora went to the associated XMPP summit, so I’ll leave it to them to post details about that.). One thing that is worth commenting on is that there is actually surprisingly little impedance mismatch between XMPP and many web2/AJAX technologies. Watch this space for a complete JavaScript port of Prosody and a massive flood of JavaScript-based server components.

September 11, 2009

Telepathic Ramblings

Filed under: collabora — Tags: , , , , , , — alsuren @ 11:09 am

Okay, so I should probably inform people of what I’ve been working on recently.

A few of you might remember my cupsandstring Telepathy (IM) client from a few years back. Well I’ve recently revisited that, because someone was asking on IRC, so if you want to read the source, it won’t make you want to puke quite so much these days.

I made a skeleton Skype connection manager way back when too. (Don’t get excited: it’s based on the public Skype API provided by their UI, and only connects to your currently configured account). It never really got off the ground though. A few weeks back (go check the bzr log if you care) I picked it up again. I got it to the point where I could use it for text chat, and have been using it to replace the ugly bits of the Skype UI. It’s currently made of gaff and verbose, and has to be run in a konsole because I make it drop into a debugger whenever anything unexpected happens. This will continue to be the case until I have a decent testing framework for it.

Guess what my next project is: A testing framework! The spec has been discussed on the Telepathy mailing list. I’m trying to make it as generic as possible, so that I can try it on a well-tested connection manager (gabble) and then move on to butterfly, and then spyke when I’m feeling brave. Since I don’t want it to depend on the protocol too much, I’ve designed it around the idea of an echo bot (which can run remotely or locally) and a set of test scripts, which mostly just poke the echo service (like Skype’s echo123), and expect a sane reply. The bonus of this is that you can test interoperability between haze and gabble/butterfly/idle (and Kopete’s protocol code if it ever becomes telepathic) for free.

Due to all of my noise in Telepathy-related communication channels, daf suggested that I apply for a job at Collabora. I did so, and officially started on Wed. That was a fun day. I arrived in the office, and daf and wjt greet me with “Hey. We’ve thought what we want you to work on first: an echo service”. To which, I could only respond “What? Like this one?”, flashing my eee at them. Turns out their priority is something that works with gabble, and handles media streams (initially just using gstreamer’s audiotestsrc but eventually actually echoing stuff, and then doing things like disabling codecs). Hopefully I will get something workable by the time daf moves to America, but I would like to write a few automated tests for the text functionality before I start adding lots of crazy features.

Also, I’ve had to re-wrap most of the functionality from python’s telepathy.client library, because it contains too much magic, and is impossible to inherit from. I’ve tried to do it in a way that could feasibly be auto-generated from the spec, so that’s a project for when I’m done with my echo service. Maybe I’ll even push it into telepathy.client. It’s great to be working on Open Source software again. 🙂

Blog at WordPress.com.