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

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

> -----Original Message-----
> From: Jo Hornsby [mailto:[email-masked]]
> Sent: Wednesday, September 05, 2001 9:04 AM
> To: Jonathan Rosenberg; [email-masked]; [email-masked]
> Subject: RE: Legal merged requests (issue #172), was: RE: 
> [Sip] Response
> Code of 422 in Session-Timer draft
> 
>
> 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. &:)

Agreed on that one.

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

I suspect that is the case.

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

Good point. Yes, I think you are right.
> 
> > Comments? My leaning is probably 3 since I think its the easiest.
> 
> Agreed.  I would see 2 as very hard in general.

Anyone else? Please speak up else in one week I will declare this issue
closed and go with #3 in addition to the UAS behavior Jo has described.

-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

---

From: Tan Ya-Ching ICM N MC MI E73 <[email-masked]>
Date: Fri, 7 Sep 2001 09:12:33 +0200

The following discussion was outside of the [SIP] list :

-----Original Message-----
From: Jonathan Rosenberg [mailto:[email-masked]]
Sent: 06 September 2001 22:29
To: Tan Ya-Ching ICM N MC MI E73; Jonathan Rosenberg;
[email-masked]'
Subject: RE: Legal merged requests (issue #172), was: RE: [Sip] Response
Code of 422 in Session-Timer draft

> From: Tan Ya-Ching ICM N MC MI E73 
> [mailto:[email-masked]]
> Sent: Wednesday, September 05, 2001 11:37 AM
> To: 'Jonathan Rosenberg'; [email-masked]'
> Subject: RE: Legal merged requests (issue #172), was: RE: [Sip] Response
> 
> | 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.
> | 
> 
> I thought bis-04 clearly implies view 3. In section 17.3.4 Stateful Proxy:
> Receiving Requests, in addition to To, From, Call-ID and CSeq, bis-04
added
> the check for Request-URI and topmost Via, against existing request
records.
> It then states that if the tuple does not exist (topmost Via (and the
branch
> parameter) will be different), "the request corresponds to a new
> transaction, and the request should be proxied".

That is certainly true, but thats not consistent with some other writings
that have been done on the subject of merged requests. I have come to the
conclusion that what is written in bis-04 is the right thing. It buys us the
very important capability for a proxy to retry a request by changing some
other things, so long as the via branch id changes.

-Jonathan R.
---