Hello everyone, In irc SwK said that freeswitch AND operator is lazy. To me this means that if a condition is set to break=true and it evaluates to FAIL, then the that break=never will invert the meaning of FAIL; Change it to a PASS . But why doesn't break=false behave in this same manner when there is only a single condition? Take this call trace and dialplan for example. I use a single condition with break=false. However, unlike the stacked conditions, the action is not executed when the single condition evaluates to FAIL. Why doesn't break=never cause the action to be executed in a non stacked condition? Call trace: Dialplan: sofia/external/Unknown@72.37.252.18 Regex (FAIL) [emergency_set_variables] ${caller_id_name}(Unknown) =~ /^Emerg_/ break=never Dialplan: sofia/external/Unknown@72.37.252.18 Date/TimeMatch (FAIL) [emergency_set_variables] break=never Dialplan: sofia/external/Unknown@72.37.252.18 Date/Time Match (PASS) [emergency_set_variables] break=never Dialplan: sofia/external/Unknown@72.37.252.18 Action set(open=true) INLINE EXECUTE sofia/external/Unknown@72.37.252.18 set(open=true) Dialplan: <condition field="${caller_id_name}" expression="^Emerg_" break="never"> <action application="set" data="emergency_call=true" inline="true"/> </condition> <condition wday="2-6" time-of-day="22:00-23:59" break="never"> <action application="set" data="open=true" inline="true"/> </condition> <condition wday="1,7" time-of-day="05:00-23:59" break="never"> <action application="set" data="open=true" inline="true"/> </condition> ------------------------------------------------- I also getting confusing behavior with anti-action and stacked condition. I expect the anti-action to be executed if any of the stacked conditions evaluates to FAIL. However, in the case below, the extension simply breaks if any of the condition evaluates to FAIL. Call trace: Dialplan: sofia/external/Unknown@72.37.252.18 parsing [public->emergency_bridge] continue=true Dialplan: sofia/external/Unknown@72.37.252.18 Regex (PASS) [emergency_bridge] ${sip_gateway}(1006_7217) =~ /^1006_7217$/ break=on-false Dialplan: sofia/external/Unknown@72.37.252.18 Regex (FAIL) [emergency_bridge] ${emergency_call}() =~ /^true$/ break=on-false Dialplan: sofia/external/Unknown@72.37.252.18 parsing [public->public_did] continue=false <-- [[MOVES ON TO ANOTHER EXTENSION WITH EXECUTING THE anti-action]] Dialplan: <condition field="${sip_gateway}" expression="^${default_provider}$"/> <condition field="${emergency_call}" expression="^true$"/> <condition field="${db(select/emergency/autoanswer)}" expression="^1$"> <action application="set" data="call_timeout=60"/> <action application="set" data="effective_caller_id_name=${regex(${caller_id_name}|^Emerg(_.*)$|Auto%1)}"/> <action application="set" data="autoanswered=true"/> <action application="answer" data=""/> <action application="set" data="group_confirm_file=/usr/local/freeswitch/sounds/en/us/callie/emergency/press_to_accept.wav"/> <action application="set" data="group_confirm_key=1"/> <action application="bridge" data="user/1000@${domain_name},sofia/gateway/1006_7217/${mobile_number}"/> <anti-action application="set" data="effective_caller_id_name=${regex(${caller_id_name}|^Emerg(_.*)$|NotAuto%1)}"/> <anti-action application="set" data="call_timeout=30"/> <anti-action application="set" data="autoanswered=false"/> <anti-action application="set" data="group_confirm_file=/usr/local/freeswitch/sounds/en/us/callie/emergency/press_to_accept.wav"/> <anti-action application="set" data="group_confirm_key=1"/> <anti-action application="bridge" data="user/1000@${domain_name},sofia/gateway/1006_7217/${mobile_number}"/> </condition> </extension> SwK suggested that I use a script language, which is probably what I'll end up doing. However, I'm very interested in understanding why the scenarios above. Are these bugs or are they just counter intuitive rules that we must simply memorize? Thanks for your input. Herman Griffin On Sat, Jan 14, 2012 at 11:42 AM, Jeff Lenk <jeff@jefflenk.com> wrote:
By putting the break=never you are defeating the "and" processing. Remove that.
Move the second group into its own extension.
-- View this message in context: http://freeswitch-users.2379917.n2.nabble.com/Stacked-conditions-are-not-act... Sent from the freeswitch-users mailing list archive at Nabble.com.
_________________________________________________________________________ Professional FreeSWITCH Consulting Services: consulting@freeswitch.org http://www.freeswitchsolutions.com
FreeSWITCH-powered IP PBX: The CudaTel Communication Server http://www.cudatel.com
Official FreeSWITCH Sites http://www.freeswitch.org http://wiki.freeswitch.org http://www.cluecon.com
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org