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.

17 thoughts on “Broken GTalk calls

  1. I know, but it’s not the same. Normal non-geek users would never benefit from it and maybe they use calls on the N900.

    Convincing Google to implement a N900-specific workaround makes it very easy to make calls work again for everybody.

    Like

  2. No web-based vidoe chat? Is that what this means? I never used it much, but when I did it was awesome. This is a bummer.

    Like

  3. I already implemented a work-around on the Google servers for N900 video calls, which will roll out in a week or so. And the Telepathy team already implemented a work around for other video calls, so this should be resolved pretty soon.

    I don’t know about the in-stream parameter changes, though. That might still be an issue.

    Like

  4. @Peter:
    Thanks for the fixes, please let us know when the change is deployed so we can test it.

    With parameters changes I meant resolution changes. I think gst-dsp doesn’t handle when resolution changes, so after a few seconds we show garbage on screen.
    I think somebody could have written patches for the upstream version, but I’m not sure.

    @Tanner:
    Google did their part 🙂

    @Lance:
    That’s what I meant. We will see if we can fix the problem somehow.

    Like

  5. Google moves to standard XMPP jingle. So how does that affect video calls on the N900 if I used standard XMPP before too?

    I don’t use google and don’t have any problem when the partner is logged in to Google as a standard XMPP account.

    This can’t be broken now can it!?

    Because then the news would just mean, that (at least) audio calls from and to outside of google will work nicely.

    Like

  6. @Martin:
    There were 3 problems AFAIK:
    1. GTalk omitted a required attribute in the stream (so a bug in their standard compliance).
    2. The name of the streams were different from what we expected when using Google’s P2P transport instead of the standard ICE or raw UDP.
    3. One of our GStreamer components doesn’t like resolution changes.

    And the solutions are:
    1. Google fixed the bug, but it’s not deployed yet.
    2. Here is where the Google workaround happens: they will use the names we need when talking with a N900. Newer versions of Gabble will cope fine with both old and new names.
    3. This is the reason why video doesn’t work on the N900.

    Like

  7. How does this affect Diablo’s (ie N8x0) telepathy-gabble? Does Google’s N900-specific workaround cover this too?

    If not, we also have a community SSU so pointers to patches to be back-ported welcome (the URL in the bug report just gives “Invalid branch: legabb”)

    Like

  8. While the workaround is nice, this still seems to be broken. I cannot call from the n900 to a gtalk contact but can from gmail with the audio/video plugin for firefox. Also, in Fedora 15 up to date this is also broken (telepathy-gabble 0.12.2).
    In the n900 case, it would be nice to have the update in the cssu which is the only channel of updates as of today

    Like

  9. In reply to https://blog.barisione.org/2010-06/handling-phone-numbers/

    >> can be written as 02073212233, +44 (0)20 7321 2233, 0044 207 321 2233 <> Not quite sure why +XX (0) YYYYZZZZZZ is a “stupid” format. Surely it emphasises the rules for dialling UK numbers (drop the leading 0) <> the other UK format which is still seen all over the place: (0YYYY) ZZZZZZ <<

    This format means the area code can be omitted when calling from another number within the same area code. This is the recommnded ITU-T E.123 national format and widely used in a huge number of countries.

    Like

  10. In reply to https://blog.barisione.org/2010-06/handling-phone-numbers/

    ** can be written as 02073212233, +44 (0)20 7321 2233, 0044 207 321 2233 **

    +44 (0)20 7321 2233 — No! The (0) is NOT valid. The international format must include only the digits that are dialled from abroad.

    0044 207 321 2233 — No! The 00 access code is specific to only a few countries. The US and Canada uses 011. Australia uses 0011. Use the + symbol instead.

    Use (020) 7321 2233 for national format and +44 20 7321 2233 for international format.

    When storing a phone number you should strip the trunk code and all punctuation and spaces, and add the country code at the start.

    ** Not quite sure why +XX (0) YYYYZZZZZZ is a “stupid” format. Surely it emphasises the rules for dialling UK numbers (drop the leading 0) **

    Digits in parentheses are dialled from outside the local calling area. So, +44 (0) 20 7234 1234 means dial +44 020 7234 1234 from abroad. The call will fail. See the ITU-T E.123 standard.

    E.123 specifies “do not use parentheses in the international format” and “in the international format, include only the digits that must be dialled from abroad”.

    ** the other UK format which is still seen all over the place: (0YYYY) ZZZZZZ **

    This format means the area code can be omitted when calling from another number within the same area code. This is the recommnded ITU-T E.123 national format and widely used in a huge number of countries.

    Like

Comments are closed.