Subject: RE: [Sip] RE: [Sipping] SIP Negotiate

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

Take a look at section 2.1 of the bis draft dealing with SIP URL 
comparison. The user portion of the SIP URL is case-sensitive.
This should be taken into account when determining the call 
leg (based on To:/From: URLs). For example,
"sip:[email-masked]" is not the same as "sip:[email-masked]"
 
It is a very minor nit. My recommendation would be to include the
user portion in its original case and everything else in lowercase.
This is not strictly correct either. I don't have a perfect solution
in mind. Just something to think about.
 
/sean

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

Sean,
 
For your last question, about the MD5, the reason that we specified all uppercase prior to the MD5 hash was because there is no requirement that we're aware of that says that any given SIP node (proxy, UA, etc) has to be case sensitive, or preserve the case of SIP message headers as they traverse the network. So, if we didn't specify a case in the algorithm, the two nodes could come up with two different hash values for the same set of headers.
 
As always, thanks for your comments.
 
Brian

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

Sean, 

Thanks for you comments. My reply in-line prefaced by [SP]. 

Best 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: Sean Olson (EUS) [ mailto:[email-masked] <mailto:[email-masked]> ] 
Sent: Friday, August 31, 2001 10:06 AM 
To: Parameswar, Sriram [NGB:B658:EXCH]; [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. 

[SP] Allow typically handles SIP Methods, we were looking at session 
     parameters - Code Book size, Compression Algorithms, QoS mechanisms etc. 
     If we extended Allow to perform a Negotiation type role we would have 
     backward compatability issues, also it would be session specific. We are looking 
     for a mechanism that applies across sessions. 

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

[SP] we considered OPTIONS when we started this work and 
     it is our opinion that it would break backwards compatability. 

   Alternatively, a nested INVITE might work. 

[SP] If I understand ths correctly you would use the 
     INVITE to perform negotiations. I see two problems with 
     this approach (please correct me if I have mis-understood): 
       ** this would add to delays in setting up sessions 
       ** Again an INVITE would do this on a session-by-session basis 
          it was our intentions that Negotiated parameters apply across 
          sessions. 

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. 

[SP] Agreed certain parameters may need to be negotiated on 
     a per session basis. You *could* use Negotiate for such 
     situations too, in this case the Expires header does 
     not have the same value. As an example we are looking 
     at meta-session parameters that you could negotiate that 
     would last across sessions like: compression to your Local 
     Outbound Proxy. 

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. 
[SP] Agreed there are problems with Stateless proxies and we 
     do note that in the document. 

5) I would treat NEGOTIATE exactly like SUBSCRIBE with 
   respect to forking proxies. 
[SP] Thanks we will include that in future updates of the document. 

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? 
[SP] Its my initial reaction that we should have uniqueness even 
     with the conversion to uppercase. But will definitely consider 
     removing it if otherwise. 

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, 
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 <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: "Bob Penfield" <[email-masked]>
Date: Fri, 31 Aug 2001 19:25:13 -0400

I agree with Sean that you don't want to change the content of the headers,
but it is probably wise to normalize the header labels. In 2543bis (section
18.2), one is required to use the full & correct forms of the header labels
as input when cryptographically signing part of a SIP message.

(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

----- Original Message -----
From: "Sean Olson (EUS)" <[email-masked]>
To: "'Brian Stucker'" <[email-masked]>; "Sriram Parameswar"
<[email-masked]>; <[email-masked]>
Sent: Friday, August 31, 2001 4:53 PM
Subject: RE: [Sip] RE: [Sipping] SIP Negotiate

> For your last question, about the MD5, the reason that we specified all
uppercase prior to the MD5 hash was because there is no requirement that
we're aware of that says that any given SIP node (proxy, UA, etc) has to be
case sensitive, or preserve the case of SIP message headers as they traverse
the network. So, if we didn't specify a case in the algorithm, the two nodes
could come up with two different hash values for the same set of headers.
> 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
<http://www.obsidian97.com/draft-spbs-sip-negotiate-00.txt>
> We invite your comments, the abstract is included below for your perusal.

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