Subject: [PINT] Again one question

From: "Stephane Nicoll" <[email-masked]>
Date: Thu, 19 Oct 2000 14:35:11 +0200

Hello again,

I've one more question : "Why the PINT group has choosen SIP and not H.323? In other words, what are the properties or the requierements that has driven the group to this decision?

Thanks a lot in advance

Stephane

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 19 Oct 2000 12:29:22 -0400

Stephane Nicoll wrote:

> Hello again, I've one more question : "Why the PINT group has choosen
> SIP and not H.323? In other words, what are the properties or the
> requierements that has driven the group to this decision?

A bit of history:

Technically, only three protocols were discussed in PINT to begin with
(see RFC 2458): 1) A Lucent-prototype one, specifically developed for
PINT services; 2) a CTI-like Simple Computer Telephony Protocol; 3) HTTP
(with some extensions).

We never formally worked on the requirements, but the problem was rather
straight-forward, and it already had a few proposed solutions. The
MMUSIC people (Scott Petrack, Dave Oran, and Jonathan Rosenberg--in the
order of microphone use, according to my memory) immediately pointed out
that there already was a protocol (two protocols--SIP and SDP, actually)
under development that  would do what was needed: 1) relatively simple
secure Internet-friendly transactions 2) ability to specify media
characteristics; and 3) ability to transfer content. M. Handley made a
presentation at the first PINT meeting, then Henning worked with us and
co-authored RFC 2458, which effectively had the requirements. Because of
Hui-Lan's continuos effort as ISOC representative to ITU-T SG 11, SIP
was recognized as the "IN service access" mechanism in ITU.

So, PINT was the first SIP application in the IETF.

Now, why not H.323?  (This question was asked a couple of times before,
of course.) Very simple: H.323 is a VoIP protocol, but VoIP is NOT part
of PINT charter. Of course, hypothetically, one could pick-up a subset
of H.323, mask unnecessary parameters, add others as extensions, etc.,
but no one ever proposed such an action. In other words, H.323 is rather
a counterpart of Q.931 and ISUP than INAP/TC. PINT chose the SIP
function which WAS a counterpart of INAP/TC stack.

The PINT problem needed a simple direct solution to service access, and
such a solution was found and later used for many other services.

Igor

---

From: Lawrence Conroy <[email-masked]>
Date: Fri, 20 Oct 2000 14:40:02 +0100

At 12:29 pm -0400 19/10/00, Igor Faynberg wrote:
>
>
>Stephane Nicoll wrote:
>
>>Hello again, I've one more question : "Why the PINT group has 
>>choosen SIP and not H.323? In other words, what are the properties 
>>or the requierements that has driven the group to this decision?
>>
>A bit of history:
><snip>

>Now, why not H.323?  (This question was asked a couple of times 
>before, of course.) Very simple: H.323 is a VoIP protocol, but VoIP 
>is NOT part of PINT charter. Of course, hypothetically, one could 
>pick-up a subset of H.323, mask unnecessary parameters, add others 
>as extensions, etc., but no one ever proposed such an action. In 
>other words, H.323 is rather a counterpart of Q.931 and ISUP than 
>INAP/TC. PINT chose the SIP function which WAS a counterpart of 
>INAP/TC stack.
<snip>
Hi Stephane,

Igor has given an excellent summary. I should add that some people 
*DID* suggest that H.323 might be considered early on in the group (I 
seem to remember in the Los Angeles Meeting in early '98). I remember 
that the response was that PINT was always open to proposals, and 
people were asked to come up with the details on how it could be 
used; No proposals were actually delivered.

In answer to a question in the Los Angeles meeting, I suggested that 
we *could* use H.323/245/225, but the easiest way was to set up a 
T.120 association between PINT client and PINT server once the 
initial H.323/245 association had been set up, and then send whatever 
messages one wanted over that T.120 association.

It seemed difficult to send (for example) a text document or a 
graphic using a "pure" H.323/245 connection. As Igor points out, the 
idea of changing H.323/245 to "fit" PINT's needs was too challenging, 
particularly as these change proposals would need to be made in the 
ITU and/or ETSI.

The rough consensus at the time appeared to be that this was a LOT 
more complex than the equivalent SIP scheme, where we could just 
re-use some of the attributes and send any needed documents or 
references within the body parts of the message.

In summary; H.323 hard for technical and standards group reasons ; 
SIP/SDP easy, extensible, and a fairly natural fit to carry the 
information we needed (and the experts were in the same room!).

BTW, RFC2848 was created using BBEdit (a pure text editor) - If you 
want I'll distill it for you, but text is its native format. What's 
the problem?

regards,
   Lawrence

_______________________________________________
PINT mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/pint