Howto:SIP redundancy / failover

Overview

We often encounter scenarios in which the reliability of the SIP connection is to be ensured. There are several approaches and scenarios how to achieve this SIP redundancy or failover.

How well SIP redundancy and/or failover works, depends on the interaction between the PBX and the carrier providing the SIP account.

PBX / Gateway

To support various carriers, innovaphone has already implemented the following configurable features:

• Accepting trunk registrations from multiples Sources (GWs)
• Always place the call on a primary trunk and in case of an error, on a secondary trunk or round robin
• Receive calls from multiple trunk registrations
• Route calls between GWs back and forth
• Rerouting of failed calls

Carrier scenarios

Of course your possibilities here depend on the carrier's feature-set

If you don't know if your provider(s) do support redundancy, you can check our test reports of the Certified SIP Providers in our wiki or ask your provider.

Two permanent active SIP Interfaces

The best practice would be if the Carrier accepts two registrations from different sources with the same credentials

• SIP Interfaces on two Gateways with identical configuration
  • Both Interfaces register to the Trunk Object in the PBX
• The routing configuration on the Gateway should be identical
• The call distribution is not critical, but needs to be considered in the configuration
  • Some carriers send all incoming calls on the primary trunk only and expect all outgoing calls over the same primary trunk
    • Outgoing Calls must be first sent to the primary Interface, then to the secondary one
  • Some carriers use both trunks for incoming and outgoing calls

Active SIP Interface, secondary disabled SIP Interface

If the Carrier doesn't accept two registrations from different sources with the same credentials then you can prepare the failover scenario, but you have to switch here manually.

• SIP Interfaces on two Gateways with identical configuration
  • The primary Interface should be enabled
  • The secondary Interface should be disabled
  • Both Interfaces register to the Trunk Object in the PBX
• Routing on the Gateway should be identical
• The call distribution is straight-forward because there is only one single active Interface at the same time
• If the primary trunk fails, it must be disabled manually or with a custom script/curl command and the secondary one activated

Automatically registration switch with local DNS SRV Records

Requirements

• V7 Gatekeeper License (Article Number: 01-00500-007)

Idea

If the Carrier doesn't accept redundant registrations for the same SIP Account then you can set up the following failover scenario with local SRV Records.

The idea is that the Master PBX registers with well-known default configurations the SIP Trunk to the Carrier. To automate the failover and force activation of the SIP Trunk located on the Standby PBX we need some configuration and local SRV Records. The Master PBX uses e.g. SIP1 for the SIP registration to the carrier. The Master PBX should accept incoming SIP Register-Messages for the target SIP-Realm of the Carrier. (We will simulate for incoming SIP Register-Messages, that we are the Carrier) On the Standby PBX we will use local SRV Records to create priority on different SIP targets. The highest priority will have the simulated carrier on the Master PBX.

So in normal operation mode the Standby boots up, checks via DNS all available gatekeepers and will send the SIP Register-Message to the Master PBX, because it is the gatekeeper with the highest priority. The Master PBX will accept the request. (On this connection nothing happens. The Master PBX will never send a call to the Standby PBX. The Standby PBX cannot send a call because it is a Standby and not active until the Master PBX fails.) If the Master PBX fails, the Standby PBX recognize it and automatically register the SIP Trunk to the next gatekeeper (from the DNS-SRV list) which is the real carrier. All other features are covered from the Standby mechanism.

If the Master PBX comes back after a downtime, the Standby will recognize it and stop to act as Master and unregister the SIP Trunk to the real carrier. The Standby PBX reconnects to the gatekeeper with the highest priority. (Which is the Master PBX)

Setup

1. Setup the well-known Master/Standby PBX configuration
2. Change the Gatekeeper ID in the Master PBX according to the SIP-Realm of your carrier
3. Create a GK Interface in the Master PBX
   • Name: SIP-Realm of your carrier
   • Protocol: The Protocol of your carrier
   • Mode: Gatekeeper/Registrar
   • Proxy: IP of your Standby PBX
   • Mask: 255.255.255.255
   • Authorization: Credentials from your Carrier SIP Account
   • Alias List -> Name: Username from your Carrier SIP Account
4. Enable local DNS Sever on Standby PBX
   • Setup needed DNS Records
   • SRV: _sip._udp.carrier.tld master.customer.tld 5060 0 0
   • SRV: _sip._udp.carrier.tld carrier.tld 5060 1 0
   • A: master.customer.tld 172.16.80.231 (optionally if you don't have an existing record)
   • node: the red marked numbers are the priority in the SRV record. (Lower value, higher priority)
5. Configure SIP1 on the Standby according the Master PBX. (You have also to set up manually the same Interface Maps, Routing etc.)
   • You can customize the Proposed Registration Interval [s] to a lower value than the default of 120 seconds for a faster SIP Switch.
   • You MUST NOT use the Advanced Parameter /reg-redirect-support in the SIP Interop Tweaks.

If needed you can tweak the failover timeouts for faster function switches.

Additional information

• There are some ideas to achieve this with the help of some lines of codes and your monitoring appliance which would trigger and be able to disable/enable these Interfaces via HTTP(S) commands.
• There are some ideas to achieve this with the help of V13 App Platform and the SDK by developing your own App to automate this process suiting your needs
• Currently (i.e. 13r1sr4) there's no automatic mechanism for SIP interfaces to enable a secondary SIP interface if the primary one fails. There is a feature request where you can vote for it.

Related Articles

• Howto:DNS Resolving in SIP