> On Wed, 2009-03-11 at 14:25 -0400, Joly, Robert (CAR:9D30) wrote: > > Kathy, > > I'm trying to troubleshoot a scenario where I have a remote > phone that > > is configured with the exact same private IP address as the sipXecs. > > Such scenarios can happen when two disjointed private IP networks > > happen to use overlapping private IP address ranges. > > > > There were a few things that I had to solve to get this to > work better > > and I now believe that I am at my last hurdle and this is > what brings > > me to you :) > > > > Roughly a year ago, you committed some changes to SipRouter.cpp as > > part of XECS-54 > > > (http://sipxecs.sipfoundry.org/ViewVC/sipXecs/main/sipXproxy/s > rc/SipRouter.cpp?r1=12076&r2=12092) which routed any > in-dialog request to our domain over to the redirect server > with the expectation that it will be capable of steering it > to the proper UA instance by resolving the GRUU AOR. The > problem here is that when a request is to be sent to the > remote phone that has the same private IP as the sipXecs, the > request-uri has a private IP address that matches our own and > your code routes the request over to the redirect server but > it fails to resolve that AOR to the UA instance because it is > not a GRUU AOR. > > > > It appears to me that the check done on line 326 (use link above) > > sends every in-dialog request with our own domain to the redirect > > server assuming that it will be able produce a contact to a UA > > instance. From my understanding of GRUU, this will only be true if > > the AOR is a GRUU to begin with. > > > > What would happen if we only routed requests back to our redirect > > server only if the domain matched ours AND the r-uri was GRUU (i.e. > > carries the ;gr parameter)? Ideally, this is how I would like to > > address the problem that I'm facing but I want to check with you > > first... > > > > from my notes at the time- > > - There is no GRUU knowledge outside of Redirector Plug-ins > > I haven't been paying attention to GRUU specs but this note > brings back a vague memory that there is no way the code at > this point can(or was it > 'should'?) know whether GRUU is involved.
The spec says that "...all GRUUs contain the "gr" URI parameter". I guess up to this point we had no reason to make the proxy aware of gruu but the overlapping private space scenario changes that. > > Another vague memory is that there was a reason we might want > to send _all_ in-dialog requests which are to the local > domain through the redirector, but that doesn't make sense to > me today. I'll keep thinking on that. > > One caveat is that when sipx generates GRUU addresses, we do > NOT add the > (now) conventional ";gr=" parameter. > Assuming that it is > valid to check for GRUU as you would like, our generating > code would have to change to add that parameter. When you say "generate", are you referring to the public and temproary gruus that the Registrar generates in response to a REGISTER request. If so then we need to change this regardless to comply with the spec. > > HTH. > -ke Thanks for the info. I think I npw have enough info to post a semi-intelligent message o nthe devlist. _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
