Disruptive Telephony

Yesterday the team over at Wire launched a new WebRTC-based "Wire for Web" app that lets people on Windows, Linux or any other platform now communicate with people using Wire on iOS, Android or OS X. You can get to it simply at:

https://app.wire.com/

If you already have an account you simply sign in with your credentials. If you don't have an account you can easily create one.

I've been running both the native Mac OS X client and the web client for a bit now (I was part of web beta program for Wire) and it is truly amazing how well the team has made the web experience to be seamless between the web and native client. Here's a screenshot showing both side by side (click/tap for a larger image):

In the web view on the right you have the browser bars at the top and one of the images did not go the full width of the column, but otherwise the experience and visual display has been essentially identical between the two platforms. The synchronization between the two is nearly instantaneous and all the features work really, really well.

Notifications in the web browser (if you allow them) work great to alert you to new messages.

And the voice calls from within the web browser have the same outstanding audio quality I've come to expect from Wire.

All in all the web implementation is quite excellent.

This new web app also addresses a concern I had from the initial launch of Wire back in December - the lack of a client for users on Microsoft Windows. With this web app Windows users - and Linux users - can now equally participate in communication over Wire. This is all courtesy of WebRTC that allows modern browsers to be able to use voice and chat from directly within the browser. Wire co-founder and CTO Alan Duric published a post about how they use WebRTC.

Alan also clued me in to the strong degree that the Wire team takes security extremely seriously. In fact I would say they take it more seriously than many other similar web apps I've seen. If you go over to Qualys SSL Labs and plug in "app.wire.com" you get a result of an "A+":

The same can NOT be said of other similar web interfaces that I tested from similar services.

I've been writing about Wire for a bit now (see my various articles) and I have it running on my Mac all the time, primarily because of the great value I get out of a couple of group chats that I am in. From a chat / messaging perspective it's one of the best I've seen and I find it extremely useful.

Curiously, I don't find myself using Wire as much for actual calls, primarily because I find that much of my interaction has moved to video calls, and Wire doesn't support those yet. When I do use Wire the audio quality is truly amazing, but that has to do with the audio pedigree of the team behind Wire, and the fact that they are using the Opus codec. On a larger level, there is also the continued "directory dilemma" that I've written about, namely that Wire has the same struggle as most other new tools in that you need to gather a strong "directory" of people who are actually using the app for it to be an app that people regularly use. Most of the people with whom I regularly communicate aren't users of Wire ... yet.

Still, the release of this "Wire for Web" gives me hope that Wire may be able to build some momentum now that, for example, Microsoft Windows users can now join in. Time will tell... but this will definitely help!

Kudos to the team at Wire for this very excellent web release?

P.S. If you are using Wire, or try it out, you should be able to find me on Wire as "Dan York".

---

Note: an audio podcast about this topic is also available:

---

As I checked my AppStore updates on my iPhone this week I was surprised but pleased to see that WhatsApp now includes "WhatsApp Calling". As it says:

"Call your friends and family using WhatsApp for free, even if they're in another country. WhatsApp calls use your phone's Internet connection rather than your cellular plan's voice minutes. Data charges may apply.

How many ways can you spell "disruption"?
(Hint: w - h - a - t - s - a - p - p)

Sure, there have been a zillion mobile apps providing Over-The-Top (OTT) voice services, many of which I've written about here on this site.

But this is WhatsApp!

This is the application that just passed 800 million monthly active users! (Techmeme link) With projections to hit 1 billion monthly active users by the end of the year.

Oh, and it's owned by Facebook! :-)

Now, I personally don't use WhatsApp that much right now. The people who I want to message are primarily using iMessage, Facebook Messenger or Wire. (And every once in a great while I'll fire up Skype on my iPhone.)

But obviously there are 800 million people who do use WhatsApp each month... and they now have free calling! (If they are on Android, iOS or BlackBerry 10... and subject to a staggered rollout, i.e. people will get the actual ability to call over the next while.)

It will be fascinating to see how this plays out.

WhatsApp provides a messaging app with a very simple user experience (UX) that works seamlessly inside the iPhone. Now that same app can be used for calling. And most importantly, WhatsApp has the massive directory of users.

The legacy telcos are going to be saying good bye to even more of their diminishing calling revenue...

Interesting times ahead!

More on this topic:

• WhatsApp: How do I use WhatsApp Calling?
• Wired: Facebook’s WhatsApp Will Be How the World Makes Phone Calls (good read about the impact in the developing countries)
• TechCrunch: WhatsApp Begins Rolling Out Its Voice-Calling Feature To iOS Users

Congratulations to Emil Ivov and the whole team behind Jitsi for their acquisition by Atlassian! As they say on the Jitsi news page:

The Jitsi Community just got a lot stronger! BlueJimp, founder of Jitsi, is now part of Atlasssian! The plan is to keep Jitsi at the cutting edge of innovation by keeping it open and in the hands of those who created it in the first place: the open source community.

The news is outlined in an article on TechCrunch and explained in more detail in a HipChat blog post.

To be clear, Atlassian is acquiring the company BlueJimp that employed the founders of Jitsi, but in the process they are also effectively getting the open source Jitsi project. It's great to read in their blog post, though, that they intend to continue to support and invest in the project.

I've been a big fan of Jitsi for quite some time as it was one of the earliest VoIP clients to support both IPv6 and DNSSEC. I wrote about this support both here and also over on the Deploy360 blog and recorded this video interview with Emil Ivov:

Previously I'd also written about Jitsi's support for DNSSEC as it was the first softphone to do so.

More recently I've been using Jitsi's WebRTC-based video bridge for some of the remote participation work we've been experimenting with inside the IETF.

It's all great work and I'm delighted that Emil and his team have found a home inside of Atlassian. I hope it works well for them all and I hope we see further evolution of Jitsi and other similar products.

Congrats to the whole team!

---

Want to learn more about what's up with Skype right now? Tomorrow, March 27, 2015, at 12 noon US Eastern, my friend Jim Courtney is going to be discussing the new second edition of his "Experience Skype to the Max" on episode 534 of the VoIP Users Conference (VUC) podcast.

As noted on the VUC page, Jim will be talking about:

• New features over the past three years and why they don’t have the “buzz” impact that new features used to have. Are we becoming calloused to anything new?
• The challenge of innovating with a product that has built up a legacy and familiarity
• The challenge of educating users about features beyond free voice and video calling (and it’s also a challenge for smartphones – to make users realize there is value in all those applications available beyond voice calls and SMS messages).
• The feature set to consider when evaluating other alternatives
• The directory issue
• Skype vs Skype for Business
• Asynchronous vs real time comms (migrating to IM backend has allowed more “persistence” with chat messaging, for instance)
• Anytime communications Rooms

It should be a good session. I've known Jim for many years through his blogging about VoIP and he has a great amount of knowledge about Skype. Sadly, I'll be occupied with IETF 92 activities during the live broadcast so I will have to catch up with the recording of the session.

It's probably best to also join the IRC backchannel where links are shared, questions are answered and other comments occur. You also can visit the Google+ event page for the VUC #534 session today where there may be additional links and info.

If you won't be at your computer, you can also call in via:

• sip:[email protected]
• +1 (646) 475-2098
• Skype:vuc.me

The session will of course be recorded so you can listen/watch later. Here is the YouTube live video stream:

---

"Hey, that's a Mitel IP phone... I remember when that handset was introduced. It was very different from the previous one but had better 'shoulderability' ... it created a bit of a stir among customers, though. Hmmm... I wonder what model IP phone that is......"

All of this was running through my head during a routine visit to my bank this morning while waiting at a counter talking to someone. He had to call another office so there I was looking at his desk phone.

It happens to me all the time!

Even though I left Mitel way back in 2007... and really left IP telephony when I left Voxeo in 2011... IP telephony hasn't left me!

I'll be at a hotel... and I am checking out their phone system. A bank... an office... Wherever! There's a Cisco IP phone... there's an Avaya... there's a Mitel... a snow... a I-have-no-clue...

I guess it's just an occupational hazard of having been a product manager for IP phones during my time at Mitel... or maybe just the 6 years I spent there learning about IP telephony... but I just always see the IP phones. :-)

As a follow-up to my post yesterday about how Indian telcos are complaining to the the Telecom Regulatory Authority of India (TRAI) about WhatsApp's plans to launch VoIP, long-time VoIP blogger Aswath Rao took issue on Twitter with one particular sentence in my article:

India has NOT been a very friendly place for VoIP historically, and so we'll have to see what happens here...

In a series of tweets Aswath pointed out that the TRAI has in fact been very supportive of IP-to-IP VoIP services and has left them unregulated. The regulation has all been around VoIP services interconnecting to the Indian PSTN. Aswath's tweets: https://twitter.com/aswath/status/548681349344034818

You are mistaken when you say "India has NOT been a very friendly place for VoIP historically". And I have pted it out many times.

https://twitter.com/aswath/status/548681697227980800

From the get go, TRAI has regulated only IP to Indian PSTN. IP/IP & IP to foreign PSTN have been unregulated

https://twitter.com/aswath/status/548687939862290432

My point is that TRAI has been very enlightened in its ruling. Even after 11/26 attack & pressure it has not reg IP/IP

Given that Aswath has been very involved in VoIP in India for many years, I'll defer to his opinion on this one.

Thanks, Aswath, for challenging me on this sentence.

---

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 Ello;
• following me on App.net;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

To the surprise of absolutely no one, telcos in India are objecting to plans for WhatsApp to launch VoIP and complaining about it to the Telecom Regulatory Authority of India (TRAI). So reports The Hindu Business Line that includes this glorious quote from a representative of the Cellular Operators Association of India (COAI):

“Allowing the use of VoIP/ Internet telephony at such massive scale without licensing regime would lead to a significant disruption in the existing business of TSPs and can substantially derail their investment capability”

Gee... allowing a new innovative entrant into the market would lead to "significant disruption in the existing business" of the existing telcos.

Yes. Exactly.

And the representative further pointed out that this could lead to a "significant loss of revenues" for the government in the form of taxes.

Yes. Exactly.

This is the nature of Over-The-Top (OTT) applications and services. In providing better services for customers they very often DO cause "significant disruption" to existing businesses.

This is the nature of innovation.

This is the value of the "permissionless innovation" that has made the Internet the amazing tool for communication, collaboration and creation that it is today.

The folks at WhatsApp don't need to ask anyone to roll out VoIP, as articles seem to point to them being ready to do soon. (See also this AndroidWorld.nl article in Dutch.)

They just do it.

And... of course... the legacy telcos fight back using every tool in their formidable arsenal, which includes of course legislation and government lobbying such as that shown in this article.

India has NOT been a very friendly place for VoIP historically, and so we'll have to see what happens here...

[UPDATE: Aswath Rao says I'm wrong with this last sentence and that India has been friendly to pure IP-to-IP VoIP systems.]

... but while they can attempt to throw up as many roadblocks as they can... in the end my bet would be on the OTT services and applications to win.

They provide the services the customers want... and can probably do so at a much more reasonable cost... and in the user experience that the customers want.

A classic example of "disruptive telephony"...

---

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 Ello;
• following me on App.net;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

Congratulations to the Wire.com team for having Wire be selected as one of The Next Web's "Apps of the Year"!

TNW's Napier Lopez talks about how beautiful Wire is and how much it is a platform that he wants to use... and suddenly he is the one asking people to join him.

Many of comments mirror my own opinion of how much I enjoy using the app. It's just a pleasure to use for communication.

Napier Lopez does, though, hit Wire's real challenge:

Still, I mentioned earlier that I started using other messaging platforms because my friends made me, and therein lies the crux with Wire, or any new messaging platofrm, really: you need to get users on the platform.

This is indeed the "user directory problem" that I wrote about at great length. And I, too, hope that the Wire team - and we all as Wire users - can find ways to help bring people to the platform.

Meanwhile, congrats to the Wire team for this recognition - and I look forward to seeing what may be coming up next in the app!

P.S. I notice a version 1.2 for iOS just appeared in the AppStore and it includes the ability to invite people to join, so that's a start....

---

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 Ello;
• following me on App.net;
• subscribing to my email newsletter; or
• subscribing to the RSS feed

---

The big telecom story today certainly seems to the be launch of Ray Ozzie's new "Talko" application for iOS. Tons of attention in the tech media, and many of my friends on social media have been trying it out. There's a brilliant article posted on Medium about the "Brave New Phone Call" along with a great blog post from Ray Ozzie about how this new app will revolutionize the voice experience.

I think Talko has great potential to do so, particularly after using it.

But...

... I had to change my firewall rules in order to make Talko work. :-(

And I don't know how long it will continue to work.

Perhaps worse than that... it wasn't clear initially that I had a firewall problem. Frequent testing partner Jim Courtney sent me a message and after installing the Talko app on my iPhone I tried to talk to him, but all I seemed to be able to do was send him a voice message or a text message.

Subsequently I tried connecting to Tim Panton and again could only send voice messages. It made for a very asynchronous "walkie-talkie" style of communication that clearly seemed to not be what was described in the article.

At that point my many years in VoIP kicked in and I realized the firewall at the edge of my network was probably blocking something. Sure enough, when I pulled up the live firewall log and filtered on my iPhone's IP address I could see blocked connections from my iPhone that were intended for an IP address in Amazon's EC2 cloud. These blocked connections happened when I tried to initiate a voice conversation within Talko.

I first tried to create a firewall rule that would allow specific ports through, just by guessing from the firewall logs what ports Talko might be using. However, they jumped around and what I ultimately had to do was create a rule allowing any connection from inside my network to the specific IPv4 address of what I assume is one of Talko's servers on Amazon EC2.

Once I did this, I was able to have a voice conversation with Tim perfectly fine. It was actually rather cool how it would record the conversation and let me easily go back, listen again, advance through it, etc.

But...

... poking a hole in my firewall to a specific IP address is very definitely NOT the way to have a telecom application work.

And... Talko will only work on my network as long as that destination IP address doesn't change. If they add more servers or change their architecture, it's dead to me. At least... dead on my home WiFi network. Presumably it could still work on my mobile data network (at a cost to me).

Now, to be fair, I'm a bit more security-paranoid than the average home user and so I run a Linux-based firewall/server/gateway on the edge of my home network with a fairly restrictive set of firewall rules. The default policy is to deny outbound connections unless they fit into various rules. I've had to add rules allowing VoIP and IM protocols... and it's not uncommon for me to have to add new rules for applications like this. For instance, I had to do so for Tox when I was playing with it a few months back.

Odds are Talko will probably work fine for the vast majority of connections from WiFi networks with less paranoid firewall rules.

But... for an app like this to really challenge the existing telecom infrastructure, it needs to work from almost anywhere. This is why Skype usage is so ubiquitous - Skype "just works" and has its ways to work around firewalls. Within the SIP and WebRTC communities there are all the STUN / TURN / ICE servers and technologies that enable this kind of transit of a firewall. The technology is out there. And there will certainly be some enterprises and other businesses that set up firewalls at least as restrictive as mine is.

I realize today's news is the initial public launch and that this is early days for the app. I hope the Talko team can figure out a way to make the voice conversation work through firewalls. I really like what I see inside the app.

Meanwhile... I'm just hoping they don't change the IP address of the server with which my app is communicating!

---

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

---

"What is a minimum set of specifications that a vendor must implement to be able to say that it is SIP-compliant?"

A friend asked me that question and my response was:

It depends.

and even more unfortunately:

I don't know.

It turns out to be a challenging question to answer... and it led me to ask:

• How do we define what "SIP" is for telecommunications in 2014?
• How do we help vendors move their products/services to be based on SIP?
• As we talk about "turning off the PSTN" and "moving all telecom to IP", how can we make it easier for companies to switch to using SIP?

The reality is that being "SIP-compliant" does turn out to depend upon where in the larger SIP interconnection ecosystem the vendor is located.

Is the vendor:

1. a SIP client, in terms of a "hard" phone, a softphone, or other application that is seeking to connect to a SIP server?
2. a SIP server seeking to connect to a SIP "service provider" to have connectivity out to the PSTN and other SIP networks?
3. a SIP service provider seeking to interconnect with other SIP service providers and to the PSTN?
4. a middlebox such as a firewall or session border controller (SBC) seeking to be in the middle of a SIP communication stream?
5. an application that interacts with SIP systems in some way? (ex. call recording, IVR, networking monitoring)

To be "SIP-compliant" really means you need to figure out what amount of "SIP" you need to implement to play your part in the larger picture. Particularly when the SIP "architecture" we describe isn't the pretty little picture we use:

but rather a much more complex reality:

Unfortunately, the "Session Initiation Protocol" (SIP) is no longer just good old RFC 3261 and a few friends. RFC 3261 provided a radical new way to do telecommunications... it was "HTTP for voice"... it was simple, easy and pretty amazing. If you have a moment, go back and read RFC 3261. It's a remarkable document and set of ideas.

However, there were two factors that started to complicate "SIP":

• the "Internet" community kept thinking of new and innovative ways that they could do more with SIP-based telecommunications; and

• the traditional telecom companies/vendors kept wanting to bring across more and more legacy PSTN functionality into the world of SIP, typically without changing that PSTN functionality so that they wouldn't have to change their business models or processes.

This combination set SIP up to slowly become more and more of an accretion of various hacks and kludges designed to either enable SIP to unleash new possibilities and/or to take over key functionality from the PSTN.

But in doing so it became so much harder to define what "SIP" was.

Back around 2008/2009, Jonathan Rosenberg tried with his "Hitchiker's Guide to SIP" that was published as RFC 5411 in February 2009:

http://tools.ietf.org/html/rfc5411

Now consider that this contained about 26 pages worth of documents to be referenced... and this was back in 2009! In the 5 years since, the "Realtime Applications and Infrastructure (RAI)" area of the IETF has been extremely busy and a similar document today would be be MUCH longer.

But does such a long list really help?

Going back to to my list of different roles within the SIP ecosystem, do we need more narrower lists for each role? A SIP client connecting to an IP-PBX may not need to implement all of the same specifications as a SIP service provider connecting to the PSTN.

What is the minimum set of SIP specifications for each role?

The good news is that for the second role I mention, the SIP server to SIP service provider, the SIP Forum has done some outstanding work with their SIPconnect initiative. You can find more info at:

http://www.sipforum.org/sipconnect

You can download the SIPconnect 1.1 technical specification and see the great amount of work they have done. The idea is that ultimately any "SIPconnect-compliant" IP-PBX or other SIP server can connect to any "SIPconnect-compliant" SIP service provider. It should "just work" with a minimum amount of testing. The goal is to allow the more rapid deployment of SIP-based IP-PBXs and making this part of the interconnection puzzle work that much better.

So if you are a vendor of a SIP server, whether you call it an IP-PBX, a call server, or whatever... or you are a SIP service provider seeking to connect to SIP servers at your customers - in either case you have SIPconnect that you can use to be "SIP-compliant".

But what about the other roles?

What if a vendor has multiple products?

What if a service provider or enterprise is just trying to get "SIP" products to work together? What should they specify beyond the vague statement that a product should support "SIP"?

Now, there are other organizations that have attempted to answer this question. The 3GPP has a list of SIP specifications and the GSMA seems to have similar documents. The ITU-T has many recommendations but since they rename everything it's hard to understand what really links back to SIP - and many of the ITU recommendations are only available to members and so you can't easily view them.

Which brings me back to these questions:

• Do we need a new IETF document that aims to update RFC 5411 with a newer list and perhaps "profiles" of what would be needed for different roles?

• Is this something the SIP Forum or some other organization should take on?

• Has someone else already created a concise list/document/specification and I just haven't yet found it?

And perhaps the even larger question:

• Do you believe this is an issue that we collectively should be working on as an industry to help make the deployment of SIP easier?

What do you think? How do we define SIP in 2014? What should we do? I'd love to hear your comments either in response to this post here on this blog or out on social media where this is posted. (Thanks!)

---

An audio commentary on this post is also available:

---

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

---