Subject: Legal merged requests (issue #172), was: RE: [Sip] Response Code of 422 in Session-Timer draft

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Aug 2001 16:41:56 -0400

> -----Original Message-----
> From: Brett Tate [mailto:[email-masked]]
> Sent: Wednesday, August 08, 2001 8:20 AM
> To: [email-masked]
> Subject: RE: [Sip] Response Code of 422 in Session-Timer draft
> 
> Solution 3) Allow P1 to fork the same 
> request to P2 but use a higher Session-Expires.  
> This is bad because P2 potentially may not 
> realize that it is a different request and 
> assume that a forked request merged.  Thus the
> same negative response might get returned.
> 
> Solution 3's problem is common for any 
> merged forking situation where a proxy includes 
> different headers or header values on the 
> different branches.  This could be hopefully 
> avoided by specifying in the bis that if a 
> negative response was returned on a merged branch 
> request, subsequent merged requests must still 
> be checked to see if the same response applies.

I think it is worth discussing this as a separate item. Its come up a few
times and is amongst my open issues list for bis.

We've run into a couple of cases now where a merged request isn't a bad
thing. The current text on merged requests
(http://www.jdrosen.net/sip/multiple_requests.txt) pretty much assumes that
the only thing of relevance for a proxy is the r-uri, so that if this hasn't
changed, the results of the proxy processing won't change. It has become
clear that this is not the case at all. We now have several things that an
upstream proxy might have modified which will result in differing behaviors:

1. Require/Proxy-Require stripping/addition
2. Session-Expires updating
3. modification of caller preferences headers

There are several views on what to do here:

1. proxies shouldn't be mucking with any of these things anyway. The only
real thing a proxy should change is the r-uri, so that the current merging
text is correct. Basically, don't fix this problem.

2. As Brett has suggested, the proxy can redo its processing on these
requests. If the "result" is the same, reject it as described in the text.
Note that figuring out whether the result is the same is not easy. The
previous request may have even been forked, so that this computation is
quite hard. But, it is doable. Maybe the infrequency of this problem makes
that OK.

3. Proxies don't even look for merged requests. A merged request is treated
as a totally new and independent transaction, and thus processed normally.
The result is that a proxy might proxy the same request twice. Hopefully,
each time is with a different set of top via branch params. Ultimately,
these arrive at a UA, which sees the merging. It applies the same response
to all of them (so long as it uses the same tag, this works out ok). 

Comments? My leaning is probably 3 since I think its the easiest.

-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

_______________________________________________
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