TryLearn More

Use SIP trunks, WebRTC & Apps

Slash your Phone Bill by 80%

Failover

On this topic:

Failover

Registration-based

Failover Mechanism

Failover Time

Failover when UDP SRV is used

Failover when TCP SRV is used

IP-based

Failover Mechanism

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

Re-query the UDP SRV record

Re-query _sip._udp.sip.contoso.com

3

Try to register against highest priority (lowest value) UDP SRV entry

Register against “sip3.contoso.com”

4

Resend REGISTER message for 32 seconds

Resend REGISTER message for 32 seconds

5

Try to register against next priority UDP SRV entry

Register against “sip4.contoso.com”

6

Repeat steps 4 and 5 for a maximum of 3 SRV entries

Failover when TCP SRV is used

Using the example entries at the beginning of this section, 3CX starts registering against “sip1.contoso.com”.

 The is TCP connection between 3CX and the SIP Trunk Provider SIP Server is likely reset, if it goes offline between registration attempts, causing 3CX to immediatelyfailover 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

Re-query the TCP SRV record

Re-query _sip._tcp.sip.contoso.com

3

Try to register against next priority TCP SRV entry

Attempt to register against “sip2.contoso.com”

4

Repeat steps 2 and 3 for  a maximum of 3 SRV entries

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

Free for up to 1 year! Select preferred deployment:

On-Premise

for Linux on a $200 appliance or as a VM

Get the ISO

On-Premise

for Windows as a VM

Download the setup file

On the cloud

In your Google, Amazon, Azure account

Take the PBX Express