Category: Standards

May 23

Did Google REALLY Kill Off All XMPP/Jabber Support In Google+ Hangouts? It Still Seems To Partially Work

Google hangoutsDid Google really kill off all of their support for XMPP (Jabber) in Google+ Hangouts? Or is it still there in a reduced form? Will they be bringing back more support? What is really going on here?

In my excitement yesterday about Google Voice now being integrated with Google+ Hangouts, I missed a huge negative side of the new Hangouts change that is being widely reported: the removal of support for the XMPP (Jabber) protocol and interoperability with third-party clients.

But yet a few moments ago I did have a chat from an external XMPP client (Apple's "Messages" app) with Randy Resnick who received the message in a Google+ Hangout. I opened up a Google+ window in my browser and I could see the exchange happening there as well. Here's a side-by-side shot of the exchange in both clients:

Googleplusxmppinterop 450

So what is going on here?

Reports Of Google Removing XMPP

This issue has been widely reported in many of the tech blogs and sites. Matt Landis covered this issue very well in his post: Hangouts Won’t Hangout With Other Messaging Vendors: Google’s New Unified Messaging Drops Open XMPP/Jabber Interop which then generated long threads on Reddit and Slashdot.

The Verge in their lengthy story about Google+ Hangoutscontains this statement from Google's Nikhyl Singhal:

Talk, for example, was built to help enterprise users communicate better, Singhal says. "The notion of creating something that’s social and that’s always available wasn’t the same charter as we set out with when we created Talk." With Hangouts, Singhal says Google had to make the difficult decision to drop the very "open" XMPP standard that it helped pioneer.

The "Google Talk for Developers" pagealso very clearly states this:

Note: We announced a new communications product, Hangouts, in May 2013. Hangouts will replace Google Talk and does not support XMPP.

A Google+ post by Nikhyl Singhal has generated a large amount of comments (not solely about XMPP) and a post from Google's Ben Eidelson about how Google Messenger will be changed by Hangouts has also received many comments.

There was also a Hacker News thread about the news out of Google AppEngine that apps hosted there would not be able to communicate users of the new Hangouts app via XMPP - and providing a couple of workarounds.

A couple of Google+ threads from Matt Mastracci and Jan Wildeboer are also worth reading as is this note from Daniel Pentecost about how he has lost interop with his clients / customers.

But Is XMPP Support Still There?

I was a bit puzzled, though, by a couple of comments from Google's Ben Eidelson down in one of the G+ threads:

Ben Eidelson
+Thomas Heinen Thanks for your report of the issue. Hangouts supports basic interop with XMPP, so you can-for the time being-continue to use 3rd party clients. It does not work the same way as Talk, and so I believe the issue you're having with the XMPP bridge will not resolve in Hangouts.
Jason Summerfield
+Ben Eidelson So there is still some basic XMPP functionality under the hood? Does this mean that Hangouts will still be able to communicate with federated Jabber servers/clients, at least for now?

Ben Eidelson
+Jason Summerfield Not federated support, but supports interop with XMPP clients. Meaning you can continue to use XMPP clients to log in to Google Talk and those messages will interop with folks on Hangouts.

It was this that prompted me to call up Messages on my Mac, where I am logged in via XMPP to my GMail account, and to initiate a chat with Randy as shown above. We found we could chat perfectly fine. We couldn't initiate a callinto a Google+ Hangout from an external XMPP client - although I'll be honest and say I don't know how well that worked in the past. My own usage of external clients has entirely been for chat.

So What Is The Story?

I don't know. The statement quoted in The Verge's story seems pretty definitive that XMPP has been dropped, as does the message sent to AppEngine developers. It does seem so far that:

  • "Server-to-server" XMPP, used for federation with other servers / services, has been dropped.
  • "Presence" and status messages have been dropped (because the idea seems to be with Hangouts that you just send a message and people will get it either right then or whenever they are next online).
  • Within the Hangouts app, you can only connect to people with Google+ accounts, i.e. contacts on external XMPP servers no longer appear.
  • Google hasn't made any clear statements on what exactly is going on.

But is this partial XMPP support only temporary? Will it go away at some point whenever Hangouts fully "replaces" GoogleTalk? Or is this a communication mixup? (As happened recently with Google's announcement of DNSSEC support for their Public DNS Service?)

For me the disappointment in all of this is mostly that Google has been one of the largest advocates for the open XMPP protocol and I enjoyed the fact that I could use multiple different chat clients to interact with my GoogleTalk account. I was also very intrigued by the federation that we were starting to see between GTalk and other systems out there via XMPP.

Whereas before Google+ seemed to be an interesting social/messaging backbone to which I could connect many different apps and systems, now Google+ is looking like simply yet another proprietary walled garden - and we don't need more of those!

Hopefully we'll hear something more out of Google soon.

P.S. Here's another interesting viewpoint: Google Hangouts and XMPP – is cloud harming the Internet?

UPDATE: In a comment over on Google+, Daniel Pentecost states that Randy and I were not actually using Hangouts:

Dan, you weren't actually chatting through Hangouts. You were chatting through Google Talk which itself has a bridge into Hangouts. It only works b/c Randy is a Gmail user and still has access to Google Talk in Gmail.

Perhaps that is the case, which again then begs the question of whether this is only a temporary capability until GoogleTalk is shut down.

If you found this post interesting or useful, please consider either:

May 22

Video: My Discussion of DNSSEC and DANE with VoIP / SIP on The VUC

What role could DNSSEC potentially play to help better secure voice-over-IP (VoIP)? How could the DANE protocol help provide a stronger level of security to SSL/TLS certificates used in VoIP? What VoIP software out there right now works with DNSSEC?

Back on May 3, 2013, I participated in a VoIP Users Conference (VUC) call on precisely these questions. In the call that went for close to 90 minutes I outlined what DNSSEC and DANE are all about, how they work in a web browser world and how they could potentially work in a world of VoIP with SIP. We also discussed the current support for DNSSEC in the Jitsi softphone and the Kamailio SIP server. There was also a healthy question and answer period where we went off on different tangents. I referenced a presentation I made at SIPNOC 2013 and the slides for that presentation as well as other resources are available from the Deploy360 DNSSEC and VoIP page.

It was a great call and the video is available on YouTube:

If you want to just listen to the audio, you can play or download it from the VUC episode page.

If you found this post interesting or useful, please consider either:

Mar 28

Video Interview: Emil Ivov about how the Jitsi softphone works with IPv6 and DNSSEC

How does the Jitsi softphone work with IPv6? And what role could DNSSEC play with VoIP? At IETF86 earlier this month, I sat down with Emil Ivov, project leader of the Jitsi Project to talk about a wide range of topics including how Jitsi got started and why it does so much with IPv6 (interesting reason!), what they are looking to do with Jitsi now, the role of DNSSEC and why they added that support to Jitsi... and much, much more... I quite enjoyed talking to Emil and the Jitsi project is certainly one that I will continue to watch - and use!

If you found this post interesting or useful, please consider either:

Jun 21

June 23 Deadline For Submissions to Invite-Only WebRTC/RTCWEB Congestion Control Workshop

Iab logoHow do we manage network congestion as we move real-time voice, video, chat and data communication into web browsers? How do we make sure browser-based voice/video doesn't overwhelm the local network?

If you've been following the excellent work of the WebRTC/RTCWEB initiative you'll know that developers are already using developer builds of browsers like Google Chrome and Mozilla Firefox to move real-time communications (RTC) directly into web browsers - without using Flash or Java plugins.

It's a powerful step to bake real-time communications into the very fabric of the Web. It stands to open up a zillion new opportunities for innovative uses of voice and video... and can fundamentally disrupt so many aspects of today's telecommunications.

It also stands a chance of completely swamping today's networks with RTC traffic!

So what do we do? How do make sure that browser-based RTC plays nice with other traffic? How do we help it succeed?

Those are the type of topics to be discussed and debated in a "Workshop on Congestion Control for Interactive Real-Time Communication" taking place on Saturday, July 28, 2012, in Vancouver, British Columbia, on the weekend before the start of the week-long IETF 84 standards meeting.

The workshop is free of charge, and even has the possibility for remote participation, but you must be invited to attend. It is a working session and the organizers, the Internet Architecture Board (IAB) and Internet Research Task Force (IRTF), are requiring all potential attendees to submit a position paper basically explaining why they want to attend. More information and details can be found here:

http://www.iab.org/cc-workshop/

THE DEADLINE FOR SUBMITTING POSITION PAPERS IS SATURDAY, JUNE 23!

So if you want to participate in what should be an extremely interesting session, you need to go now and submit a paper for consideration.

It's an extremely important topic - and one that must be addressed for WebRTC/RTCWEB to truly be the innovative force that it can be. I hope you'll consider participating!

P.S. If you can't attend that particular day, the outcome of the event will definitely be discussed on the IETF's rtcweb mailing list (Warning - high traffic!!!). Anyone can join that list so you subscribe if you'd like to monitor what is going on. (Did I mention that the list has a high volume of traffic?)

If you found this post interesting or useful, please consider either:

May 11

Video: What is the role of the IETF? How does it help the Internet and open standards?

What does the Internet Engineering Task Force (IETF) do? What role does it play in setting Internet standards?

As readers are probably aware, I've been a long-time supporter and advocate of the IETF's work on open standards, writing about it both here on Disruptive Telephony and previously quite extensively over on Voxeo's Speaking of Standards blog. In my new role with the Internet Society Deploy360 Programme, of course, I'm even more directly involved and am now regularly attending IETF meetings.

For those who aren't familiar with the IETF, I recently came across this great video that explains the basics of what the IETF does:

The IETF is a great organization that is truly open to anyone to get involved. All you need to do is sign up for one of the mailing lists for one of the working groups and start reading and then participating. You can also attend one of the face-to-face IETF meetings to get even more involved.

Anyway, if you're not familiar with the IETF, do check out this video as it is a great intro!

If you found this post interesting or useful, please consider either:

Mar 08

WebRTC + Phono SDK = Browser Phone Calls WITHOUT A Plugin

Calling people using your browser - but without a Flash or Java plugin? That's been the mission of the WebRTC initiative for some time now with efforts underway in both the IETF and the W3C to standardize the work so that it can be broadly implemented.

I was very pleased to see the team at Voxeo Labs announce that the Phono SDK can now support WebRTC with the developer build of the Google Chrome browser. They outlined their work in a blog post and produced a video demonstrating the technology and also received a very nice writeup on TheNextWeb:

This is very cool as it has the potential once WebRTC is baked into more browsers to provide us with a very solid browser-based platform for building and deploying real-time communication apps. Kudos to the Voxeo Labs team for what they've done so far!

P.S. Some interesting comments about this topic over on Hacker News...

If you found this post interesting or useful, please consider either:

Feb 24

Humor: What Standards Experts Do

What exactly is it that “standards experts” do? If you’ve been on Facebook, Twitter, Google+ or pretty much any other social network lately, you’ve seen this meme going around, and so we did have to laugh when a gent named Greg Schumacher posted this image to Facebook:

StandardsExpert GregSchumacher

Sadly, this image is far too true!

Nov 10

IETF Journal for October 2011 Digs into DNSSEC, Port Control Protocol, Internet Evolution

Ietfjournal oct2011
Want to learn more about what is happening with regard to standards in the Internet Engineering Task Force (IETF)?  Want to understand the details about new proposals to offer another way to secure domains using DNSSEC? Never heard of the "Port Control Protocol" before and wonder how it may (or may not) help you? Want to understand some of the latest thoughts from Internet leaders about where the Internet is evolving?

The October 2011 edition of the IETF Journal gets into all of that and more. Here's the Table of Contents  (a PDF is also available for printing or ebook reading):

The IETF Journal is published three times a year and past (and future) versions can be found at:

http://isoc.org/wp/ietfjournal/

If you would like to be alerted to future editions - or would like to contribute articles - more information can be found on that page.
 

If you found this post interesting or useful, please consider either:

Oct 20

My Rant: Who Are We Building RTCWEB/WebRTC For? Telephony Developers or Web Developers?

IetflogoYesterday morning I did something I haven't done in eons. Many years, probably. (I can't remember.) I fired off a "rant" on an IETF mailing list.

I've been a huge proponent of the "RTCWEB/WebRTC" work going on in the "RTCWEB" Working of the IETF and the "WebRTC" of the W3C. I've mentioned it in many of my presentations. I've advocated for people to join the mailing lists. I've written about it a good bit on Voxeo's standards blog when I was at Voxeo.

We have an opportunity to make it easy for web developers to add "real-time communications" via voice, video, IM, etc., to web applications. We can make that work from directly within the browser.

Think of it... HTML5 with the ability to quickly add voice, video, chat... and without the need for a browser plugin or extension in Flash, Java, etc. (the limitation of all of today's proprietary options).

It's the opportunity to move real-time communications into the very fabric of the Web.

Awesome potential!

The work has been moving along quite rapidly in both the IETF and the W3C. Extremely active (high-volume!) mailing lists. Many Internet-Draft documents being created. Regular conference calls, interim meetings, face-to-face meetings. Some truly brilliant - and passionate - people involved. (Read the RTCWEB overview Internet-Draft for more background.)

But I still can't escape the feeling that the direction isn't quite right... as a friend said to me:

my feeling is that this is being appoached as SIP 5.6.2 - a minor tweak on an established standard - not WebRTC 0.9 - a new dawn in a new world.

I haven't honestly had the time to read all the messages with the crazy amount of traffic (which is good - shows people are passionate about the topic!), but I've felt increasingly frustrated with reading the messages that I have read that we're collectively in the midst of developing something that few developers will actually use.

So I ranted. Will it do any good? Maybe. Maybe not.

What the rant really needs is to be backed up by people who have the time to join in the process and contribute suggestions for how a RTC API that would appeal to "web developers" would look like.

Care to help out? The mailing list is open to anyone to join.

Anyway here's the rant... (and yes, for the truly pedantic, I am very aware that I ended with a </rant> but did not start with a <rant>)...

Folks,

I need to rant. I've been lurking on this list from the beginning but with a new job I haven't been able to really keep up with the volume of messages... and every time I get ready to reply I find that others like Hadriel, Tim, Neil, Tolga or others have made the points I was going to make...

But I find myself increasingly frustrated with the ongoing discussions and want to ask a fundamental question:

- WHO ARE WE BUILDING RTCWEB/WEBRTC FOR?

Is it for:

1. Telephony developers who are tired of writing code in traditional languages and want to do things in new web ways;

2. Web developers who want to add real-time comms (as in voice, video and chat) to their existing or new web applications;

3. Both 1 and 2.

If the answer is #1, then I think everything is going along just wonderfully. We can go ahead and use the SIP/SDP/etc. stuff that we all in the RAI area are all used to and understand just fine. Heck, let's just all end the discussions about a signalling protocol and agree on SIP... get the browser vendors to agree on baking a SIP UA into their browsers... and call it a day and go have a beer. Simple. Easy. Done.

And the only people who will ever use it will be people who work for RTC/UC/VoIP vendors and random other programmers who actually care about telephony, etc.

But that's okay, because the people who do use it (and their employers) will be really happy and life will be good.

If the answer is #2, then I think we need to step back and ask -

HOW DO "WEB DEVELOPERS" REALLY WANT TO WORK?

Here's the thing... in my experience...

99% OF WEB DEVELOPERS DON'T GIVE A ______ ABOUT TELEPHONY!

Never have. Never will. (In fact, I may be understating that. It may actually be 99.99999%.)

If they are with startups, they want to build nice bright shiny objects that people will chase and use. They want to make the next Twitter or FourSquare or (pick your cool service that everyone salivates over). If they are with more established companies, they want to create easy-to-use interfaces that expose data or information in new and interesting ways or allow users to interact with their web apps in new and useful ways.

And they want to do all this using the "languages of the web"... JavaScript, PHP, Ruby, Python, etc.

They want "easily consumable" APIs where they can just look at a web page of documentation and understand in a few minutes how they can add functionality to their app using simple REST calls or adding snippets of code to their web page. Their interaction with telephony is more along these lines:

"Wow, dude, all I have to do is get an authorization token and curl this URL with my token and a phone number and I can create a phone call!"

And the thing is... they can do this **TODAY** with existing proprietary products and services. You can code it all up in Flex/Flash. You can write it in Java. You can use Voxeo's Phono. You could probably do it in Microsoft's Silverlight. I seem to recall Twilio having a web browser client. A bunch of the carriers/operators are starting to offer their own ways of doing this. On any given week there are probably a dozen new startups out there with their own ideas for a new proprietary, locked-in way of doing RTC via web browsers.

Web developers don't *NEED* this RTCWEB/WebRTC work to do real-time communications between browsers.

It can be done today. Now.

The drawback is that today you need to have some kind of applet/plugin/extension downloaded to the browser to allow access to the mic and speakers and make the RTC actually work. So you have to use some Flash or Java or something. AND... you are locked into some particular vendor's way of doing things and are reliant on that vendor being around.

THAT is what RTCWEB can overcome. Make it so that web developers can easily add RTC to their web apps without requiring any downloads, etc. Make it do-able in open standards that don't lock developers in to a specific product or vendor.

But if we are targeting "web developers", that is who we need to satisfy... and we need to understand that they *already* have ways to do what we are allowing them to do.

If we come out with something that is so "different" from what "web developers" are used to... that requires someone to, for instance, understand all of what SIP is about... that requires a whole bunch of lines of code, etc.... well...

... the web developers out there will NOT launch an "Occupy RTCWEB" movement claiming that they are the "99% who don't care about telephony"... they will simply... not... use.... RTCWEB!

They will continue to use proprietary products and services because those work in the ways that web developers are used to and they make it simple for a web developer to go add voice, video and chat to a web app. Sure... they will still require the dreaded plugin/extension, but so be it... the "open standard" way is far too complicated for them to look at.

And all the work and the zillions of hours of writing emails and I-Ds that this group has done will all be for nothing. Well, not nothing... some of the telephony-centric developers will use them. But the majority of the web developers out there may not because there are other simpler, easier ways to do what they need to do.

So I go back to the question - who are we building RTCWEB for?

Is the goal to enable the zillions of web developers out to be able to use real-time communications in new and innovative ways? Or is it solely to make it so that VoIP/UC/RTC vendors can make a softphone in the browser that calls into their call center software?

RTCWEB *can* enable both... but to me it's a question of where the priority is.

The question is - will the RTCWEB/WEBRTC API/protocol/whatever be so simple and easy that web developers will choose to use it over Flash/Phono/Twilio/Java/whatever to add RTC functions to their web apps?

If the answer is yes, we win. Open standards win. Maybe we upgrade from having a beer to having champagne.

If the answer is no, what are spending all this time for?

</rant>

Dan

NOTE: And, as I suppose must be the case with any good rant, mine was not entirely accurate. As multiple people pointed out (one example), my ending where I ask about whether people would choose the RTCWEB/WebRTC API over Flash/Phono/Twilio/Java/whatever is not entirely on target. The question is really... will vendors creating libraries like Phono choose to use the RTCWEB/WebRTC protocols/APIs or will they continue to use their own proprietary solutions?

As people pointed out, there will be a hundred different JavaScript libraries created (like Phono) that will consume the RTCWEB work... and most web developers will use those libraries and not program directly with the RTWEB/WebRTC APIs and protocols.

Fair enough... but the question remains - will the RTCWEB work make it easy enough for all those JavaScript libraries to blossom?

Others pointed out that I'm really talking about the web API that would be exposed via the W3C's work versus the low-level API coming out of the IETF. And yes, that is perhaps technically true... but the reality is that it is the same set of people working in two different mailing lists... and both efforts are contributing to the end result.

In the end, I want to see a result of all this RTCWEB/WebRTC work that developers will actually deploy and use!

I want open standards to win.

If you found this post interesting or useful, please consider either:

Oct 08

Dilbert Nails One Of The Inherent Challenges of Standards

Dilbert nails it... (back in August 2011)

Dilbert standards

If you found this post interesting or useful, please consider either: