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:

  1. 3CX will attempt to register to 2.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.
  3. 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

https://www.3cx.com/docs/sip-trunk-failover/