I was piqued by this until I realized it was an advertisement for SIP. SIP
has its own set of problems.
-Ian.
http://www.networkcomputing.com/1017/1017colwillis.html
When Good Standards Go Bad
August 23, 1999
By DAVID WILLIS
Sometimes there's just no turning back: When the raft is in the rapids, the
skis are at 45 degrees, or the tattoo gun is halfway through your sweetie's
name, all you can do is plow ahead. That's where the VoIP (voice over IP)
industry is with H.323, but behind the scenes vendors and users are
beginning to question the choice.
Everybody loves standards. They promise interoperability, freedom from the
tyranny of closed systems, greater choice for the customer and lower cost of
ownership. Criticizing standards is like censuring democracy and capitalism.
But the wrong standard can stagnate an entire industry.
The first version of H.323 is now more than three years old. Version 2 has
been out for 18 months, yet the few products claiming compliance still lack
features essential to practical use--namely encryption, advanced call
control and network-based call management. Microsoft's latest Windows
NetMeeting 3 still can't claim more than partial compliance, and it is the
industry's most used PC desktop end point. H.323 stacks are available, but
only from a handful of vendors. And don't look now, but version 3 is just
around the corner. The H.323 standards are further ahead of the market than
any other technology since ATM, and for the same reason: The market doesn't
understand them.
H.323 makes for good voice calling in the same way that Sumo wrestlers make
good jockeys. I'm not claiming that H.323 has any architectural flaws, just
that it produces bloated products. I can only comment on what I've seen it
do to a network, on bugs found in H.323 implementations and on the painfully
slow process of getting vendors to fix them. The promise of opening up
advanced PBX call-handling features using H.323 simply isn't being met.
IP-based PBX vendors can't even forward calls between each other's products,
for example.
Without a doubt, vendors are devoting some attention to interoperability,
with many very smart people endeavoring to make this stuff work. More than
30 vendors have pledged support for the iNow! Profile
(www.imtc.org/act_inow.htm), which plans to bring about Internet telephony
interoperability using H.323 version 2. But the profile was published more
than four months ago and the implementation dates are still fuzzy. iNow!
isn't that ambitious anyway--it doesn't address call privacy,
gateway-to-gatekeeper interoperability, phone-to-PC/device service, roaming
or SS7 integration. Where iNow! will succeed is in gateway-to-gateway and
phone-to-phone connections--in other words, in providing transmission
services in the middle of the network. It won't help at the end points,
where we're still waiting for real innovation.
VoIP should run on Internet time, but H.323 is still dialing into Prodigy at
300 baud. Long-distance cost reductions are only a short-term reason to use
VoIP, and when that opportunity dries up, H.323 will have no future.
Long-term, innovative applications at the end points will drive VoIP. These
applications must be easy to create by a wide range of developers, and H.323
won't deliver. It's not optimized for real networks, it's too difficult to
develop and it requires too many resources at the client. The specification
is further burdened by video and whiteboarding services. H.323 has more
oversized baggage than the Augusta airport a week before the Masters.
Do an end run around all the H.323 marketing, and product engineers will
tell you that they're waiting for something better. A number of efforts aim
to simplify VoIP development, some with amazing success. Four weeks after
the IETF's SIP RFC (Session Initiation Protocol-RFC 2543) was published, 18
vendors demonstrated some level of interoperability. Columbia University
students have even built SIP implementations as homework assignments. It's
exciting stuff, and I'll be digging into it in more detail in my next
column.
Send your comments on this column to David Willis at dwillis@nwc.com.
--
.:|:..:|:.
--------------BFA4CD9F387B8FF3BB900DE7
Content-Type: text/x-vcard; charset=us-ascii;
name="ibell.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for Ian Andrew Bell
Content-Disposition: attachment;
filename="ibell.vcf"
begin:vcard
n:Bell;Ian
tel;pager:(800) 365-4578
tel;cell:(408) 921-4873
tel;fax:(781) 685-5915
tel;home:(408) 564-2523
tel;work:(408) 525-8630
x-mozilla-html:FALSE
url:http://www.cisco.com
org:Cisco Systems - Service Provider LOB;Packet Telephony Division
version:2.1
email;internet:ibell@cisco.com
title:Solutions Manager
adr;quoted-printable:version:2.1;;Building SJ-6/4=0D=0A375 East Tasman Drive ;San Jose;CA;95134;USA
note;quoted-printable:AOL Instant Messenger ID: ibell SJ=0D=0A=0D=0A
x-mozilla-cpt:;-8400
fn:Ian Andrew Bell
end:vcard
--------------BFA4CD9F387B8FF3BB900DE7--