Subject: RE: H.323

From: Dan Wing <[email-masked]>
Date: Sat, 13 Dec 1997 12:28:02 -0800

>I know it is very late in the game for this, but does anyone share this
>concern and can anything be done about it from the political/IETF arena?
>Is perhaps an IETF based set of protocols appropriate?

It may very well be too late for SIP (and related protocols) versus H.323
(and related protocols).  For voice-over-IP, vendors are building products
using H.323 because the standard exists.

This is happening again in fax.  Both IETF and ITU are defining competing
standards for fax over SMTP; coordination is difficult when the market is
pushing for interoperating products "now" but correct engineering takes
awhile, especially educating people without knowledge of the Internet about
the Internet, and educating people without knowledge of fax about fax. 
There will be a flurry of activity on the IETF-FAX mailing list as we try to
create a standard that will more-or-less acceptable to both groups. 

In the future, such problems can only be resolved by getting standards out 
the door quickly and efficiently, concentrating on what is necessary to 
build a product that solves the immediate problems while allowing for later 
extensions for what is perceived to be important for "version 2".

(Above is my personal opinion only.)

-Dan Wing

---

From: Jon Crowcroft <[email-masked]>
Date: Sun, 14 Dec 1997 17:39:11 +0000

In message <[email-masked]>, Dan Wing typed:

 //>I know it is very late in the game for this, but does anyone share this
 //>concern and can anything be done about it from the political/IETF arena?
 //>Is perhaps an IETF based set of protocols appropriate?
 
 //It may very well be too late for SIP (and related protocols) versus H.323
 //(and related protocols).  For voice-over-IP, vendors are building products
 //using H.323 because the standard exists.

um, its never too late for end systems software, especially not for
applications software such as call contol protocols - 

i personally find the argument difficulat to sustain for/agaist h.323
for fat client s/w, but for thin client (read "not gates " or
palmtop/pilot or anything where we don;t want to waste batteries
supporting MS-ware) and for thin serve/gateway (e.g. on processor on
line card in _existing large scale digital phone exchanges) h.323
simply DOESNT fit. - when its changed to fit (e.g. H.323 "lite", it
will, but that puts it on a level playing field vis-a-vis protocol
standards and SIP....

thin (not gates, e.g. psion's o-o operating system, or the newtons, or
the java vm, or even the playstation os (now there is a niche product
idea - internet  telephone on a java vm on the playstation:-)), would
all benefit more from sip...

but sip (and other call control and conferencing protocol development)
 will benfit from a close reading of the h323 (as it does since there
are some h323 experts in mmusic and siptel) to see what the target
protocol size to _avoid_ is:-)
 //
 //This is happening again in fax.  Both IETF and ITU are defining competing
 //standards for fax over SMTP; coordination is difficult when the market is
 //pushing for interoperating products "now" but correct engineering takes
 //awhile, especially educating people without knowledge of the Internet about
 //the Internet, and educating people without knowledge of fax about fax. 
 //There will be a flurry of activity on the IETF-FAX mailing list as we try to
 //create a standard that will more-or-less acceptable to both groups. 
 //
 //In the future, such problems can only be resolved by getting standards out 
 //the door quickly and efficiently, concentrating on what is necessary to 
 //build a product that solves the immediate problems while allowing for later 
 //extensions for what is perceived to be important for "version 2".
 //
 //(Above is my personal opinion only.)
 //
 //-Dan Wing

 cheers

   jon

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 15 Dec 1997 09:54:07 -0500

The assumption, of course, is that SIP stays "thin". The evidence for this
proposition is itstelf rather "thin" if other people read the tea leaves
the way I do...

Cheers, Dave.

> //(Above is my personal opinion only.)
-----------------
David R. Oran
Cisco Systems		Direct: 408-527-0567 (don't leave voicemail)
7 Ladyslipper Lane	Home Office: 508-264-2048,  Home: 508-263-2705
Acton, MA 01720	EMail: [email-masked]

---

From: Mark Handley <[email-masked]>
Date: Mon, 15 Dec 1997 11:22:55 -0500

>proposition is itstelf rather "thin" if other people read the tea leaves

Actually the compulsory part of SIP is still very "thin".

We are actively working to split the spec into a base spec and
specific extension specs, which should help people understand this,
and also help us freeze the base spec very soon now.

Mark

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 15 Dec 1997 12:38:53 -0500

> proposition is itstelf rather "thin" if other people read the tea leaves

While "thin" is somewhat in the eye of the beholder, I should point out
that the specification that adds full IN call control to SIP is 5 pages,
with another 6 or so pages of translation to "Bell-head speak". See the
http://www.cs.columbia.edu/~hgs/sip for the new draft-drafts. Not sure
which tea leaves you are reading, but there are no major extensions
planned to the base spec. (I'm usually the one accused of adding to it,
so I may know :-))

SIP has a reasonably straightforward extension mechanism that avoids
some of the profiling issues found elsewhere. For example, the ability
to do call control might be signaled using

Require: org.ietf.sip.call

(take the feature name with a grain of salt), so that there should never
be any doubt what features you support and do not support.

-- 
Henning Schulzrinne        email: [email-masked]
Dept. of Computer Science  phone: +1 212 939-7042 (@Bell Labs: 732 949
8344)
Columbia University        fax:   +1 212 666-0140
New York, NY 10027         URL:   http://www.cs.columbia.edu/~hgs