Hacker News new | comments | ask | show | jobs | submit login

Well, I am not sure why Google went with XMPP when the rest of the telecom and networking industry is gravitating towards IETF SIP as signaling protocol. There are so may overlaps in both of them in the sense that they use the same components such as SDP and ICE. Can anyone from Google or otherwise throw some more light on

- 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?




I guess SIP has weak support for Instant Messaging, which was the primary use case for Google Talk before video chat came along.

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."

[1] http://xmpp.org/about-xmpp/technology-overview/jingle/


If this had happened for email, we would have had to deal with a myriad of different clients, servers and 'interworking' gateways.

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.


If this had happened for email, we would have had to deal with a myriad of different clients, servers and 'interworking' gateways.

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.


I hadn't looked at it from this perspective, thank you for the enlightenment. I'm just too impatient.

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.


I'm far too impatient as well, I suppose. It seems to me (from the armchair where I quarterback) that IM interoperability isn't happening not because companies prefer the advantages of their chosen protocol, but because they simply want to "be the platform." I can't imagine a better advantage than actually being able to talk with any of my friends on any other client.

If email hasn't proven a standard can be beneficial to everyone, I don't know what would.


Yet another thing I find amusing from Google is that the latest Android SDK has dedicated APIs for multimedia calls using SIP - http://developer.android.com/guide/topics/network/sip.html


XMPP is much more extensible than SIP. Presence, messaging, and IM work much better in XMPP. There are extensions for archiving messages, return receipts, etc. There are extensions for file transfer.

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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: