Disruptive Telephony

Did 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:

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:

• following me on Twitter;
• adding me to a circle on Google+;
• following me on App.net;
• subscribing to my email newsletter; or
• subscribing to the RSS feed.

---

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:

• following me on Twitter;
• adding me to a circle on Google+;
• following me on App.net
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

How 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:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

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:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

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:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

• From the Editor’s Desk
• DANE: Taking TLS Authentication to the Next Level Using DNSSEC
• Message from the IETF Chair
• Words from the IAB Chair
• ISOC Panel Addresses Regulation, Innovation, and the Internet
• IAB Plenary Tackles IPv6, Privacy Issues
• New Technology Demo: PCP
• Internet Society Fellows to the IETF Increase Participation on a Global Scale
• IETF Ornithology: Recent Sightings
• IETF 81 At–A–Glance
• IRTF Update
• IETF Meeting Calendar

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:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

Yesterday 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>)...

---

---

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:

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

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

---

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

• following me on Twitter;
• adding me to a circle on Google+;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

Today Alec Saunders posted a truly brilliant piece: Voice 3.0: The Emergence of the Voice Web. It's a much-needed update to his 2005 "Voice 2.0 Manifesto" and very nicely brings together much of the thinking about telecom today. (And yes, I had a chance to review it and provided feedback before it went live.)

It's brilliant. It's long. You really need to go and read it. It includes many of the themes we'll be talking about next week at eComm. It's right about so many things.

IT'S ALSO VERY WRONG.

The document as written has two big, glaring omissions.

---

Voice Doesn't Matter... As Much

First off... the piece is all about voice. Which is great. But here's a reality check:

People do NOT want to communicate by ONLY voice.

I spend my day communicating with people all over the world... in pretty much constant "real-time" communication. But almost NONE of it is by voice.

Instead it is by IM... by Twitter... by Facebook... by SMS... even by email. All text-based mediums.

No voice.

Now occasionally I do actually speak with someone - and usually get startled when my phone or Skype actually rings. But the majority of my communication happens outside of voice.

I wrote about this evolution of communication four years ago ... and it has only continued to evolve to a situation where voice is only one of the available communication channels... and not even the primary communication channel.

I'd argue this trend is only going to continue. Voxeo commissioned some research by Opus Research a year ago where they surveyed consumer preference. The demographic shift is pretty clear in charts like this one:

Look at the purple bar for consumers aged 45-54 ... then look at the blue bar for consumers aged 18-24.

See the "wave"?

We live in a world of ubiquitous mobility ... a world where we use mobile devices accessing cloud-based services and interacting with social networks and other similar services.

Sometimes by voice.

So to Alec's three "Defining Themes", I would add a fourth theme of Voice 3.0, which is the rise of multi-channel communication and the evolution of voice to "just another channel".

In the new world of communication, it is about:

Enabling customers to connect with you in the channel of their choice.

All that Alec wrote about the other themes of Voice 3.0 will be true ... but merged into a broader context in which voice is simply one of the available communication channels. Alec writes:

The service package will include not just voice, but detailed statistics, group management controls, and more. And it will bristle with API’s that will enable an ecosystem of other players to be built around it.

I would argue that it is better stated:

The service package will include not just voice, but the ability to communicate across a wide variety of channels, supported by detailed statistics, group management controls, and more. And it will bristle with API’s that will enable an ecosystem of other players to be built around it.

Don't get me wrong... I'm not arguing that voice telephony will go away. It will be here with us probably forever. And there are certainly times when we need and want to use voice. But not always - and maybe not primarily.

"Voice 3.0" needs to recognize this evolution.

---

Voice 3.0 Must Be Open

The second omission I see is perhaps more of a philosophical and personal one. I firmly believe that for voice to continue to be relevant and in fact to potentially grow in usage, Voice 3.0 must be based on open standards and not locking people in to specific services or providers.

Alec nails it with regard to the success of the Web (my emphasis added):

The web went from being a hyperlinked text library, to the largest programmable application on the planet, fuelled by open standards, lightweight communications infrastructure, standards which allowed content to be separated from logic and presentation, and an explosion of end-user devices, including today’s mobile devices.

He goes on to say:

Voice is on the cusp of the same revolution – a revolution that will be defined by letting the customer define the business logic of the application, not the service provider.

But then he doesn't quite bring it home. He says later again a similar thread (my emphasis added):

Ultimately, we’ll build systems where communications result in artefacts that can be consumed by services that have not been pre-specified. Think, for example, of the role that RSS played in the syndication of content, and imagine a similar world for voice. Tool chains will be created that will allow people to participate in building these services, and an explosion of new applications to consume these voice artefacts will be built.

The key here is that RSS is an open standard..

Alec in fact concludes with this (again, my emphasis added):

Network effects in the Voice 3.0 world become even more important. Will an open standard emerge? Although many die-hard networking folks would prefer that scenario, it’s hard to say. We may find ourselves in a world where a dominant proprietary player like Skype controls the platform, as a result of winning the race to build thriving developer ecosystems, and the applications that customers use and want.

Perhaps I am just part of the "die-hard networking folks", but I do believe that for voice to truly be integrated with the rest of the Web... for the "Voice Web" to emerge that Alec writes of in his title... for all the amazing new opportunities to emerge and "explode onto the scene"... for all of that to occur, Voice 3.0 needs to be based on open standards.

In fact, I would re-write his "web" paragraph with a voice spin:

Voice went from being an obscure medium locked up in proprietary/legacy telco control, to the largest programmable application on the planet, fueled by open standards, lightweight communications infrastructure, standards which allowed content to be separated from logic and presentation, and an explosion of end-user devices, including today’s mobile devices.

That is Voice 3.0.

And that is the fifth defining theme, being based on open standards that move control to the users and developers instead of the providers.

---

Again, you NEED to read Alec's full Voice 3.0 piece. It's an outstanding piece that is very well done.

Despite what I've written here, I do believe Alec's piece gets it right... subject to my modifications. :-)

And then please add your view on this. Do you agree with me about these additions? Do you think I'm wrong? Please leave comments here - or write your own piece and leave a link here in the comments. Comment on Alec's piece... comment on Twitter or Facebook... talk to us at eComm next week...

Where do you see "Voice 3.0" going?

---

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

• following me on Twitter;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

How does IPv6 impact telecommunications networks? How will IPv6 affect the SIP protocol? If you work in telecom, what should you be aware of with regard to IPv6? With World IPv6 Day only a week away, if you have been wondering about these kind of questions, please feel free to join me live in a free session hosted by the US Telecommunications Association:

IPv6 and Telecom Networks
Thursday, June 2, 2011
1:00pm US Eastern

Registration is free and if you are unable to attend it will be recorded for later viewing. (And if you register now, you'll be notified when the archive is available for viewing.) The description of the session is:

The networks that make up the Internet and IP communications are in the middle of a sea-change with the transition to IPv6. What impact will IPv6 have on telecom and communications networks?

Join USTelecom and Voxeo for a look at the various challenges that telecom and broadband services providers face in keeping their communication services working while transitioning to IPv6.

I'll be explaining briefly why there is all the attention on IPv6 then getting into the basics of IPv6 addressing. After a brief overview, I'll then dive into how IPv6 affects the Session Initiation Protocol (SIP) and get into some technical detail. I'll then wrap up with some resources about how to learn more and get started with IPv6 and finish with a Q&A session.

If you attended the Voxeo Developer Jam Session I presented back in May on IPv6, I'm going to be covering basically the same material although with a vendor-neutral perspective (i.e. I won't be explaining and demonstrating how Voxeo Prophecy and PRISM now natively support IPv6). Obviously the live Q&A session will be new, too, and I find the questions around IPv6 always quite fun to discuss.

Please feel free to join us at 1pm US Eastern tomorrow. Registration is free - and if you can't join live the session will be archived and available for viewing on US Telecom's website for 90 days. With World IPv6 Day coming up on June 8th, it's a great time to learn about what is going on with IPv6!

P.S. If you are interested in IPv6 in general, you may be interested in the IPv6 Resource Page I put together for Voxeo at:

http://bit.ly/voxeoipv6

Lots of good links to tutorials, VoIP resources and more...

---

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

• following me on Twitter;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---