Broken GTalk calls

Recently Google updated their XMPP servers to use standard Jingle for audio and video calls; see the “Google: The Future is Jingle” post on xmpp.org for some more details.
This would be good news for us, except that, by doing so, they broke calls in telepathy-gabble (so in Empathy, the N900 and MeeGo) in multiple ways.

Luckily GTalk developers were really cooperative and they agreed on fixing their servers and Will and Olivier already fixed Gabble too. The new version of Gabble (0.12.2 for the stable branch and 0.13.1 for the development one) should make calls work again on the desktop, MeeGo and on Harmattan (i.e. the N9 and N950) too.
For the N900 we don’t have any way to release updates, but Google will push an update to their servers (in the next week or two hopefully) with a N900-specific workaround.

Sadly video calls on the N900 will keep not working; the version of gst-dsp on the N900 doesn’t properly handle changes in the parameters of the stream :(.

Update: just to be clear, this affects only calls from GTalk to gabble. Calls in the other direction still work and calls between two devices of Gabble work too.

SOCKS5 in telepathy-gabble

In the Telepathy framework there is a mechanism, called tubes, for arbitrary data transfer with your IM contacts so you can play games, do collaborative editing, etc. Until now telepathy-gabble (the component that does XMPP) supported only in-band bytestreams, or IBB for short: all the data is sent inside the XMPP stream encoded in base64. The pro of IBB is that you don’t have to worry about NATs or listening on new ports but on the other hand it’s slow and could use too many resources on the server.

In the long term we want to use Jingle also for data transfer and not only for audio/video calls, but in the meantime we needed something better than IBB so Guillaume Desmottes and I started to implement SOCKS5 bytestreams support in telepathy-gabble. With SOCKS5 bytestreams you just send a list of IP addresses, both yours and the ones for possible intermediate proxies, when you want to start a bytestream. The other side tries to connect to the addresses it received and, when it succeeds connecting to one of them, sends the working address back to the initiator. This leads to three possible results: a direct connection, a connection through a proxy (still better than with IBB as you don’t use base64 and the proxy can be a separate machine from the XMPP server) or just fail if no connection is possible.

In XMPP you decide whether to use SOCKS5 or IBB using a negotiation method called stream initiation that allows the choice of a single bytestream method, if it fails you cannot fallback to the slow but safe IBB. Just failing is not acceptable as the applications running fine with just IBB could stop working for somebody, so we decided to extend stream initiation. With our simple extension we can keep compatibility but also be able to try SOCKS5 and, in case of failure, switch to IBB.

With fallback we were able to finally merge the SOCKS5 branch, so now the next two steps are adding support for intermediate proxies (for now we do only direct connections), and add file transfer using the same bytestream mechanisms. Hope to have good news about this soon :)