> On Thu, 2009-03-12 at 16:00 -0400, Robert Joly wrote: > > 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. > > Sorry I've taken so long to review this. > > Doesn't this fundamentally break using the IP address of the > proxy as an > alias for the domain?
It does not. The problematic piece of logic that is the topic of this thread is there to route in-dialog requests with sipXecs's domain to the redirect server so that it can provide a contact to the correct UA instance - this was done in support of GRUU. This logic (and the modifications I'm proposing) does not interfere with our ability to allow sipXecs's IP address as a domain alias because even though sipXecs's IP address may be present in the R-URI of a dialog-forming request, subsequent in-dialog requests will have a R-URI to the other party's contact, not our IP address meaning that the piece of logic in question not even come into play. In case you are interested in looking at it, the 'piece of logic' I'm referring to is contained in the else-if block starting at line 475 of http://sipxecs.sipfoundry.org/ViewVC/sipXecs/main/sipXproxy/src/SipRoute r.cpp?annotate=14870. I'm pretty far along in my implementation of this change and I have SIP Router unit tests that verify the condition you have flagged. > I'm not in love with allowing that, but we did > put it in for a reason - it cuts off lots of complaints from > people who either somehow think it's better to use IP > addresses or whose phones can't do anything else. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
