Broken call routing under 710b4- known issue- has anyone fixed it ?

[bulek]

Hi,

I'm slowly setting my telephony features in new home... I had a working setup under 704, but it seems that freepbx automatic setup of call routing is broken under 710b4. It's reported as a known issue.

when I compared working 704 with non-working 710 it seems that whole file extensions_pluto_dial.conf is missing (and all call routing and customization go into this file).

Has anyone fixed this problem ? I've tried to add emplty file but it didn't get updated on config change, so problem is a bit more demanding..

Can anyone confirm that file is missing ?

Thanks in advance,

regards,

Bulek.

[Zaerc]

Looks like that file should have been created by /usr/pluto/bin/create_pluto_dialplan.pl.

When run from the commandline under beta4, this produces the following output:

Code: [Select]

# ./create_pluto_dialplan.pl
Global symbol "$count" requires explicit package name at ./create_pluto_dialplan.pl line 182.
Global symbol "$count" requires explicit package name at ./create_pluto_dialplan.pl line 184.
Execution of ./create_pluto_dialplan.pl aborted due to compilation errors.

Which I just fixed like this:

Code: [Select]

# diff -u create_pluto_dialplan.pl.orig create_pluto_dialplan.pl
--- create_pluto_dialplan.pl.orig       2008-04-03 14:36:04.000000000 +0200
+++ create_pluto_dialplan.pl    2008-04-03 14:45:37.000000000 +0200
@@ -179,9 +179,9 @@
 $EXT_BUFFER .= "exten => s,3,SET(count=1)\n";
 $EXT_BUFFER .= "exten => s,4,AGI(pluto-callersforme.agi)\n";
 $EXT_BUFFER .= "exten => s,5,Background(pluto/pluto-default-voicemenu)\n";
-$EXT_BUFFER .= "exten => s,6,SET(count=${count}+1)\n";
+$EXT_BUFFER .= 'exten => s,6,SET(count=${count}+1)\n';
 $EXT_BUFFER .= "exten => s,7,Wait(1)\n";
-$EXT_BUFFER .= "exten => s,8,GoToIf($[${count}<4]?4)\n";
+$EXT_BUFFER .= 'exten => s,8,GoToIf($[${count}<4]?4)\n';
 $EXT_BUFFER .= "exten => s,9,Wait(2)\n";
 $EXT_BUFFER .= "exten => s,10,DigitTimeout,20\n";
 $EXT_BUFFER .= "exten => s,11,ResponseTimeout,20\n";

That kind of makes me wonder, do these "professionals" ever test anything before committing it to SVN? 

Anyway, thanks for the pointer bulek, been waiting for that hint quite some time now.

[aaron.b]

the bug was present feb 26, but was fixed shortly thereafter in the svn.linuxmce.org