[Freeswitch-dev] [PATCH] Fixed loop unrolling in dialplan configuration
Greetings, While grepping through the sources to identify how channel variables are used (and I must say, the FreeSWITCH sources are exquisitely beautiful C code), I uncovered the following minor issue. It appears this would have prevented loop unrolling from working as intended with the in-tree dialplan. Author: Travis Cross <tc@traviscross.com> Date: Fri Oct 17 03:54:12 2008 +0000 Fixed loop unrolling in dialplan configuration. unroll_loops is a preprocessor variable, not a channel variable. diff --git a/conf/dialplan/default.xml b/conf/dialplan/default.xml index 61a7500..6bf4ca3 100644 --- a/conf/dialplan/default.xml +++ b/conf/dialplan/default.xml @@ -15,7 +15,7 @@ <context name="default"> <extension name="unloop"> - <condition field="${unroll_loops}" expression="^true$"/> + <condition field="$${unroll_loops}" expression="^true$"/> <condition field="${sip_looped_call}" expression="^true$"> <action application="deflect" data="${destination_number}"/> </condition> diff --git a/conf/dialplan/public.xml b/conf/dialplan/public.xml index 49b8850..5c8cdc5 100644 --- a/conf/dialplan/public.xml +++ b/conf/dialplan/public.xml @@ -14,7 +14,7 @@ <context name="public"> <extension name="unloop"> - <condition field="${unroll_loops}" expression="^true$"/> + <condition field="$${unroll_loops}" expression="^true$"/> <condition field="${sip_looped_call}" expression="^true$"> <action application="deflect" data="${destination_number}"/> </condition> Cheers, -- Travis
Committed revision 10051. Thanks for this find. /b On Oct 16, 2008, at 9:50 PM, Travis Cross wrote:
Greetings,
While grepping through the sources to identify how channel variables are used (and I must say, the FreeSWITCH sources are exquisitely beautiful C code), I uncovered the following minor issue. It appears this would have prevented loop unrolling from working as intended with the in-tree dialplan.
Author: Travis Cross <tc@traviscross.com> Date: Fri Oct 17 03:54:12 2008 +0000
Fixed loop unrolling in dialplan configuration.
unroll_loops is a preprocessor variable, not a channel variable.
diff --git a/conf/dialplan/default.xml b/conf/dialplan/default.xml index 61a7500..6bf4ca3 100644 --- a/conf/dialplan/default.xml +++ b/conf/dialplan/default.xml @@ -15,7 +15,7 @@ <context name="default">
<extension name="unloop"> - <condition field="${unroll_loops}" expression="^true$"/> + <condition field="$${unroll_loops}" expression="^true$"/> <condition field="${sip_looped_call}" expression="^true$"> <action application="deflect" data="${destination_number}"/> </condition> diff --git a/conf/dialplan/public.xml b/conf/dialplan/public.xml index 49b8850..5c8cdc5 100644 --- a/conf/dialplan/public.xml +++ b/conf/dialplan/public.xml @@ -14,7 +14,7 @@ <context name="public">
<extension name="unloop"> - <condition field="${unroll_loops}" expression="^true$"/> + <condition field="$${unroll_loops}" expression="^true$"/> <condition field="${sip_looped_call}" expression="^true$"> <action application="deflect" data="${destination_number}"/> </condition>
Cheers,
-- Travis
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
The same would apply to the call_debug variable too but it works without $$ in the config as is..... And I'm pretty sure they work in either case but you're right it shouldn't have to eval it every time. /b On Oct 16, 2008, at 9:50 PM, Travis Cross wrote:
Fixed loop unrolling in dialplan configuration.
Brian West wrote:
The same would apply to the call_debug variable too but it works without $$ in the config as is..... And I'm pretty sure they work in either case but you're right it shouldn't have to eval it every time.
I did wonder if there might be some super special magic going on there.... I took a look in switch_xml.c and switch_core.c; now I understand. <X-pre-process cmd="set" data="foo=bar"/> does more than operate exclusively in the preprocessor, as I intuitively would have expected. Instead, it sets foo as a global runtime variable, which is then used by the preprocessor during expansion. When we lookup a channel variable in switch_channel.c, upon finding that there is no channel variable by the requested name, we fall back to using a global runtime variable by the same name, if one exists. Cheers, -- Travis
participants (2)
-
Brian West
-
Travis Cross