> 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.
I like this suggestion. > > > 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. Yes, the problem is along those lines. The redirector fails to provide a contact for the 'non-GRUU' and as a result, the message is not routed any further. This prevents the NAT traversal agant plug-in from seeing the message and making the necessary adjustments to ensure its proper routing through NATs. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
