A real dial-tone

The concept of “killer app” is a powerful driver of our collective psychology. We want to believe that our entire community can be propelled forward and our lives reshaped by the next must-have technology. A search on “VoIP killer app” will give you an idea of the extend of this belief...
It's hard to get people excited about new frontiers and possibilities. Painting vivid and exciting pictures is not enough. They need to be credible. I earlier hinted at some of the reasons for considering presence the “new dial-tone”. Alec Saunders also looked at the decreasing value of Skype presence. I believe that his post is characteristic of many misconceptions attached to presence (in short IM is not presence, and AOL is not IM), although he probably wrote it on purpose... That said, he re-stated the major flaws of today's combined IM/VoIP messaging

• Presence tells you nothing about the person using the device at the other end. For example, it doesn’t indicate that I am talking when I am in a call.
• Presence gives me little to no control over who can reach me.
• Presence does not express my willingness to communicate.

I agree when he says the word presence cannot properly express whether I am willing to engage in a conversation. Same when he says we really mean availability, i.e. the result of processing presence information according to rules about our reachability. But this is yesterday's news. This difference was entirely detailed by the PAM forum many years ago. On the other hand, I believe Saunders is wrong when he says presence is a broken idea. He should have said the implementation of presence in all the existing IM or VoIP applications is broken. Not the idea of presence.

Generating the “new dial-tone” requires a tight integration between the presence aggregation engine, the availability inference engine and the presence notification engine. I will quickly expose why I believe XMPP as a protocol have a more appropriate design to support this integration and produce an accurate and useful dial-tone. A dial-tone that would signal busy when you do not want to be disturbed, and be your voice mail's dial-tone when you are in a meeting.

When establishing a point to point a voice communication, presence does not appear necessary. And de-facto, many VoIP services are only mimicking the PSTN model with a different technology. So much for those trying to make you believe they are “re-inventing telephony”. In doing so, VoIP is a bit of a side show. Establishing a bidirectional audio stream over a network is also yesterday’s news. VoIP only gets all the attention because of the PSTN charges and the sustained rush to mine them. Nonetheless, attempts at combining multimedia communications with presence have been around, at least on paper, for some times. Some implementations, such as Skype, call presence the information derived from authenticating on their system. AOL, along with other legacy services, is coming at VoIP from the instant messaging side. By adding voice to a client, it can claim offering a presence enabled VoIP service. Another interesting implementation is the upcoming 3GPP mobile phone service. The most courageous amongst you may read their thousand of specification pages to have an idea of how the carriers' world wants to use SIP presence extensions.

All these implementations have in common a “loose coupling” at protocol level between presence and call management. Skype's presence is irrelevant. AOL use a mix of proprietary instant messaging protocol with SIP signaling for the media sessions. The 3GPP IMS is SIP based, but provides presence as an “added value” service through the SIMPLE extensions to SIP.
SIP is a respectable player when it comes to negotiating point to point call sessions. It carries the weight of some big industry names behind it. But this concerns only SIP, not the integration of its presence extensions. How many SIP phones on the market implement the SIMPLE extensions? How many phones implementing these extensions actually use presence as a way to indicate willingness to communicate? How many presence enabled phones actually change automatically the presence status to "on the phone" when the call is in progress (The same could be said from AOL's Triton client)? By offering presence as a service the telecom world is taking the wrong road.

You could say that it would be easy to integrate these different protocols in the client. I agree that setting a status to "on the phone" is easily implemented in a client (I actually wonder why current SIP phones or clients are not doing it, don't you?) On the other hand, deriving availability from the aggregated presence information requires a close collaboration at the protocol level between the presence and call management. This is where, in my opinion, XMPP has an advantage. XMPP is a presence based protocol. Not only do all IM client applications receive notification of presence state changes, but many non IM XMPP applications are natively presence enabled. These application will only provide their services to you when you express certain presence states. Such applications today range from IM federation gateways to news feed aggregators and generic publish-subscribe systems. Many XMPP clients already allow message to be filtered out against presence status, and either shown or buffered. Because presence is deeply rooted in the XMPP protocol, the usage of presence is natural to many developers. This alone provides a huge advantage over other protocols. Many SIP developers are still thinking like telecom developers, not focusing on what a user is trying to accomplish and what the other party is available for. In this context, Jingle, as a natural extension to XMPP, will also benefit from the same advantages. Very naturally, the upcoming Jingle clients can automatically change the presence status when a call is in progress (GTalk does not do it, but GTalk is not a Jingle client). Some Jingle clients offer call filtering and call re-routing derived from the actual presence set by the user. On the server side, XMPP enables granular routing between multiple client instances based on presence application priority, whereas SIP will fork calls to every registered instances of a SIP URI.

In all, XMPP has many natural constructs leveraging presence. The root integration of presence in the protocol has created a larger community of “presence aware” developers. In comparison, SIP implementations today treat presence as accessory. Those of you that have tried to integrate presence in SIP applications have certainly found out that it is a complex task. And everybody would agree that complexity is an “app killer”.

Technorati Tags: XMPP, Jabber, Jingle, SIP, VoIP, Skype, Presence, Antecipate