Posts categorized "VoIP"

What Devices And Software Support The Opus Audio Codec? Here Is A List

Opus codec logoWhat devices support the Opus audio codec? What softphones? hardphones? call servers? Obviously given that Opus is the "mandatory to implement" audio codec for WebRTC, it will be in many web browsers... but what other I was asked this question by a colleague recently and when I couldn't easily find a list on the Opus codec web site, I turned to the VUC community inside of Google+ and posted there. The great folks there naturally were a huge help, and quickly came up with this list:

UPDATE: No sooner had I hit "Publish" then I discovered that Wikipedia has a list of devices and software supporting the Opus codec. As that list is much longer than this one below, I'd encourage you to look at that list.

What other devices or software supports the Opus codec? (Or what other lists are out there listing devices supporting the Opus codec?) Please do let me know either by comments here or on social media.

Thanks!

P.S. If you don't understand WHY the Opus codec matters so much, please read my earlier post on this topic.


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



Don't Miss Friday's Live VUC Call! - Martin Geddes on "Rethinking Broadband and Voice"

What are you doing tomorrow, Friday, December 6, 2013, at 12noon US Eastern (1700 UTC)? Would you like to join in to what should be an excellent conversation about the future of broadband networks, IP communications, telecom, etc.? If so, make plans to join the VoIP Users Conference (VUC) call happening live at 12 noon where the guest will be the ever-interesting Martin Geddes. The topic will be "Rethinking broadband and voice: Network Science and Hypervoice" and should prompt some vigorous discussion!

I've known Martin for many years now and have been a great fan of his analysis and writing ever since back in the days of his "Telepocalypse" blog. He's truly a great thinker in the space and is also quite an enjoyable and fun speaker to listen to. We know each other well from the early days of VoIP blogging as well as the conference circuit, and I regularly read his email newsletter and other great content he puts out. He's very active on Twitter as well.

Having said all that, I do have some fundamental disagreements with some of what he is advocating these days. I wrote about some of this disagreement last year and he and I had a good conversation both in the comments to that post and in some private exchanges.

Now, I very much agree with much of what he calls "Hypervoice" and where he sees voice going. Where we disagree is about the broadband component. This is the part that Randy outlines in the VUC page as:

He will outline some (controversial) answers that suggest we’re heading down a dead end and should consider a different technical and commercial approach.

It should be a fun conversation and I'm very much looking forward to the group discussion with Martin!

You can join the fun, too! If you want to just simply watch and listen, you can:

If you want to join in to the actual discussion, you can call in via:

Regardless of whether you are just listening or planning to participate, it's always a good idea to join the #vuc IRC channel on Freednode.net. More info and a web interface to IRC can be found on the VUC site.

If you can't join in live, the session will be recorded in both audio and video form. You'll be able to find the archive on the VUC page and on the Google+ event page.

Please do join us! It should be a great conversation!


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



Telefonica Shuts Down Jajah

TheNextWeb reported yesterday that Telefonica is shutting down the Jajah VoIP service that they acquired back in 2009 for a reported $207 million. While certainly disappointing for the users and presumably for some staff, it's not entirely unexpected. In the early pre-acquistion days, Jajah was doing some very cool things (ex. powering Yahoo!Voice, although that service has since faded) and was quite interesting to watch. Back when Alec Saunders was doing his daily "Squawk Box" podcast, we interviewed Jajah co-founder Roman Scharf on April 29, 2008 (you can still listen to the episode).

However, ever since the Telefonica acquisition you didn't hear a whole lot about them... although they did come out with an Android app in 2011 for calling Facebook contacts.

Telefonica isn't saying anything yet publicly about why they are shutting down Jajah. Pretty much the entire Jajah website points to a single "shut down" page and the blog now only has an entry about the shutdown. Matt Marshall over on VentureBeat speculates that Jajah simply didn't have any substantial revenue after voice traffic has been so commoditized - and that's as good a suggestion as any.

So... goodbye to Jajah... best wishes to all the customers and (presumably) staff.


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



Linphone On iOS Now Supports The Opus Codec

Linphone opus 2When updating my iPhone this week, I was extremely pleased to see the message in the attached screenshot that Linphone now supports the Opus audio codec. Somewhat strangely, I don't see any mention of this Opus support (or even the 2.1 release for iOS) on the Linphone news page or even on the Linphone features page, but the mention of a "Linphone Web" release does also mention Opus, so I'll assume this is real.

I've written before about why the Opus code is so incredibly important if we want to truly deliver a richer and better communications experience than we've had with the traditional PSTN and so it is great to see this support coming in to Linphone. Linphone is certainly not the first SIP softphone to support Opus - there are a number of others out there, including Jitsi and Counterpath's Bria (and X-Lite) - but it's definitely great to see another softphone added to the mix. Hopefully we'll also see this Opus support move to the desktop versions of Linphone (for Windows, OS X and Linux) as well.

Congrats to the Linphone team on making this happen!

P.S. Linphone also supports IPv6, ensuring that it will continue to work on all future networks.

Related Posts


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



Can We Create A "Secure Caller ID" For VoIP? (Join Tomorrow's STIR BOF To Learn More)

Can we create a "secure Caller ID" for IP-based communications, a.k.a. voice-over-IP (VoIP)? And specifically for VoIP based on the Session Initiation Protocol (SIP)? Can we create a way to securely identify the origin of a call that can be used to combat robocalling, phishing and telephony denial-of-service (TDOS) attacks?

That is the challenge to be undertaken by the "Secure Telephone Identity Revisited (STIR)" group meeting tomorrow morning, July 30, 2013, at 9:00 am in Berlin, Germany, as part of the 87th meeting of the Internet Engineering Task Force (IETF). The meeting tomorrow is a "Birds Of a Feather (BOF)", which in IETF language is a meeting to determine whether there is sufficient interest to create a formal "working group" to take on a new body of work within the IETF. The proposed "charter" for this new work begins:

Over the last decade, a growing set of problems have resulted from the lack of security mechanisms for attesting the origins of real-time communications. As with email, the claimed source identity of a SIP request is not verified, and this permits unauthorized use of source identities as part of deceptive and coercive activities, such as robocalling (bulk unsolicited commercial communications), vishing (voicemail hacking, and impersonating banks) and swatting (impersonating callers to emergency services to stimulate unwarranted large scale law enforcement deployments). This working group will define a deployable mechanism that verifies the authorization of the calling party to use a particular telephone number.

The agenda for tomorrow's STIR meeting begins with a presentation by Henning Schulzrinne, now CTO of the US Federal Communications Commission (FCC) but also a long-time IETF participant and one of the co-authors of the original RFC 3261 specification for SIP. Henning will be laying out the problem statement and there will be a discussion of the proposed scope of the IETF work. He'll be followed by presentations of potential solutions by Jon Peterson, Eric Rescorla and Hadriel Kaplan and then a discussion of the proposed charter and the work to be done. Given the intense debate that has occurred on the STIR mailing list over the past weeks I expect tomorrow's session to be one where some points will receive a great amount of passionate debate and discussion. (If you are interested in listening in or participating remotely in tomorrow's STIR meeting, see the information later in this article.)

Revisiting Previous SIP Identity Work

As some background, the Internet Architecture Board (IAB) laid out some of the challenges to "secure origin identification" in IP-based communication last November and took a very high-level look at the overall issue. Next, in preparation for what became this STIR effort, Jon Peterson, Henning Schulzrinne and Hannes Tschofenig authored a draft problem statement and requirements document.

The "Revisited" part of the group name is a nod to the fact that this whole issue of asserting "identity" has been explored within the SIP community in the past. Way back in 2006, RFC 4474 defined what has been called "SIP Identity" and provided a method for cryptographically signing certain SIP headers to identify the origin of a call. Unfortunately, RFC 4474 turned out not to work well with the way SIP was actually deployed and so usage has been virtually non-existent. An effort to update that document, what is called "RFC4474bis", has also been proposed and some of those ideas may be incorporated into the new proposed work for the STIR group.

There have also been other efforts such as the "P-Asserted-Identity (P-A-I)" defined in RFC 3325. The challenge here, though is that theoretically P-A-I is supposed to be limited to usage within a trusted network, although in practice it may be seen by other networks. There have also been several efforts to define or document identifiers for billing purposes (including my own P-Charge-Info) although these efforts are trying to solve a slightly different problem.

The point here really is that the STIR effort is drawing upon a rich body of "SIP identity" work that dates all the way back to some early drafts in 2002. Much thought has been given to this issue and many of the people involved with STIR have also been involved with earlier efforts and understand well some of the challenges faced by that past work.

An Important Difference

One important difference between STIR and earlier "SIP identity" efforts is that initially the STIR effort is only focused on telephone numbers. The draft charter explicitly states this:

As its first work item, the working group will specify a SIP header-based authorization mechanism to verify the originator of a SIP session is authorized to use the claimed source telephone number, where the session is established with SIP end to end. This is called an in-band mechanism. The mechanism will use a canonical telephone number representation specified by the working group, including any mappings that might be needed between the SIP header fields and the canonical telephone number representation.

and later:

Expansion of the authorization mechanism to identities using the user@domain form deferred since the main focus of the working group is to develop a solution for telephone numbers.

Previous "identity" work was also undertaken to include a "SIP URI" or "SIP address" and while the ultimate STIR mechanism (or a variant thereof) might also work for SIP URIs, the focus in this initial work is all around securing the origin identification of telephone numbers.

This initial focus makes a great amount of sense given that so much of the SIP traffic today is a result of telecom service providers moving their regular calls to telephone numbers off of the legacy PSTN networks and over to IP networks where they use SIP. Additionally, a great amount of the "problem" traffic seen in VoIP today can be created by attackers who use simple VoIP software to generate their calls to regular telephone numbers.

Remotely Participating In Tomorrow's STIR BOF

If you are interested in participating in the meeting (or at least listening in) on Tuesday, July 30, the meeting will go from 9:00 - 11:30 local time in Berlin, Germany. Berlin is in Central European Summer Time (CEST) which is UTC+2 (and 3:00 am US EDT / midnight US PDT for my friends back in the USA).

You can hear the audio stream at:

You can also join the Jabber chat room at:

The slides and other meeting materials can be found at (and note that materials may not be uploaded until shortly before the session and so you may need to refresh your browser):

Alternatively you can use the "MeetEcho" conferencing system that integrates the audio, the slides and the Jabber chat room at:

More information about participately remotely can be found on the IETF 87 Remote Participation page.

To get the most out of the meeting, you'll also want to read these three Internet Drafts that will be part of the solutions being discussed:

.... and be prepared for what should be a LIVELY discussion!

If you are unable to participate remotely, the session will be recorded and you will be able to listen to the archived audio stream, view the Jabber chat logs and also playback the MeetEcho recording.

Getting More Involved

Beyond listening to tomorrow's BOF session, the best way to get involved - either to actively participate or to at least monitor the effort - is to join the STIR mailing list at:

https://www.ietf.org/mailman/listinfo/stir

The list is open to anyone to join. There are no membership or corporate requirements or fees - anyone with an email address may participate.

WARNING! - As can be seen in the list archive, there is currently a large volume of discussion and it will probably continue for some time. If you do join the mailing list you may want to consider setting up rules to sort the STIR email into a folder - or just prepare for the volume to be added to your inbox.

The other way to be involved is to monitor and read the documents that are created for the STIR effort. Newer documents are being created with "stir" in the document name and so they can be easily found at:

http://datatracker.ietf.org/doc/search/?name=stir&activedrafts=on

Other documents that are useful to understand this effort are linked to earlier in this article and can also be found in the text of the proposed STIR charter. After tomorrow's STIR BOF session there will be more information about how the effort will proceed within the IETF. The meeting tomorrow should result, I expect, in the recommendation to go ahead with formally creating a working group and undertaking this work, but we'll see what outcome occurs.

Can a method of secure origin identification for SIP-based VoIP calls be created? Given that basically all telecom traffic is in the process of moving to be based on IP, the need for a secure origin identifier is very clearly here - and many of us do believe we can develop a system that will work in today's environment.

What do you think? Are you ready to join in and help?


Update: Added the additional charter text about "Expansion of the authorization mechanism to identities..."


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



Why The Opus Codec Matters - Even If You Don't Care About Audio

Opus codec logoWhat makes the Opus codec so interesting? Why is there such a buzz about Opus right now? If you are not in telecom or doing anything with audio, why should you even remotely care about Opus?

In a word...

Innovation!

And because Opus has the potential to let us communicate with each other across the Internet with a richer and more natural sound. You will be able to hear people or music or presenters with much more clarity and more like you are right there with them.

Opus can help build a better user experience across the Internet.

You see, the reality is that today "real-time communication" using voice and video is increasingly being based on top of the Internet Protocol (IP), whether that communication is happening across the actual Internet or whether it is happening within private networks. If you've used Skype, Google+ Hangouts, any voice-over-IP (VoIP) softphones, any of the new WebRTC apps or any of the mobile smartphone apps that do voice or video, you've already been using IP-based real-time communication.

Dropping The Shackles Of The Legacy PSTN

Part of the beauty of the move to IP is that we no longer have to worry about the constraints imposed upon telecom by the legacy Public Switched Telephone Network (PSTN). Chief among those constraints is the requirement to use only part of the sound frequencies we can hear. You all know the "sound" of the telephone - and you hear it in any movie or TV show when someone is using the phone. It's that certain "sound" that we are all used to... that's what the "phone" sounds like.

In technical terms, we call this "narrowband" audio and it has a frequency range of only 300-3400 Hz.

There are historical reasons for this limitation in telecom, but moving to IP-based communications removes those limits. With VoIP we can use what is called "wideband" audio to have a full rich sound to our voice or video call.

Have you had a really good Skype connection with someone where it sounded like they were almost right there in the room with you?

That is wideband audio.

The Codec Problem

Now, for voice or video over IP to work, you need to use something called a "codec" to translate the sound of your voice to digital bits and carry them across the network (and to do the opposite for whomever you are speaking with). There are MANY audio codecs out there and they come in all sorts of flavors and with all different kinds of capabilities. The problem has been that there hasn't been a codec that:

  1. is optimized for interactive Internet applications;
  2. is published by a recognized standards organization; and
  3. can be widely implemented and easily distributed at little or no cost.

In particular that last point about the cost of licensing, especially for wideband codecs, often caused developers to shy away from giving us the rich voice quality that we can now have with IP. Or, in the case of companies like Skype or Google, they went out and bought companies who created wideband codecs so that they could use those codecs in their products. (See my story from 2010 about Google buying GIPS.)

Now there are free codecs out there that developers can use. For narrowband, there has been the ubiquitous G.711 which provides an IP version of "PSTN audio". There have been many others, including notably Speex.

But the struggle has been that there hasn't been a widely accepted "G.711 for wideband" equivalent that developers can just bake into their products and start using. Instead there have been a number of different, incompatible codecs used in different products.

Enter Opus...

So to address these points, back in 2010, engineers within the IETF got together and formed the CODEC Working Group to come up with a codec that could meet these requirements and become the ubiquitous wideband codec used across the Internet. Skype was involved early on through contributing their SILK codec. The folks at Xiph.org contributed their CELT codec. People from many other companies got involved and there were huge technical discussions on the mailing lists and at IETF meetings.

And it worked... the Opus codec was standardized in RFC 6716 in September 2012.

You can read all about the codec at:

http://www.opus-codec.org/

The key points are at the beginning:

Opus is a totally open, royalty-free, highly versatile audio codec. Opus is unmatched for interactive speech and music transmission over the Internet, but is also intended for storage and streaming applications.

Open, highly-versatile... and royalty-free.

At that site there is some great information, including:

There is also a FAQ and many other great pieces of information.

So Why Does Opus Matter?

Opus matters because it lets developers focus on creating a high quality user experience and not having to worry about codec incompatibilities and licensing issues.

Opus matters because it lets developers easily create applications with high quality audio. They can just start using available libraries and communicating with other applications and devices using a common wideband codec.

Opus matters because it can work in very low-bandwidth environments enabling real-time communications across Internet connections that might not previously have supported such communications. As we start to get more Internet connectivity out to the 5 billion people not yet on the Internet, the ability to work over different kinds of connections is critical.

Opus matters because it can help foster innovation in applications and the user experience. Opus is the default audio codec for WebRTC, and so all the zillion new WebRTC-based apps and startups are already beginning with a far superior audio experience than we've had before.

Opus matters because it will enable even more ways that we can connect with family members or friends and have the experience of being "right there". It can help musicians collaborate better across the Internet. It can help podcasters and journalists deliver higher quality interviews across the Internet. It can, in the best conditions, give us that rich audio experience we get when we are right with someone - even though we may be thousands of miles away.

Opus can help us deliver on the potential of the Internet to create more powerful user experiences and to help us better communicate.

THAT is why Opus matters.

Learn More At Monday's IETF 87 Technical Plenary

To understand more about the current status of Opus, who is using it and where it is going, the IETF 87 Technical Plenary on this coming Monday evening in Berlin, Germany, will have a special segment focused on Opus that will include a number of people involved with the Opus work. The agenda for the session can be found at:

http://trac.tools.ietf.org/group/iab/trac/wiki/IETF-87

It is happening from 17:40-19:40 Berlin time, which is Central European Summer Time, which is currently UTC+2 and 6 hours ahead of where I live in US Eastern time. If you can't be there in person, there are several remote options:

If you are unable to watch the meeting in real time it will be archived for later viewing.

The first option above to listen to the session using the Opus codec (and WebRTC!) is a very cool one. The panel also includes people who have actually implemented Opus including people from Google and also Emil Ivov from the Jitsi softphone. Their insight into what they did will be great to hear.

What's Next?

So if Opus is so great, how do you get it?

Well, if you are using any of the WebRTC apps popping up all across the Internet, you are already using Opus. As I noted above, the Jitsi softphone supports Opus. In an interesting bit of synchronicity, I noticed that Michael Graves wrote today about the Blink softphone now supporting Opus. More and more communications apps are starting to implement Opus.

If you are a developer of communications apps or services (or a product manager), you can look at how to incorporate Opus into your application or service. There is documentation and software available to help with the process, and many people are out there who can help.

If you are a user of IP-based communications apps or services, ask the company or vendor behind those services when they will support Opus. See if you can get it on their radar as something to implement.

And regardless of what you do with audio, let people know that this new way of communicating exists - help spread the word about Opus - let people know that audio across the Internet can be even better than it has been to date.

As you can tell, I'm excited about the potential - and very much looking forward to seeing what happens as Opus gets more widely deployed.

What do you think? If you are a telecom developer, or a vendor of such services, have you implemented Opus already? Are you thinking about it? (and if not, why not?)


An audio commentary on this post is available at:


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



Further Thoughts on the Google Voice / Google+ Hangouts Integration

Google hangoutsMy post this week about Google Voice ringing into Google+ Hangouts generated a good bit of commentary, not only on the original post but also out on Hacker News, Reddit, Google+ and other areas. Given the range of responses, I thought I'd reply to a couple of points and also expand on some further related topics. So here goes...

"DUH! This is nothing new/disruptive. You could do it forever with GTalk/Gmail!"

A common response was to point out to me that Google Voice had been integrated with GoogleTalk / GMail for quite some time and so this integration was really nothing new.

Okay, fair enough. Point taken.

I'll admit that I never keep GMail open in a web window and so while I do recall that this integration was there in the past, I never personally used it.

Similarly, in Google+, I've taken to logging out of the GoogleTalk/chat sidebar because I found it was sucking up CPU cycles on my Mac. For whatever reason, the new Hangouts sidebar doesn't seem to consume as much CPU cycles and so I've left it running there.

So yes, the integration may have been there in the past and now it is there in Hangouts - and people like me are actually now noticing it. :-)

Ringing G+ Hangouts BEFORE Ringing Other Devices

There were a couple of comments that it seemed like calls to a Google Voice number rang the Google+ Hangouts first and then rang the other devices connected to the GV number. In my own testing there does seem to be about a 3-second delay between when the call starts ringing in Google+ Hangouts and when it starts ringing on my cell phone and Skype. Now, this may be a fact of Google giving priority to their own application - or it may just be an architectural fact that when they fork the call out to the different numbers it is faster to connect to their own service while the calls to my cell and my Skype numbers have to go through various PSTN gateways. Either way, there does seem to be a degree of delay before all devices ring.

Delay In Answering

A couple of people noted that there was a delay from the time you hit "Answer" to when the call was actually established. I've noticed this, too, although not consistently. I think part of it may be with starting up the Hangouts component inside of your browser - particularly with getting the video going, since that seems to be required for the Hangouts component. It may also be just the paths through whatever systems Google is using. It's certainly something to monitor.

Google Voice Call Does Not Ring The Hangouts App on iOS

In my own testing, I found a curious omission. When I call in on my Google Voice number, it does not ring on my Hangouts app running on my iPad. It rings Hangouts on my web browser... but nothing happens in the mobile app. Now, my iPhone rings - but that is because it is also connected to the Google Voice account. I didn't try removing that number from Google Voice and then seeing if the Hangouts app on the iPhone would ring. At least for the iPad, nothing happens. It would be great if this did work so that I could receive the calls on that mobile device.

XMPP...

Multiple people pointed out that my final remark about maybe some day getting SIP support was probably unrealistic given Google "dropping" XMPP support. I was admittedly away on vacation and at a conference last week and so I missed this point in all the announcement about Hangouts coming out of Google I/O. I wrote about this yesterday, though: Did Google REALLY Kill Off All XMPP/Jabber Support In Google+ Hangouts? It Still Seems To Partially Work

Although, as pointed out in a comment on Google+, this "partial" XMPP support may just be a factor of the continued GoogleTalk support - and may fade away when Google finally pulls the plug on that.

This is definitely an area where it would be helpful if Google could provide a few clarifications.

That's all I have right now for a quite update and response to points. Thanks for all the great comments and I do look forward to seeing where Google is going with all of this.


You can also listen to an audio version of this post:



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



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:



You Can Now Call Into Google+ From Regular Phones - Google Connects Google Voice To Hangouts

Want to hear the sound of Google further disrupting the world of telecom? If you have a Google Voice number and also use Google+ (as I do) with the Hangouts feature enabled, you'll soon be hearing this new sound if you haven't already.

UPDATE: I have written a follow-up post responding to several comments and expanding on several points.

An Unexpected Ringing

Yesterday a random PR person called the phone number in the sidebar of this blog to pitch me on why I should write about her client. This phone number is through Google Voice and I knew by the fact that my cell phone and Skype both started ringing simultaneously that someone was calling that number.

But as I was deciding whether or not to actually answer the call, I realized that there was another "ringing" sound coming from my computer that I had not heard before. Flipping quickly through my browser windows I found my Google+ window where this box appeared at the top of the "Hangouts" sidebar on the right:

Googleplus incoming call

Now, of course, I HAD to answer the call, even though I knew from experience that most calls to that number are PR pitches. I clicked the "Answer" button and in a moment a regular "Hangout" window appeared, complete with my own video, and with an audio connection to the phone call.

Hangouts phonecall

The PR person and I then had a pleasant conversation where I rather predictably determined quickly that she'd probably never actually readthis blog or she would have known that I've never written about her client's type of software. Be that as it may, the audio quality of the call was great and the call went on without any issues.

A subsequent test showed me that I also had access to the dialpad had I needed to send any button presses (for instance, in interacting with an IVR or robocall):

Hangout keypad

The only real "issue" with the phone call was that when I pressed the "Hang up" button I wound up still being in the Hangouts window with this message displayed:

Google+ Hangouts

The irony of course is that that phone number was never in the "video call"... at least via video. Regardless, I was now alone in the video call with my camera still running. I needed to press the "Exit" button in the upper right corner of the Hangouts window. Outside of that, the user experience for the phone call was fine.

The Future Of Google Voice?

Like many people interested in what Google is doing with Google+, I had read the announcement from Google of the new streams and Hangouts features last week and had gone ahead and installed the iOS Hangouts app onto my iPhone to try it out (marking Google's entrance into the OTT VoIP space). But nowhere in there had I seen that this connection was going to happen between Google Voice and Hangouts. I'd seen speculation in various media sites, but nothing direct.

So it was a bit of a surprise when it happened... particularly because I'd done nothing to enable it. Google had simply connected my Google Voice number to my Google+ account.

I admit that it is a pleasant surprise... although I do wish for the sake of my laptop's CPU that I could somehow configure it to NOT launch myvideo when I get an audio-only call. Yes, I can just go stop my video, but that's an annoying extra step.

It seems, though, that another feature removed from Hangouts, at least temporarily, was the ability to make outbound phone calls. Given that all signs of Google Voice were removed from Google's interface and replaced by "Hangouts", this has predictably upset people who used the service, particularly those who paid for credits to make outgoing calls. There does seem to be a way to restore the old Chat interfacefor those who want to make outgoing calls so that is at least a temporary workaround.

Google's Nikhyl Singhal posted to Google+ about the new Hangouts featuresstating these two points:

1) Today's version of Hangouts doesn't yet support outbound calls on the web and in the Chrome extension, but we do support inbound calls to your Google Voice number. We're working hard on supporting both, and outbound/inbound calls will soon be available. In the meantime, you can continue using Google Talk in Gmail.

2) Hangouts is designed to be the future of Google Voice, and making/receiving phone calls is just the beginning. Future versions of Hangouts will integrate Google Voice more seamlessly.

I'm sure that won't satisfy those who are troubled by the change, but it will be interesting to see where they go with Hangouts and voice communication.

(Note: the comment thread on Nikhyl Singhal's Google+ post makes for very interesting reading as people are sounding off there about what they'd like to see in a Hangouts / Google Voice merger.)

Will Hangouts Do SIP?

Of course, my big question will be... will Hangouts let us truly move beyond the traditional telephony of the PSTN and into the world of IP-based communications where can connect directly over the Internet? Google Voice once briefly let us receive VoIP calls using the SIP protocol - can Hangouts finally deliver on this capability? (And let us make outbound SIP calls as well?)

What do you think? Do you like this new linkage of Google Voice PSTN numbers to your Google+ account?


UPDATE #1 - I have written a follow-up post about XMPP support in Hangouts and confusion over what level of XMPP/Jabber support is still in Google+ Hangouts.


Audio commentary related to this post can be found in TDYR episode #009 on SoundCloud:


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



At SIPNOC 2013 This Week Talking About VoIP And IPv6, DNSSEC ... and Security, Of Course

Sipnoc 2013 logoOne of the conferences I've found most interesting each year is the SIP Network Operators Conference (SIPNOC) produced by the SIP Forum, a nonprofit industry association. Part of my interest is that it is only an educational conference, i.e. there's no massive exhibit floor or anything... it's all about education. It also brings together pretty much all the major players in the "IP communications" space - certainly within North America but also from around the world.

I'll be there this week in Herndon, Virginia, talking about how VoIP can work over IPv6 and how DNSSEC can make VoIP more secure. The sessions I am directly involved with include:

  • Panel Discussion: Anatomy of a VoIP DMZ
  • VoIP Security BOF
  • Panel Discussion:  IPv6 and SIP - Myth or Reality?
  • Who Are You Really Calling? How DNSSEC Can Help

There are quite a range of other topics on the SIPNOC 2013 agenda, including a number of other talks related to security.  

It should be quite a good show and I'm very much looking forward to it.  I'm particularly looking forward to my "DNSSEC and VoIP" talk on Thursday as that is a topic I've not presented on before... but I think there is some quite valuable potential about using DNSSEC with VoIP.

If you are there at SIPNOC this week, please do say hello!

P.S. While SIPNOC is not being livestreamed, you may find some people tweeting using the hashtag #SIPNOC.


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