Failover SIP

[nicoonline]

Hello,

Is there any solutions when having two trunks (NO Registration) to send the calls to the second trunk when the first is failing.
Today there is a 32 seconds delay. That is not possible in a business environnement.

You said that you cannot detected the trunk down, that is not true. You can send SIP Option every 60 seconds and in case of no answers , you can set the trunk down.
You can also put a timer of 2000ms. If you didn't receive a trying, cancel the call and go to the next.

I followed also the recommandations on https://www.3cx.com/docs/sip-trunk-failover/#h.lpuilwd1bkbl
Using SRV records for the failover, there is also a delay of 20 seconds on ALL calls.

Any helps on this please ?

 

[YiannisH_3CX]

Currently the PBX will keep trying the same trunk for 32 seconds before switching to the second route. This is based on the RFC timers and there is no way to change it.
If the PBX receives an error code then it will immediately switch to the second route.

You can also switch to an authentication based provider so the PBX can detect when the registration fails.

 

[nicoonline]

Hello,
Thanks for your answer but what you are saying about RFC is not correct.
We worked with Cisco, Avaya and we have not this issue. You are not forced by RFC to wait 30 seconds before sending a CANCEL. You can detect an IP trunk is down with <options> packet.

So there are no solutions with IP trunks ?
do you know someone who will wait 40 seconds without any ringback?

 

[YiannisH_3CX]

The rfc is pretty clear on this: https://tools.ietf.org/html/rfc3261#section-17.1.1.2

Although you can technically detect an IP trunk is down with Options packets, most providers do not support this because of the overhead it creates. If we start blindly sending Option packets to providers that do not want this we will most probably be blacklisted.

Since you worked with Cisco before, the timer actually works in the same way. The only difference is that you can reduce the amount of retries of the PBX so the process happens faster.

This is something that we are considering changing in a future update as we understand that 32 seconds is too long for a user to wait. This is not something simple however as the timers in the SIP engine are complex and affect many parameters.

 

[nicoonline]

Okay but the difference here is we are using SIP SRV DNS so according to RFC, when a proxy is down, you have to send the traffic to the next available server. It's what Cisco does very well
64*T1 is 7 retries. Think 2 retries are enough to consider it down.

 

[nicoonline]

Also i checked the behavior and i replied with a "503" error on the invite.
The call is not sent "directly" to the second server.

 

[nicoonline]

Hello Yiannish,
Others vendors like Asterisk provide an option named "Qualify". This can be enabled or disabled on the trunk. That option i used to monitor the state of the trunk sending "OPTIONS" packets. I don't understand why you DON'T WANT to use this. this is used for that & i don't know any providers blocking this !

Can you please reply me with the solution you can provide now or in the future.
Using an AUTH trunk is not an option, 3CX cannot guarantee to follow the SIP SRV directive.

 

[YiannisH_3CX]

As i mentioned we are looking into ways to reduce the time it takes to failover to a second trunk without messing with the other timers. How this will done i cannot say as it is still being decided.