> On Mon, Jun 15, 2009 at 4:12 PM, Scott > Lawrence<[email protected]> wrote: > > On Mon, 2009-06-15 at 15:52 -0400, M. Ranganathan wrote: > >> > >> Another question I have in my mind is : > >> > >> If you have two systems behind NATs each with a domain name > >> sixp.example.local ( perfectly legal ) and you want to > federate them > >> in the manner you are describing but without a B2BUA, will > one system > >> not ge confused by the From header of the other? > > > > That one answers itself - the '.local' domain is _local_. > It's never > > going to work to expect that to work _anywhere_ with _anything_ > > outside it's scope. > > > The question should be rephrased. > > > If I send a request from one proxy to another both of them > behind NATs and both and they BOTH have the same sipx proxy > domain name AND there is no request re-writing then does the > second domain proxy server get confused by the From header > that it sees from the first proxy server? > If not, how do we deal with this. > > Does the federation scheme that we currently have work under > such circumstances?
Our current site-to-site scheme does not work if the servers at both sites claim to be authoritative for the same SIP domain. If we were to ever get a support request for such a configuration, I think we would politely ask the person to change the SIP domain at one of the sites. > > Note: It is possible (likely) that the answer is yes but I'd > like to understand how this is handled ( pointer to the > document or thread would be appreciated if the document talks > about it). > > > If not then I assume we are mandating that the domains of > each of the sipx proxy servers being federated is distinct > from the other even though they are private. Domain names must be distinct and DNS-resolvable. > > > Note : This is not a major limitation -- I am just trying to > understand things a bit better. > > > Thanks > > > Regards, > > Ranga > > > > > > > -- > M. Ranganathan > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
