On Thu, 2009-03-12 at 16:00 -0400, Robert Joly wrote: > Note: As I was writing the details of Condition #1 I started wondering > if we really need to take into consideration domain aliases when testing > the domain of the AOR. Given that the GRUUs we generate all use our SIP > domain as the host part of the URI, all the GRUUs we will ever need to > route will have our SIP domain and never the alias. Perhaps another way > to fix this remote worker problem would be to use a single condition to > decide to route in-dialog requests to the redirect server and that > condition would be: > > Condition #1- Domain part of Request-URI matches our domain. > > Such a condition would prevent in-dialog requests with sipXecs's IP as > the host part to be routed to the redirect server which is the behavior > I am looking for.
Given that the special "send to the redirector" behavior is "deviant", and thus likely to trigger problems (as it has in this situation), the fewer URIs that trigger the special behavior the better. So this approach seems to be a good one, or perhaps even the narrower condition: domain part of request-URI matches our domain and is a GRUU. > The purpose of this e-mail is to describe a problematic NAT traversal > scenario involving remote workers and propose a change to sipXproxy and > sipXregistar to address it. > > Scenario Description > ===================== > - sipXecs is deployed inside private network P1 > - Remote Worker RW1 is deployed in remote private network P2 > - Private IP address ranges used in networks P1 and P2 overlap > - The sipXecs and RW1 happen to use the same private IP address - let's > call this address IP_colliding > > User at some local phone tries to make a call to RW1. The INVITE > reaches the RW; RW sends 200 OK with a Contact header set to > sip:r...@ip_colliding. The local user then sends an ACK to > sip:r...@ip_colliding and is never routed by sipXproxy to RW - here is > why. If I remember how NAT Traversal works, this Contact URI is modified by NAT Traversal when it arrives to record RW1's public IP address, because otherwise phones with contacts on P2 would never be accessible. But the problem arises because we do the "should this be routed to the redirector?" test much earlier than we check for the NAT-Traversal URI parameters. Dale _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
