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

My original email had more details:

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.

In light of interoperability, could you please address the Google rationale for going with XMPP rather then SIP, as there is considerable support for SIP in existence, e.g. IMS on 4G networks, VoIP providers, PSTN gateways, Skype Connect, etc.?

I'm one of the authors of the XEP and was part of the Google Talk team back in the day. I haven't been working on it in quite a while so I really don't speak for the current team.

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.

I'm curious as to why the windows Google Talk product has stalled - I always thought Google planned to improve it to make it a worthy competitor to Skype, but it seems to have stalled.

And now this news indicates that it appears to be AbandonWare. Which is a real pity.

I guess for Google the browser is the platform. No need to make dedicated Windows/Linux/OSX programs.

I agree. They likely still have intentions of making it a Skype competitor, but it will be in the browser rather than on the desktop.

The latest inclusion of voice and video protocols in Chrome agrees with you.

Why is the Google Talk application for Windows considered legacy? Are you hoping to shift them to WebRTC in Chrome?

Applications are open for YC Summer 2019

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