Trunk Failover Questions

Status
Not open for further replies.

cobaltit

Platinum Partner
Advanced Certified
Joined
Mar 22, 2012
Messages
6,735
Reaction score
2,324
https://www.3cx.com/docs/sip-trunk-failover/

Per the above document, with an IP authenticated trunk you will have at least 1 outbound call fail before 3CX will re-query the SRV records and then try the next SRV record in order. I'm trying to avoid having any calls fail and I'm curious if listing the same trunk multiple times on the outbound rule as Route 2 (and possibly 3-5) will cause 3CX to behave the same way as far as re-querying and then trying the next SRV record but without the call failing. Or will 3CX look at it as a different trunk and potentially hit the same SRV record for each iteration?

For example if I have TRUNKFQDN with 4 SRV records (priority 10/20/30/40) and I list the same trunk 5 times in the outbound rule will 3CX try 5 times to complete the call in SVR priority (so 10, then 20, then 30, then 40, then back to 10) before giving up, or will it consider it a new trunk each lookup even though it's the same trunk and just try to send the call to the priority 10 record 5 times? Or if I have 4 SRV entries will it not try a 5th time since all 4 failed? If so, would I be better off putting the same FQDN in the alternative proxy field to force it to try the first entry again? Or would it need to be a completely different FQDN?

Just trying to see how I can reduce my call failures when there's a temporary issue since we should never have a situation where all of our servers are down. Hoping for an official 3CX answer before I spend an evening with beer and wireshark to test/confirm. Also curious if the failure reason changes the behavior at all.

Thanks
 
  • Like
Reactions: Evolute IT
Hmm, that's a good question. I'm actually curious to find a way to test that since I use Telnyx with DNS SRV.
 
Regarding IP based trunks a failed call means one of two things. Either the call timed out or an error code was received. For a call to time out 32 seconds must elapse of the PBX trying to reach the provider so keep that in mind,

So we have 1 registrar with 2 SRV records for our example. If you have more the same apply
Assuming that the trunk is added only once to the outbound rule.

If a call is made and the call is allowed to time out then the next call will be routed to the next SRV. So 1 call will fail in this scenario.
If the call receives an error code the next call will be routed to the SRV. Not all error codes cause the trunk to failover though so the PBX may keep trying the first route again. So at least1 call will fail in this scenario.

Assuming that the trunk is added twice to the outbound rule.

If a call is made and the call is allowed to time out then the call will be routed to the next SRV without needing to redial the number.
If the call receives an error code the call will be routed to the SRV without needing to redial the number. Not all error codes cause the trunk to failover though so the PBX may keep trying the first route again.

Note: The PBX will query the DNS again only when all possible targets are exhausted.
Note 2: The error codes that can trigger the failover are 408 Request Timeout and 503 ServiceUnavailable.

Hmm, that's a good question. I'm actually curious to find a way to test that since I use Telnyx with DNS SRV.
Registration based providers work in a different way so the above don't apply fully.
 
  • Like
Reactions: Evolute IT
Thank you for the explanation @YiannisH_3CX . It sounds like adding the same trunk multiple times might work although we were encountering 403 Not Allowed from one of the 4 SRV records intermittently. How would 3CX handle that?

And based on your explanation, it sounds like adding the trunk 5 times to the outbound rule would work like so if the code is one that triggers failover then it would look something like this:

- DNS lookup returns 4 SRV records
- 3CX attempts each SRV once for routes 1-4
- 3CX does a fresh DNS lookup and then will try 1 of the SRVs for the 5th route

And if the error code is one that doesn't trigger failover then it should look something like this:

- DNS lookup returns 4 SRV records
- 3CX attempts makes 5 attempts, possibly to the same SRV record

Is my understanding correct?
 
And then I guess if 403 doesn't trigger a failover, any chance there's an advanced parameter where we can add that? :)
 
Also, we noticed that if the trunk is simply not responding, the timeout is 30sec before it fails over. Is there a way to adjust that? The trunk doesn't return any response if it's completely down.
 
It sounds like adding the same trunk multiple times might work although we were encountering 403 Not Allowed from one of the 4 SRV records intermittently. How would 3CX handle that?
It will keep trying the same SRV record as the error will not trigger a failover.

And based on your explanation, it sounds like adding the trunk 5 times to the outbound rule would work like so if the code is one that triggers failover then it would look something like this:

- DNS lookup returns 4 SRV records
- 3CX attempts each SRV once for routes 1-4
- 3CX does a fresh DNS lookup and then will try 1 of the SRVs for the 5th route
Correct


- DNS lookup returns 4 SRV records
- 3CX attempts makes 5 attempts, possibly to the same SRV record

Is my understanding correct?
Your understanding is correct.
 
Also, we noticed that if the trunk is simply not responding, the timeout is 30sec before it fails over. Is there a way to adjust that? The trunk doesn't return any response if it's completely down.
The timeout is 32 seconds as per RFC timers. For a trunk to be considered not responding 32 seconds must elapse. There is no way to alter the timer.
 
  • Like
Reactions: Evolute IT
Status
Not open for further replies.

Forum statistics

Threads
111,995
Messages
590,194
Members
164,934
Latest member
bunthoeun.may