Jean-Louis Seguineau: 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”. [Planet Jabber]