________________________________________ From: [email protected] [[email protected]] On Behalf Of Iñaki Baz Castillo [[email protected]]
1) Route: <sip:A.org> 2) Route: <sip:A.org:5060> 3) Route: <sip:A.org:6060> 4) Route: <sip:B.org> 5) Route: <sip:B.org:5060> 6) Route: <sip:B.org:6060> By following SIP URI comparison procedures, sip:A.org is different than sip:A.org:5060 so, obviously the proxy cannot perform SIP URI comparison when matching local Route's. But obviously all the 6 pre-loaded Routes above should be matched by the proxy as "local Route" so they should be removed. _______________________________________________ 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. Dale _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
