Subject: RE: [SIP] What do we want with SIP?

From: "Arnoud van Wijk (ETM)" <[email-masked]>
Date: Thu, 3 Aug 2000 15:04:25 +0200

Itmar,

Thank you for your reply.
Your answer did confirm many of my musings and wonderings and eased my worries.
The most important part is indeed that reference to Jonathan R's words: "there will be no version 2.1 of SIP".
I am glad to see that the extensions proposals are seen as a seperate entity. And later, the good ones will deserve an official place next to SIP.
This means that all UAs are required to read the RFC2543 defined headers, and can ignore any other headers?
So in fact it is up to the UA creator to accept the "good" extensions given in the drafts.
It may still be a very good idea to reach some consensus on which extensions are most promising and stimulate their acceptance. (note, it is then only to give developers an idea, not that this is a law on itself.)

Arnoud

-----Original Message-----
From: Itamar Gilad [mailto:[email-masked]]
Sent: Thursday, August 03, 2000 2:25 PM
To: 'Arnoud van Wijk (ETM)'; 'SIP'
Subject: RE: [SIP] What do we want with SIP?

Arnoud,

I'm allowing myself to try and answer these valid questions although it's
not really _my_ answer I'm giving, but rather a summary of answers I got
from various key people in SIP to which I posed similar questions. I think a
lot of people are wondering about these things so I hope I can save them
some time. If I'm missing a point I'm sure someone will correct me before
long.

SIP is a signaling protocol where signaling is a shapeless, ever-growing
term that roughly means "establishment-modification-termination of some sort
of interactive real-time session between any two entities". The sessions may
include voice, video, IM, games, a combination of those and much more (no,
telnet is not included).  The entities may be software clients for the
above, IP phones, telephony GWs, mobile devices, Softswitches, MCUs, play
stations and what-have-you. Each group brings its own (possibly) unique set
of requirements to the signaling protocol. Throw into this pot also services
(yet another vastly overloaded term) which SIP is supposed to accommodate:
anything from transfer to next-gen
your-refrigerator-is-calling-to-say-you're-out-of-milk. In short signaling
in the context of SIP is a pretty big thing now with lots of different
interest groups and lots of different priorities. The question (and I think
that's basically what you were asking) is how do you accommodate all of this
within one protocol. 

The answer is composed of two words: generality and extensibility.  Baseline
SIP (RFC 2543) attempts to be both general and highly extensible. All the
fundamental session management stuff which is applicable to all applications
(establishment, modification, termination, capabilities exchange,
registration etc.) is there in the baseline spec.  There's very little
application-specific stuff though. This is intentional.  The fundamental
idea is: "if you want something more - extend or, better yet, use an
existing extension".  Baseline SIP provides mechanisms to add new methods,
response codes, headers header params and much more and it allows extension
announcement and negotiation so all parties of a call can be sure that a
required extension is supported by all others.  You can say extensions are
encouraged in SIP.  And there are plenty of extension proposals as anyone
reading this mailing list knows.  None of that is supposed to penetrate into
RFC 2543, though. It's supposed to remain pure and backwards compatible for
ever (Jonathan R's words: "there will be no version 2.1 of SIP"). The
extensions will continue to develop and move along the standardization
process as independent entities and eventually (hopefully) the "good"
extensions will be finalized and gain popularity and the "bad" ones will die
out from lack of demand or technological merit.  There's not going to be a
planning committee that says "this will become a part of SIP from now on" or
"this is what SIP is about to be used for" because reaching an agreement on
such issues is close to impossible.   

That's my 0.08 Shekel (2 US cent equivalent) :)

  Itamar

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Aug 2000 15:04:38 -0400

I am acutely aware of this problem, as both an active promoter of sip
and one of the most vocal opponents against many uses that I consider
inappropriate.

There is a thin line between reuse of infrastructures and protocols, and
abuse of a protocol which only hurts long term interoperability and
viability. I have been attempting to capture this balancing act in the
"guidelines for authors of sip extensions", which will continue to
evolve as our understanding of this subject increases.

Check it out at:
http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-00.txt

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 03 Aug 2000 16:12:24 -0400

There is also another line. Extensions are potentially bad if they
increase the N^2 problem of interoperability for similar devices, and
the number of cases (does the other side have feature 1? 1+2? 1 or 3?,
etc.) that need to be tested. It is probably less of an issue if the use
of SIP is either go or no go. (In that sense, I find the use of SIP for
sending control messages less dangerous, since it is unlikely that a
phone worries about lightbulb messages or vice versa, so that the these
can be implemented without lightbulb implementors having to be VoIP
experts, and vice versa.)

This is encouraged by clear labeling of methods, message bodies
(Content-Type and Content-Disposition), Require and other mechanisms.
The worst problem in extensions is, I believe, mutual dependence or
deadlock, such as "You can't do X because my completely unrelated
application relies on SIP doing Y."

Currently, "feature interaction" seems to be a particular problem with
the proliferation of SIP-for-VoIP features (COMET, PRACK, 3pcc, session
timer, REFER, etc.) rather than simpler "new stand-alone methods that
don't interact with anything else". (PRACK and COMET are examples where
new methods *can* interact with existing methods and can raise feature
interaction issues.)

The other complexity concern is N ways of doing very closely related
things (DTMF comes to mind for some reason...)