Robert Can you please confirm my understanding of what you suggest - The UAC that has state information for two possible dialog-legs due to the 18x recveived from 2 UASes may receive a response from the proxy with a new tag thereby causing the establishment of state for a new dialog-tag in order to handle possible retransmissions of the ACK if the final response is retransmitted by the proxy. At the same time, the receipt of a non-2xx response on this new call-leg should result in cleaning up the state for the transaction in the call-legs established by the 18x responses.
The redirection aggregation is a no-brainer since no call-legs are established at the UAC by 1xx responses. Venkat -----Original Message----- From: Robert Sparks [mailto:[EMAIL PROTECTED]] Sent: Friday, November 16, 2001 9:53 AM To: 'Bob Penfield'; Arunachalam Venkatraman; Wei BJ Lu Cc: [EMAIL PROTECTED] Subject: RE: [Sip-implementors] How does forking proxy handle To Tag in errorresponse selection? 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
