2011/4/25 Vijay K. Gurbani <[email protected]>: > 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.
I agree, but I cannot see clear why a 404 is not better than a 604. In fact IMHO both mean the same (as a 404 must only be replied by a server responsible for the destination domain, or by a proxy trying to resolve a non existing domain as in this thread). > 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. I assume you mean 404 :) > 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. 6XX responses are painful in many cases. In fact, I do know about some proxies which, optionally, ignore the special behavior/meaning of 6XX responses. Things work better without 6XX (at least under my experience). Thanks a lot. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
