Dan York on how Voice over IP is rewriting (almost) everything you thought you understood about telephony...

Posts categorized "IM"

Last month the first Request For Comments (RFC) was published where I was one of the co-authors. Ironically, this RFC 7649 had nothing to do with SIP, VoIP, telecom, IPv6, DNSSEC, security... or any of the other open Internet standards I've been working on in recent years!

In fact, it's not a "standard" at all but rather an "informational" document.

This document collects together a series of best practices for how someone can fill the role of the "jabber scribe" at IETF meetings, such as the IETF 94 meeting about to happen in Yokohama, Japan, starting this weekend. (Which I will not be attending due to scheduling challenges.) You can read RFC 7659 at:

During IETF meetings, individual volunteers often help sessions run more smoothly by relaying information back and forth between the physical meeting room and an associated textual chatroom. Such volunteers are commonly called "Jabber scribes". This document summarizes experience with the Jabber scribe role and provides some suggestions for fulfilling the role at IETF meetings.

The document came about because over the years that I've been involved with the Internet Engineering Task Force (IETF) I've come to both value the critical role the "jabber scribe" can play - and I've also tried to do the best I can to perform that role when I'm in working group sessions at IETF meetings. I typically volunteer as a jabber scribe in any of the sessions I'm in and try to make the experience as good as possible for remote participants.

Largely my interest is because I spent many IETF meetings as a remote participant and I knew how poor that experience can be.

A few years ago after one of the IETF meetings, I made a comment to a couple of people that we ought to write down some of the suggestions and best practices so that people could easily get some ideas for how they could help out in the role. If they were new to the idea... or even if they had been around but were interested in doing the role better.

I kept track of some ideas ... and a small group of us kept occasionally bouncing ideas around... but none of us had the cycles to write the actual document.

Then last year at, I think, the Toronto IETF meeting in July, Peter St. Andre and I were talking about it again - and this time we actually got it off the ground! More precisely, Peter kicked it off and then he and I went through several rounds of revisions and comments.

Given that Peter's authored 35+ RFCs and countless Internet-Drafts (I-Ds), he knows the IETF process inside and out and so was able to guide the document through the publishing process, including having it move through the "independent submission" stream of RFC documents. I've written a number of Internet-Drafts over the years, but none have yet progressed to an RFC. I learned a great bit from Peter through the process and look forward to using that knowledge in the future.

I greatly appreciate Peter's leadership on this - and I hope that this document will be helpful to many folks out there who are helping involve more people remotely in the IETF's standards process.

Given the timezone difference with Japan, I'm not sure how many of the IETF 94 working group sessions I'll actually be able to attend remotely... but if I do, I'll be hoping that whomever is acting as the Jabber scribe will help include those of us who are remote.

Meanwhile, it is kind of fun to have my name on an RFC, even if it's an Informational one. I look forward to being able to play even more of a role in the IETF standards process in the years ahead...

UPDATE: Please see the post "No, it’s not the end of XMPP for Google Talk" on the XMPP Standards Foundation site. The XSF notes that XMPP is still used inside of Google and that XMPP federation can still occur with a third-part XMPP client. However, because Google does not support the secure use of XMPP via TLS, many public XMPP servers will not connect to its server. I join the XSF in wishing that Google would embrace secure messaging and better federation. However, given that their product direction is for Hangouts, which does NOT support XMPP, I'm skeptical that we'll ever see any better federation at this point.

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.

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

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.

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.

Skype today brought its increased integration with Microsoft services to the iPhone and iPad with the new release 4.2.1 available in the iOS AppStore. As you can already do in the Windows, Mac and Android versions of Skype, the big feature is that you can now sign in with your "Microsoft account" and merge our Skype contacts with those from Windows Live Messenger (WLM) and Outlook.com. You will now be able to chat back and forth with your WLM contacts directly from within Skype.

This is very cool from the point-of-view that Skype has always been a "walled garden" of instant messaging (IM) that did not interoperate with any other service. Many of us long ago wound up having to use two IM clients on our system: 1) Skype; and 2) a multi-service client (like Adium or Pidgin) for all the other IM networks. This doesn't quite solve that problem because it is now really just expanding the Skype client to work with two IM networks, but it is at least a step toward greater interop.

Sign in with your Microsoft Account to merge your Windows Live Messenger, Outlook.com and Skype accounts - then IM those contacts direct from Skype.

Ability to edit and delete instant messages

Choose an emoticon while typing an instant message via a new emoticon picker

Animated emoticons for devices with a Retina display

Edit phone numbers from the dial pad

Create a new Skype account when you download the app

UI improvements

Skype's post on their "Big Blog" has a bit more detail and mentions that Skype for iOS has now been downloaded over 120 million times. The improvements to the chat interface, particularly the editing, will definitely be useful. I personally don't really care about the improved emoticons, but I know some people do like those and will be pleased.

My only criticism is that in order to make use of the Microsoft integration you have to log out of your Skype account and then login with your Microsoft account, at which point you presumably can merge the accounts. It's not a big deal to me, as I don't use a "Microsoft account" these days. I certainly did have a WLM login that I used to use years ago, but I haven't used it in years and don't really feel any compelling need to do so. Still, it would be nice if the Microsoft account could just be added to your existing Skype login as you can do in so many other IM clients.

Anyway, Skype 4.2.1 for iOS/iPad/iPhone is now out there and ready for download from the AppStore.

P.S. If you installed Skype 4.2 yesterday, you'll need to go back to the AppStore today to get Skype 4.2.1 as there were some critical bugs that were fixed in 4.2.1.

So which would you rather do? Watch the Royal Wedding? Or talk about all things XMPP with a bunch of VoIP and telephony geeks?

If you'd prefer the latter, then join the VUC conf call at 12 noon US Eastern on Friday, April 29, for a lengthy dive into all things XMPP. (XMPP being the "Extensible Messaging and Presence Protocol" originally known as the Jabber protocol.)

As noted on the show page the session will feature Emil Ivov of Jitsi.org (formerly SIP Communicator) and Thiago Rocha Camargo (of Nimbuzz) and is going to cover a whole range of topics:

What is XMPP/Jabber

How does one do telephony with XMPP

How does XMPP/Jingle compare to SIP and (why) is it better.

Who supports it

Facebook and their XMPP gateway

Google Talk

Nimbuzz – one of the biggest VoIP providers using XMPP as their primary protocol

NAT traversal

How does one do it with XMPP

Again, how is this part different from what we have with SIP

Media relaying with TURN and Jingle Nodes

I am a big fan of XMPP on the IM/messaging side so I'm very much looking forward to this conversation.

Would you like to make it so that when you add someone to a Skype chat they automagically see some of the recent history of the chat? So that people joining a team or a project can rapidly come up to speed on what has been discussed?

This turns out to be ridiculously easy to do in a Skype group chat. An administrator for the chat simply has to type in the chat window:

Joiners can see the conversation that took place before they joined. The limit that they can see is either 400 messages or two weeks of time, depending on which is reached first.

I've enabled this setting on a number of chats for which I am an admin, and it's definitely helped newcomers come up to speed on what is being discussed in the chat. (Of course, some of those chats are very busy and so 400 messages may only take you back a very short period of time.)

Note, again, that you must be an administrator of a Skype chat for this command to actually execute. You can type it if you are just a user in the chat, and Skype won't tell you that it didn't execute... but it won't. You have to be an admin.

BROKEN IN SKYPE 5.1?

Now, having said all this, I recently had two people join a Skype chat and not get any history upon joining. In asking what Skype version they were using, it turned out both were running the new Skype 5.1 on Windows. Did this chat history feature get broken in Skype 5.1? I don't know... and given that I have no Windows machines around to test, I can't tell you for sure.... but I thought I'd mention it in case you have people joining a chat and not getting any history. You may want to find out what version of Skype they are using.

P.S. Note that this is VERY different from the "/history" command in the IRC-style commands for Skype I recently wrote about. The "/history" command loads the chat history ON YOUR COMPUTER into the window for the chat. However, this history is only available for the time that you have been in the chat. You are NOT able to get the history of the chat before you joined. The only way to get that previous history automatically is if an admin set the option described in this post before you joined the chat. Once you are in a chat, the only real way to get chat history is to ask someone else to copy/paste their history either directly to you or in the chat itself.

Many folks who are new to using Skype for group chat may not be aware that Skype brings along some of the commands that are popular in IRC chat systems - and the general "/" style of commands used in IRC. To see the list of commands, simply go into any Skype chat (it could even be a chat with only one other person) and type the following command:

/help

This will work on old and new versions of Skype and will give you a list of what commands are available:

If you are the administrator of a chat, you have access to the full list of commands. You are an admin if you either are the original creator or a chat - or were promoted to an admin by another admin using the /setrole command.

I personally use "/me" a good bit to attempt to add emotion into a text chat (ex. "/me laughs"). I also use /alertson and /alertsoff quite a bit to change whether or not I am notified of new messages in a chat. (I'll note that the recent Skype clients also have a GUI way to do this typically through a menu choice of "Chat Notification Settings...".)

I also administer a number of chats and so use /setrole to give others admin privileges and also /kick and /kickban to remove people from chats.

There are also a few other commands that aren't listed (try /info), but this list has most of the ones I'm aware of.

Anyway, try out these commands... they may help you work more quickly with Skype chats!

What is one reason why many people continue using Skype for chat / instant messaging when so many other solutions are out there? Particularly when Skype chat is a closed, proprietary "walled garden" that doesn't interact with IM networks?

After I wrote recently about being a huge user of Skype, Michael Graves asked in the comments why an organization like Voxeo that is so insanely devoted to open standards (and even uses a tagline of "Unlocked Communications") would use something as closed as Skype?

Being a globally distributed company, Voxeo is an IM-centric organization and we set up "group chats" within Skype for pretty much every activity we're doing. Some of those are long-living group chats for communication within various teams or groups of people. Those chats may continue to exist for literally years and have people added and removed to them over time. Some group chats are created for short-term projects or deliverables. And some may be created ad hoc for resolving quick issues - and then disbanded as soon as the issue is dealt with. If a customer has a problem, an alert may be posted in one of our "main chats" and then a "side chat" is formed with the specific group of people who can help right then to resolve whatever the problem will be.

It's a very effective way to work once you get used to it (and learn how to use Skype's ability to notify you of certain types of activity in chats). I have probably 50+ chats open in my Skype client right now, most of which are having little or no traffic at the moment, but a few of which are having active discussions.

The Power of Persistent Group Chats

But what I described as an IM-centric workflow could be accomplished by any chat system... why Skype? This comes down to the difference between typical "group chat" systems and "persistent group chat" systems.

Here's the basic scenario of why this is so powerful:

1. I GO OFFLINE - Perhaps I'm going offline for a meeting. Maybe I'm about to board a plane. Maybe I'm shutting off my system at the end of the day.

2. PEOPLE DISCUSS ITEMS IN MY ABSENCE - The messages in the chat continue to be exchanged, discussions happen, decisions get made, etc., etc.

3. I COME BACK ONLINE - My meeting is over. I landed at my destination. My work day starts. Whatever...

4. I RECEIVE *ALL* THE MESSAGES THAT OCCURRED IN THE CHAT WHILE I WAS OFFLINE - Bingo... I can just scan through everything that happened while I was offline and get caught up on what happened while I was away. Now this sometimes may take a few minutes (for a reason I'll discuss below) and isn't always perfect, but most of the time it works incredibly well.

There is immense collaboration power in this capability. Given that I travel a good bit speaking at conferences I spend a great deal of time on planes. I'll often be working at the airport prior to departure and will be interacting with others via Skype. I'll close my laptop, fly to wherever I'm going, and then open the laptop back up either at the destination airport or at the hotel or office or wherever. Over the course of a minute or two, my Skype client automagically catches up and gives me the full history (subject to a caveat below) of all the discussions that occurred while I was in transit.

Similarly, with globally distributed teams where we may have engineers in Germany, the US and China all collaborating on a project, persistent group chats allow them to rapidly catch up on what occurred when each group was offline.

Of course, if you are offline for a longer period of time, you might come back to literally thousands of messages and want to just "catch up" and mark all old messages as viewed. This was why I was displeased that Skype removed the "Mark All Viewed" button from the Skype 5.0 Beta for Mac client (and I do hope they'll bring it backUPDATE: Skype did bring the feature back in the production release of the Skype 5.0 Mac client).

UPDATE: - Another aspect of working offline bears mentioning. Recently, I shut down my computer and got on a flight. While in the air, I went through a Skype chat, read all the messages and wrote a whole bunch of responses into the chat. When I landed, I connected to the free WiFi at the airport and Skype went through its sync process, pulling down all the chat messages that occurred while I was in the air and posting to the chat all the messages I had written while in the air. I then shut down and traveled from the airport to my hotel, where I once again opened up my laptop, reconnected with Skype and received all the messages that people had written while I was in transit from the airport.

This ability to read and write while offline is a powerful capability. In the past I've had flights with a long layover and performed a similar process. Reading and writing on the first leg, syncing at the layover to get new messages, and then reading those and responding to them on the second leg of my trip.

But why Skype?

But, you say, there are other "persistent group chat" implementations out there... why Skype? Simply because it is the best implementation of persistent group chats we've found so far. Add to that the simplicity of usage, the fact that it has a solid Mac client (and we're a Mac shop), the fact that it can connect from pretty much any location we're in... and the fact that it uses encrypted communication channels.

Having said all this, we're not wed to Skype.... we certainly keep an eye out on other communication tools and have a number of ideas ourselves... if we found something that worked as well and had an open architecture, we'd certainly look at it... but today we use what works - and works well.

The Technology Behind Skype's Persistent Group Chats

If you think about Skype's P2P architecture a bit, the technology behind their implementation of persistent group chats is intriguing. In a typical client/server IM network (like AIM, Yahoo, Jabber, IRC, etc.), the clients are communicating with a server and all the chat messages are stored on the server. Other server-based systems can implement persistent group chats by storing all the messages on the server and then sending them out to clients that re-connect to the server.

But with Skype, there are no servers. Instead, the chat messages get stored in the fabric of the P2P overlay network that interconnects the Skype clients to each other - and more specifically within each of the various Skype clients participating in the group chat.

When your Skype client comes back online, it initiates connections out to other clients that are members of the same chat and requests updates for what messages were sent in the chat while your client was offline. I don't know the exact number of clients your client will reach out to, but conversations with folks from Skype in the past seemed to indicate your client would reach out to a maximum of 15 other clients to find out what was in the chat. (Assuming there are more than 15 people in the chat. If not, obviously it only reaches out to those clients in the chat.)

For EACH group chat that you have.

So if you have a lot of Skype group chats, like I do, you can understand why Skype might trigger security systems at hotels when it goes off to do its initial sync with other Skype clients, purely by the sheer volume of network connections it opens up.

This does bring up one caveat with Skype that I referenced above. Depending upon the size of the chat and the availability of all participants, the full history may not be immediately available. If you are in a chat with 4 people, and the other 3 are offline when you come back online, you won't see the history until others come online. If one other person is online, you will get the history from that other client... which may be the full history, depending upon whether that client was online all the time. You see where I'm going with this... it may take a bit for you to get the full history.

In larger chats, I've seen less of an issue with this because odds are that more people will be online at any time and so your client can receive updates (although there is an edge case that I'll write about sometime). In smaller chats, though, I've seen update issues like this.

All in all it is an intriguing implementation from a technology point-of-view... as someone working with networks for years, I admit to being fascinated by it all. :-)

What if you could have customers call in to your call center from directly within your web browser? No "click to call" that calls them back on their cell phone... but literally just press a button on your web site and start talking? And get connected directly to the team appropriate to the web page rather than a generic inbox?

What if you could do this with more than just voice... but also video? screen sharing? with better audio quality than the legacy telephony network (the PSTN)?

What if you could also add in live chat sessions directly from your website? Giving you true multi-channel interaction with your customers?

And what if you could do this without any downloads by the customer?

Even better... what if this could be done with your branding? and connecting to ANY IP communications system?

Announcing Phono

Today at the JQuery Conference in Boston, the Voxeo Labs team is announcing Phono a new software development kit that lets you create apps just like the ones I mentioned. It's free, it's "skinnable" and it works with any systems that use SIP or XMPP (Jabber). More info here:

You can use it to connect to your IP-PBX... to applications on platforms like Tropo... or really any other IP communications / Unified Communications platform.

FAR More Than Just A Softphone

That last part is really the point... the Phono SDK being shown today is far more than "just" a softphone. Sure... that's what some of the first reference implementations are all about. Things like Twelephone that let you easily call all your Twitter friends... or Facebook Telephone that lets you call your Facebook Friends. You'll see some more apps like that in the coming weeks.

But Phono is more than that...

Phono is a toolkit for Rewiring the Real-time Web

We as an industry need to drop the shackles of the legacy telephone network... we need to move beyond the PSTN in true rich collaboration between people... wherever they may be.

Are you interested in how you can service customer requests across all the different communication channels they might use? Do you want to give your customers a choice in the way they interact with you? Rather than requiring them to call in to a customer service phone number, do you want to let them send you a text message? Or an IM? Or use Twitter?

Perhaps obviously to long-time readers, I have an interest in the "social" side of the communication, particularly as we talk about "Social CRM" and engaging with customers through social channels. You can naturally expect to hear me talk about that tomorrow as well.