On 04/23/2011 06:28 PM, Iñaki Baz Castillo wrote: > I the proxy does parallel forking and receives a 180 in branch-1 and > 603 in branch-2, it would send a CANCEL for branch-2 and obtain a > 487 from branch-2. Now it must choose the first final response (603 > vs 487), which one? (I ask it because I'm not sure right now, I think > 4xx replies win, but I'm not sure).
RFC3261 is pretty clear on this, the 6xx is to be returned (step 6 of Section 16.7 in rfc3261). However, we have deviated from the original problem [1] by introducing forking. In the original problem, an outbound proxy receives a request which does not fall in its domain and it is getting ready to route the request based on the R-URI. Since the outbound proxy did not fork, and since it knows that sending this particular request to some other server will not result in the domain magically appearing, I feel that a 604 is justified. Now, when we bring forking in the picture, then forking can happen at one of two places: either at the outbound proxy or some client upstream of the outbound proxy. Case 1: The forking is done at the outbound proxy, and let's assume that a location server was contacted and it responds with multiple URIs for the AoR, one of which is a URI rooted in the "invalid- domain.net". Here, the correct behaviour would be for the proxy to generate a 408 on the branch that included the "invalid-domain.net" host. Case 2: The forking happened at some upstream client causing a downstream proxy to receive a R-URI with "invalid-domain.net". RFC3261 would require the proxy to return a 404. Dale's response was predicated on this case, I believe. Were the proxy to return a 604, it would have taken precedence at the upstream client, causing the 604 to become the "best" response. With forking and getting a 6xx response on one branch and non-2xx responses on the other branches we are left with a manifestation of the well-known HERFP problem where a repairable response is hidden by another response. At this point I do not recall why we chose to give special treatment to 6xx responses by making them the best responses when they exist in a response context (maybe someone remembers from the rfc2543-bis days...). If we would not have done this, then a 4xx class would be the best response (assuming there were no 3xx and 2xx-class responses). Personally, I still think that 604 is the most appropriate response when a proxy sees a R-URI with an invalid domain name; clearly, trying that request elsewhere will not make the domain magically appear. But it does seem that sending a 6xx-class response interacts badly when forking is involved and there are other repairable error responses that can be sent upstream. [1] https://lists.cs.columbia.edu/pipermail/sip-implementors/2011-April/026966.html Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / [email protected] Web: http://ect.bell-labs.com/who/vkg/ _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
