> > > 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. > > I am starting to see some advantages in separating the > function but I have one question - how can the single > signaling server ( i.e. > sipxbridge that talks to ITSP registrars ) know about the > various instances of media relay ( i.e. which ones are alive, > which ones it can use etc. ) ? > > I assume there is some configuration parameter that can tell > me at least where all the HA instances are running. I can do > mutual pinging to figure out liveness after system restart. > How can I find this information?
The media relay redundancy model that I'm advocating is one where a media relay runs on each system that is part of an HA deployment. The service that requires the need of a media relay always goes to the local one. That is a very simple model but it covers most failure cases except the one where the media relay process crashes on one system but the SipXproxy and sipXbridge remain up. Given that the media relay process will be restarted anyway, IMHO that is not such a big deal. > > There can be only one instance of signaling (that talks to > external registrars). So we need a failover mechanism for > that. How shall we do this ? > > Minor: I assume sipXrelay would be a decent name to give such > a service. > > Ranga > > > > > -- > > 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/ > > > > > > > > -- > 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
