On Mon, Jun 15, 2009 at 3:07 PM, Scott Lawrence<[email protected]> wrote: > On Mon, 2009-06-15 at 14:54 -0400, M. Ranganathan wrote: >> Hello all! >> >> There was a thread some time ago about relay free sipxbridge operation >> and recently there has been a thread on sipx federation. I wonder what >> you feel about the following. >> >> Say you wanted to tie system A and System B together. System A is the >> "server" in this case and is providing NAT compensation to its remote >> workers. System B can be configured using sipxbridge to look like a >> remote worker to system A. >> >> Clearly we don't need two media relays between the systems. If we can >> support an option to suppress relaying of media, then system B looks >> like a remote worker to system A. >> >> When a request originates from System B bound for system A via >> sipxbridge, its contact and Via would get re-written but sipxbridge >> would leave the SDP alone. >> sipxbridge on system B can forward REFER after appropriate re-writing >> of the request as it is aware that is talking to another sipx system >> that is capable of handling that REFER. >> >> It seems to me that this should be relatively easy to support in >> sipxbridge. Will this scheme work in principle, as a possible solution >> for federating systems? If not, what is wrong with this? > > Sorry - I don't understand either what configuration you're describing > or what problem you're trying to solve. > > > I should have been a bit clearer in stating my goials.
First, systems A and B are both behind NATs System A and System B are each managed by their own sipXconfig ( this is not a multi branch system but rather a federated system ). With dial plans and using sipxbridge as the bridging component between these systems where one sipx instance acts like an "ITSP" to another one we can route requests between the two systems. In a nutshell that is the idea I am experimenting with (only in my imagination at present -- no code yet). -- 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/
