Robert It is understood that the receipt of a non-2xx final response on one of the provisional call-legs should cleanup the state in all other call-legs for that transaction and a timer started for the call-leg that received the non-2xx final response. If a 2xx class response is received on one call-leg, a timer should be started on the other legs for cleaning up if no 2xx class is ever received on the others. I am not sure that we should impose an additional twist on the UAC by allowing the proxy to create a new call-leg by sending the non-2xx response with a tag that is different from the ones on the provisionals that have been forwarded, earlier. When picking a best reponse, can we not suggest that the proxy re-use a tag from one of the final responses it is choosing from? Venkat
-----Original Message----- From: Robert Sparks [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 10:43 AM To: 'Paul Kyzivat'; Robert Sparks Cc: 'Bob Penfield'; Arunachalam Venkatraman; Wei BJ Lu; [EMAIL PROTECTED] Subject: RE: [Sip-implementors] How does forking proxy handle To Tag in errorresponse selection? I assume you are asking about how endpoints deal with any state they may created due to provisional responses, and not really about what the proxy does with multiple provisionals? (Venkat was asking this question). A stateful proxy just forwards any provisional (except 100) it sees. Basically, you are doomed to clean up such state with timers. Consider the following: A / requestor - P1 \ B Where A and B return a state-invoking provisional. Suppose now that both A and B reject the dialog, each returning a 486 perhaps. Even if P1 preserves the tag from one, you have no way of seeing a final response containing the tag of the other. RjS > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED]] > Sent: Friday, November 16, 2001 10:18 AM > To: Robert Sparks > Cc: 'Bob Penfield'; Arunachalam Venkatraman; Wei BJ Lu; > [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] How does forking proxy handle > To Tag in > errorresponse selection? > > > Robert - thanks for the clear explanation. It is helpful. > > So what happens if the proxy receives 183 from more than one of the > forked destinations? > > Paul > > Robert Sparks wrote: > > > > There is some subtlety here that's important to understand. > > > > The restriction below is not actually in the text - I'm working > > to try to find a way to make it harder for people to reach it and > > welcome input. > > > > First - we are talking about a proxy that is handling a transaction > > statefully. If the transaction is being handled statelessy, > it doesn't > > deal with this whole "best" response concept. > > > > When a stateful proxy sends any non-200 response (basically any > > hop-hop response), it is really responding on its own as a UAS > > using the various responses it received as inputs. > > > > It MAY choose to reuse the To: tag from one of those inputs if > > it chooses to forward it, but ->nothing<- will break if it chooses > > to make up its own. > > > > In fact, there are cases where its going to have to - if every > > downstream proxy for this particular request returns a 503, this > > proxy probably is probably going to return a 4xx and provide its > > own tag (other requests going through other downstream proxies > > may yet succeed). If the proxy determines that the whole world > > has gone sour and wants to return its own 503 - it really is making > > a statement about itself, not forwarding a statement about proxies > > downstream from it. > > > > Consider further a proxy that acts as a redirect > aggregation service - > > every place it sent this request to returns a 302. It chooses not to > > recurse, but to pool all the contacts into one big collection and > > send it upstream. The resulting 302 comes from _this_ > element (acting > > as a UAS). So does it add its own tag or reuse one from one of the > > responses it received? It _doesn't matter_. An implementation could > > just pick one of the received 302s, copy the contacts from all the > > others into it and forward it. Or it could build its own response > > from scratch, making its own tag in the process. The end result from > > a system perspective is exactly the same. > > > > The same is true for returning a 401/407 (where a proxy has to > > aggregate all of the challenges from any other 401s or 407s its > > seen into this one). > > > > The main thing to remember is that as non-200 responses, they > > are hop-hop. The tag information contained in them has _NO_CHANCE_ > > of being used to construct an ongoing dialog. An element could > > munge the tag for _every_ forwarded non-200 replacing it with its > > own value (globally unique to the transaction of course) and > > nothing breaks. From a system perspective, nobody could even tell. > > > > Responses that might create a dialog are a whole different matter. > > The restrictions on not touching the tags there are very important. > > > > RjS > > > > > Based on table 3 (Summary of Header fields), and on the text > > > in section > > > 16.6, the proxy is not allowed to modify the To header in the > > > "best" non-2xx > > > final response it sends to the UAC. Therefore, the proxy is > > > not allowed to > > > add a tag, or change the tag in the response. > > _______________________________________________ > > Sip-implementors mailing list > > [EMAIL PROTECTED] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
