M. Ranganathan wrote: > On Mon, Jun 9, 2008 at 11:01 AM, Martin Steinmann <[EMAIL PROTECTED]> > wrote: >> <snip> >>>> course would fail, but calls could be redialed immediately using >>> another relay. >>> >>> There isn't a practical way of utilizing SNS SRV to 'find' the media >>> relay that is alive short of inventing our own polling mechanism that >>> would periodically hit a specific media relay port on all the hosts >>> returned by an SRV lookup of our SIP domain to maintain a list of >>> functioning media relays but even that would not buy you much because >> it >>> does not tell you anything about the network connectivity between the >>> real relay media endpoint and the media relay - that is a non-starter. >>> The way I had envisioned the media relay redundancy working would be to >>> have one media relay running locally on each system of an HA >> deployment. >>> The proxy on a given system would always utilize the services of the >>> local media relay whenever relaying is required. This is a very simple >>> solution that covers most outage scenarios. The only one that it does >>> not cover is the 'media relay crash' one. More specifically, if the >>> media relay process on a system goes belly-up, the proxy on that system >>> will not be capable of turning to the media relay of another system to >>> complete a call that required relaying. Other cases such as network >>> outage, power loss, box reset are covered. >>> >> >> That would be acceptable from my perspective --martin >> >> > > Discussed this issue further with Scott and Martin and would like to share > gist of the discussion with the list : > > - Since sipxbridge bridge implements symmitron, what can be done for process > management is to start two processes that are independently configured. One > will be called symmitron and another will be called sipxbridge. Each will > have its own process descriptor and be managed independent of the other. Both > will use the same nat traversal library ( they will share code ) but they > will run as independent processes.
Can Robert and/or you open a sipXconfig issue on how to configure symmitron. Are we going to have any changes in sipXbridge configuration as well? > > - Sharing symmitron resources port ranges makes sense when we want to load > balance across a cluster. Otherwise it may complicate some things in the > implementation. We will re-visit this and share symmitron resources when we > deal with load balancing and HA for sipxbridge. At that time sipxbridge will > be separated from symmitron and will use the common xml rpc mechanism to talk > to a cluster of symmitrons. HA and load balancing for ITSP bridging will be > deferred until we have worked out a good design for this. > > - For the moment, nothing precludes starting an ITSP bridge for each machine > on a cluster but they cannot share the same account. To facilitate this, the > sipxbridge.xml file should not be replicated across the cluster. Yes - it should be assigned to the specific instance of sipXbridge. I'll check if this is the case. At the moment sipXconfig allows to configure only one instance of sipXbridge per cluster thought. But once we have a new way of configuring cluster implemented we can easily change it to one sipXbridge instace per server. > > > Scott and Martin, please add to this if I have missed anything. > > Thanks for the stimulating discussion. I would like to discuss sipxbridge > failover in another thread. > _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
