Tag Archives: xmpp

Spurious nonresponsive XMPP resource "Messaging XXXXXXX" under Google Talk/Hangouts

2 Replies

This information is prepared based on my understanding of XMPP systems, on the fact that Hangouts is not XMPP, and on the threads I linked to. I’ve sorted out the user-originating speculation that seems most useful. Hopefully I’ve given enough search-friendly keywords so someone saves time I’ve lost figuring out what’s the culprit.

By looking at XMPP resources (a fancy name for ‘connection identifiers’) using the most awesome XMPP client out there, Psi, and then digging around old Google Groups posts from late April and May 2013, all the way across the summer, I’ve identified the culprit of why my Google Talk account was appearing as “Away”.

If there is a resource connected to your gmail.com account called something similar to “MessagingXXXXXXX”, that’s the ‘new’ Google Hangouts (the one that doesn’t play nicely with XMPP). And quite possibly it’s the Android application for Google Hangouts.

That was hard to figure out because, among other things, the Hangouts service refuses to talk to my external non-Google XMPP accounts. So I was completely flabbergasted that I did not get a response to handcrafted request — not even an error — when, retrospectively obviously, that was Hangouts discriminating against my federated XMPP server. Oh well.

So yes, Google Hangouts stays connected even if the device you’ve logged into from is not. Apparently this is a connection that’s created internally, inside Google, from their Hangouts service to their Talk service — from the new IM tech to the XMPP tech. And if you try to trick the XMPP service to sign out Hangouts (for example, by creating a new connection with identical XMPP resource), the Hangouts will happily log back into XMPP in your name and present you as ‘away’. And messages intended to be stored offline will end up in Hangouts, never to be seen again unless you use Hangouts on other systems.

In threads I linked to, users claim clearing and reinstalling Hangouts might mean getting a new static per-device XMPP identifier. Others claim that clearing data for various subsystems (Google Play Services, Google Hangouts, etc), revoking two-factor codes, OAuth tokens and single-application-passwords might help.

Aside from turning on the device and logging out, the solution seems to be: wait for 30 days until the connection times out. So, do NOT wipe a device clean unless you’re ready to wait for 30 days to be signed off in front of your friends. Do NOT give the device out before you explicitly sign out of Hangouts (don’t just ‘restore’ it and wipe it).

Or it may just be easier to log out.

Which is what I did: I turned on the laptop, I fired up the VirtualBox machine where AndroVM was installed, and I signed out. (Imagine that: accidentally firing up Hangouts, force-shutting down the VM and then spending several night-time hours scratching your head and feeling miserable in all sorts of ways because technology is disobeying again. Ah.)

Google killing XMPP federation with their Google Hangouts?

Leave a reply

According to the Ars Technica article on Hangouts, we can expect Google to drop support for XMPP federation.

We should apparently be happy that Google is not dropping XMPP client-to-server connections.

The instant messaging space is apparently turning into a duopoly of Microsoft’s Skype and Google’s Hangouts with everyone else shoved to the sidelines. I’m not counting Facebook Chat as a serious alternative, and iMessage is not intended as an instant messaging service.

I hopefully don’t have to point out how much this frustrates and annoys me. Google is turning out to be worse than Microsoft ever was: they’re actively backpedaling on their past promises. They’re backstabbing the “open”. Scratch that — they’re throwing a stake through open’s heart, ripping it in pieces, then gorging on its still beating remains. Instead of reading RSS through Reader, we’re supposed to read custom posts via the closed and locked down Google+. They are killing iGoogle. They’re basically killing the open web and open Internet, while at the same time paying lip service to open.

Android, which is just-enough-Linux-but-not-really. Rich authorship markup, which requires two-way linking to Google+ instead of using the semantic web techniques.

I’ll keep on looking for ways to back out of Google ecosystem as much as possible. What’s next — Gmail that can’t send emails out?

libjingle with your own signaling or your own XMPP library

Leave a reply

Just sharing the link here, since I was googling for far too long to dig it out.

How To Use STUN In Applications

It’s surprising this is found as a part of the manual for Maemo, the fantastic OS that moved in the right direction, but was practically abandoned by Nokia.

NOTE: This is apparently a guide for the outdated libjingle 0.3.0. I can’t find any guide for the new version of libjingle.

Toying with iChat's AV over XMPP, part one

1 Reply

I added fake caps&features to Z-XMPP to simulate iChat’s AV support. List of the caps&features that I added:

this.features.push("apple:profile:bundle-transfer");
this.features.push("apple:profile:efh-transfer");
this.features.push("apple:profile:transfer-extensions:rsrcfork");
this.features.push("http://www.apple.com/xmpp/message-attachments");
this.featuresExt["ice"] = ["apple:iq:vc:ice"];
this.featuresExt["recauth"] = ["apple:iq:vc:recauth"];
this.featuresExt["rdserver"] = ["apple:iq:rd:server"];
this.featuresExt["maudio"] = ["apple:iq:vc:multiaudio"];
this.featuresExt["audio"] = ["apple:iq:vc:audio"];
this.featuresExt["rdclient"] = ["apple:iq:rd:client"];
this.featuresExt["mvideo"] = ["apple:iq:vc:multivideo"];
this.featuresExt["auxvideo"] = ["apple:iq:vc:auxvideo"];
this.featuresExt["rdmuxing"] = ["apple:iq:rd:muxing"];
this.featuresExt["avcap"] = ["apple:iq:vc:capable"];
this.featuresExt["avavail"] = ["apple:iq:vc:available"];
this.featuresExt["video"] = ["apple:iq:vc:video"];

And here’s what I get when I press call:
Continue reading →

Which XMPP technologies to use?

1 Reply

I’ve been writing a piece of software in order to perform a major upgrade of ZATEMAS, a specialized web app suite I’m a co-author on. Since there is a small community of users on it that might interact better if they had an opportunity to do so, I came to an idea to provide them with an instant messaging client built right into the browser, similar to Facebook Chat, Meebo Bar and Gmail Chat. I’ve picked XMPP as the protocol; better known as Jabber, this is the same protocol Google Talk uses.

Examining various options took a while. I’ve looked at Meebo Bar, and concluded that it doesn’t fit my use case, since I want users to be automatically logged in on a local XMPP server.

I’ve examined several clients. In the process, I’ve learned a bit about BOSH (the standardized method for using XMPP over HTTP), about Apache’s mod_redirect, and a bit about rules for doing cross-domain xmlHttpRequests in Javascript.

The only serious contender for the throne of the best open easily deployable web-based XMPP client is JWChat. This is a venerable old client which creates a popup and behaves much like a typical desktop IM client. This means it was unsuitable; there is no easy way to embed it in a page, yet preserve its state upon page switching.

This is actually the biggest problem I came upon. There seems to be no XMPP client nor library written in Javascript that can trivially handle page switching (which means destroying entire Javascript context); you cannot trivially serialize their state. Which is why I’m proud to announce a custom-made client, Z-XMPP. It’s already available for preview on https://bitbucket.org/ivucica/zxmpp, and will soon be available for preview on ZATEMAS. Its license is currently a custom one, hand-written, and most definitely not satisfying any open source/free software definition. That will change soon, as soon as I pick the right license.

That brings us to the other part of the XMPP stack. Which server to pick? Which BOSH connection manager to pick?

There are, really, two contestants in my arena when it comes to a server. First one is a veteran of XMPP, ejabberd. ejabberd is written in Erlang, and is massively scalable. It’s trivial to install and configure in Debian, and it supports a lot of cool features out of the box. It supports something called “shared rosters”, which basically means you can create groups in people’s contact lists that you, as the admin, can enforce to contain whomever you want. You can force people, for example, to see everyone else working in the company. This is a critical feature for ZATEMAS, just as is so-called “external authentication”. What I’m missing here is: external auth does not support fetching any attribute apart from basic operations with passwords (is it correct? please change it!), and vCard cannot be created from command line, only updated. This means I cannot trivially set people’s real names during an update run.

Obviously, ejabberd has flaws, and I cannot easily update it since Erlang is a language fundamentally different from any other I worked with.

So the second contender is a server I discovered only tonight. It’s Prosody, an extremely lightweight XMPP server written in Lua by a bunch of very friendly folks. I really like the attitude and personal approach the principal author of Prosody has, but that’s not all. Server’s source code looks extremely well organized, the server is quite featureful, and most importantly, it’s written in a language that mere mortals can understand. I’m not a big fan of Lua, but I can read it, and I can update it, especially when it’s so well written as Prosody seems to be.

I’m currently not very familiar with Prosody, but the fact that I managed to set it up very quickly and that it starts up momentarily… well, I think that we can hack a ZATEMAS-based external authentication module into it! Also, I think I might be able to better add my own debug functions, to easily see what I did wrong while developing my client.

Both ejabberd and Prosody come with a BOSH connection manager (the thing that translates HTTP requests into a continuous XMPP stream; a continuous XMPP TCP stream is something you cannot achieve from the web). So why another one?

Well, perhaps you want to log into Google Talk!

Yep, folks, that’s what PunJab allows: have your BOSH-based client log into any XMPP server. I must say I like PunJab; it’s written in Python. Despite that, its internals seem a bit less clear than Prosody’s, yet still manageable. PunJab does its job and does it extremely well.

So there you have it. Perhaps we’ll soon have an opportunity to talk about how to install Z-XMPP instead of just talking about why and how I’m working on an IM service 🙂

Until next time!

Making iPhone calls to Google Talk/XMPP Jingle/XEP-0166 users

Leave a reply

If you are looking for an iPhone application to make calls to Google Talk users (and all others who use Jingle extension for XMPP, or XEP-0166), check out Talkonaut. App is currently free on the app store, but I wouldn’t be surprised if that changed; in fact, I’d love it if the developers made extra money by doing so. I’d give back the free version and give a few bucks for the paid version. It’s worth it.

It even contains Jingle-to-SIP conversion; that is, you can use the XMPP connection to establish a SIP connection. SIP is a “more traditional” VOIP protocol, while Jingle is what Google Talk uses.

They also have partnered with many SIP-to-PSTN providers (where PSTN is regular telephony, such as landlines and cellphone), enabling you to make GTalk-to-phone calls for apparently very low prices. At the moment I have no need for such a service, but it might be a good way to pay back for the free app. I’m not getting paid to say all this — as a developer, I can appreciate the numerous hours that went into this project.

[This is syndicated content. Read my blog at http://blog.vucica.net/ – please also leave comments there ]