Disruptive Telephony

In one picture, this comic from xkcd nails the very sad state of fragmentation with our messaging systems today. The text says:

I have a hard time keeping track of which contacts use which chat systems.

And that is our major pain point today.

Think about it... do you know how to reach most of the people you need to communicate with?

Some readers may have just decided that they are going to ONLY use one service. They communicate on only, say, Facebook. Or WhatsApp. (Or in one case I know, someone has rejected all new messaging apps and will only communicate with email.)

And so if you want to communicate with them you have to use their one service.

But of course, if you want to communicate with other people, you have to use their service... which leads to this comic and the mental energy we all must expend to remember (names are made up):

• George likes to get Twitter DMs
• Sue and Jose only use Facebook Messenger
• Carlos only uses WhatsApp
• Heidi, Frederick and Laura only use Wire
• Your parents all use iMessage... except when they decide to use Facebook Messenger
• Your teenage kids ignore most messages except on Snapchat
• Nick only responds to Instagram DMs
• Jon is old-skool and can only be found on IRC
• Your work colleagues are best found on Slack... except a couple are also Facebook friends so you can reach them that way... and a couple of others are on Twitter and so you can reach them there
• Your friend in Asia prefers WeChat
• A number of people you know use Matrix and Riot.im
• and...
• and...
• and... the list goes on...

Think about the sheer amount of thought processing and memory we all must expend to keep this all straight in our heads! And yes, some tools and contact/address books can help... as can some clients.

But it's a mess.

Two years ago I wrote about why I thought that some degree of centralization was inevitable: The Directory Dilemma - Why Facebook, Google and Skype May Win the Mobile App War.

I still believe the "directory dilemma" is the key issue here. All this fragmentation can't last.

Naturally the large players would like us all to forget about the others and move all our messaging to be inside of Facebook Messenger, or iMessage, or WhatsApp. They have zero interest in sharing or federating because they are all about the lock-in and keeping people inside their pretty walled gardens.

And groups like Matrix.org are working on creating the kind of distributed, decentralized messaging I'd like to see. But they run into the issue that it's hard to do that in a way that's simple and easy to an end user.

We don't care about where Fred sends messages...

... we just want to reach Fred.

I do worry that in the end all our messaging will be inside the private, commercial walled gardens, because people will default to the ease of finding people. The big directories will win.

Right now it's a mess.

What do you think? What is our path out of this mess?

A related audio commentary is available:

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:

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

As the abstract states:

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

GoogleTalk is dead, Jim!

By way of a comment to a post I wrote back in May 2013 about Google seeming to kill off XMPP/Jabber support in Google+ Hangouts (spoiler: They did!), I learned from a friend that the GoogleTalk API was officially deprecated as of February 23, 2015. I confirmed this by finding a Google+ post from Google's Mayur Kamat.

Now, this is not a surprise. Google has been clear that Hangouts was the replacement and also that Hangouts does not support XMPP:

Still, I'm sad to see the XMPP integration die off. It is just a continuation of the descent of messaging services into walled gardens ... a topic I've been writing about for many years.

On that note, it was really no surprise to see the media reports about Microsoft killing off Google and Facebook chat support in its Outlook.com service. Microsoft made this Google integration available back in May 2013, but today Microsoft really has no choice:

• Google has killed off XMPP integration with Hangouts.
• Facebook has killed off XMPP integration with their new v2.0 API.

And so Microsoft can only offer Outlook.com its own proprietary walled garden... Skype!

Goodbye GoogleTalk and... sadly... goodbye XMPP integration!

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

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.

In a post on Skype's "Garage" blog, Beom Soo Park indicates these new features:

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

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

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

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.

You can join the live call via SIP, Skype or the regular old PSTN. There is also an IRC backchannel that gets heavy usage during the call. It will be recorded so you can always listen later.

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

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

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:

/set options +HISTORY_DISCLOSED

After this, anyone joining the chat will see recent history. Per Skype's FAQ on chat commands:

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.

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

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

/help

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

Available commands:
/add [skypename]
/help
/topic [new topic]
/me
/history
/leave
/goadmin
/get creator
/get role
/whois [skypename]
/setrole [skypename] MASTER|HELPER|USER|LISTENER
/kick [skypename]
/kickban [skypename]
/get guidelines
/set guidelines [text]
/get options [text]
/set options [[+|-]flag] ...
/setpassword [password] [password hint]
/clearpassword
/get password_hint
/set password_hint [text]
/set password [text]
/get banlist
/get allowlist
/set banlist [[+|-]mask] ...
/set allowlist [[+|-]mask] ...
/alertson [text to match]
/alertsoff
/call [skypename[,skypename,...]]

You simply type any of these commands into a chat and, assuming you have permission to run the command, the action will occur. The full list of commands and options is available at this URL:

http://www.skype.com/go/help.chathelp

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!

P.S. Users of Skype 5.0 have an additional command, "/golive", that I described in an earlier post and that provides a simple way to launch conference calls.

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

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

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?

It's a great question, and while I answered his comment, it bears a bit more exploration.

In 3 words, the largest reason for using Skype is this:

persistent group chats

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

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

P.S. It's amusing to also look at what I wrote about Skype's persistent group chats back in January 2007... little did I know how much I would come to use them!

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

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

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:

• Phono.com is Live!
• Hello PhonoSDK!
• PhonoSDK Demo

The Phono SDK is free to download and use. You can also naturally follow Phono on Twitter or Facebook.

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.

Voice, chat, video, screensharing... whatever mode they want to work in... from basic web browsers to mobile devices...

Phono is our contribution to that... and to taking away friction from developers wanting to build communications apps that make the most of the new tools and media we have available to us.

Try it out!

We're excited to see what you'll do with it!

Extra bonus... here's a video intro:

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

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