Star InactiveStar InactiveStar InactiveStar InactiveStar Inactive

Since two days ago, I have been working with a new customer. He has reported in the FusionPBX Forums that dial code *72 (call forward) is not working. As per his explanation, dialing *72 forwards you to a little IVR that reports the forward was successfully set. But when you call to the extension with the call forward enabled, it was not forwarding, instead, the voice mail answers.

Some Explanation

At first sight I though he probably did not understand how the *72, *73 and *74 dial codes work. But after reading the call_forward.lua script I was able to reproduce the issue. My first thought was a Memcached issue. FusionPBX uses Memcached to store the directory information; the call forward information is stored within the directory.

But I was wrong, after putting some debug flags and having flushed the cache manually the bug was still there. Later I realized of the following lines in the console:

2017-04-19 17:33:21.001297 [ERR] switch_regex.c:83 Regular Expression Error expression[/^(933] missing ending '/' delimeter
2017-04-19 17:33:21.001297 [ERR] switch_regex.c:83 Regular Expression Error expression[/^(933] missing ending '/' delimeter
2017-04-19 17:33:21.001297 [ERR] switch_regex.c:83 Regular Expression Error expression[/^(933] missing ending '/' delimeter
2017-04-19 17:33:21.001297 [ERR] switch_regex.c:83 Regular Expression Error expression[/^(933] missing ending '/' delimeter
2017-04-19 17:33:21.001297 [ERR] switch_regex.c:83 Regular Expression Error expression[/^(933] missing ending '/' delimeter
2017-04-19 17:33:21.001297 [ERR] switch_regex.c:83 Regular Expression Error expression[/^(933] missing ending '/' delimeter
2017-04-19 17:33:21.001297 [DEBUG] switch_cpp.cpp:1365 [route_to_bridge] PASS condition destination_number(^(933|911)$) to `2136232424`

In short, this log tells that a regular expression could not be processed because of a syntax error. After reading the call_forward.lua script, I found that the error was not really there, but in the resources/functions/route_to_bridge.lua file. At this moment my LUA coding can not fix the error, however, there are two workarounds.

Please note that this bug it is really hidden. You must have a dial plan with a regular expression like $(911|933)^ to make it fail. Regular expressions built automatically by FusionPBX will not fail.

Workarounds

The first workaround is to move the 911 dial plan to the very end of the outbound routes. FusionPBX by default sets the value of 100 to the order. You will need to change that value, maybe 105, a value that will make sure it will be the last dial plan to be evaluated.

The second workaround is by turning on a default setting domain-bridge-text to the value of "loopback" or anything different than "bridge" or "outbound". This will force the loopback. You must understand that using the loopback may have a little side effect. Your CDR will report two calls, one from the caller to your extension and other from your extension to the forwarded number. More than that, it will work very well.

Good luck!

blog comments powered by Disqus

About

Read about IT, Migration, Business, Money, Marketing and other subjects.

Some subjects: FusionPBX, FreeSWITCH, Linux, Security, Canada, Cryptocurrency, Trading.