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

From: "Jo Hornsby" <[email-masked]>
Date: Wed, 5 Sep 2001 14:04:10 +0100

Jonathan wrote:
> 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.

Nononono. &:)

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

I think this is valid.  (Well, I think it might technically
only be unique within the sent-by space, but that's a small
issue.)   There might be a slight issue with 2543 proxies,
but I'm thinking that they would fail to notice the merge
anyway...?

> 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).

Uh.  I don't think it should apply the same response to all.
What is the motivation for this?  I think this would mean
that we would get the horrible forked route problem.  I would
suggest that the UA has the oppurtunity to prefer one request
over all the others (in the case of a 200) (this decision
may be arbitrarily complex), and 482 the rest.

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

Agreed.  I would see 2 as very hard in general.

 - Jo.

_______________________________________________
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