VoIP is a series of tubes...

But unlike the Internet, these tubes can be filled without allowing inter-tube communication. Unless I am mistaking, we are getting yet another replay of the "my little walled garden" show, this time with point to point voice communication as the guest star. Just take the same incumbents as in the case of consumer instant messaging services, add eBay with Skype, and Google with GTalk and you have the new landscape. What is also interesting is the parallel uptake of VoIP hard phone devices for use with these closed services. We already knew the series of Skype phones, but more recently the movement has accelerated with examples of Yahoo! and GTalk phones.

I will resist enumerating the reasons why walled gardens and non interconnected “tubes” cannot provide a sustainable model, as I have done so here before. But this multiplication of closed voice services and associated devices raise two questions.

Firstly, the technological context in which these services are being created is different from the context of instant messaging. At the time where IM services have originally been created, there was no established standard for instant messaging, which in turn led to the development of proprietary and incompatible protocols. In comparison, SIP was available as an open VoIP standard. So why wasn’t SIP chosen by all these players to incorporate in their soft clients? Apart from AOL which included a SIP stack in its latest AIM clients, the other incumbents, including Microsoft, as well as Skype and Google came up with their own VoIP solution. I have various reasons coming to my mind that could explain why SIP was not chosen, amongst them I can cite:

• Inability of the players to conceive voice services outside the existing traditional telco model, where the only conceivable option for them is to play the role of clearing house. Using a proprietary VoIP system would force the end users to go through the incumbent's gateways to reach out to other VoIP services.
• Fear that adopting SIP would give an unfair advantage to Microsoft which had clearly endorsed this standard in its enterprise products. The current situation is proving that this possibility was grossly exaggerated, as MSN does not use SIP for VoIP, and there is no concrete proof that SIP is used to a large extend by MSN yet.
• Inherent complexity of a SIP solution ranging from the phone configuration, recurring subject cited by many VoIP observers, to the associated infrastructure necessary to support and control the service. Furthermore, SIP is a documented standard, but its standardization process is similar to a vendors' consortium initiative. As a result, most of the SIP equipments are only manufactured by traditional telecom vendors, and the cost of a SIP infrastructure may have been excessive.
• Scarce SIP expertise amongst the developers that have been put in charge of implementing the service and integrate voice in the IM clients. Skype and GTalk are typical examples, where developers had a protocol at hand that was solving many issues SIP is facing with NAT traversal. In such condition, it was easiest to just add signaling and voice transport to the existing protocol than to learn SIP in order to embed a full stack.

Secondly, why do all the VoIP pundits remain silent before the obvious rise of these new walls?  I find this silence deafening and profoundly puzzling. I don't know if you are like me, but I don't think it is difficult to infer that all these voice services are of no real value to the end user. I was under the impression we were in an era of users' empowerment and "social" communications. Furthermoe, if the attention economy is effectively the natural economy of the Internet, then voice is the first natural way to draw someone else's attention. After all, what does a baby do immediately after it is born but cry to draw attention? Voice is the ultimate open medium, and is the first and most ubiquitous human way of communication, far before writing. But when someone can only use words in the limited context of a closed community, without the possibility to be heard outside, it looks strangely similar to being deprived from basic freedom of speech.

I can hazard a possible explanation to their silence. Maybe the said pundits, having been exposed to long to the traditional telco business, are only able to conceive a single type of voice applications: toll gates, which are the natural complement of non interconnected “tubes”.

Technorati Tags: Interoperability, Conversation space, VoIP, Antecipate

VoIP is irrelevant

At least for the purpose and in the context of this poll! When your [truck, ship, plane, add your own transport here] is stuck in the middle of a distant nowhere following a breakdown, the first thing you think of is getting in touch with the [driver, captain, pilot, etc…]. At that point, your only intention is to communicate, to exchange and gather information, for finally come to some decisions and trigger some actions. And during that process, the last thing you will be worrying about is if part of your communication is carried out using VoIP. It is irrelevant. Even the cost of the communication will become irrelevant. What you would want though, once the communication has been established, is to take photos or videos of the incident to be able to share them with the appropriate expert for deciding on the better course of action, and at the same time to start the claim procedure with your insurance company. What you would want is to quickly gain access to the nearest repair facilities and arrange for you transport to be taken care of, because your business depends of it.

Even if the transport of multiple data streams using the same underlying technology has become increasingly more common, it does not make VoIP relevant in itself. The induced fall of the wall between the voice and data silos is relevant. The ensuing cross domain knowledge dissemination between these two areas of expertise is relevant. The growing awareness of the possibilities offered by merging multiple communication types into applications is relevant. And only at that point will it become relevant to use VoIP, not the other way round. Obviously, all these positive consequences will only happen at the slow pace of human behavior changes. And this is much too slow for the buzz makers.

More profoundly what is relevant is "to impart, to share, to make common". And in that respect, the current impersonations of VoIP are far from providing this basic communication attribute, as they are repeating the creation of wall gardens in the same way early email providers did, in the same way consumer IM providers still do. And by taking this approach, their proponents are as good as the poll's author and other VoIP's meme builders: clueless…

Technorati Tags: VoIP, Antecipate

Ostriches don't solve problems...

As reminded by Ken Kamp, entrepreneurs and executives sit around board room tables to discuss real business problems and look for real solutions to those problems. That does not include their existing phone systems, services, or expenses. Even less VoIP, SIP or Jingle… Let me illustrate by the following story.

The Capulet family has been running a flourishing wine business, and has succeeded by maintaining a tight focus on its core activities. They are well known for their almost real time customer service and their proximity sales service. Now that they are extending their reach well beyond the comfort of the provincial borders, they have signed up for the latest presence enabled real-time communication system provided by Veronizon.  The Capulets have long been running their own XMPP server for fast internal messaging. But they have to make sure all relevant business communications are seamlessly routed to the appropriate representative, without creating undue distraction. And this is precisely what the rule based presence engine of Veronizon's intelligent centrex service allow them to do. Obviously, the service offers all the necessary gateways to ensure that they could also reach their marquee customers or distributors wherever they are, and whatever communication system they use. And guess what, Veronizon charge its service on the number of rules held in the system, and by the number of time these rules are used. The communication time is free, which adds a compelling advantage in regards to the traffic based charges still in use at all other communication providers.

This is in my opinion a very likely scenario for many enterprises wanting to leverage IT and communications for what they are: a support for their business. And in this context what is any protocol's "raison d'etre" if not allowing the brightest entrepreneurs and service providers to propose adapted business problem solving responses to these enterprises.

If we examine the consequences for Jingle in enabling this type of service to be implemented outside the premises of the Capulet's business. We can easily see that the Jingle signaling path must be re-routed through the Veronizon centrex service in order for the relevant call routing decision to be made. Juliet which is working in the family's estate has programmed her personal centrex rule engine to forward immediately any call from Romeo to her. When Romeo select "initiate call" on his favorite client, Jingle will start negotiating a session with Juliet's client.

<iq to='juliet@capulet.com' from='romeo@montague.net/orchard' id='jingle1' type='set'>
   <jingle xmlns='http://jabber.org/protocol/jingle'
          action='session-initiate'
          initiator='romeo@montague.net/orchard'
          sid='a73sjjvkla37jfea'>
    <content name='audio-content'>
        ...
    </content>
  </jingle>
</iq>

The Montague XMPP server will faithfully route the request over S2S to the Capulet server. Following the contact with Veronizon, the Capulet server has received a new plugin that

• Filters all Jingle signaling stanzas,
• Reroute the filtered stanzas to the Veronizon centrex service.

thus making the service invisible and transparent to standard Jingle clients.

In order to enable the rerouting, the plugin modify the Jingle stanza by specifying the centrex service address as the new target, and adding a XEP-0033 extended address to retain the original target JID. The Capulet server can thus route the stanza to the centex service over S2S.

<iq to='centrex.veronizon.com' from='romeo@montague.net/orchard' id='jingle1' type='set'>
   <addresses xmlns='http://jabber.org/protocol/address'>
       <address type='to' jid='juliet@capulet.com'/>
   </addresses>
   <jingle xmlns='http://jabber.org/protocol/jingle'
          action='session-initiate'
          initiator='romeo@montague.net/orchard'
          sid='a73sjjvkla37jfea'>
    <content name='audio-content'>
        ...
    </content>
  </jingle>
</iq>

Upon receiving the stanza, the centrex service feeds the incoming request to Juliet's private rule engine, and determines that Juliet is currently available for taking Romeo's call on her "balcony" resource. The centrex service then modifies Juliet's JID to reflect her availability, and forward the stanza to the Capulet server over S2S for final delivery.

<iq to='juliet@capulet.com/balcony' from='romeo@montague.net/orchard' id='jingle1' type='set'>
   <jingle xmlns='http://jabber.org/protocol/jingle'
          action='session-initiate'
          initiator='romeo@montague.net/orchard'
          sid='a73sjjvkla37jfea'>
    <content name='audio-content'>
        ...
    </content>
  </jingle>
</iq>

In the end, customers don't care about what a protocol, a platform or any technical implementation is doing under the covers. They care about their business problems and solutions to those problems. Protocols and platforms are just the enablers for smart solution providers to deliver on their promises.

The danger for protocols' authors is to only consider the world through the lens of a 17 inches screen, as they may be losing sight of reality.  Just bluntly stating that a scenario is unlikely because one never thought of it or never came across it before will in no way make this scenario improbable. How many times have we heard stories about customers using an application or a protocol in a way nobody ever thought before? This is just how progresses are made. Protocol authors and developers often get sidetracked into how to achieve technical interoperability only. I unfortunately believe it is still rather common for them to proclaim that certain usage scenarios do not make any technical sense in the light of their own perception of the problems to solve, and to evade providing solutions by just “hiding their head in the sand”. Until they start to realize this attitude is not enhancing their reputation, they will be considered obstacles more than advantages by many solution providers who build solutions rather than platforms. And, as Ken put it, “those are the ones who will win in the market”…

Technorati Tags: XMPP, Jabber, Jingle, VoIP, Session signaling, Interoperability, Antecipate

YOIP (yawns over IP)

Steering an old stew doesn't turn it into a gourmet meal. And frankly, I think the latest babble-chatter around which VoIP start-up is more voice 2.0 than the other is kind of boring.

I recently left a simple comment on a series of posts describing the "bad practices" dictating the success or failure of new voice and video over IP enterprises: "what should they do to succeed?" Well, the tentative answer has only highten my perplexity. In short, no one seems to knows, but many are talking…

after all is said, more is said than done…

The unease grew even stronger when I red that voice 2.0 in a nutshell sums-up as "be different and give the customer control". What a great discovery! That sounds so marketing 0.1, dear. It just leaves me wondering if anyone is seeing the obvious: until the toll based business model ceases to exist, there are not many chances for large scale innovative and compelling voice applications to emerge. The promise land of converged applications remains a mirage. Unfortunately for all these new enterprises, the issue lies with the networks business model, not with technology. On the positive side though, these VoIP start-ups are helping an ongoing customer education process. Whatever their fate may be, by providing a test bed of other possibilities to end users, they are more valuable than it appears at first sight. Obviously, trying to quantify this value in business terms is open to interpetations. Like any return on peoples’ education…

The troubling feeling I had was further re-enforced when I red the self-congratulating inventor of the so called Voice 2.0 meme suggesting that switching from one's current telecom provider to AOL, Google or [insert your favorite walled garden keeper name here] is the next panacea and will open a wonderful era of user driven voice applications. I doubt refurbishing second hand ideas which have been around since the beginning of the nineties will ever make this meme a reality soon. If like me you have seen so many of these layered voice/directory/application diagrams in any single telecom operator presentation, and so little changes over the same period of time, you remain somewhat skeptical…

As Aesop, this fine observer of humanity, declared, "after all is said, more is said than done". I believe the VoIP meme, in its current voice 2.0 disguise, as well as all its “propagandists” unfortunately do not escape this great saying.

Technorati Tags: VoIP, Interoperability, Antecipate

Is Skype a parasite or a Trojan?

In those days of web 2.x, I often feel that those practicing high doses of ideas mashup usually end up with brain jam. I have had found another good example with this fine piece. Obviously, there has been some discussion going on around IM interoperability lately, which in turn has brought back all the bitterness about our inability to easily and instantly communicate. But have you ever noticed how the same recipes always make for headline of “tabloid blogging”. This one starts with an aggressive title using a few recuperated clichés such a “cold war” and “détente” to awaken old instinctive fears inside the reader. The post follows with a spread of unrelated references, which relevance and validity were obviously never questioned. It goes on enrolling some fellow bloggers unwillingly, citing them partially and out of context. After this the author can pretend to pose as a pundit. Well... Some have different views and present alternatives hypothesis. I personally believe there is one approximately true statement and two major flawed assumptions to justify a lot of conjecture in this paper.

Beyond the tectonic plates’ image, declaring that IM interoperability is a business issue is probably true. Very simply, because this is a matter of toll gates, which is usually solved by a financial transaction. This is turn is business. Am I missing something?

The first flawed assumption is to present LCS as the enterprise federator, and by consequence, suggesting SIMPLE as the federating protocol. In the context of gatekeepers business, it is normal for Microsoft to claim its LCS as the universal federator for an enterprise willing to access public IM networks. This was only a matter of deep pockets and separate negotiation with every “entrenched interest”. Skimming through the recently discovered interoperability guide for LCS 2005 has somehow persuaded the author that LCS was “the” technical interoperability solution. I would only say that it may be a hasted conclusion. LCS (and other federating EIM servers) does not allow federating between public IM clouds, as inter cloud communication is specifically restricted by every individual business agreement. A second hasted conclusion is to use Google’s (very real) inaptitude at marketing Google Talk as a reason to look at XMPP with contempt. Jabberites, you would certainly be happy to learn that “with just 3.4 million [GTalk] users, who really gives a damn what you do”! Beyond the arrogance of the statement, Google is not interested in building communities; it is interested in driving traffic though its sites to increase its advertising broker’s exposure. Google has just opened the door to millions of XMPP users. This was a smart move and was received as a friendly gesture, re-enforcing their “not so evil” perception as a web company. Obviously, seeing this requires thinking outside the IM box. Which in my opinion, neither the IM incumbents, nor this author, have shown a good aptitude at doing.

The second flawed assumption is to present the Skype protocol as the “white knight” of interoperability. When writing about IM interoperability, it would not be wise nor popular to support any one of the competing incumbent public IM protocols. If so, what is left in the protocol landscape to fulfill that interoperability role for the public IM crowd? SIP has been ruled out as a contender (look at the bottom of the post). XMPP has been dismissed above. Only Skype remains to take up the role of the messiah. But now that its protocol has been hacked, I personally think Skype will pay a ransom to this group of Chinese hackers and buy them. This is in line with the recent wave of extortion based virus activity. Hacking a proprietary protocol is the just another flavor of it. But Skype could also make their protocol specification public and disable the threat, couldn’t they? They won’t do it, as they would have to admit publicly that their protocol’s client exhibits a singular cross between a parasite and a Trojan’s behavior. For the Skype network protocol, any node is a potential relay for any other node. There is nothing wrong with this design. But there is something very wrong with hiding this behavior from the end user. Aside from the questions of ethics and privacy, it steals from the user by using the computer's memory resources and also by eating bandwidth as it relays traffic via the user's Internet connection. Because it is using memory and system resources beyond the specific user’s need, the client operation may also lead to general system instability. Hence Skype’s relative reluctance to documenting the protocol...

Two approximations in one post make me feel suspicious. However, I know some peoples also define a truth as “an ingenious compound of desirability and appearance”, adding immediately that

Discovery of truth is the sole purpose of philosophy, which is the most ancient occupation of the human mind and has a fair prospect of existing with increasing activity to the end of time.

Who knows, the author may just be a philosopher in the making ;) As a conclusion, his conjectures provided sources for an additional demonstration that IM interoperability is not about technology. The solution to interoperability will never be resolved by interests entrenched in vendors’ consortia, be it Cisco behind SIMPLE, any other incumbent public IM or Skype. In the same way mail clients are on every personal computer, IM consumers and developers would only benefit when they will have the same kind of protocol: free, open and standard.

Technorati Tags: XMPP, Jabber, SIP, VoIP, Skype, Interoperability, Antecipate

FreeSWITCH has got a clue

The FreeSWITCH project is reaching maturity, and I whish they manage to get their first release out to be presented at ClueCon.

From what I know of its architecture, it possesses all the ingredients for a real internet wide distributed voice system. As such I believe FreeSWITCH would have to be seriously considered as the voice platform of choice to complement XMPP. The philosophy driving their concept of distributed platform bodes well with the XMPP federation cloud. But above all, beyond the necessity to provide early solutions, they really understand the difference between Jingle and Google Talk.

I just hope they fix their registration procedure so I could get a build to run on my Windows server…

Technorati Tags: XMPP, Jingle, Jabber, VoIP, IPBX, SIP, Session signaling, Antecipate

Skype's missing dial tone

I came across the lament of Steve Smith caused by the decline of Skype’s presence component usage. I believe this is the inevitable outcome for a company that never properly understood presence.

Let's go back in time to the origin of Skype. It was born as a clever technical workaround to remedy SIP's inability to properly negotiate NAT traversal. The Skype protocol relies on clients outside a NAT device to proxy for clients behind the NAT device. As a consequence, a client may be used without its user's knowledge or consent to relay Skype traffic. In effect, Skype has an approach similar to what mail spammers do when they use a compromised computer as a relay... For those interested in digging further, this post provides additional sources on this closed protocol hidden features and their consequences.

So, in the beginning was the word, and voice filled the Skype space. Skype users had to wait until October 2004 to discover presence. Fourteen months after Skype was presented to the world as the "arrival of P2P Telephony". In essence, Skype is one of these clever companies that perfectly masters the art of surfing the wave of existing and emerging technologies. Don’t you see how Skype rhymes with hype... Looking at Skype's press releases over the first year gives a pretty good idea of the company’s positioning as "the Global Internet Telephony Company". The press announcements provide all the mandatory ingredients to reinforce this positioning, including the community building, the minimal instant messaging features, and the phone peering agreement negotiations. It becomes easy to conclude that, from the start, Skype’s business model was to become a VoIP phone company. This is not very original, but in October 2004 they cleverly announced "one million simultaneous users globally connected to each other at the same time" and added they had "served more than two billion minutes of free Skype-to-Skype calling". With a technology entirely built on point-to-point communication, Skype own infrastructure had nothing to do but authenticate these users. How could they claimed "serving" anything with an overlay point-to-point network? The actual transport capacity was in fact provided entirely by the Internet without any Skype resource being involved. What a marketing mastery!

And presence in all this? I always refer to presence as the “glue” that improves users’ ability to communicate and interact in true real-time. It ties together applications that previously lived in isolation. Presence is a dynamic extension of an entity's digital representation on a network; it describes one or many states, exposing entities’ ability, means and overall willingness to engage in a transaction. Typically, a presence engine manages the connectivity status of users, their devices and their capabilities. In the case of Skype, as it implements a point-to-point overlay network, I believe presence state changes are processed locally by the clients. As a consequence, only online/offline state would really be used to determine the ability to communicate. Skype allows several clients to be logged in for the same entity. In this context, the client side logic makes it difficult to aggregate an entity’s multiple availability information and present it to a contact. In turn, it decreases the ability to leverage presence to re-direct or temporary divert a call according to certain states. In an enterprise context, the client side logic is not the best design to fully take advantage of collaboration indicators, such as calendar based presence.

Presence can have a tremendous impact when implemented and used as the new "dial tone" in a communication system. Let’s consider an example. Many business process delays result both from inadequate access to missing information, and from users’ inability to locate and briefly interact with peers regarding such information. By enhancing the ability to reach a colleague using the most appropriate communication channel, presence addresses this recurrent business challenge. With presence, we no longer request, we subscribe!

Granular presence states, coupled with the ability to inject collaboration indicators and use rules are powerful enhancements to a VoIP communication system. When on the contrary, presence is reduced to an online/offline binary information, it looses any advantage over the POTS dial tone. In Skype, presence is derived from the call management, not integrated as the nervous influx in the system architecture. A typical carrier approach, where the business model relies entirely on the peering agreements and associated traffic clearing houses, not on services. Skype cleverly rode the presence hype without harnessing its power. And Skype will go back to what it really is: a proprietary non-interoperable VoIP phone provider.

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

The VoIP fear factor

At VON Europe, experts from well known VoIP vendors have publicly admitted that many of their products were not inter-operable with those form other vendors. They also said these vendors were not implementing basic security technologies over their entire product range. What an interesting disclosure. I was under the impression VoIP was a communication enabler. Maybe incompatible VoIP technologies are just a way to protect the large investments made in legacy voice systems by the same vendors? Or is it just a way to lock potential customers in…

But what I find really unsettling is the use of the fear factor all throughout this article. No fact, no analysis, a clear un-understanding of the issues at stake. Just a un-intelligible blurb of words between unrelated “experts” quotes. Somebody will have to explain to me the role of TLS in an UDP based VoIP system, for example. But the keyword TLS will probably bring this page in good position in the results o a search engine when looking for VoIP security.

One thing is certain, though, deploying a SIP VoIP infrastructure is the kind of project that makes your entire security protection look like swiss cheese. And fingerpointing the other party for lack of security understanding will not change this result.

Technorati Tags: SIP, VoIP, Security, Antecipate