Failover
Introduction
The section explains how 3CX handles failover between SIP Trunk Providers’ servers. It is split into 2 major categories representing the 2 provider types, Registration-based and IP-based.
Registration-based
Failover for Registration-based SIP Trunk providers in 3CX can only occur if the Registrar and/or Outbound Proxy is an FQDN and the FQDN has either NAPTR and/or SRV records. See the DNS Resolution section for more info.
For this section consider “sip.contoso.com” as an example with the following SRV records:
- _sip._tcp.sip.contoso.com:
SRV Record | Weight | Priority | Port | A Record |
_sip._tcp.sip.contoso.com | 10 | 10 | 5060 | sip1.contoso.com |
_sip._tcp.sip.contoso.com | 20 | 20 | 5060 | sip2.contoso.com |
- _sip._udp.sip.contoso.com:
SRV Record | Weight | Priority | Port | A Record |
_sip._udp.sip.contoso.com | 10 | 10 | 5060 | sip3.contoso.com |
_sip._udp.sip.contoso.com | 20 | 20 | 5060 | sip4.contoso.com |
Failover Mechanism
When creating a new SIP Trunk in 3CX using an FQDN as Registrar in the SIP Trunk settings and the FQDN has SIP SRV records, 3CX orders these by weight and priority.
Using the above example values, a SIP Trunk registering against Registrar “sip.contoso.com”, it registers to the IP that “sip1.contoso.com” resolves to.
If “sip1.contoso.com” stops responding, 3CX then re-assesses the SRV records, selects the next responding entry by priority and registers against the IP “sip2.contoso.com” resolves to. 3CX then stays registered against “sip2.contoso.com” until it fails and then repeats the same process , selecting the responding entry with the lowest weight/priority and connects to that (“sip1.contoso.com”).
Failover Time
The 3CX failover to the next SRV entry duration depends on whether it has a TCP SRV or a UDP SRV, explained separately below.
Failover when UDP SRV is used
Using the example entries at the beginning of this section, 3CX starts registering against “sip3.contoso.com”.
Between registration attempts, 3CX is unaware of the status of the SIP Server it is connected to, as there is no constant connection with the SIP Trunk Provider’s SIP Server when using UDP transport.
3CX can determine if the SIP Server of the SIP Trunk Provider has gone offline whenever a re-registration attempt occurs, i.e. longer re-registration time results in longer duration for failover to the next SRV entry.
Attempting to re-register against “sip3.contoso.com”, while 3CX is not receiving any SIP responses, results to the following sequence:
General Description | Example | |
1 | Resend REGISTER message for 32 seconds | Resend REGISTER message for 32 seconds |
2 | Try to register against next priority UDP SRV entry | Register against “sip4.contoso.com” for 32 seconds |
3 | Repeat above steps for all remaining SRV entries | |
4 | When all SRV entries have failed to register, waits for half the Re-Register timeout defined |
Failover when TCP/TLS SRV is used
Using the example entries at the beginning of this section, 3CX starts registering against “sip1.contoso.com”.
The TCP connection between 3CX and the SIP Trunk Provider SIP Server is likely reset, if it goes offline between registration attempts, causing 3CX to immediately failover to the next SRV entry.
In this case what will happen is:
General Description | Example | |
1 | TCP connection drops | TCP connection to “sip1.contoso.com” drops |
2 | Try to register against next priority TCP SRV entry | Attempt to register against “sip2.contoso.com” |
3 | Repeat above steps for all remaining SRV entries | |
4 | When all SRV entries have failed to register, waits for half the Re-Register timeout defined |
IP-based
For an IP-based SIP Trunk to failover, it must have an FQDN as Registrar and/or Outbound Proxy configured in the 3CX SIP Trunk settings, and the FQDN must have either an NAPTR and/or SRV records.
Failover Mechanism
IP-based SIP Trunk in 3CX always appears as “Registered”, meaning that 3CX always attempts to send an INVITE for an outgoing call. If 3CX has not resolved the FQDN before, it does this during the outgoing call process. If an SRV is found (or a NAPTR that points to an SRV), 3CX orders the SRV entries by weight/priority and sends the INVITE to the top priority entry.
If a call attempt fails, on the next outbound call, 3CX re-queries the FQDN and routes the INVITE to the next in order SRV entry.This means that for IP-based providers, at least 1 outbound call fails for failover to occur.
Using the "Alternative Proxy"
In the SIP Trunk settings, in the “Options” tab, there is the option “Alternative Proxy” which can be enabled. This field accepts either an IP or FQDN that complements the settings already configured in the“General” tab.
The “Alternative Proxy” value will be resolved as per the DNS Resolution document with one difference, all the IPs that are resolved by the Alternative Proxy will be used only if all IPs that have been resolved by the Primary Registrar/Outbound Proxy fail.
When the IPs that the Alternative Proxy are being used, note that the SIP message that initially failed to be sent to the Primary Registrar or Outbound Proxy IP will be identical, the only thing that will change is the target IP.
This means that the Server must be in a position to receive this SIP message.
"Alternative Proxy" Example
You have configured:
- Registrar: sip1.contoso.com (resolves to 2.2.2.2)
- Alternative Proxy: sip2.contoso.com (resolves to 3.3.3.3)
What will happen:
- 3CX will attempt to register to 2.2.2.2
- The registration will remain with 2.2.2.2 until a SIP error occurs which will be handled as explained throughout this document.
- Because the Registrar does not have any other target IPs, only 2.2.2.2, 3CX will attempt to resolve and send the SIP message to 3.3.3.3.
Last Updated
This document was last updated on 25 July 2024