On Sat, Jun 7, 2008 at 8:36 PM, Martin Steinmann <[EMAIL PROTECTED]> wrote: > Ranga > > As far as I know there is no failover as such. In an HA system two > servers run an instance of sipXproxy and sipXregistrar each. Two is > what we typically test, but in theory it could be a larger number of > servers. These servers load balance on a per transaction basis using > DNS SRV name resolution. If a server fails, in progress transactions > will fail. As the phone's retransmit, the DNS SRV resolution will > point to another server that is still alive. That way no in progress > calls are lost and the user does not notice that a server failed. > > Only one instance of sipXconfig runs per system, but sipXconfig is not
> required for the PBX to perform. Also, currently only one instance of > media services run per system. Therefore, calls to AA, VM or other > media related services will fail and the respective service will be > unavailable if that server fails. > > The registrars involved in a redundant setup exchange state > information using XML RPC. > > I think there is a spec somewhere about how this all works. Some of it > is explained here: > http://sipx-wiki.calivia.com/index.php/High-Availability_Installation. > For an HA system to work we require a properly configured DNS server > with SRV records for all the components involved. > > http://sipxecs.sipfoundry.org/ViewVC/sipXecs/main/sipXregistry/doc/HaS > etup.pdf > > Given that the NAT traversal function now is part of the proxy, the > media relay should run alongside it. This would mean that media is > routed to the media relay using DNS SRV so that if one media relay is > no longer available, another one could take over. In-progress calls of > 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. > > Hope this makes sense > --martin > > > -----Original Message----- > From: M. Ranganathan [mailto:[EMAIL PROTECTED] > Sent: Sat 6/7/2008 6:28 PM > To: Martin Steinmann > Cc: Robert Joly; [email protected] > Subject: Re: [sipX-dev] Questions re: NAT traversal configuration > > On Sat, Jun 7, 2008 at 2:18 PM, Martin Steinmann > <[EMAIL PROTECTED]> wrote: >>> >>>> How would this work in an HA system? Can there be two media relays, >>>> one per call server, to support NAT traversal for a redundant >>>> system? >>>> --martin >>>> >>> >>> In principle, it can work as follows: the sipxbridge service does >>>not start on the backup until the failover occurs and the backup >>>takes control. We need some discussion on this mechanism ( for my benefit ). >>> >>>Ranga. >>> >> >> Yes, it would be great to discuss this some more. Since NAT traversal >> is a function of the proxy now it would be desirable if media relay >> services would run alongside the proxy (master and distributed >> server). It would be acceptable to loose the calls that are anchored >> in a specific instance of the media relay upon a server failure. >> However, redialing should immediately allow to re-establish the calls >> using a media relay on the redundant machine. >> --martin >> > > > Can somebody shed some light on how sipx handles failover? I should like : > > 1. A signal upon failover ( when the new replica starts ) OR 2. A > start of the sipxbridge process on the replica machine so I can > re-register. > > I think 1 is the preferred way to operate to save on startup time. > > I need some notification one way or another that a new primary server > is running so I can re-register and do whatever else needs to be done. > > As for the port range discussion, I am in favor of : > > 1. Hard coding the port range that sipxbridge manages and just making > that a read only part of the GUI for nat traversal. > 2. Hard coding the port assigned to the XML RPC server that runs as > part of sipxbridge. That way the remote client always knows where it > can find the service. > > This way everything that the media relay service needs is known > apriori. There is nothing to configure. > > Also, in case there is a strong argument for actually separating the > media relay and signaling functionality into two separate processes ( > sipx services ), I can do so ( will cost re-implementation of > something that already works) but I should like to understand the > motivation first. Apologies if my previous mail on this thread > (response to Damian) sounded strident. It was not meant to be so, but > perhaps was too strongly worded. I think we are firing up a lot of > processes and hence would like to examine the motivation for adding > one more. More processes is less efficient and is harder to manage. > > Thanks > > Ranga > > > > > > >> > > > > -- > M. Ranganathan > > -- 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
