Don't we have it all?

Reading about H325, the next specification effort by the ITU, I was struck by the argument used to support the need for a more appropriate multimedia communication protocol .

When H.323 and SIP were under development in the mid- to late-1990's, the popular thinking was that service logic should be located entirely within the user's telephone or videoconferencing system. Features like call transfer, call park, call hold, call pick-up, and call forwarding were designed to be implemented within the endpoints. This gives rise to several problems.

No kidding! But with the advent of consumer mass VoIP services, the ‘popular thinking’ is all but gone, to say the least. VoIP has been in the popular mind since a decade. Only recently has the power of home computer reached a sufficient level to make call quality acceptable. The important point, though, is that all current consumer VoIP services such as GTalk or Skype have retained the characteristics of P2P client based communication. And this is the wrong approach.

The  H325 information page does a good job at describing some of the drawbacks associated with the current protocols and technology approaches. They first state that interoperability between and provisioning of clients in such VoIP system can become a nightmare for any medium to large size organization.

… every time a new feature is added, the endpoint must be updated. While this is not a major task for an individual phone, the prospect of updating tens of thousands or millions of endpoints is a very expensive exercise. With a number of different endpoints implementing features slightly differently, this leads to interoperability issues ...

Knowing how important interoperability is for any communication system, one could easily measure the impact of this task. After all, seamless interoperability is what makes POTS what it is today. Non inter-operable devices and ‘narcissistic’ signaling protocols have a significant negative impact on large scale adoption of VoIP solutions. Either by locking end users into a particular brand (name your favorite telecom vendor here…), or into a particular community (name your favorite VoIP/IM provider here…).

They then state that management and control of multimedia services are made almost impossible or extremely costly.

… some service providers elected to deploy services based on the device-control protocols H.248 and MGCP. However, whereas H.323 and SIP removed too much control from the service provider or IT department, device-control protocols put too much responsibility on the managing devices. Every task that needs to be performed must be signaled and controlled by the Call Agent or Media Gateway Controller. This leads to scalability issues when the controlling agent must manage thousands or tens of thousands of individual endpoints…

Anyone having managed anything but a small SIP based VoIP deployment will understand this statement. Not only is the number of equipment pieces necessary to achieve a proper service prone to enrich a few large vendors, but the resulting system is in most cases very difficult to control and modify.

What I find really interesting in this information page are the arguments used to position H325 as the next thing to use to overcome all these hurdles: separate call control logic from service control logic, and use a flexible capability negotiation mechanism. Nothing revolutionary or new here. Just plain common sense. And guess what, we happen to have a  set of specifications in XMPP which can closely map to the H325 project goals.

XMPP already provides various standardized ways to advertise, discover and negotiate features. Call control logic can easily be delegated to the Jingle framework. Identity and trust assessment are integral components of the XMPP specification. Isn’t that a strong position? The rest is matter of lobbying.

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