Call hangup when dialing external number defined in followme

I just upgraded all 29 available modules in freepbx. But now my system is not dialing external number defined in Followme. It is also not dialing a number directly defined in the extension. This was working fine before module update.
Can some one please help?
My system Configuration:
Core 2.4.0.2
Feature Code Admin 2.4.0.2
FreePBX Framework 2.4.0.1
System Dashboard 2.4.0.2
Voicemail 2.4.0.1

Below is the asterisk log:
– Executing [[email protected]:4] Macro(“Local/[email protected],2”, “dialout-trunk|15|19299999999||”) in new stack
– Executing [[email protected]:1] Set(“Local/[email protected],2”, “DIAL_TRUNK=15”) in new stack
– Executing [[email protected]:2] ExecIf(“Local/[email protected],2”, “0|Authenticate|”) in new stack
– Executing [[email protected]:3] GotoIf(“Local/[email protected],2”, “0?disabletrunk|1”) in new stack
– Executing [[email protected]:4] Set(“Local/[email protected],2”, “DIAL_NUMBER=19299999999”) in new stack
– Executing [[email protected]:5] Set(“Local/[email protected],2”, “DIAL_TRUNK_OPTIONS=tr”) in new stack
– Executing [[email protected]:6] Set(“Local/[email protected],2”, “GROUP()=OUT_15”) in new stack
– Executing [[email protected]:7] GotoIf(“Local/[email protected],2”, “1?nomax”) in new stack
– Goto (macro-dialout-trunk,s,9)
– Executing [[email protected]:9] GotoIf(“Local/[email protected],2”, “0?skipoutcid”) in new stack
– Executing [[email protected]:10] Set(“Local/[email protected],2”, “DIAL_TRUNK_OPTIONS=”) in new stack
– Executing [[email protected]:11] Macro(“Local/[email protected],2”, “outbound-callerid|15”) in new stack
– Executing [[email protected]:1] ExecIf(“Local/[email protected],2”, “1|SetCallingPres|allowed_not_screened”) in new stack
== Spawn extension (macro-outbound-callerid, s, 1) exited non-zero on ‘Local/[email protected],2’ in macro ‘outbound-callerid’
== Spawn extension (macro-outbound-callerid, s, 1) exited non-zero on ‘Local/[email protected],2’ in macro ‘dialout-trunk’
== Spawn extension (macro-outbound-callerid, s, 1) exited non-zero on ‘Local/[email protected],2’
== Everyone is busy/congested at this time (1:0/0/1)
– Executing [[email protected]:8] Set(“SIP/1048638637-09817f98”, “DIALSTATUS=CHANUNAVAIL”) in new stack
– Executing [[email protected]:10] Set(“SIP/1048638637-09817f98”, “SV_DIALSTATUS=CHANUNAVAIL”) in new stack
– Executing [[email protected]:11] GosubIf(“SIP/1048638637-09817f98”, “0?docfu|1”) in new stack
– Executing [[email protected]:12] GosubIf(“SIP/1048638637-09817f98”, “0?docfb|1”) in new stack
– Executing [[email protected]:13] Set(“SIP/1048638637-09817f98”, “DIALSTATUS=CHANUNAVAIL”) in new stack
– Executing [[email protected]:14] NoOp(“SIP/1048638637-09817f98”, “Voicemail is novm”) in new stack
– Executing [[email protected]:15] GotoIf(“SIP/1048638637-09817f98”, “1?s-CHANUNAVAIL|1”) in new stack
– Goto (macro-exten-vm,s-CHANUNAVAIL,1)
– Executing [[email protected]:1] PlayTones(“SIP/1048638637-09817f98”, “congestion”) in new stack
– Executing [[email protected]:2] Congestion(“SIP/1048638637-09817f98”, “10”) in new stack
== Spawn extension (macro-exten-vm, s-CHANUNAVAIL, 2) exited non-zero on ‘SIP/1048638637-09817f98’ in macro ‘exten-vm’
== Spawn extension (macro-exten-vm, s-CHANUNAVAIL, 2) exited non-zero on ‘SIP/1048638637-09817f98’

Upgrade Core to version 2.4.0.3 fix the problem calling extenal number.

Upgrade core to 2.4.0.3 fixed the problem. I appreciate your help.

I just upgraded to core 2.4.0.3 to get this feature fixed. I get

Everyone is busy/congested at this time

BTW I am running elastix 1.1 upgraded the core manually. Calling out on the same sip channel works fine. Just

Local/[email protected] fails.

exact same issue as you mentioned. My Local/[email protected] was not working when I used extension to dial an external number in this fashion. However, after I upgraded to core 2.4.0.3 it starts working. Sorry, I don’t have a solution for you. Just my own experience.

A side question: How folks handle this type of situation in production environment? Meaning do they apply upgrades in some other non-production environment first? If so, how do they test all of the existing trunks, extensions, and other functions to make sure the upgrade does not break the system?

BlueSky,
people operate across the board, from applying updates in the middle of a busy day to running through tests. FreePBX has gained a respected reputation by many that module upgrades are almost always flawless and to be trusted at a very high level.

This particular bug was rather unfortunate that it slipped in as it has been the first such bug introduced in an update that effected the operation of the system that I can remember for a long time. With that said, the bug, #2851, was fixed and a new module published within 26 minutes of being reported. The effect of the bug was also not catastrophic since the worse case should have been a ‘destination if no answer’ picking up the call.

Anyhow - you will have to use your own judgment for such matters but you should rest confident that we will continue to operate in the mode that has gained the trust of most of the community. In general, if you wait a week or so after a new updated module has become available it has probably been tested by enough people that any issues would have been flushed out. (and you can always check the Trac Timeline to see if there are any recent issues reported related to new updates.

Thanks for your quick reply. Please don’t get me wrong. Freepbx is a great product and I have been using it successfully with out any issues. I always take updates as soon as it appears on my dashboard. This was the first time an update broke external call function.
I was more curious to know if folks do some specific testing after upgrades. Thanks for your advise to wait one week or so before applying the new upgrade.

This morning I logged in and saw core update 2.4.0.4 and bunch of other updates. I upgraded my system and now it works.

BTW

The number to call is 555-1212. I have setup prefix Zero to call outside line. Hence I added Zero to dial command such as

Local/[email protected]

to get this working. It may be obvious to all the experts but I have posted it here for newbies like me. (I stumbled on it and was not sure if this is the correct syntax till the bug was fixed, I did not see this in the documentation).