On Sat, 2008-06-07 at 14:32 -0400, M. Ranganathan wrote: > > Actually that is not quite correct ( my error for bad explanation ) . > > Sipxbridge is dependent upon media relay but not vice versa. Does it > > really matter to you if they run as two independent processes? I dont > > mind if the configuration has to be read from two different files but > > when we had this discussion at the start of the project you wanted to > > combine them into a single file. On the other hand it makes life > > easier for me if sipxbridge and the media relay run as an independent > > process. > > Sorry... > > On the other hand it makes life easier for me and more efficient if > they do NOT run as independent processes. So long as sipxbridge + > relay export the right functionality what does it matter? Please feed > me as many xml files as you wish.
But isn't it true that the media relay is also used by the proxy for NAT traversal? Assume a 2 system HA configuration with no sipXbridge (using either some other SBC or gateways for PSTN connections), but _with_ the new proxy NAT traversal support. Is there any reason why each of the 2 proxies should not have its own co-resident media relay (presumably each media relay instance would have its own allocated port range at the NAT)? If you then have such a configuration, and you add a sipXbridge, it could (with no changes from what we have now) only share the media relay with one of the two proxies, but both proxies could route calls through it, correct? I would think that the above would argue for separating the media relay configuration and process management from that of sipXbridge. The 4.0 sipXsupervisor has a mechanism to configure process dependencies, so it can take care of not starting a proxy or a bridge that depends upon a media relay until after it is up if that is needed. -- Scott Lawrence tel:+1.781.229.0533;ext=162 or sip:[EMAIL PROTECTED] sipXecs project coordinator - SIPfoundry http://www.sipfoundry.org/sipXecs CTO, Voice Solutions - Bluesocket Inc. http://www.bluesocket.com/ http://www.pingtel.com/ _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
