Monitor Trunk Failures, any scripts?

So i see this cool new, monitor trunk failures option under Trunks. This is great, my only question is that if the Trunk fails i would like it to use a different Trunk right away. How can this be done? I am not sure if just setting “Primary” and “Secondary” trunks under outbound routes does the trick.

Something tells me if the trunk fails this feature is what i need. If it is, does anyone know an AGI script which will allow me to automatically place the call under a different Trunk? The idea is create ultimate redundancy and not have a failed call (unless of course they dial the wrong number)

if the trunk fails for reasons such as CHANUAVAIL or CONGESTION, then the nest trunk is always tried. This assumes trunk providers are sending back the correct signaling though, as not all do. If the call fails because of BUSY it will not try the next trunk. The script is simply run if a failure mode is detected and upon returning it continues as always. A failure is considered anything that is not BUSY, NOANSWER, or CANCEL.

Philippe Lindheimer - FreePBX Project Lead
http// - IRC #freepbx

This would work for sip/iax trunks but not zap since these channels are considered answered once handed over to the modem card (ex tdm400).

first off - not all zap trunks act as POTS lines do. If it is a PRI it is not answered until signaled answered. However - it will work fine with a zap trunk that is not configured properly, as it should return with a CHANUNAVAIL. But one of the purposes for such a monitor is to monitor failing VoIP trunks such as SIP/IAX since they are the ones that tend to give more problems.

Philippe Lindheimer - FreePBX Project Lead
http// - IRC #freepbx

could you give some examples of when this would kick into effect? i understand not BUSY, NoANSWER, CANCEL,Chanunavail or congestion, so is failure just “FAIL”? also any scripts you know or would like to share, curious what kind of failover measure scripts people have come up with for “FAIL” (assuming thats the command which would trigger it)

Can AGI script for trunk failures be written in PHP as long as hash bang is correct?

Do AGI scripts all have to have the AGI extension? Or could it have a PHP extension?

How do I test my Monitor Trunk Failures script while my trunk is still up?

Does Monitor Trunk Failures require a cron for it to be activated?

Any pointers would be appreciated.


We have just enabled “Monitor Trunk Failures” option in FreePBX.
We have obtained a script from online, and modified for our needs.

Everything seems to be working perfectly, except for knowing the actual trunk with the failure.

It would appear (as we can not find it in any AGI docs online), there is no way to retrieve the outbound trunk via AGI. We have the inbound trunk,but not the outbound… this we know there is an issue with a trunk, but are not notified as to which trunk.

agi_channel provides the inbound channel name

We tried agi_trunk (which one would suspect as the logical variable name), but that is not it.

Does anyone know the AGI variable to retrieve the outbound trunk name?

Can anyone assist with this question/issue?

The FreePBX Macro that actually executes your AGI script also sets a few channel variables that you should be able to access and use in this case. I haven’t tested to be 100% sure, but the Macro name is macro-dialout-trunk, and it sets a number of variables:
DIAL_TRUNK=${ARG1} – this will be something like OUT_2, OUT_3, etc
DIAL_NUMBER=${ARG2} – the actual outbound number to dial, if you care…

and others.

There are global variables that store the actual channel name mappings (I.e. OUT_3 = MyTrunkName), but I’m not sure if you can access that through AGI… quick google says maybe yes, maybe no depending on your version. If this is a one off/customization you could probably hard-code that into your AGI if you really needed it though.

To access those variables, try using get_variable, as described here:

i.e. $AGI->get_variable(“DIAL_TRUNK”);

Again I have not tested, but should point you in the right direction at least…

Thank you… this is very helpful.
I will try and report back.