Subject: RE: [Sipping] SIP Negotiate

From: "Sriram Parameswar" <[email-masked]>
Date: Fri, 7 Sep 2001 16:39:39 -0500

Jonathan,

Thank you for your comments. In my opinion there is definitely a need in SIP
to negotiate meta-session parameters. The main reason being - you do not
have to negotiate these parameters over-and-over again on a per session
basis. All negotiation that SIP currently does is typically session based. 

** I am not very comfortable with using SRV to indicate that a proxy is
capable of SIP compression - I think an explicit mechanism that can
negotiate down to the algorithm is advantageous. 

** As far as message integrity goes, yes I am talking about SIP level
message integrity. Choosing a baseline algorithm is definitely easier. But
then you are defeating the flexibility of SIP (which was one of the original
goals of the protocol correct?)

** As far as codebook size is concerned - OK, we could go either way. 

In general I think flexibility in a protocol is important and that the
NEGOTIATE method we propose actually helps interop  by allowing SIP entities
interwork based on a negotiated set of common parameters. 

I understand negotiation may not being a highly desireable trait for a
protocol, but we are proposing to solve problems that already exist (where
there are multiple choices for compression, security, etc.) and others that
will perhaps come forth, that need some sort of negotiation to allow the
protocol to be more generic, less restrictive and have reasonable longevity.
Otherwise would SIP be any different from ISUP ...:) (from another thread on
the list).

Regards,

Sriram

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

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: Friday, September 07, 2001 1:52 AM
To: Sean Olson; Parameswar, Sriram [NGB:B658:EXCH]; [email-masked]'
Subject: RE: [Sipping] SIP Negotiate

I'm not convinced we need this. Partly, this is because its not clear what
exactly problems are being solved. This is a classic case of the sipping/sip
split and why it was created. Everyone likes to rush and create new
extensions, but what are we trying to accomplish? 

SIP has the ability to negotiate lots of stuff already. Some of the things
briefly mentioned in this draft are:

1. compression algorithms: you mean sip compression algorithms (ala,
UDPComp?). SRV seems to work for that.

2. codebook size: wouldn't this be part of the compresion algorithm itself?
That is the trend in the rohc efforts so far.

3. message integrity mechanisms: for transport security, TLS/SSL already
negotiate this. I suppose you are talking sip level stuff. Probably choosing
a baseline algorithm is much easier.

4. QoS: not sure what this has to do with SIP.

In general, negotiation means that you have not been able to pick amongst a
set of alternate choices for a particular feature. Protocol design
guidelines have taught us that you are better off picking one than designing
the compleixty (and interop issues) that will arise with negotiation of
these parameters. There is already too much negotiable stuff in sip, its not
clear to me that adding more is the right direction. 

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com
  
-----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: RE: [Sipping] SIP Negotiate

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: "Jari Arkko" <[email-masked]>
Date: Sat, 8 Sep 2001 08:06:24 +0300

RE: [Sipping] SIP Negotiate
Sriram writes:

>** As far as message integrity goes, yes I am talking about SIP 
>level message integrity. Choosing a baseline algorithm is definitely 
>easier. But then you are defeating the flexibility of SIP (which was 
>one of the original goals of the protocol correct?)

Jonathan's proposal of choosing a baseline algorithm would be the
easiest way. But I'm afraid that as we talk about security, the ability
to change algorithms will be a requirement. One reason for this is
that algorithms could be broken and other ones would have to be
used thereafter. Secondly, algorithms development will introduce
new algorithms with different characteristics, and people want to
take advantage of this. (All security protocols seem to offer this
functionality in one way or another, even, say, HTTP Digest.)

Jari

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

---

From: "David R. Oran" <[email-masked]>
Date: Mon, 10 Sep 2001 09:07:02 -0400

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Sriram Parameswar
> Sent: Friday, September 07, 2001 5:40 PM
> To: 'Jonathan Rosenberg'; Sean Olson; [email-masked]'; 
> Brian Stucker; [email-masked]'
> Thank you for your comments. In my opinion there is 
> definitely a need in SIP to negotiate meta-session 
> parameters. The main reason being - you do not have to 
> negotiate these parameters over-and-over again on a per 
> session basis. 
Sure you do. You have no idea if an endpoint has crashed an rebooted
with different software since the last time you talked to it.

> All negotiation that SIP currently does is 
> typically session based. 
Which is correct, IMHO. 

> ** I am not very comfortable with using SRV to indicate that 
> a proxy is capable of SIP compression - I think an explicit 
> mechanism that can negotiate down to the algorithm is advantageous. 
There is always a tradeoff between publishing your capabilities via a
third-party (e.g. SRV) and negotiating on the fly. If you do not expect
things to change frequently there are significant advantages to the
former, as it allows someone to decide whether to try to talk to you
without trying to talk to you.

> ** As far as message integrity goes, yes I am talking about 
> SIP level message integrity. Choosing a baseline algorithm is 
> definitely easier. But then you are defeating the flexibility 
> of SIP (which was one of the original goals of the protocol correct?)
I do no see how this defeats flexibility, unless you consider the
flexibility of allowing non-interoperable endpoints an advantage.

> In general I think flexibility in a protocol is important and 
> that the NEGOTIATE method we propose actually helps interop  
> by allowing SIP entities interwork based on a negotiated set 
> of common parameters. 
In the past, my experience has been that complex negotiation schemes
(e.g. H.245, X.400) are in fact the cause of many interoperability
problems. Your experience may have been different.

Cheers, Dave.

> I understand negotiation may not being a highly desirable 
> trait for a protocol, but we are proposing to solve problems 
> that already exist (where there are multiple choices for 
> compression, security, etc.) and others that will perhaps 
> come forth, that need some sort of negotiation to allow the 
> protocol to be more generic, less restrictive and have 
> reasonable longevity.  Otherwise would SIP be any different 
> from ISUP ...:) (from another thread on the list). Regards, 
> Sriram