Subject: [Sipping] SIP Negotiate

From: "Sriram Parameswar" <[email-masked]>
Date: Fri, 31 Aug 2001 09:35:08 -0500

Hi,

We have just submitted a new I-D on negotiation of meta-session parameters
for SIP sessions. Until the draft appears in the archives, you can pick up a
copy at:

http://www.obsidian97.com/draft-spbs-sip-negotiate-00.txt

We invite your comments, the abstract is included below for your perusal.

Thanks,

Sriram Parameswar
Brian Stucker
--------------------------------------------------------------
Abstract:
There is a need to negotiate a multitude of parameters, settings, and
algorithms when setting up sessions using Session Initiated Protocol (SIP).
While SIP itself provides mechanisms for negotiation of these parameters on
a per-session basis through the use of the INVITE method, it does not
provide a ready mechanism for meta-session negotiation. The closest
mechanism provided is the REGISTER method, however, this method is directed
towards the registrar alone, and cannot be used to conduct negotiation of
parameters between any two arbitrary SIP nodes. Examples of parameters that
may need to be negotiated (and thus, the ready impetus for providing a
simple mechanism to handle this) include: compression algorithms, code book
size, message integrity mechanisms, encryption algorithms, etc. Many of
these parameters are not always eligible for use in an INVITE method, for
two reasons: 
	- The INVITE method describes the parameters for initiation of a
particular session. Once the session is over, the negotiated settings (such
as the RTP profile used, in the case of SDP) are invalidated for future
re-use. It would be inefficient to have to renegotiate parameters that are
the same from session to session, or have to transmit large quantities of
persistent data (such as a code book) each time. 
	- Many meta-session applications (and therefore their attendant
negotiable parameters) are best utilized if they can be applied for the
first message of a session. An example of this would be header compression.
If the INVITE were compressed, then the header that identifies the type of
compression in use would also be compressed, and therefore unintelligible
(assuming no shim mechanism). 

This document seeks to solve these problems by introducing a SIP extension
that allows for meta-session parameters to be negotiated in a generic
manner. This negotiation would take place prior to session establishment,
between any two SIP entities (User Agents, Proxies etc.). 

__________________________________________
Sriram Parameswar              Phone: 972-685-8540
Interactive Multimedia Server (IMS) Fax: 972-685-3563
Nortel Networks, Richardson USA  Email: [email-masked]

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Fri, 31 Aug 2001 10:06:18 -0500

Hello,

I have a few immediate comments. First, I agree that such
a mechanism is needed. My comments really are 
directed at the details of your proposal.

1) Do we need to define a named extension "negotiate"?
   It seems the Allow: header and the 405 response give
   you everything you need in this regard.

2) Would it be possible to use the OPTIONS method instead?
   I realize this is a bit of a twist on OPTIONS.

   Alternatively, a nested INVITE might work.

3) It seems that some of the information that you
   are negotiating should be applied on a per-session
   basis and should not necessarily be used across
   sessions (e.g keys). Do you anticipate sending a
   NEGOTIATE request before every INVITE? The Expires:
   header doesn't really give you the level of control
   that I'm talking about.

4) For stateless proxy operation, it seems more appropriate
   to include/reiterate the meta session parameters in the
   INVITE. That is, I wouldn't expect a stateless proxy
   to use parameters in the NEGOTIATE for the "next" INVITE.
   Naturally, there are some parameters that will be completely
   meaningless to a stateless proxy. Compression may be one
   example.

5) I would treat NEGOTIATE exactly like SUBSCRIBE with
   respect to forking proxies.

6) In your MD5 hash description, you convert the To/From URL
   to all uppercase. This is a bit pedantic, but wouldn't
   you want to preserve the case of at least the userinfo
   portion of those URLs for uniqueness?

Regards,
Sean Olson
Ericsson Inc.

-----Original Message-----
From: Sriram Parameswar [mailto:[email-masked]]
Sent: Friday, August 31, 2001 9:35 AM
To: [email-masked]'; [email-masked]'
Subject: [Sipping] SIP Negotiate

Hi, 
We have just submitted a new I-D on negotiation of meta-session parameters for SIP sessions. Until the draft appears in the archives, you can pick up a copy at:
http://www.obsidian97.com/draft-spbs-sip-negotiate-00.txt 
We invite your comments, the abstract is included below for your perusal. 
Thanks, 
Sriram Parameswar 
Brian Stucker

---

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 31 Aug 2001 11:17:19 -0400

Would future responders to this thread PLEASE remove
the copy to sipping.  If this were to be adopted as a work
item based on this draft, it would be a work item for sip.
It's conceivable we could take a step back and ask 
sipping to do a requirements document.  For the
moment, let's keep the comments on the sip list ONLY.
 
In general NEVER post the same message to sip and
sipping.  If you have a doubt, ask a chair near you.
 
Brian

-----Original Message-----
From: Sean Olson (EUS) [mailto:[email-masked]]
Sent: Friday, August 31, 2001 11:06 AM
To: 'Sriram Parameswar'; [email-masked]'; [email-masked]'
Subject: [Sip] RE: [Sipping] SIP Negotiate

Hello, 

Regards, 
Sean Olson 
Ericsson Inc. 

-----Original Message----- 
From: Sriram Parameswar [ mailto:[email-masked]
<mailto:[email-masked]> ] 
Sent: Friday, August 31, 2001 9:35 AM 
To: [email-masked]'; [email-masked]' 
Subject: [Sipping] SIP Negotiate 

Hi, 

http://www.obsidian97.com/draft-spbs-sip-negotiate-00.txt
<http://www.obsidian97.com/draft-spbs-sip-negotiate-00.txt>  
We invite your comments, the abstract is included below for your perusal. 
Thanks, 
Sriram Parameswar 
Brian Stucker