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/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.

Thanks for the pointers.

Separating the relays from signaling would give you multiple media
relays. Sipxbridge would have to pick one to relay the call  -- a
simple Round Robin algorithm should do the trick.

You can have only a single active instance of the signaling component
of sipxbridge however, because it needs to REGISTER with the ITSP and
most ITSPs that I have seen so far allow only registration from a
single IP Address. The one exception is BT ( british telecom ) which
does allow multiple registrations.

The limitation above would imply that the right HA design for
sipxbridge would be to implement a failover based design - not one
that supports multiple concurrent active copies -- i.e. when the
active sipxbridge instance fails the standby re-registers with the
ITSP and takes over. The problem is that internally, calls have to be
re-routed to the new instance of sipxbridge. This means that the Route
present in fallbackrules.xml should use a DNS entry for sipxbridge and
that a DNS SRV record for it has to be created.

I was under the impression that we would defer HA considerations for
sipxbridge and NAT traversal for this iteration but clearly there is
no harm in discussing it.


Ranga



>
> 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

Reply via email to