Hi, 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. When the sipXproxy sees the in-dialog ACK sip:r...@ip_colliding it recognizes the 'IP_colliding' as an alias of its own domain and concludes that this must be a GRUU and therefore forwards the ACK to the redirect server so that the GRUU can be resolved to the Contact of the RW1 UA instance. The obvious problem with that approach is that is that sip:r...@ip_colliding is the actual contact of the RW and is *not* a GRUU that the redirect server can resolve. As a result, the redirect server fails to provide a 'better contact' for sip:r...@ip_colliding and the ACK is not routed -> call fails. It appears to me that the correct way to fix this issue is to modify the sipXproxy to only consult the redirect server for in-dialog request routing if the following two conditions are met: Condition #1- Domain part of Request-URI matches our domain or a domain alias; Condition #2- The Request-URI is a GRUU as determined by the presence of the 'gr' URL parameter. Currently, sipXproxy only checks for condition 1 which leads to failures to reach remote workers that happen have the same IP address as sipXecs (that IP address being a domain alias by default). In order for this solution to work though, the sipXregistrar would also need to be changed because the public GRUUs it generates do not comply with the gruu format by not appending a 'gr' URL parameter to the GRUU (see XECS-2351). I have prototyped a slimmed down version of this proposal to confirm that this change makes it possible for the NAT traversal feature to reach out to remote workers that have a private IP address identical to sipXecs's. I'm seeking comments on the proposed approach - thank you in advance. 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. Cheers, bob _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
