Search This Blog

Wednesday, June 21, 2006

H.325 - Is a rehash necessary ?

At the 2006 ITU-T workshop, a presentation was made on the 'next' generation of protocols 'H.325' !

The primary pitch for H.325:
a) It offers a 'centralized' model of operation, as opposed to SIP and H.323 which put intelligence in the device. SIP cannot do this (*cough* tell this to the SIP centrex guys *cough* B2B)

Secondary pitches for H.325 :
b) Reduced Complexity ( haven't we heard that before)
c) Rapid Service creation (we have seen this on marketing slideware for years)
d) Better 'capability negotiation' (which does not need a new protocol - its a behavioural change that can be adapted to any existing protocol)
e) "Truly" take advantage of IP networks (not sure what that really means)
f) Better NAT/FW traversal (enough already ! we have come to a point where Sykpe's NAT traversel works everywhere. Why bother again ?)
g) It says "SIP is largely equated to voice" (not at all, really)

And finally:

"H.325 was launched by ITU SG-16 to meet NGN requirements and overcome limitations of 'legacy' systems" - oh brother ! Join the queue please, we have 3GPP, 3GPP2, TISPAN and a bunch of other SDOs trying to 'solve the next generation' problem.

The interesting part is that H.325 is a 'new effort' with requirements being confirmed by end 2007 and 2008 being the year for the protocol definition.

We spent till 2000 battling between protocol choice for deployment (SIP vs. H.323). For good or for worse, that battle was won by SIP. Today, we have 3GPP, TISPAN, IPTV, Cable and several other forums who have brought out architectures that meet initial requirements for their respective networks. More importantly, OEMs and carriers have invested billions of dollars in getting those networks ready, with SIP support.

Is this really a time to launch YAAAPHWANH ? (Yet Another Attempt At Promoting H.323 With Another New H.325 ?)

I personally think this is an effort which is too late. Some of the problems are real - but instead of blowing off the dust of a has-been protocol and adding bells to it, why not add the missing features to SIP ?