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

From: Itamar Gilad <[email-masked]>
Date: Thu, 3 Aug 2000 15:25:11 +0300

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

> -----Original Message-----
> From: Arnoud van Wijk (ETM) [mailto:[email-masked]]
> Sent: Thu, August 03, 2000 12:39 PM
> To: 'SIP'
> Subject: [SIP] What do we want with SIP?
> 
> 
> Scott Petrack's message indeed made me realise that to my 
> impression we all are not really sure on what the duty for 
> SIP will be.
> A real danger what is possibly going to happen is that we all 
> want to add headers and other extensions to SIP, that before 
> we realise, SIP will act like a fat pregnant elephant instead 
> of a sleek and fast gazelle.
> 
> SIP is indeed very good at Initiating a Session, and then 
> hand it off to a different protocol. Like RTP or RSVP etc. 
> Preconditions set in the header will also be a good idea, but 
> for exactly which protocols?
> 
> In fact, what do we plan to use SIP for? We all have a 
> different idea what we want SIP to do for ourselves. I am not 
> immune either.
> Maybe it is a very good idea to form a consensus on what we 
> want SIP to do for us.
> Do we want SIP for:
> Only IP-telephony?
> Also Multimedia IP sessions on 1. a computer, 2 a mobile 
> digital board (PIM/PDA/WAP/UMTS phone etc)?
> Do we want home appliances and other machines be able to send 
> us info via SIP?
> Do we want to send instant messaging via SIP?
> Do we want SIP to track mobility of the user?
> Do we want to use SIP to handle the AAA services? (Billing of 
> network usage and QoS and the service from content providers, 
> like a database search or keeping track of the IP session 
> duration and the amount of data passing through the UAs used 
> for the session)?
> 
> With good planning, many of those tasks can overlap each other.
> 
> If we try to make a list of what the required duties of SIP 
> are and what can be handed off to the protocol that SIP is 
> initiating the session for.
> Then we can really define which headers are really necessary 
> for SIP (like the media type <video, audio, text> and 
> language <english, dutch, french>, and which headers will 
> just refer to the preconditions of the handed off protocol 
> <Security options and QoS options and OSP tokens for AAA services>).
> With our combined visions, we should be able to do this. 
> The ideal to obtain is publish it once and then many years 
> without any new versions of SIP. While the possebilities of 
> SIP continue to expand (at application level).
> 
> Also, when we know which protocols are required to team up 
> with SIP, we will get those protocols also finished and ready for use.
> Future protocols should be easily be added to SIP in the 
> Content-Type header (draft-ietf-sip-rfc2543bis-00).
> So that most future changes will be on UAs level on how to 
> process the offered protocols, instead of how to send/receive 
> and read/write/understand SIP messages.
> 
> Well those were my 2 Euro cents.
> This mail is not intended to show any disrespect nor to 
> discard all the efforts. I just hope to have all of us team 
> up and sail in ONE direction.
> 
> Arnoud
> _______________________________________________________________
> ERICSSON TELECOMMUNICATIE BV
> Arnoud van Wijk
> Research & Development
> ETM/BL/RE
> Fax: +31-161 247569
> _______________________________________________________________
> 
> 
> 
> 
> 
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
> 

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