Subject: Re: H.320,H.323, and MBONE gateway.

From: "Michael Benson" <[email-masked]>
Date: Tue, 17 Feb 1998 13:12:55 -0500

Don't count on it... most companies having any type of H.323 stack are
capitalizing on the fact that the standard was done in the ITU and is
extremely poorly documented, and requires people (and/or companies) to work
with existing companies in order to get any projects working.  As a result,
stacks are going for around $100K plus royalties in many circumstances.

Now if the standards were done in the IETF, I doubt there would have been
this problem... hence I believe why a lot of people are starting to work
with the SIP/SDR/SDP/etc standards.  While they do not replace all of H.323
standards, they do work as a good alternative for many applications needing
telephony technologies.

Personally, I feel the IETF should also establish other standards in this
field, such as data sharing, whiteboard sharing, audio codecs, etc.
Otherwise, the standards will be bloated and close to impossible to
implement based upon the published standards documents, as the H.323
standard proves.  It is unwise to force a standard from a hardware based
switching network onto a packet oriented network if you expect any type of
optimization, clarity, or sanity.

Michael

---
Michael Benson

-----Original Message-----
From: Peter Hoermann <[email-masked]>
To: Michael K. Sewell <[email-masked]>
Cc: [email-masked] <[email-masked]>
Date: Monday, February 16, 1998 5:09 PM
Subject: Re: H.320,H.323, and MBONE gateway.

>Michael K. Sewell wrote:
>
>> Does anyone have any knowledge on a gateway that can service H.320,H.323,
as well as the MBONE suite for video conferencing? Can
>> this be done?
>
>Hi Mike,
>
>in principle yes, but the signalization on the H.323-side is quite tricky.
Nevertheless, there exists a prototyp that was build
>during the MERCI project. For a first glance, take a look at:
>
>http://www-mice.cs.ucl.ac.uk/mice/merci/deliverables/d10.1/d10.1.html#BM7
>
>They divided the gateway into two parts, one which serves as a H.320/H.323
gateway and the other - yep, right guess - as a
>H.323/MBone gateway.
>
>Me, myself and I are three students working on a H.323/MBone gateway, too,
but we three got big problems with the signalization on
>the H.323 side because it is on the one hand - politely said - not well
documented and on the other hand coded in Packed Encoding
>Rules which makes it - I am very polite today - a little hard to code and
decode.
>
>BTW: maybe there are some sponsors out there just waiting to provide me
with a H.323-stack :-) ?
>
>Hope this information helped a little
>
>Peter
>
>

---

From: Petri Helenius <[email-masked]>
Date: Tue, 17 Feb 1998 23:12:53 +0200 (EET)

> standard proves.  It is unwise to force a standard from a hardware based

I'm not an intellectual property expert here so I'll put forward my
opinion with no concern whether that approach would violate ITU-T
rights or not.

IMO, IETF (which we all can put stuff into and I'm having the feeling
I should) should measure a rough consensus on the fact whether SIP is
supposed to be a peer-to-peer "session initiation protocol" or a
full-fledged session signaling protocol which can handle transfers,
diverts, conferences, charging information, user-to-user free-form
information, terminal display control, etc.

If the latter would be the choice, I feel that the most of the functionality
currently in H.323 family of specifications should be put into SIP
upfront, not to augment the specification as needs arise. (and by
doing that, reinvent IETF-way-of-H.323 the hard way)

Pete

---

From: Jon Crowcroft <[email-masked]>
Date: Wed, 18 Feb 1998 09:24:26 +0000

>>stacks are going for around $100K plus royalties in many circumstances.

the point about documentation is a good one - the documents leave it
EXTREMELY open to interpretation exactly how a 323 system would be
configured to use MCs and so on......i suspect that in fact, 323 comes
from a very smal lnumber of companies who have a detaield model they
don't want to write down

the proper way to use standards (politicxally correct) would have
profiles of the configurations and examples of the message flows....so
that one could construct a system with soem sort of idea that it might
interwork.....while there is copious deailt on the ASN for 245 and al
lthe adjunct protocols, the actual _distriobuted_ operation of the
overal components is simply not captured anywhere....this is what
leads one to build systems to montitor and trace and pretty print all
the messages from what systems there are that one can get - but
having to reverse engineer a standard from an implementaiton (and the
free/affordable oens are pretty terrible) is a damning inditement of
the people that wrote the spec...

sorry guys, maybe 323 is the best thing since sliced white bread, but
you couldn't tell from looking at a piece of it that landed butter
side down:-)

cheers

jon