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/HaSetup.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. 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
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev
