Call fails instead of using backup trunk

[SteveITS]

Ran into a situation today where the primary SIP trunk at our provider was flipping down and up repeatedly every few seconds, for a half hour. A few calls attempted failed, with event:

Device 1630xxxxxxx dialed on (AnyLine@primary) had no available outgoing trunk(s) for Call(from "username"<sip:[email protected].3cx.us>;tag=c7c64d4b80e24417ae1f125c0faa40bf to 1630xxxxxxx)

Shouldn't 3CX have retried the call on the backup trunk?

I found https://www.3cx.com/community/threads/outbound-rules-calls-switch-to-backup-trunk.57879/ which indicates there is a 32 second delay before switching outbound calls to the backup trunk?

 

[leejor]

If the primary trunk is going up and down repeatedly "every few seconds", then 3CX routing calls "cleanly" to the second route may be impacted. This function is probably depending on the first route being down for an extended time, which could simply be... 5 minutes. Anything toggling, is going to cause problems, and unexpected behaviour.

 

[cobaltit]

3CX will try other trunks if configured to do so. First you'd want to confirm that the outbound rule that particular call used actually has a second trunk defined.

 

[YiannisH_3CX]

If there is no reply from the provider the PBX will currently attempt to reach the provider for 32 seconds before going to the second route.
If there is a error reply from the provider then the PBX will immediately try the second route.

 

[SteveITS]

Thanks for confirming. We did have the secondary/backup trunk set in the outbound routes. I think that much of the time it simply hadn't gotten past 32 seconds so it wasn't triggering the alternate. In our case the trunk was showing as not registered so there would have been no error reply.

 

[leejor]

If the primary route is showing as not registered (and not changing status every few seconds), then 3CX should know the route is not available and send the call to the second choice with no delay.

 

[SteveITS]

Hmm, maybe I'm not using the right terminology. Here is a section of our activity log, in reverse order of course:

08/05/2019 10:06:16 AM
SIP Server/Call Manager ID: 4100
Trunk L:10000(PrimaryTrunk) has changed status to registered.

08/05/2019 10:06:14 AM
SIP Server/Call Manager ID: 12293
Registration at PrimaryTrunk has failed. Destination (sip:@aa01.*.net:5060) is not reachable, DNS error resolving FQDN, or service is not available.

08/05/2019 10:05:41 AM
SIP Server/Call Manager ID: 12293
Registration at PrimaryTrunk has failed. Destination (sip:@aa01.*.net:5060) is not reachable, DNS error resolving FQDN, or service is not available.

08/05/2019 10:05:19 AM
SIP Server/Call Manager ID: 12289
Device 1630* dialed on (AnyLine@PrimaryTrunk) had no available outgoing trunk(s) for Call(from "John *"<sip:112@3cxhostname>;tag=c7c64d4b80e24417ae1f125c0faa40bf to 1630*)

08/05/2019 10:05:08 AM
SIP Server/Call Manager ID: 12293
Registration at PrimaryTrunk has failed. Destination (sip:@aa01.*.net:5060) is not reachable, DNS error resolving FQDN, or service is not available.

08/05/2019 10:04:41 AM
SIP Server/Call Manager ID: 12289
Device 163 dialed on (AnyLine@PrimaryTrunk) had no available outgoing trunk(s) for Call(from "John *"<sip:112@3cxhostname>;tag=27df364b4bf14671bc1a5cfbe36c55c7 to 163)

08/05/2019 10:04:35 AM
SIP Server/Call Manager ID: 12293
Registration at PrimaryTrunk has failed. Destination (sip:@aa01.*.net:5060) is not reachable, DNS error resolving FQDN, or service is not available.

08/05/2019 10:04:01 AM
SIP Server/Call Manager ID: 12293
Registration at PrimaryTrunk has failed. Destination (sip:@aa01.*.net:5060) is not reachable, DNS error resolving FQDN, or service is not available.

08/05/2019 10:03:57 AM
SIP Server/Call Manager ID: 12289
Device 1630* dialed on (AnyLine@PrimaryTrunk) had no available outgoing trunk(s) for Call(from "John *"<sip:112@3cxhostname>;tag=cdc640562bbe4940be6fd096afeff98b to 1630*)

08/05/2019 10:03:28 AM
SIP Server/Call Manager ID: 12293
Registration at PrimaryTrunk has failed. Destination (sip:@aa01.*.net:5060) is not reachable, DNS error resolving FQDN, or service is not available.

 

[cobaltit]

So again, I'd check your outbound routes. I only see an attempt out of one trunk (the flapping one) and if the trunk was unregistered, then it should immediately try the second trunk. I don't see any such attempt.

 

[SteveITS]

check your outbound routes

We have one outbound rule, with route 1 as the primary trunk and route 2 as the backup. Is there any other setup needed?

 

[YiannisH_3CX]

Is the second trunk used in route 2 a different provider with a different registrar or do you have a second trunk from the same provider?

 

[SteveITS]

It's the same provider, their backup/secondary trunk.

Is there any sort of delay after a trunk is registered before calls will happen? My log snippet starting at 08/05/2019 10:03:28 AM was the start of that outage (one of several) for the primary trunk. The secondary trunk did have a short outage just before that but logged "registered" at 08/05/2019 10:03:23 AM, 5 seconds before the above log entries. Most of the hour or so of intermittent problems (provider confirmed was their issue) the secondary trunk was up.

I would have expected 3CX to log that it tried the outbound call on the primary trunk/route, failed, and immediately tried again on the secondary.

 

[cobaltit]

I recall the logs showing that, but I'd have to recreate that configuration to test.

 

[YiannisH_3CX]

The PBX should try the second route without delay if the first trunk is not registered. The question is what was the providers failure at that point and if the second trunk was indeed up.