Subject: RE: [Sipping] SIP Negotiate

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Sep 2001 02:51:32 -0400

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 

_______________________________________________
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: "Brian Stucker" <[email-masked]>
Date: Mon, 10 Sep 2001 10:57:38 -0500

Thanks all for your views, please keep them coming.

Dave, actually, no you don't (need to renegotiate). If you include the key
in your SIP messages
(either as a shim or a header) then if the other end is no longer
synchronized because it 
was rebooted (which may not necessarily clear the key out depending on the
implementation)
or is running different software, then the key will be rejected. 

It was our feeling that when parameters are always getting negotiated, each
session, to be
basically the same thing, over, and over, that it's a waste of time to do
this negotiation
constantly when it yeilds very little diversity in the results. Therefore,
we're proposing
a mechanism to "factor out" those parameters so that this extra work is
performed as few
times as can be. We did not give specific examples of usage because we don't
pretend to
know all of the possible applications that this could be used for. The
parameters that are
setup could apply only to the media stream, or only to the signalling
stream, or a mix. 
Additionally, renegotiating on a per session basis amounts to a requirements
"ping" 
mechanism where one end is asking the other "have your requirements
changed?" and most of
the time it's going to say "no". So in effect, all of the times you
negotiate settings
was a waste of time up to the point at which they've changed. What we're
doing is asking
that question once, and assuming that those requirements are good until
otherwise told
by the other end (by rejecting the key). We're removing all of the
extraneous negotiation
that didn't reveal any new information, but was necessary only because
there's no notion
of state outside of each session.

When initiating a session, endpoints are likely to come up with similar
requirements on the
payload or signalling in order to process the session or the session setup
appropriately.
Requiring 3rd party services to take on the responsibility of identifying
these parameters
adds a sometimes useful mechanism, as Johnathan pointed out, to resolve
this, and I agree
with that approach in some circumstances. However, is it appropriate to
assume that in 
order for a SIP endpoint to compress it's signalling, that we require it to
have a 
DNS-SRV entry somewhere? This model works well in a 3GPP architecture, but
would it work 
as well in the realm of the home user who may not be able to access a DNS
server directly, 
or have an ISP that supports SRV records? Maybe not. Is it still useful, of
course. Does
our draft preclude publishing of capabilities, no. In fact, if publishing
were used to
display the menu of options available, the negotiation process would be
simplified further.
The two are complimentary to each other.

Choosing several algorithms to tackle some of the jobs that face SIP (such
as compression,
message integrity, QoS of the media stream, etc.) and saying that they're
the only way that
SIP is going to provide a solution to these problems seems to decrease
flexibility in the
protocol. As SIP has grown more in new arenas, such as wireless, it is
becoming increasingly
obvious that the baseline protocol needs to be as flexible as possible. It
also needs to operate
as efficiently as possible. 

I agree that complex negotiation schemes can cause interoperability
problems, which is why 
we left ours relatively simple and straight-forward. If you look at a
typical messaging stream
using NEGOTIATE, I think it would be hard to argue that it's any more
complex than what goes on
in most INVITE transactions. Again, we are trying to factor out the
complexity of the more common
transactions in order to reduce per-transaction complexity, and bundle it
into as short and sweet
a negotiation as is possible.

Thoughts?

Brian

-----Original Message-----
From: David R. Oran [mailto:[email-masked]]
Sent: Monday, September 10, 2001 8:07 AM
To: Parameswar, Sriram [NGB:B658:EXCH]; 'Jonathan Rosenberg'; 'Sean
Olson'; sipping; Stucker, Brian [NGB:B651:EXCH]; jari.arkko
Subject: RE: [Sipping] SIP Negotiate

> 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]'
> 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. 
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.

> ** 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. 
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 
> __________________________________________ 
> Sriram Parameswar              Phone: 972-685-8540 
> Interactive Multimedia Server (IMS) Fax: 972-685-3563 
> Nortel Networks, Richardson USA  Email: [email-masked] 
> 
> 
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Friday, September 07, 2001 1:52 AM 
> To: Sean Olson; Parameswar, Sriram [NGB:B658:EXCH]; 
> [email-masked]'