Update 2011-12-05: After a few weeks of testing since it was first reported that the bug has been fixed, I can finally say with confidence that it is indeed fixed. Special thanks goes to ProcessOne (the ejabberd guys) for getting the attention of Google through their blog post: Migrating from Google Apps to hosted.IM.
Getting support from some Google services like Google Apps and Google XMPP is close to impossibility. There are lot of reasons why a company like Google won’t be able to address your issues and as such I’ve given them time to do so. Weeks… weeks… of waiting but nothing.
So it is time to create a blog post about it and hopefully they will take notice and start addressing this “serious” bug with their Google Apps XMPP Chat. What is it? Even if you turn-off the GApps Chat feature, their server still retains your domain in their XMPP Chat network, because of it the server prevents you from connecting to the Google XMPP network.
Initially, I attached my domain name to an existing Google Apps account as “another domain” (read: not as alias). Turned-off the GApps Chat XMPP service and waited two weeks. Nothing.
Earlier this week, I detached my domain name from that old account and created a seperate, independent new account. First thing I did, I turned-off the GApps Chat XMPP service, hoping their servers will not have created it yet before it detects approval of my domain.
Unfortunately, nothing. Absolutely nothing changed. Clearly the problem lies with Google and not on my end, here’s a checklist:
- Turned-off the Google Apps Chat XMPP service
- Created an independent account for my domain
- Waited for more than 72 hours for DNS propagation
- Waited for more than 72 hours to give Google’s servers a chance to update itself
- Posted help at their Forum system
- Search for their “contact form” which is nowhere to be found
- Contacted @googleapps via Twitter but to no avail
- Contacted my XMPP host @hosted_im for help and they replied (see below)
Hosted.im’s Quick Reply to My Problem
Before anything, I want to thank and commend ProcessOne for their always quick reply to their customers, even for those like me who are using their Hosted.im service for free. With that said this is their explanation of what is happening.
We had the same problem you described with other customers. The causes were always the same: both Google Apps and hosted.IM have a local and remote routing. If a user from GApps sends packets to another on GApps, the route is located without asking any DNS on the Internet, because it is found locally.
The same happens with hosted.IM: it first looks if the domain is hosted locally, if not, it issues a query to the Internet to define the packet route. Of course, there is no “google.com” domain hosted by hosted.IM and your DNS records are correctly defined, so the only option is that Google is keeping your old domain on its “local routes”.
(note: my emphasis)
There you go. Straight from the people who have been in the XMPP/Jabber business far longer than Google, ProcessOne, the developers of the XMPP eJabberd server.
Why not use Google’s Chat XMPP?
Simple reason: They do not offer XMPP transports and I doubt they ever will. Yes there are public transports available but these are not as reliable as the transports offered by your host itself.
Secondly, ProcessOne, as I mentioned, the creator behind the highly popular and widely used XMPP eJabberd server, is an experienced and knowledgeable company in the XMPP business. I used to run eJabberd when I had my own server a few years back and it was very stable, always updated and implementing the latest in technology, I trust them that much.
ProcessOne’s hosted.im and talkr.im transports themselves are the first I always see that is updated. For example, when Windows Live Messenger [WLM] (f. Microsoft Network Messenger [MSN]) introduced multi-sign-on feature on their network, ProcessOne’s own WLM/MSN transport was the first to have it updated to support multi-sign-on. It was only earlier this year that I started seeing other transports that started supporting such feature.
That is a huge difference for me, as I need to be signed-on in WLM so when I leave my desk at work to eat lunch for example, I can still receive messages on my mobile phone. So I’m staying with hosted.im / talkr.im.
Now if only Google will fix the bug in their servers, then everything will work as expected. I am wondering if this is the kind of service Google Apps give to their “free” account holders? Then I commend more ProcessOne for not being bias between their “free” and “paid” customers.