On Mon, Jun 15, 2009 at 3:31 PM, Robert Joly<[email protected]> 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? > > I'm a bit confused by the description and I'm not sure why you would > want to use sipXbridge to connect two sipXecs systems in the first > place? We recommend to do this with site-to-site dialplans and the > existing remote-worker solution has mechanisms in place to avoid doing > the double-relaying. What real-world problem are we trying solve?
It is quite possible that a mechanism already exists and that I just do not understand it so please help me understand : When a remote worker phone registered at site A wants to do a call to a phone registered as a remote worker on Site B, could you please tell me how it would proceed ( what would be the call flow and how do you avoid relaying media twice?). Thanks in advance. 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/
