Trunk failover when first trunk is Disabled: should it continue to next trunk?

General Help
1

Hi all,

I’m looking for some clarity on how trunk failover is supposed to behave in FreePBX when the first trunk in an outbound route is marked Disabled.

Scenario

  • Outbound route “Mobile” has a trunk sequence like:

    • Trunk 14 (disabled)

    • Trunk 15 (enabled)

    • Trunk 16 (enabled)

    • etc.

  • Route dialplan (dialplan show outrt-9) is generated with multiple Gosub(macro-dialout-trunk...) calls, one per trunk, e.g.:

12. Gosub(macro-dialout-trunk,s,1(14,${EXTEN},,on))
13. Gosub(macro-dialout-trunk,s,1(15,${EXTEN},,on))
14. Gosub(macro-dialout-trunk,s,1(16,${EXTEN},,on))
...

What I expect

If trunk 14 is disabled, I’d expect FreePBX to skip it and continue to trunk 15, then 16, etc.

What I’m seeing

When trunk 14 is disabled, the call enters macro-dialout-trunk, hits the disabled-trunk branch, and the call ends immediately. It does not return to the outbound route dialplan to try trunk 15.

CLI trace when dialling out:

Gosub(macro-dialout-trunk,s,1(14,021666999,,on))
...
GotoIf(... "1?disabletrunk,1")
NoOp("...","TRUNK: PJSIP DISABLED - falling through to next trunk")
-- Auto fallthrough, channel ... status is 'UNKNOWN'
-- Executing [h@macro-dialout-trunk:1] Gosub(...macro-hangupcall...)

Questions

  1. Is it expected behaviour that if a trunk is administratively disabled, FreePBX will not continue to subsequent trunks in the route trunk sequence?

  2. What is the recommended way to handle maintenance/outage scenarios if you still want failover?

    • Remove disabled trunks from route sequences?

    • Leave trunks enabled and allow them to fail “normally” (CHANUNAVAIL/etc.)?

    • Is there a supported way to override/patch this behaviour?

I’m happy to provide version details if needed, but I’m mainly trying to understand what the intended behaviour is here and what the best practice is for failover.

Thanks in advance!

2

Assuming the code is official, this looks to me like it is probably a bug introduced when macros were eliminated from the code. There should be a Return() after the Noop, but the code is just running off the end. Maybe running off the end of a macro was treated as MacroExit, but doing so for a subroutine doesn’t imply a Return().

3

Thanks @david55, yes this is the official code. I’m 99% sure you are right, the end of a macro was indeed treated MacroExit.

4

Someone else has already logged this as a bug…. should of taken a look there first!

[bug]: Outbound call fails if outbound route has it’s first trunk in disabled state · Issue #876 · FreePBX/issue-tracker