Disruptive Telephony

IETF Journal for October 2011 Digs into DNSSEC, Port Control Protocol, Internet Evolution

Want to learn more about what is happening with regard to standards in the Internet Engineering Task Force (IETF)?  Want to understand the details about new proposals to offer another way to secure domains using DNSSEC? Never heard of the "Port Control Protocol" before and wonder how it may (or may not) help you? Want to understand some of the latest thoughts from Internet leaders about where the Internet is evolving?

The October 2011 edition of the IETF Journal gets into all of that and more. Here's the Table of Contents  (a PDF is also available for printing or ebook reading):

• From the Editor’s Desk
• DANE: Taking TLS Authentication to the Next Level Using DNSSEC
• Message from the IETF Chair
• Words from the IAB Chair
• ISOC Panel Addresses Regulation, Innovation, and the Internet
• IAB Plenary Tackles IPv6, Privacy Issues
• New Technology Demo: PCP
• Internet Society Fellows to the IETF Increase Participation on a Global Scale
• IETF Ornithology: Recent Sightings
• IETF 81 At–A–Glance
• IRTF Update
• IETF Meeting Calendar

The IETF Journal is published three times a year and past (and future) versions can be found at:

http://isoc.org/wp/ietfjournal/

If you would like to be alerted to future editions - or would like to contribute articles - more information can be found on that page.
 

---

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

---

My Rant: Who Are We Building RTCWEB/WebRTC For? Telephony Developers or Web Developers?

Yesterday morning I did something I haven't done in eons. Many years, probably. (I can't remember.) I fired off a "rant" on an IETF mailing list.

I've been a huge proponent of the "RTCWEB/WebRTC" work going on in the "RTCWEB" Working of the IETF and the "WebRTC" of the W3C. I've mentioned it in many of my presentations. I've advocated for people to join the mailing lists. I've written about it a good bit on Voxeo's standards blog when I was at Voxeo.

We have an opportunity to make it easy for web developers to add "real-time communications" via voice, video, IM, etc., to web applications. We can make that work from directly within the browser.

Think of it... HTML5 with the ability to quickly add voice, video, chat... and without the need for a browser plugin or extension in Flash, Java, etc. (the limitation of all of today's proprietary options).

It's the opportunity to move real-time communications into the very fabric of the Web.

Awesome potential!

The work has been moving along quite rapidly in both the IETF and the W3C. Extremely active (high-volume!) mailing lists. Many Internet-Draft documents being created. Regular conference calls, interim meetings, face-to-face meetings. Some truly brilliant - and passionate - people involved. (Read the RTCWEB overview Internet-Draft for more background.)

But I still can't escape the feeling that the direction isn't quite right... as a friend said to me:

my feeling is that this is being appoached as SIP 5.6.2 - a minor tweak on an established standard - not WebRTC 0.9 - a new dawn in a new world.

I haven't honestly had the time to read all the messages with the crazy amount of traffic (which is good - shows people are passionate about the topic!), but I've felt increasingly frustrated with reading the messages that I have read that we're collectively in the midst of developing something that few developers will actually use.

So I ranted. Will it do any good? Maybe. Maybe not.

What the rant really needs is to be backed up by people who have the time to join in the process and contribute suggestions for how a RTC API that would appeal to "web developers" would look like.

Care to help out? The mailing list is open to anyone to join.

Anyway here's the rant... (and yes, for the truly pedantic, I am very aware that I ended with a </rant> but did not start with a <rant>)...

---

Folks,

I need to rant. I've been lurking on this list from the beginning but with a new job I haven't been able to really keep up with the volume of messages... and every time I get ready to reply I find that others like Hadriel, Tim, Neil, Tolga or others have made the points I was going to make...

But I find myself increasingly frustrated with the ongoing discussions and want to ask a fundamental question:

- WHO ARE WE BUILDING RTCWEB/WEBRTC FOR?

Is it for:

1. Telephony developers who are tired of writing code in traditional languages and want to do things in new web ways;

2. Web developers who want to add real-time comms (as in voice, video and chat) to their existing or new web applications;

3. Both 1 and 2.

If the answer is #1, then I think everything is going along just wonderfully. We can go ahead and use the SIP/SDP/etc. stuff that we all in the RAI area are all used to and understand just fine. Heck, let's just all end the discussions about a signalling protocol and agree on SIP... get the browser vendors to agree on baking a SIP UA into their browsers... and call it a day and go have a beer. Simple. Easy. Done.

And the only people who will ever use it will be people who work for RTC/UC/VoIP vendors and random other programmers who actually care about telephony, etc.

But that's okay, because the people who do use it (and their employers) will be really happy and life will be good.

If the answer is #2, then I think we need to step back and ask -

HOW DO "WEB DEVELOPERS" REALLY WANT TO WORK?

Here's the thing... in my experience...

99% OF WEB DEVELOPERS DON'T GIVE A ______ ABOUT TELEPHONY!

Never have. Never will. (In fact, I may be understating that. It may actually be 99.99999%.)

If they are with startups, they want to build nice bright shiny objects that people will chase and use. They want to make the next Twitter or FourSquare or (pick your cool service that everyone salivates over). If they are with more established companies, they want to create easy-to-use interfaces that expose data or information in new and interesting ways or allow users to interact with their web apps in new and useful ways.

And they want to do all this using the "languages of the web"... JavaScript, PHP, Ruby, Python, etc.

They want "easily consumable" APIs where they can just look at a web page of documentation and understand in a few minutes how they can add functionality to their app using simple REST calls or adding snippets of code to their web page. Their interaction with telephony is more along these lines:

"Wow, dude, all I have to do is get an authorization token and curl this URL with my token and a phone number and I can create a phone call!"

And the thing is... they can do this **TODAY** with existing proprietary products and services. You can code it all up in Flex/Flash. You can write it in Java. You can use Voxeo's Phono. You could probably do it in Microsoft's Silverlight. I seem to recall Twilio having a web browser client. A bunch of the carriers/operators are starting to offer their own ways of doing this. On any given week there are probably a dozen new startups out there with their own ideas for a new proprietary, locked-in way of doing RTC via web browsers.

Web developers don't *NEED* this RTCWEB/WebRTC work to do real-time communications between browsers.

It can be done today. Now.

The drawback is that today you need to have some kind of applet/plugin/extension downloaded to the browser to allow access to the mic and speakers and make the RTC actually work. So you have to use some Flash or Java or something. AND... you are locked into some particular vendor's way of doing things and are reliant on that vendor being around.

THAT is what RTCWEB can overcome. Make it so that web developers can easily add RTC to their web apps without requiring any downloads, etc. Make it do-able in open standards that don't lock developers in to a specific product or vendor.

But if we are targeting "web developers", that is who we need to satisfy... and we need to understand that they *already* have ways to do what we are allowing them to do.

If we come out with something that is so "different" from what "web developers" are used to... that requires someone to, for instance, understand all of what SIP is about... that requires a whole bunch of lines of code, etc.... well...

... the web developers out there will NOT launch an "Occupy RTCWEB" movement claiming that they are the "99% who don't care about telephony"... they will simply... not... use.... RTCWEB!

They will continue to use proprietary products and services because those work in the ways that web developers are used to and they make it simple for a web developer to go add voice, video and chat to a web app. Sure... they will still require the dreaded plugin/extension, but so be it... the "open standard" way is far too complicated for them to look at.

And all the work and the zillions of hours of writing emails and I-Ds that this group has done will all be for nothing. Well, not nothing... some of the telephony-centric developers will use them. But the majority of the web developers out there may not because there are other simpler, easier ways to do what they need to do.

So I go back to the question - who are we building RTCWEB for?

Is the goal to enable the zillions of web developers out to be able to use real-time communications in new and innovative ways? Or is it solely to make it so that VoIP/UC/RTC vendors can make a softphone in the browser that calls into their call center software?

RTCWEB *can* enable both... but to me it's a question of where the priority is.

The question is - will the RTCWEB/WEBRTC API/protocol/whatever be so simple and easy that web developers will choose to use it over Flash/Phono/Twilio/Java/whatever to add RTC functions to their web apps?

If the answer is yes, we win. Open standards win. Maybe we upgrade from having a beer to having champagne.

If the answer is no, what are spending all this time for?

</rant>

Dan

---

NOTE: And, as I suppose must be the case with any good rant, mine was not entirely accurate. As multiple people pointed out (one example), my ending where I ask about whether people would choose the RTCWEB/WebRTC API over Flash/Phono/Twilio/Java/whatever is not entirely on target. The question is really... will vendors creating libraries like Phono choose to use the RTCWEB/WebRTC protocols/APIs or will they continue to use their own proprietary solutions?

As people pointed out, there will be a hundred different JavaScript libraries created (like Phono) that will consume the RTCWEB work... and most web developers will use those libraries and not program directly with the RTWEB/WebRTC APIs and protocols.

Fair enough... but the question remains - will the RTCWEB work make it easy enough for all those JavaScript libraries to blossom?

Others pointed out that I'm really talking about the web API that would be exposed via the W3C's work versus the low-level API coming out of the IETF. And yes, that is perhaps technically true... but the reality is that it is the same set of people working in two different mailing lists... and both efforts are contributing to the end result.

In the end, I want to see a result of all this RTCWEB/WebRTC work that developers will actually deploy and use!

I want open standards to win.

---

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

---

Dilbert Nails One Of The Inherent Challenges of Standards

Dilbert nails it... (back in August 2011)

---

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

---

The 2 Big, Glaring Failures of the "Voice 3.0" Manifesto

Today Alec Saunders posted a truly brilliant piece: Voice 3.0: The Emergence of the Voice Web. It's a much-needed update to his 2005 "Voice 2.0 Manifesto" and very nicely brings together much of the thinking about telecom today. (And yes, I had a chance to review it and provided feedback before it went live.)

It's brilliant. It's long. You really need to go and read it. It includes many of the themes we'll be talking about next week at eComm. It's right about so many things.

IT'S ALSO VERY WRONG.

The document as written has two big, glaring omissions.

---

Voice Doesn't Matter... As Much

First off... the piece is all about voice. Which is great. But here's a reality check:

People do NOT want to communicate by ONLY voice.

I spend my day communicating with people all over the world... in pretty much constant "real-time" communication. But almost NONE of it is by voice.

Instead it is by IM... by Twitter... by Facebook... by SMS... even by email. All text-based mediums.

No voice.

Now occasionally I do actually speak with someone - and usually get startled when my phone or Skype actually rings. But the majority of my communication happens outside of voice.

I wrote about this evolution of communication four years ago ... and it has only continued to evolve to a situation where voice is only one of the available communication channels... and not even the primary communication channel.

I'd argue this trend is only going to continue. Voxeo commissioned some research by Opus Research a year ago where they surveyed consumer preference. The demographic shift is pretty clear in charts like this one:

Look at the purple bar for consumers aged 45-54 ... then look at the blue bar for consumers aged 18-24.

See the "wave"?

We live in a world of ubiquitous mobility ... a world where we use mobile devices accessing cloud-based services and interacting with social networks and other similar services.

Sometimes by voice.

So to Alec's three "Defining Themes", I would add a fourth theme of Voice 3.0, which is the rise of multi-channel communication and the evolution of voice to "just another channel".

In the new world of communication, it is about:

Enabling customers to connect with you in the channel of their choice.

All that Alec wrote about the other themes of Voice 3.0 will be true ... but merged into a broader context in which voice is simply one of the available communication channels. Alec writes:

The service package will include not just voice, but detailed statistics, group management controls, and more. And it will bristle with API’s that will enable an ecosystem of other players to be built around it.

I would argue that it is better stated:

The service package will include not just voice, but the ability to communicate across a wide variety of channels, supported by detailed statistics, group management controls, and more. And it will bristle with API’s that will enable an ecosystem of other players to be built around it.

Don't get me wrong... I'm not arguing that voice telephony will go away. It will be here with us probably forever. And there are certainly times when we need and want to use voice. But not always - and maybe not primarily.

"Voice 3.0" needs to recognize this evolution.

---

Voice 3.0 Must Be Open

The second omission I see is perhaps more of a philosophical and personal one. I firmly believe that for voice to continue to be relevant and in fact to potentially grow in usage, Voice 3.0 must be based on open standards and not locking people in to specific services or providers.

Alec nails it with regard to the success of the Web (my emphasis added):

The web went from being a hyperlinked text library, to the largest programmable application on the planet, fuelled by open standards, lightweight communications infrastructure, standards which allowed content to be separated from logic and presentation, and an explosion of end-user devices, including today’s mobile devices.

He goes on to say:

Voice is on the cusp of the same revolution – a revolution that will be defined by letting the customer define the business logic of the application, not the service provider.

But then he doesn't quite bring it home. He says later again a similar thread (my emphasis added):

Ultimately, we’ll build systems where communications result in artefacts that can be consumed by services that have not been pre-specified. Think, for example, of the role that RSS played in the syndication of content, and imagine a similar world for voice. Tool chains will be created that will allow people to participate in building these services, and an explosion of new applications to consume these voice artefacts will be built.

The key here is that RSS is an open standard..

Alec in fact concludes with this (again, my emphasis added):

Network effects in the Voice 3.0 world become even more important. Will an open standard emerge? Although many die-hard networking folks would prefer that scenario, it’s hard to say. We may find ourselves in a world where a dominant proprietary player like Skype controls the platform, as a result of winning the race to build thriving developer ecosystems, and the applications that customers use and want.

Perhaps I am just part of the "die-hard networking folks", but I do believe that for voice to truly be integrated with the rest of the Web... for the "Voice Web" to emerge that Alec writes of in his title... for all the amazing new opportunities to emerge and "explode onto the scene"... for all of that to occur, Voice 3.0 needs to be based on open standards.

In fact, I would re-write his "web" paragraph with a voice spin:

Voice went from being an obscure medium locked up in proprietary/legacy telco control, to the largest programmable application on the planet, fueled by open standards, lightweight communications infrastructure, standards which allowed content to be separated from logic and presentation, and an explosion of end-user devices, including today’s mobile devices.

That is Voice 3.0.

And that is the fifth defining theme, being based on open standards that move control to the users and developers instead of the providers.

---

Again, you NEED to read Alec's full Voice 3.0 piece. It's an outstanding piece that is very well done.

Despite what I've written here, I do believe Alec's piece gets it right... subject to my modifications. :-)

And then please add your view on this. Do you agree with me about these additions? Do you think I'm wrong? Please leave comments here - or write your own piece and leave a link here in the comments. Comment on Alec's piece... comment on Twitter or Facebook... talk to us at eComm next week...

Where do you see "Voice 3.0" going?

---

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

---

How Does IPv6 Impact Telecom Networks? Join This Free Online Session Tomorrow To Learn...

How does IPv6 impact telecommunications networks? How will IPv6 affect the SIP protocol? If you work in telecom, what should you be aware of with regard to IPv6? With World IPv6 Day only a week away, if you have been wondering about these kind of questions, please feel free to join me live in a free session hosted by the US Telecommunications Association:

IPv6 and Telecom Networks
Thursday, June 2, 2011
1:00pm US Eastern

Registration is free and if you are unable to attend it will be recorded for later viewing. (And if you register now, you'll be notified when the archive is available for viewing.) The description of the session is:

The networks that make up the Internet and IP communications are in the middle of a sea-change with the transition to IPv6. What impact will IPv6 have on telecom and communications networks?

Join USTelecom and Voxeo for a look at the various challenges that telecom and broadband services providers face in keeping their communication services working while transitioning to IPv6.

I'll be explaining briefly why there is all the attention on IPv6 then getting into the basics of IPv6 addressing. After a brief overview, I'll then dive into how IPv6 affects the Session Initiation Protocol (SIP) and get into some technical detail. I'll then wrap up with some resources about how to learn more and get started with IPv6 and finish with a Q&A session.

If you attended the Voxeo Developer Jam Session I presented back in May on IPv6, I'm going to be covering basically the same material although with a vendor-neutral perspective (i.e. I won't be explaining and demonstrating how Voxeo Prophecy and PRISM now natively support IPv6). Obviously the live Q&A session will be new, too, and I find the questions around IPv6 always quite fun to discuss.

Please feel free to join us at 1pm US Eastern tomorrow. Registration is free - and if you can't join live the session will be archived and available for viewing on US Telecom's website for 90 days. With World IPv6 Day coming up on June 8th, it's a great time to learn about what is going on with IPv6!

P.S. If you are interested in IPv6 in general, you may be interested in the IPv6 Resource Page I put together for Voxeo at:

http://bit.ly/voxeoipv6

Lots of good links to tutorials, VoIP resources and more...

---

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

---

Watch the Royal Wedding? Or talk about XMPP? Join VUC on April 29th for an XMPP-fest

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.

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

---

NetworkWorld interviews SIP pioneer and now Skyper Jonathan Rosenberg

This week Network World ran a great interview with Jonathan Rosenberg about his new role at Skype. Jonathan is now the "Chief Technology Strategist" at Skype, but he's known in the industry as one of the co-authors of the original RFC 3261 that defines the Session Initiation Protocol (SIP) and also for his many years working at Cisco. He's been extremely active within the IETF, writing a seriously large quantity of Internet-Drafts. I think, in fact, I first met JDR at an IETF meeting... and subsequently was on at least one panel with him (I think a VoiceCon or Interop in New York).

It's been interesting to watch Skype accumulate more and more people with strong SIP backgrounds, and hiring Jonathan was definitely an interesting - and good - move on Skype's part.

I don't know that the Network World interview broke any amazing new ground for those of us who have been watching Skype closely, but if you haven't been paying attention to Skype, Jonathan gives a great view into what the company has been doing lately and where it is going. It is definitely worth a read.

---

If you found this post interesting or useful, please consider either subscribing to the RSS feed, following me on Twitter or subscribing to my email newsletter.

---

What is new in VoiceXML 3? Join this free webinar tomorrow (May 20)

What is different in the upcoming VoiceXML 3 specification from the W3C? How will it help you create better communication applications? How can you get ready for VXML 3?

If you are curious about what the VoiceXML 3 effort is all about, Voxeo is hosting a free webinar tomorrow, Thursday, May 20, 2010, at 11 am US Eastern time where one of the co-chief editors of the specification, Dan Burnett, will talk about these questions and more.

Registration is free and you can register online. It should be a very informative session.

---

If you found this post interesting or useful, please consider either subscribing to the RSS feed, following me on Twitter or subscribing to my email newsletter.

---

IETF 74 starts next week in San Francisco...

The 74th meeting of the Internet Engineering Task Force (IETF) starts Monday morning out in San Francisco. As usual there is a packed agenda with a lot of great discussions going on. This one is particularly interesting for those of us involved in the "Real-time Applications and Infrastructure (RAI)" area - which is all the various working groups related to SIP and other real-time communications protocols - as there are some proposals moving forward to rather fundamentally restructure the ways in which SIP-related work moves through the IETF. I expect there will be many involved conversations going on out there next week.

As much as I would like to be there, I won't be physically out at IETF 74. It's not my new role at Voxeo keeping me away, but rather this... oh... wee minor little detail that my wife is now five weeks from giving birth to our second child! :-) At this stage of things I'm severely limiting my travel - and flights across the country are definitely out.

Instead I'll be participating remotely, listening to the audio streams and joining in the Jabber chat rooms. Probably writing about some of it over on the "Speaking of Standards" blog I write in from time to time. The great thing with IETF meetings is that you can participate remotely (albeit obviously not to the same level of effectiveness as being in the room).

Lots of good stuff going on...

---

If you found this post interesting or useful, please consider either subscribing to the RSS feed or following me on Twitter or identi.ca.

---

Technorati Tags: ietf, standards, sip

Do the IM protocol wars even matter? Adium and the continued *client* unification of IM...

Do you care any more about zillion different IM services? Do you care about the IM protocol wars that have plagued the usage of IM for the last years?

Odds are that if you are an IM user like me, you probably don't. Why not? Simple... we've unified the IM services on the client side and basically stopped caring about the various services and protocols.

I was reminded of this fact this morning when I received a message saying that an update was available for Adium on my Mac that solved a really annoying disconnection problem with Yahoo!Messenger. (And if you are a Yahoo IM user, you really need to get the 1.3.2b1 beta.)

[NOTE: An equivalent to Adium for Windows or Unix/Linux users is Pidgin.]

Somewhat ironically, there was a discussion going on in a Skype groupchat in which I participate about the various IM protocols and whether anyone really used GTalk, etc. Since I was updating Adium at the time, I took a moment to look at all the different protocols that Adium now supports... as seen in the screenshot on the right side of this post. If I look at my own usage, I use Adium to unify:

• AIM (two accounts)
• MSN/Windows Live Messenger
• Yahoo!Messenger (two accounts)
• Google Talk
• Jabber (two more other than GTalk)
• LiveJournal
• Facebook
• Bonjour

All of those in one client with one directory of users and one window for chats (each on their own tab - and yes, I could have chats in separate windows but I generally choose not to do so).

It's a beautiful thing.

Now you might say... so why do you have all these services, anyway? Well, I've been online since the mid-1980's and generally my work has always involved keeping up with new technology, so I've always dabbled in various services and slowly you develop this accretion of new IM accounts - each that different friends and others use. At one point I did run multiple clients but now just for my own sanity I use just one IM client (actually two, but more on that below).

THE ENTERPRISE ANGLE

The curious aspect that caught my attention was the support Adium has for enterprise IM systems. The list directly includes Lotus Sametime and Novell GroupWise. Jabber support can of course work with internal Jabber servers and SIP/SIMPLE support could work with platforms supporting SIMPLE. Does that include Microsoft OCS? I don't know, but it would be interesting if it did.

What's great about all this is that you again have a single IM client that lets you have a single directory for corporate contacts as well as personal contacts. Adium's interface nicely lets you have a single entry for a person with multiple IM contacts, so you can unify your directory to be able to reach people in different contexts.

THE DOWN SIDE

The down side of a single client is that of course you are in the old "jack of all trades, master of none" scenario. You can receive IM messages from all the various services. You can send IM messages to them. But you can't necessarily use all the features of the given service. You have one set of status states, which may or may not map to all the status states available on your service (for instance, maybe the IM service has a status "out for dinner"). I haven't tried it with recent Adium builds, but in the past when I wanted to do an encrypted Jabber session, I had to switch to using Psi. I haven't tried file transfer using the various services via Adium, so I don't know how that works. I'm not aware that voice and video works over those services via Adium. Each IM service tries to differentiate with unique features - and they aren't always supported by all-in-one clients like Adium.

The other down side is "status messages" or "mood messages" that you can set in the IM clients. I have absolutely no idea what my status message in GTalk is, for instance, because I never use it in its native form in a web browser or as a standalone client. I have no idea what my MSN advisory message is for the same reason. Now maybe there's a way to set that in Adium which I don't know about... but maybe not. It's the price you pay for using a unified client.

Now, on the plus side, you never see the ads that IM services wrap their own IM clients in. (Which of course is a down side for the service provider.)

THE MISSING IM SERVICE

If you look at that long list of IM services with which Adium can interconnect, there is one obvious glaring omission:

Skype

When I wrote earlier that I actually have to run two IM clients, it's because Skype does not allow Adium (or other all-in-one IM clients) to interconnect to its network. So I run two IM clients:

• Skype to IM with Skype contacts
• Adium to IM with contacts on all the other services

Now the reality is that I can't see technically how a client like Adium would join into the P2P clouds that make up Skype groupchats. Skype's P2P architecture is very different from the server-based architecture of all the services listed above. So it may be that such an interconnect may not be possible for group chats... and since I use those extensively, I might always have to be running the Skype client natively. Still, there might be a way to interconnect via SIP/SIMPLE... and perhaps that's something Skype will consider as part of the larger Skype interconnect issues.

SO DO WE CARE ABOUT IM PROTOCOL WARS?

I don't. I've opted out of the battle by using a unified IM client. Sure, I may lose out on some of the unique features of the different services... but I have one directory and one way to send and receive IM messages.

What about you? Do you use a unified IM client like Adium or Pidgin? Or do you run multiple clients? Or do you only use one service?

P.S. Walt Mossberg over at the Wall Street Journal had a post on this issue reviewing some other clients back in August.

Technorati Tags: im, adium, pidgin, yahoo, googletalk, aim, skype, jabber, collaboration