Disruptive Telephony

Another remarkable day in Internet communications! Today brought the launch of "Wire", a "modern communications network" that runs on iOS, Android, Mac OS X and soon in WebRTC-equipped web browsers.

My first thought was naturally - do we really need YET-another-OTT-communication app?

After all, my iPhone is littered with the dead carcasses of so many other apps that have launched trying to be THE communication platform we all want to use. (And indeed I've written about many of them here on this site.)

But what makes Wire different for me from so many other similar apps that have launched (and faded) is really the PEOPLE involved. The news announcement mentions, of course, Skype co-founder Janus Friis as one of the big names behind Wire. Jonathan Christensen is also the co-founder and CEO of Wire. The news post says this:

The company's team comprises former product and technology leaders from Apple, Skype, Nokia, and Microsoft. Christensen held leadership roles at Microsoft and Skype, and was co-founder and CEO at Camino Networks. Along with Christensen, founders include Alan Duric, Wire’s CTO, a co-founder of Telio (Oslo exchange TELIO) and co-founder of Camino (acquired by eBay/Skype); and Priidu Zilmer, Wire’s head of product design, who led design teams at Vdio and Skype. Wire’s Chief Scientist Koen Vos, created SILK and co-created Opus, the standards for fidelity and intelligibility in voice over IP that billions of people use today.

I've known Jonathan over many years from his time at Skype. Alan Duric is a personal friend from the world of SIP, IETF and more. Some of the others are names I've known - and I've been told privately of others who are there, including apparently Jaanus Kase, who was one of the first working on Skype's community relations back in 2006/2007.

It certainly looks like an excellent team!

Does that mean it will succeed? Not necessarily... but it certainly has a far greater chance in my mind than many of the other attempts.

I have a GREAT amount I want to write about with regard to Wire, but for today I just want to write a few initial thoughts.

VERY Minimalist User Interface

When they say that Wire is about "simple, beautiful conversations", they aren't joking about the "simple" part. The user interface is extremely minimalist. All based on gestures and revealing just the information you need.

It's very cool as you get used to it... but it's also a bit non-intuitive - at least for older greybeards like me. At one point I simply wanted to reply in text and wound up calling someone (Alan, as it happened).

It is definitely great to see someone experimenting with a new UI to the degree that they have.

I installed it on both my iPhone 5s and my older iPad2. It worked great on both devices. The iPad, in particular, had a very nice view in the landscape mode. I did not yet install it on my Mac but spoke with several people who did.

Chats With Photos, SoundCloud and YouTube

When you start chatting with someone, it's very easy to add photos. You also could just drop in a link to a SoundCloud sound or a YouTube video and the player would automagically appear in the chat stream. And yes... animated GIFs work, too.

Call Quality - and Chats During The Call

I made several calls today and the quality was excellent. All high-quality voice. Presumably using the Opus codec or something similar. It's great that during the call you still have the full chat capability as I was sharing text and photos with the person I called.

Persistent Group Chats

I was extremely pleased to see how wonderfully well the "group chats" worked. Someone pulled a bunch of us "early adopters" into a chat room and it felt like we were back in 2006 or so in the early days of Skype and many of the early VoIP offerings. A very pleasant experience.

The group chat also synced very nicely between devices. A message I wrote on my iPad showed up just moments later on my iPhone. Others reported a similar experience with the Mac client.

Perhaps best of all the group chats appeared to be persistent group chats. After shutting down the app and then reconnecting later, I seemed to get all the messages that had been exchanged when I was offline. I've written before about the power of persistent group chats in Skype, and it was good to see what looked like something similar here. (Need to do more testing to confirm... but it looked good.)

What's Missing?

I realize today was the first day of the launch and that the product will evolve considerably, but some initial things I found missing:

• Perhaps the biggest surprise was the lack of video, purely because that seems to be included in almost every other OTT communications app these days.
• Not having a Windows client also seemed odd, given that they had a Mac OS X client. (Not that this mattered to me personally, but it just seemed odd.)
• I also missed the ability to edit a message you've already posted.

So Now What?

I'm definitely intrigued by what I see... I'll keep using Wire and will install the Mac OS X client.

There's still the larger issue that this is yet-another-silo-of-communication that is separate from all the other mobile apps and services out there... but that's the topic for another post.

And there's the ever-present "directory" issue, i.e. how will Wire grow the directory of users so that you find the people there that you want to communicate with? But that, too, is a topic for another post. It's not clear, too, what the business model is.

I was also initially intrigued by the idea that Wire might work over IPv6 ... but while the www.wire.com website DOES work over IPv6 (yea!), further examination and network sniffing shows that the traffic going from the application goes to Amazon EC2 servers that are only on IPv4. I'm looking forward to learning more about what might or might not be true here.

All that aside, Wire looks so far like a very cool new entrant into the realm of mobile communications apps... and I'm looking forward to more experimentation and usage in the days and weeks ahead! If you are using Wire (or decide to try it out), please feel free to contact me in the Wire app as "Dan York" or via "[email protected]".

Congrats to Jonathan, Alan, Jaanus and the rest of the Wire team for their launch today!

More Articles To Read

• GigaOm: Ex-Skypers unveil Wire app, offering voice, messaging and more
• The Guardian: Skype co-founder backs Wire - to take on Skype
• TechCrunch: Skype Co-Founder Backs Wire, A New Communications App Launching Today On iOS, Android And Mac
• TechMeme list of other related articles
• Hacker News discussion

What Do YOU Think?

Have you tried Wire out yet? What do you think? Will you use it?

---

An audio commentary on this topic is available at:

---

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

---

Today at 12 noon US Eastern (in about 3.5 hours), I'll be part of a panel on the VoIP Users Conference (VUC) talking about IPv6, WebRTC, the Internet of Things (IoT) and much, much more... you should be able to watch it live at live.vuc.me or embedded here:

VUC host Randy Resnick had a scheduled guest be unable to attend and so he asked a group of us to come on for what he is calling a "VUC Vision" session. I will be on there, as will, I believe, Tim Panton and a number of others. I expect the discussion should range over good variety of topics. It should be a good time... you're welcome to join in the discussion.

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

---

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 the future of telecommunications and the Internet? As more entertainment moves to being over the Internet, what are the implications for the media and for the technology?

Today, September 19, 2014, there is an interesting set of presentations happening at the Columbia Club in New York City, organized by the Columbia (University) Institute for Tele-Information (CITI) called the "CITI State of Telecom 2014". Subtitled, "From the Internet of Science to The Internet of Next Generation Entertainment Implications for Content, Technology and Industry Consolidation", the session description states:

The goal of the early Internet was to connect research institutions. Yet today 71% of all Internet traffic consists of video, games, and music, and that number is growing. This transition raises issues for media content, technology, industry consolidation, business strategy, and regulatory policy. Media companies, academics, policy makers, and technologists must think ahead.

You can watch it all live at:

http://new.livestream.com/internetsociety/citisot14

The sessions are being recorded, too, and are available at that address.

The session agenda and list of all the speakers is available on the CITI event page. The quick summary is:

• 9:00am Welcome and Introduction of Topic
• 9:15am Session 1- Technology and business drivers of the transformation of the Internet
• 10:25am Session 2- Emerging business, marketing, and transaction models for Next Generation Video (NGV)
• 11:35am Coffee Break
• 11:50am Session 3- Public Interest Dimensions in Next-Generation Video and Networks
• 12:50pm Lunch
• 1:50pm Session 4 - Consolidation in the network platform industry: drivers and impacts
• 3:00pm Coffee Break
• 3:10pm Session 5 - New TV and (video) OTT issues for telecom and media policy
• 4:20pm Session 6 - Defining the future: initiatives to lead the next generation of internet video
• 5:30 Closing remarks and reception

The sessions began 3.5 hours ago at 9:00am US Eastern and will continue for another 5 hours. I've learned a good bit from a number of the sessions - and am listening right now to the discussion around the challenges of getting Internet infrastructure deployed in rural areas of the USA.

Great sessions to listen to!

---

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

---

In the ongoing war for mobile messaging dominance and "what will replace SMS", Facebook has decided to annoy a serious part of their user base and force all mobile users to move to Facebook's separate Messenger app. In a short period of time, you will be forced to install the Messenger app if you want to send messages to Facebook friends while using your iOS or Android mobile phone.

Here's the thing... I already tried Messenger on my iPhone a while ago... AND I *UNINSTALLED* IT!

I don't want a separate messaging app. I already have a ton of those. When I am in Facebook I want to do all my Facebook activities and messaging within the one app. I tried Messenger and found the switching between the apps to be painful enough that I wanted nothing to do with it.

Now... in fairness, being someone who tends toward the "early adopter" stage, it was a while ago that I tried Messenger and before their "big update", so presumably they've made improvements. As Facebook so helpfully tells me, 190 of my friends use Messenger already. Knowing some of the people whose images I see on that ad Facebook show me, I can't imagine them tolerating a poor user experience... so yes, perhaps I should try it again.

But it's annoying to be forced to do so. Basically what it says to me is "we (FB) have tried every incentive possible to get people to move, but they aren't, so now we're going to make them move." Facebook already forced most of their European users to make the switch - but now they are making everyone switch.

There has been a great amount of media attention to this move today, and I received the email directly this morning:

The text itself says:

We wanted to let you know that messages are moving out of the Facebook app to our Messenger app, a free app that's faster and more reliable for everyday messaging. Messenger also includes: new ways to send photos and videos, voice calls, stickers, group conversations and more.

Soon, we'll start guiding you to get started with Messenger. After a few days, you'll also see a reminder notice in the Facebook app, where you'd normally see your messages. At that point, we'll ask you to install Messenger or go to the Facebook website to view and send messages. You'll still see new message notifications in the Facebook app, and it'll be easy to switch between Facebook and Messenger.

We appreciate your taking the time to install Messenger and know it will take a little while to adjust to using a second app. We look forward to sharing this fast, fun and reliable way of messaging with you. You can learn more here.

Where the "Soon, we'll start guiding you..." is really just marketing-speak for "Soon, you'll have no choice if you want to continue using Facebook messaging on your mobile phone."

The Bigger Picture

I understand why Facebook is doing this. They want a separate, lean "messaging" app that integrates tightly with your mobile phone operating system (iOS or Android). They want it so integrated that eventually you use it only and stop using the messaging app that is part of your o/s.

On my iPhone Apple has done a brilliant job with the "Messages" app integrating Apple's iMessage service in with regular SMS text messages. By default Apple tries to send your message via their OTT messaging service (iMessage) and then falls back to SMS when the recipient isn't registered with iMessage.

Facebook wants you to use their Messenger app as your default messenging app. They would like me to replace Apple's "Messages" with their "Messenger" app as my place to go do send a message. So they need a lean and focused messenging app to do this.

The OTT War For Mobile Messaging Dominance

And this IS the end-game. The war now is for which of the many "Over-The Top" (OTT) apps will be the replacement for the dying world of SMS messaging. People aren't sending as many actual SMS messages and are instead using:

• iMessage from Apple
• Facebook Messaging
• WhatsApp (also now from Facebook)
• Line from NHN
• WeChat from Tencent
• Hangouts from Google (as part of Google+ or separate)
• Skype from Microsoft
• Viber
• Twitter
• Blackberry Messenger (BBM - see update note below)

and probably another hundred smaller ones.

[UPDATE: A Canadian friend noted that I missed Blackberry Messenger (BBM) in the list and while I admittedly don't think about BBM that much these days, he's right that there is still a population that uses it on their smartphones.]

And yes, these are all separate "walled gardens" of propriety messaging (as I wrote about back in 2007, although the names have changed substantially). You can't message someone on a different system. You both have to be part of the same system - or potentially the system may fall back to sending a SMS message as iMessage does.

The attempts to lock Internet users into closed, proprietary walled gardens continues.

Make your app easy and simple to use... and get the most people using your app so that they won't want to switch to some other app.

The Broader OTT War For Mobile Communications

Notice, too, that Facebook mentions using Messenger for "voice calls". With this on iOS they are clearly aiming to take on Apple's "Facetime Audio" that Apple now presents as an option each time you make a call. And they can take on Microsoft's Skype and Google's Hangouts.

Apple, Facebook, Google and Microsoft.

All trying to be THE app/service that you use for communication on your mobile device. (And you can probably expect folks like Amazon to enter the game at some point, too.)

Giants on the playground.

And who is missing are the past giants of telecom. The "telcos"... the "carriers"... the "service providers". They are well on their way to being commoditized down to "big, fat, dumb pipes" of data... and they don't like that.

Hence you see them trying to coming out with their own apps and services (as Telefonica has done) or trying to come out with a rival offering such as Joyn (which Dean Bubley rips apart while pointing out the fallacy of talking of the "messaging market")... or using their control of the underlying data network to slow or block services... or using their powerful lobbying capabilities to attempt to get governments to regulate or intervene.

THIS is why so many of the upcoming ITU events matter. THIS is why the discussions on "network neutrality" matter.

The war for the future of mobile communications is well underway... and Facebook's move this week is just part of that much larger battle.

Even if that move will severely annoy Facebook users like me... most of whom will, of course, suck it up and install Messenger... because whether we like it or not we do want to communicate with Facebook users while mobile.

---

You can also listen to audio commentary on this topic:

---

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 "fifth-generation" (5G) wireless technology? In about 2 hours at 12noon EDT (16:00 UTC) today, July 24, 2014, there will be a live video stream of a presentation happening at IETF 90 in Toronto, Canada. You can watch the live video on the IETF Google+ Page and also embedded in this blog post below (but check the Google+ page for any updates). The session description is:

Discussions on fifth generation (5g) wireless access has rapidly intensified during the latest two years. 5G wireless access is seen as the long-term enabler of the overall networked society, not only providing enhanced mobile broadband access but being a tool to provide wireless connectivity for any kind of application.

This speech will provide an overview of the state of 5G efforts around the world. We will discuss the specific requirements and challenges being identified for 5G wireless access and the different technology components and alternatives being considered. We will also outline possible time schedule for 5G in ITU and 3GPP.

Given that so many people are getting their Internet access through mobile networks (and increasingly will be doing so in the future), I think it's extremely important to understand where these mobile technologies are going.

The speaker is Erik Dahlman from Ericsson and more information about his background can be found on the lunch session description page on the IETF website.

The presentation will be recorded and will be able to be viewed in the viewer below after the session is over. (And again, check the IETF Google+ event page for more information about the session and any updates.

UPDATE: Unfortunately Google's YouTube Live service when down for maintenance at the time we wanted to start our session:

Instead you need to watch the session on LiveStream.com at: http://new.livestream.com/internetsociety/IETF90

---

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

---

Today I'm back at the Hyatt Dulles in Herndon, Virginia, for the fourth SIP Network Operators Conference (SIPNOC) event. These SIPNOC sessions are great because they bring together the people actually operating the SIP-based networks that make up our telecommunications infrastructure. SIPNOC continues to be THE best place I've found to interact with the people actually taking SIP standards and making them happen in the "real world".

I've been to all four SIPNOCs - and I continue to find them outstanding events, not only because of the excellent technical content, but also because of the people.

In many cases, these are the "phone guys" (and gals) who have found their way to IP. The "Bellheads" of the age-old "Bellhead vs Nethead" debate. The "telcos". The people who have been doing telecom for decades... and are now evolving to IP.

In other cases, the people here are the new contenders. The cable companies are here - and they are strongly challenging the legacy telcos, and they are creating entirely new IP-based infrastructures. The "Internet Telephony Service Providers (ITSPs)" and "SIP Trunking" providers are here, too... companies that are reimagining what telecom can be in an IP space. Newer vendors... newer application providers... etc.

It's a wonderful mix of people.

All here talking about telecom in the age of the Internet... sponsored by the SIP Forum.

As I mentioned in a post yesterday on the Deploy360 blog, I will be speaking today at SIPNOC 2014 about TLS for SIP. The abstract for my talk is:

With concerns about large-scale pervasive monitoring on the Internet, many groups are encouraging the increased use of Transport Layer Security (TLS, what we used to call “SSL”). While SIP has had TLS support for quite some time, it is often not used. This session will look at concerns of using TLS with SIP and discuss opportunities for providing higher security for SIP-based communication. The session will also outline some newer innovations such as the DANE protocol that when coupled with DNSSEC can provide a higher level of trust for TLS encryption.

This relates largely to the "TLS for Applications" work we are doing within Deploy360, as well as our advocacy for the use of the DANE protocol to add a layer of trust to TLS/SSL certificates.

As I note in that Deploy360 post, I'm delighted to see on the SIPNOC agenda that speaking before me will be Carl Klatsky from Comcast providing a case study of the lessons they have learned so far in moving to IPv6!

It's kind of fun to scan my list of presentations and look back at what I've spoken about at the past SIPNOC events:

SIPNOC 2011 (employed at Voxeo)

1. SIP Adoption and Network Security
2. Lessons Learned in Large-Scale SIP Interoperability

SIPNOC 2012 (employed at Voxeo)

1. SIP and IPv6 – Can They Get Along?
2. Panel Discussion: SIP Adoption and Network Security
3. BOF: SIP and IPv6

SIPNOC 2013 (employed at Internet Society)

1.IPv6 And SIP – Myth or Reality?
2. Who are You Really Calling? How DNSSEC Can Help
3. Panel Discussion: Anatomy of a VoIP DMZ (moderator)

SIPNOC 2014 (employed at Internet Society)

1. Is It Time For TLS For SIP? (also includes some DNSSEC/DANE)

It's nice to have someone else talking about IPv6 this year!

Of course, you'll also find me in the VoIP security BOF tonight... and listening to the other sessions. Unfortunately I have something else happening tomorrow evening back in New Hampshire and so I'm only here at SIPNOC today and will be flying back tomorrow. The SIPNOC event continues all day tomorrow and half a day on Thursday.

Sessions are underway now... here is photo proof:

Unless you happen to be located in the DC area, it would be very hard for anyone to join into this year's SIPNOC event... but if you work with SIP or VoIP networks, I would strongly encourage you to put SIPNOC 2015 on your calendar for next year!

---

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

---

I was greatly saddened to learn today of the death of Simon Gwatkin this past weekend. For those of us in the VoIP / telecom space, the world is a little bit darker now.

I came to know Simon when I worked at Mitel Networks in Ottawa from 2001-2007, although it wasn't really until the later years when I wound up working in Mitel's Office of the CTO and looking more strategically at what the future might hold for companies like Mitel. A lot of my research and time wound up being spent looking at social media and the changing communication landscape. With Simon's role as head of strategic marketing at Mitel we wound up having any number of quite lengthy conversations about where things were going. We didn't always agree, which led to very useful and valuable discussions. Simon also got me engaged with industry analysts and helped set me down a path that was quite useful in many later years.

I also spent a good bit of time interacting with some of the startups that were being nurtured under the umbrella of Wesley Clover, the investment vehicle of Sir Terry Matthews. Simon was involved with Terry's investments there and had this intense passion for helping new entrepeneurs. (And starting in 2008 had a more permanent role with Wesley Clover.) He was fascinated by the communications business (both the telecom kind of "communications" as well as the marketing/PR kind) and by all the different ways we communicate.

When I was part of the large layoff that happened when Mitel purchased Inter-Tel in 2007, Simon helped with his vast network of contacts to try to find a place for me to land. While I ultimately wound up at Voxeo by virtue of some of the blogging I was doing, a couple of his leads were ones that I explored.

After that we stayed in touch over the years and increasingly found ourselves interacting more with each other through Facebook and social networks. One of his sons was doing something with security work at one point, and I'd shared some VoIP security resources I knew of. A few years back when my wife was dealing with breast cancer, a good friend of Simon's was battling it, too, and so we shared information - and shared with each other that intense frustration of being unable to do a whole lot to help someone we care about.

Along the way we had fun teasing each other about language and many other topics. Being a Brit with his very dry wit, he could always rise to the bait of commentary about the English language (versus "American") or other similar topics.

Simon was a gentleman and just a great guy in so many ways. I never knew his children but knew from his comments and posts that he was quite proud of them. He will be missed - and my thoughts and condolences are certainly with his family right now.

For those in the Ottawa region, or able to get there (and I am not able to do so), the obituary says a memorial service will be held tomorrow, April 17, 2014, at 2:30pm. An online guestbook is available for those who wish to leave messages for his family.

R.I.P., Simon. Thank you for all that you did.

---

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

---

Talk about disruption... the telecom part of the media world is buzzing with news of Facebook's acquisition of WhatsApp. Techmeme is currently showing MANY posts on the topic and the day is just getting started.

The key point here is that WhatsApp is a prime example of what is often called an "Over-The-Top" or "OTT" application. It uses the data channel on a mobile phone to provide services. Here's another key point from the Facebook news release:

• Messaging volume approaching the entire global telecom SMS volume.

The traditional telecom companies ("telcos") have already seen their voice revenue seriously eroded by Skype and so many of the other OTT voice applications (such as Viber, which was just acquired) and they've been watching SMS traffic and revenue plateau and decline.

WhatsApp was already one of the major players in the mobile messaging space... indeed I have friends in Europe who tell me they can't remember the last time they sent an actual SMS message because they use WhatsApp for all their messaging. Their usage, too, is not just about the "free" cost of WhatsApp messages - it's also about the richer messaging experience they can get over WhatsApp versus plain SMS. They can send photos, display an online status, engage in group chats and much more that was just either difficult or expensive to do with SMS. And... they can send messages to anyone using the app regardless of where they are in the world. They don't have to worry about fees to send SMS messages internationally.

The user experience is so very simple and easy.

Plus, WhatsApp (and other OTT messaging apps) solves the directory issue by just using your mobile phone number as the identifier within their system. With a quick approval of access to your contact list you can immediately start sending messages to any other WhatsApp users. You don't have to try to get anyone's number... it's all stored in the big giant (and constantly growing) WhatsApp user directory.

And now... instead of WhatsApp being a venture-backed startup out there building its service, it is now backed by Facebook, at this point one of the more powerful corporate entities on the global stage today.

Note, too, that Facebook has also been an OTT messaging player for some time with their "Facebook Messenger" application, which even introduced voice calling at one point in the US. In a post today, Mark Zuckerberg writes about how the two apps will co-exist for different communities of friends/contacts (see also the WhatsApp blog post). Zuckerberg also writes of how WhatsApp is, in his mind, on its way to connecting a billion people.

And that is really what should concern the telcos - one of the largest OTT messaging apps is now owned by the largest global social network.

A Larger Danger

There is, though, a broader concern, not just for the telcos but for all of us. All of these OTT messaging apps... whether they are WhatsApp, Line, Facebook Messenger, Apple's iMessage, Google+ Hangouts, Skype ... or any other... are creating SILOS of users.

They are proprietary "walled gardens" of messaging.

You can ONLY send messages to people who have the app installed on their mobile device.

Say what you will about SMS, but the reality is that you can send a message to pretty much anyone with a mobile phone, anywhere on the planet. No apps to download... it's just a "feature" of having a mobile phone.

WhatsApp requires the app. And specifically the app from Whatsapp and not anyone else's application. WhatsApp does NOT have an open API that anyone can use. In fact, WhatsApp's legal counsel was recently sending DMCA takedown notices to crack down on projects interacting with Whatsapp (presumably in the run-up to this acquisition). WhatsApp - and now Facebook - are in total control of the user experience and interaction for mobile messaging on the service.

Is this REALLY what we want for the future of mobile messaging?

Way back in 2007, I wrote about how "e-mail" was returning into walled gardens and while today's players are different than the diagram I had then, the situation is similar.

This is not the open Internet.

And that should concern us all.

---

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

---