Subject: [Sip] Why not ISUP?

From: "P Villa" <[email-masked]>
Date: Thu, 06 Sep 2001 09:50:30 -0500

Hello,

I have a question for the people on this list:

Why does SIP continue to get so complex in order to provide the same basic 
telephony services that other telephony protocols developed long ago?

I'm studying the SIP protocol in school and ran across this list, so I 
figured I'd ask. It doesn't seem obvious to me what the real answer is.

P

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Paul E. Jones" <[email-masked]>
Date: Thu, 6 Sep 2001 10:50:27 -0700

P,

Trying to provide telephony services is, by its very nature, somewhat
complex.  As the issues being solved get more complicated, so will the
protocol.

Of course, the goal of SIP is to keep the complexity to a minimum.
Unfortunately, you will certainly see the protocol get more complex.
However, I think the engineers working on SIP are conscientious of this fact
and are striving to strike a good balance between complexity and
functionality.  Some functionality that is not core to SIP or essential in
all signaling scenarios is being defined in separate documents for those
more vertical applications.  I think that's the right approach.

Paul

---

From: Kim Liu <[email-masked]>
Date: Thu, 06 Sep 2001 17:00:51 -0400

> figured I'd ask. It doesn't seem obvious to me what the real answer is.

If you study the protocol, SIP is not really intended to
provide the same basic telephone services.  The underlying
design philosophies appear to be more aimed at facilitating
the development of new services rather than anything else.

The complexity arises not from trying to implement *just*
the basic telephone services, the complexity arises from
trying to develop a system that is flexible enough to handle
*any* service, or close to it, even between SIP entities
that might not understand/implement a specific service/method.
(Thus all the debate about whether methods other than INVITE
should fork/support CANCEL, etc.  If the goal was only basic
telephone service, there would be no other hypothetical
methods, and it would not be an issue -- the complexity
arises from trying to maintain flexibility.)

It's a protocol designed by programmers for programmers
as a protocol that makes it easy for people to write 
applications and services for due to its similarities to
other well-known protocols like HTTP, etc.  The assumption 
is that the hypothetical services-that-will-be-developed
are going to be beneficial enough to justify the complexity/
inefficiency of the protocol and that by creating an
environment favorable to development will speed development
of self-same future services.

The development of new services in turn would spur
the adoption of the protocol/new end points among the user
base.  If efficiency/simplicity was the primary goal, there
would not be people talking about taking a four byte integer,
converting it to a text string, compressing it with a dynamic
dictionary compression algorithm, squirting it over a wireless
link, uncompressing it back to a text string, and converting
it back to a four byte integer. :-)

So, the complexity is not just basic telephone services --
the complexity is from trying to support the PSTN model,
the H.323 model (with the delayed media issue), forking,
etc. etc. while placing as few constraints as possible on
any future service and to support all of them at the exact
same time. (i.e. a H.323 end point getting converted to
SIP via a gateway, hitting a forking proxy, terminating
on a SIP<->PSTN gateway, etc.  Trying to get that to work
transparently is not simple without restraints.)  

Disclaimer: These are my opinions only.

Kim Liu
Senior Software Engineer
Lucent Technologies
Clearwater, FL