2011/5/31 Worley, Dale R (Dale) <[email protected]>: > The important question is "By what URIs is an element allowed to indicate the > proxy?" This is an administrative decision as much as a technical one. > > For example, if an SRV record for A.org routes to 1.1.1.1:6060, that does not > mean that <sip:1.1.1.1:6060> is permitted to be used as a URI for the proxy > -- even though if an element routes a request via <sip:1.1.1.1:6000>, it will > reach the proxy. It may be administratively decreed that <sip:A.org> must be > used. > > Within that context, if you desire that all six Route headers are valid ways > to route to the proxy, then the proxy must be prepared to recognize all of > them as "indicating itself", which cannot be done with a single "URI > equivalence" test (as you know). > > But in practice, it is desirable for the proxy to recognize as "indicating > itself" as many as possible of the URIs that actually route to the proxy. > Otherwise, the proxy may receive a request with a Route URI (or request URI) > that it does not understand, and forward the request "onward" only to have > the request return to itself immediately, causing a routing loop.
Good point. In the case of matching the Request URI it's important that the proxy just accepts those domains as configured in DNS (this is, deny Request URI with proxy IP or proxy domain + port. But unfortunatelly this is not so easy when dealing with pre-loaded Routes. I've seen many cases in which some UA include a Route header by also appending the URI port and so. So IMHO the proxy could be more flexible when traying to match pre-loaded Routes as local. Anyhow, all this stuff must be locally decided within the proxy configuration. Thanks a lot. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
