On Mon, Jun 15, 2009 at 3:55 PM, Dale Worley<[email protected]> wrote: > On Mon, 2009-06-15 at 15:52 -0400, M. Ranganathan wrote: >> 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? > > If you have two systems that can communicate with each other, they must > have different SIP domains. Otherwise URIs don't have unambiguous > meanings.
The point is moot because we are not going to do this but the scheme is as follows : Each system has its public (global) address as an aias. When system A wants to send a request to System B , sipXbridge at System A would re-write the request (i;e. its From header and Contact) and send it to system B using the public alias if system B. It would hence re-write the request URI to be the alias of system B and route the request to system B. The private domain ( sipx.example.local ) is never visible across systems. This way you avoid name clashes. Just as a matter of curiosity, could you tell me where this would break down? In my mind this would be a bit easier to administer than ensuring the local DNS domains ( which are supposed to be private and not visible outside the domain) don't clash. Does our current mechanism allow each system to have its own private domain which could be identical to that of another system? If so, then the scheme I proposed adds nothing. If not, perhaps it does add something but is not a good idea anyway for other reasons. I would like to know exactly why it breaks down. I do not wish to re-invent the wheel so this is not a suggestion that we re-do something that already works satisfactorily using existing mechanisms. I am in complete agreement that B2BUA are a bad thing because they break signaling and the end-to-end principle and am not trying to push something to where it should not be used.... Just want to understand if this is a better scheme than what we have. Regards, Ranga > > Dale > > > -- 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/
