Google switches GTalk's VOIP protocol to Jingle
xmpp.org
xmpp.org
We are pleased to announce that we have launched support for Jingle XEP-166 and XEP-167 for Google Talk calls to and from Gmail, iGoogle, and Orkut. We have also added the same level of support to libjingle (http://code.google.com/p/libjingle), which is used by many native clients. From this point on, it will be our primary signalling protocol, and the old protocol will only remain for backwards compatibility. We also plan to soon update Google Talk on Android to speak Jingle, but we do not plan on updating the Google Talk Windows application.
We suggest all clients that interop with Google Talk to switch to using Jingle rather than the old protocol. We will remain backwards compatible with legacy clients by continuing to speak the old protocol as well. If you wish to continue working with legacy clients, such as the Google Talk application for Windows, you may also wish to continue speaking the old protocol. But the future is Jingle, and the old protocol will eventually go away.
Finally, we are still working on implementing XEP-176 (ICE-UDP). In the meantime, you'll need to use our draft-06 version of ICE, which is implemented both in libjingle and in libnice, two open source libraries.
I hope that this will be a support to the Jingle community and futher our efforts to have open standards for voice and video communication.
First off, I'm super proud of these guys finishing off this work. It was a long time coming.
As for why we chose XMPP over SIP: The team had made the choice to base the core IM product on XMPP before I joined. That decision was based on the ease of implementation and interoperability. XMPP for IM is much simpler than SIP/SIMPLE. The easiest answer here is that it was the most logical fit to the product we had built at the time.
My personal opinion of SIP is based on a 6 year old snapshot of the technology. Things have undoubtedly changed in the meantime. Based on that snapshot, I wasn't a fan at the time.
- It is an amazingly complex and confusing technology. It is worth noting that SIP is the longest IETF RFC out there. Meanwhile, the core XMPP spec is easy to understand and implement. It is also an IETF standard. Extensions are well modularized and documented.
- The security is hacked on after the fact and, at the time, was unevenly implemented. In basic SIP, one unauthenticated UDP packet makes a phone ring. XMPP security is based on TLS and DNS and is a required part of the core.
- Federation was a patchy mess and showed SIP's telecom roots. You pretty much had to get the lawyers involved to do anything. Federation in XMPP is a DNS SRV lookup.
The world has moved forward since then so hopefully this provides some context for the decision at the time.
And now this news indicates that it appears to be AbandonWare. Which is a real pity.
This is great news. Google has been one of the driving forces behind Jingle, but as they were implementing it far in advance of being standardised, the drafts/standards have since changed. Other implementations have to maintain support for several close but not quite the same dialects. Google updating their software will make interop much easier.
I've been somewhat critical of Google's attempts in this direction (http://senko.net/en/gmail-videochat-the-good-the-bad-and-the...), and I'm very glad to see I was wrong :)
- Why Google prefers XMPP over SIP - In what areas XMPP is better that SIP
I am not stating that one is better than the other, but would like to understand the core differences and advantages.
Also with Google moving on with XMPP and other major vendors converging on SIP, where do you see the inter-operability issue heading towards?
On the other hand the Jingle spec [1] contains many references to SIP:
"Furthermore, Jingle is not intended to supplant or replace existing Internet technologies based on the Session Initiation Protocol (SIP; RFC 3261). Because dual-stack XMPP+SIP clients are difficult to build, Jingle was designed as a pure XMPP signalling protocol. However, Jingle is at the same time designed to interwork with SIP so that the millions of deployed XMPP clients can be added onto existing Voice over Internet Protocol (VoIP) networks, rather than limiting XMPP users to a separate and distinct network."
I really don't understand why the likes of Google, Apple, Microsoft and the telcos can't agree on a standard. Guess business reasons are behind this. After all, walled gardens are great if you are the incumbent, it's how Skype got to be so valued.
Maybe the FCC should step in and take this on.
That was the networking prior to the wide adoption of IP and SMTP. There were DECnet mail clients, and clients for various other networking protocols, and users needed to know explicit bang-path routes and gateways.
Seeing this churn and this fragmentation is unpleasant, but it also means that you can see rapid advances and new features and different approaches. Once the market matures and the churn settles down, we'll see more of this sort out toward protocol consolidation.
In general, areas with high churn are some of the most interesting parts of the whole computer business. They're among the least mature, and often with the most innovations.
What irks me is that the IETF keeps banging away at protocols to solve issues like the transition from PSTN to IP (e.g. ENUM), or IM interoperability, but then nobody really implements them, or as in the case of ENUM, the incumbent telcos, at least in the USA, sit on it forever. Or some startup cooks up their own solution and kills it, like Skype.
I'm all for interoperability sorting itself out, but it does not seem to happen in the messaging/real time communications space. We still have SMS, a gazillion IM protocols, and many isolated islands of video calling. Skype, Qik, MSN, Yahoo, FaceTime, Google, I could go on. On top of that is the confounding issue of different audio and video codecs and whatever patent issues surround them. A formidable gordian knot, of which it will be interesting to see how it will be cut - if ever.
If email hasn't proven a standard can be beneficial to everyone, I don't know what would.
There are extensions for vCards. There are extensions for PubSub.
XMPP works over HTTP using BOSH. It can also work over SOCKS.
Apache/Google Wave uses XMPP for federation. It is just flat out more extensible and featureful. Just like the acronym stands for: Extensible Messaging and Presence. It does a whole lot more than just IM or just VoIP.
http://xmpp.org/xmpp-protocols/xmpp-extensions/ http://en.wikipedia.org/wiki/Apache_Wave#Federation_Protocol
I just tried the combination of web-based Gmail <-> iChat and the web client can see that the iChat client has a camera and I can initiate a call but iChat never shows an incoming one.
If I go iChat<->iChat over Google's XMPP server I can make a call. Does iChat speak yet another incompatible video call extension if it used with an XMPP network?
Adium can't do AV either.... Can anyone recommend a OS X client? Video chat is currently the last thing that stops me from uninstalling Flash.
iChat in Lion will features service plugins.
Personally I think the only native client they are interested in anymore is Gmail in Chrome...
You should also probably realize the point of using XMPP is that it's an open standard, and anyone is allowed to make their own implementation; contrast with the uneasy interoperability of, say, MSN Messenger with Pidgin. Now they're using Jingle, do you need a first-party client? You don't expect first-party SSH clients from your hosting provider, or first-party email clients from your ISP. And god knows there are enough IM/VoIP clients out there, so I'm all for thinning the herd...
Well there is always http://talkgadget.google.com/talkgadget/client
Opening a webbrowser window with that and you are set. No Gmail UI, and you get video chat.
Some of us choose native program over Web app for a reason and I believe there are many like me would stick with it.
I would love to talk to a college student in Greece about the local economic sentiment over VoIP.