Hi Herman,<br><br>These are common questions when dealing with the dialplan. I highly recommend that you acquire the FreeSWITCH "bridge book" (see link near top of <a href="http://wiki.freeswitch.org">wiki.freeswitch.org</a>) and read chapters 5 and 8. (Full disclosure: I wrote chapter 5 and Darren Schreiber wrote chapter 8.) Both of these chapters cover the break attribute in detail. I think you might be confusing the purpose of the break attribute. <br>
<br>Consider this dp fragment:<br><font style="font-family:courier new,monospace" size="1"><extension name="test"><br> <condition field="foo" expression="bar"/><br> <condition field="foo2" expression="bar2"><br>
<!-- actions here get added to task list only if both conditions are true --><br></font><font style="font-family:courier new,monospace" size="1"> <!-- anti-actions here get added to task list only if foo is true and foo2 is false --></font><br>
<font style="font-family:courier new,monospace" size="1"> </condition><br></extension><br></font><br>When the dialplan parser gets to this extension, the first thing it does is test the "foo" field. If the test fails then the parser <i>does not even look at the rest of this extension</i>. Why not? Because all conditions have an implied break="on-false". The following two conditions are identical in function:<br>
<font style="font-family:courier new,monospace" size="1"> <condition field="foo" expression="bar"/><br></font><font style="font-family:courier new,monospace" size="1"> <condition field="foo" expression="bar" break="on-false/><br>
</font><font style="font-family:courier new,monospace" size="1">
</font><br>So, if you want a set of actions to be included only if more than one condition is met then "stacking" will work, however you cannot do break="never". Why not? Because break="never" tells the dialplan parser, "Hey, even if this condition fails, go ahead and evaluate the next condition in this extension." If you have break="on-false" (or no 'break' attribute at all) then that tells the dialplan parser, "Hey, if this condition fails then 'break out' of this extension and continue parsing the dialplan." <br>
<br>Using what we've just discussed, let's look at the example you cited in your second post.<br>Dialplan extension "emergency_set_variables":<br><br><font size="1"><span style="font-family:courier new,monospace;color:rgb(153,51,153)"><condition field="${caller_id_name}" expression="^Emerg_" break="never"></span><br style="font-family:courier new,monospace;color:rgb(153,51,153)">
<span style="font-family:courier new,monospace;color:rgb(153,51,153)">
<action application="set" data="emergency_call=true" inline="true"/></span><br style="font-family:courier new,monospace;color:rgb(153,51,153)"><span style="font-family:courier new,monospace;color:rgb(153,51,153)">
</condition></span><br style="font-family:courier new,monospace;color:rgb(153,51,153)"><span style="font-family:courier new,monospace;color:rgb(153,51,153)">
</span><br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace">
<span style="color:rgb(255,102,0)"> <condition wday="2-6" time-of-day="22:00-23:59" break="never"></span></span><br style="font-family:courier new,monospace;color:rgb(255,102,0)"><span style="font-family:courier new,monospace;color:rgb(255,102,0)">
<action application="set" data="open=true" inline="true"/></span><br style="font-family:courier new,monospace;color:rgb(255,102,0)"><span style="font-family:courier new,monospace;color:rgb(255,102,0)">
</condition></span><br style="font-family:courier new,monospace;color:rgb(255,102,0)"><span style="font-family:courier new,monospace;color:rgb(255,102,0)">
</span><br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace">
<span style="color:rgb(0,153,0)"> <condition wday="1,7" time-of-day="05:00-23:59" break="never"></span></span><br style="font-family:courier new,monospace;color:rgb(0,153,0)"><span style="font-family:courier new,monospace;color:rgb(0,153,0)">
<action application="set" data="open=true" inline="true"/></span><br style="font-family:courier new,monospace;color:rgb(0,153,0)"><span style="font-family:courier new,monospace;color:rgb(0,153,0)">
</condition></span><br style="font-family:courier new,monospace;color:rgb(0,153,0)"></font><br>The dialplan parser logged this:<br><font size="1"><br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace;background-color:rgb(255,255,255);color:rgb(153,51,153)">Dialplan: sofia/external/</span><a style="font-family:courier new,monospace;background-color:rgb(255,255,255);color:rgb(153,51,153)" href="mailto:Unknown@72.37.252.18">Unknown@72.37.252.18</a><span style="font-family:courier new,monospace;background-color:rgb(255,255,255);color:rgb(153,51,153)"> Regex (FAIL)</span><br style="font-family:courier new,monospace;background-color:rgb(255,255,255);color:rgb(153,51,153)">
<span style="font-family:courier new,monospace;background-color:rgb(255,255,255);color:rgb(153,51,153)">
[emergency_set_variables] ${caller_id_name}(Unknown) =~ /^Emerg_/</span><br style="font-family:courier new,monospace;background-color:rgb(255,255,255);color:rgb(153,51,153)"><span style="font-family:courier new,monospace;background-color:rgb(255,255,255);color:rgb(153,51,153)">
break=never</span><br style="font-family:courier new,monospace;background-color:rgb(153,51,153)"><span style="font-family:courier new,monospace"><span style="background-color:rgb(153,51,153)">
</span><span style="color:rgb(255,102,0)">Dialplan: sofia/external/</span></span><a style="font-family:courier new,monospace;color:rgb(255,102,0)" href="mailto:Unknown@72.37.252.18">Unknown@72.37.252.18</a><span style="font-family:courier new,monospace;color:rgb(255,102,0)"> Date/TimeMatch (FAIL)</span><br style="font-family:courier new,monospace;color:rgb(255,102,0)">
<span style="font-family:courier new,monospace;color:rgb(255,102,0)">
[emergency_set_variables] break=never</span><br style="font-family:courier new,monospace;color:rgb(255,102,0)"><span style="font-family:courier new,monospace"><span style="color:rgb(255,102,0)">
</span><span style="color:rgb(0,153,0)">Dialplan: sofia/external/</span></span><a style="font-family:courier new,monospace;color:rgb(0,153,0)" href="mailto:Unknown@72.37.252.18">Unknown@72.37.252.18</a><span style="font-family:courier new,monospace;color:rgb(0,153,0)"> Date/Time Match (PASS)</span><br style="font-family:courier new,monospace;color:rgb(0,153,0)">
<span style="font-family:courier new,monospace;color:rgb(0,153,0)">
[emergency_set_variables] break=never</span><br style="font-family:courier new,monospace;color:rgb(0,153,0)"><span style="font-family:courier new,monospace;color:rgb(0,153,0)">
Dialplan: sofia/external/</span><a style="font-family:courier new,monospace;color:rgb(0,153,0)" href="mailto:Unknown@72.37.252.18">Unknown@72.37.252.18</a><span style="font-family:courier new,monospace;color:rgb(0,153,0)"> Action set(open=true) INLINE</span><br style="font-family:courier new,monospace;color:rgb(0,153,0)">
<span style="font-family:courier new,monospace;color:rgb(0,153,0)">
EXECUTE sofia/external/</span><a style="font-family:courier new,monospace;color:rgb(0,153,0)" href="mailto:Unknown@72.37.252.18">Unknown@72.37.252.18</a><span style="font-family:courier new,monospace;color:rgb(0,153,0)"> set(open=true)</span><br style="font-family:courier new,monospace;color:rgb(0,153,0)">
</font><br>Note: I added the color so that you could see which dialplan lines correspond to the log output.<br><br>The first condition (purple) fails. ({$caller_id_name} has the value "Unknown" which fails the regex test against /^Emerg_/) However, since you have break="never", the parser continues on to the next condition inside this extension. Had you done break="on-false" (or no break attribute) then the parser would have moved on to the next extension in the dialplan.<br>
<br>The second condition (orange) also fails. Again, you have break="never", so even though it fails, the parser moves on to the next condition.<br><br>The third condition (green) passes, so the parser adds the <action> to the task list. (Since you have inline="true" the action gets executed immediately during dialplan parsing instead later on during the "execution phase".)<br>
<br>In other words, the log output is exactly what I would expect it to be. <br><br>As to your other question about anti-actions in a stack: this also is a common question. It looks like you are trying to do something like this:<br>
<br>IF (cond1 AND cond2 AND cond3) THEN<br>do actions <br>ELSE<br>do other actions<br>ENDIF<br><br>You cannot do this particular construct just with conditions and anti-actions. Instead you'll need the brand spanking new "regex" syntax mentioned here: <a href="http://wiki.freeswitch.org/wiki/Dialplan_XML#Multiple_Conditions_.28Logical_OR.2C_XOR.29">http://wiki.freeswitch.org/wiki/Dialplan_XML#Multiple_Conditions_.28Logical_OR.2C_XOR.29</a><br>
<br>So, to do what you wanted to do in the second example (in your second post) you could try this:<br><font style="font-family:courier new,monospace" size="1"><br><condition regex="all"><br> <regex field="${sip_gateway}" expression="^${default_provider}$"/><br>
<regex field="${emergency_call}" expression="^true$"/><br> <regex field="${db(select/emergency/autoanswer)}" expression="^1$"/><br> <!-- the following actions get executed if all regexes PASS --><br>
<action application="set" data="call_timeout=60"/><br> <action application="set"<br>data="effective_caller_id_name=${regex(${caller_id_name}|^Emerg(_.*)$|Auto%1)}"/><br>
<action application="set" data="autoanswered=true"/><br> <action application="answer" data=""/><br> <action application="set"<br>data="group_confirm_file=/usr/local/freeswitch/sounds/en/us/callie/emergency/press_to_accept.wav"/><br>
<action application="set" data="group_confirm_key=1"/><br> <action application="bridge"<br>data="user/1000@${domain_name},sofia/gateway/1006_7217/${mobile_number}"/><br>
<!-- the following anti-actions are executed if any of the regexes FAIL --><br> <anti-action application="set"<br>data="effective_caller_id_name=${regex(${caller_id_name}|^Emerg(_.*)$|NotAuto%1)}"/><br>
<anti-action application="set" data="call_timeout=30"/><br> <anti-action application="set" data="autoanswered=false"/><br> <anti-action application="set"<br>
data="group_confirm_file=/usr/local/freeswitch/sounds/en/us/callie/emergency/press_to_accept.wav"/><br> <anti-action application="set" data="group_confirm_key=1"/><br> <anti-action application="bridge"<br>
data="user/1000@${domain_name},sofia/gateway/1006_7217/${mobile_number}"/><br></condition><br> </font><br>The <condition regex="all"> tells the parser, "Hey, execute the <action>'s only if all regexes PASS, otherwise execute any <anti-action>'s". That should give you what you need. <br>
<br>Hope this helps! <br><br>-Michael<br><br><br><br><div class="gmail_quote">On Sat, Jan 14, 2012 at 7:39 PM, Herman Griffin <span dir="ltr"><<a href="mailto:herman.griffin@gmail.com">herman.griffin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello everyone,<br>
<br>
In irc SwK said that freeswitch AND operator is lazy. To me this means<br>
that if a condition is set to break=true and it evaluates to FAIL,<br>
then the that break=never will invert the meaning of FAIL; Change it<br>
to a PASS . But why doesn't break=false behave in this same manner<br>
when there is only a single condition?<br>
<br>
Take this call trace and dialplan for example. I use a single<br>
condition with break=false. However, unlike the stacked conditions,<br>
the action is not executed when the single condition evaluates to<br>
FAIL. Why doesn't break=never cause the action to be executed in a non<br>
stacked condition?<br>
<br>
Call trace:<br>
<br>
Dialplan: sofia/external/<a href="mailto:Unknown@72.37.252.18">Unknown@72.37.252.18</a> Regex (FAIL)<br>
[emergency_set_variables] ${caller_id_name}(Unknown) =~ /^Emerg_/<br>
break=never<br>
Dialplan: sofia/external/<a href="mailto:Unknown@72.37.252.18">Unknown@72.37.252.18</a> Date/TimeMatch (FAIL)<br>
[emergency_set_variables] break=never<br>
Dialplan: sofia/external/<a href="mailto:Unknown@72.37.252.18">Unknown@72.37.252.18</a> Date/Time Match (PASS)<br>
[emergency_set_variables] break=never<br>
Dialplan: sofia/external/<a href="mailto:Unknown@72.37.252.18">Unknown@72.37.252.18</a> Action set(open=true) INLINE<br>
EXECUTE sofia/external/<a href="mailto:Unknown@72.37.252.18">Unknown@72.37.252.18</a> set(open=true)<br>
<br>
Dialplan:<br>
<br>
<condition field="${caller_id_name}" expression="^Emerg_" break="never"><br>
<action application="set" data="emergency_call=true" inline="true"/><br>
</condition><br>
<br>
<condition wday="2-6" time-of-day="22:00-23:59" break="never"><br>
<action application="set" data="open=true" inline="true"/><br>
</condition><br>
<br>
<condition wday="1,7" time-of-day="05:00-23:59" break="never"><br>
<action application="set" data="open=true" inline="true"/><br>
</condition><br>
<br>
-------------------------------------------------<br>
<br>
I also getting confusing behavior with anti-action and stacked<br>
condition. I expect the anti-action to be executed if any of the<br>
stacked conditions evaluates to FAIL. However, in the case below, the<br>
extension simply breaks if any of the condition evaluates to FAIL.<br>
<br>
Call trace:<br>
<br>
Dialplan: sofia/external/<a href="mailto:Unknown@72.37.252.18">Unknown@72.37.252.18</a> parsing<br>
[public->emergency_bridge] continue=true<br>
Dialplan: sofia/external/<a href="mailto:Unknown@72.37.252.18">Unknown@72.37.252.18</a> Regex (PASS)<br>
[emergency_bridge] ${sip_gateway}(1006_7217) =~ /^1006_7217$/<br>
break=on-false<br>
Dialplan: sofia/external/<a href="mailto:Unknown@72.37.252.18">Unknown@72.37.252.18</a> Regex (FAIL)<br>
[emergency_bridge] ${emergency_call}() =~ /^true$/ break=on-false<br>
Dialplan: sofia/external/<a href="mailto:Unknown@72.37.252.18">Unknown@72.37.252.18</a> parsing<br>
[public->public_did] continue=false <-- [[MOVES ON TO ANOTHER<br>
EXTENSION WITH EXECUTING THE anti-action]]<br>
<br>
Dialplan:<br>
<br>
<condition field="${sip_gateway}" expression="^${default_provider}$"/><br>
<condition field="${emergency_call}" expression="^true$"/><br>
<div class="im"> <condition field="${db(select/emergency/autoanswer)}" expression="^1$"><br>
</div><div class="im"> <action application="set" data="call_timeout=60"/><br>
<action application="set"<br>
data="effective_caller_id_name=${regex(${caller_id_name}|^Emerg(_.*)$|Auto%1)}"/><br>
<action application="set" data="autoanswered=true"/><br>
<action application="answer" data=""/><br>
<action application="set"<br>
data="group_confirm_file=/usr/local/freeswitch/sounds/en/us/callie/emergency/press_to_accept.wav"/><br>
<action application="set" data="group_confirm_key=1"/><br>
<action application="bridge"<br>
data="user/1000@${domain_name},sofia/gateway/1006_7217/${mobile_number}"/><br>
<br>
</div><div class="im"> <anti-action application="set"<br>
data="effective_caller_id_name=${regex(${caller_id_name}|^Emerg(_.*)$|NotAuto%1)}"/><br>
<anti-action application="set" data="call_timeout=30"/><br>
<anti-action application="set" data="autoanswered=false"/><br>
</div> <anti-action application="set"<br>
data="group_confirm_file=/usr/local/freeswitch/sounds/en/us/callie/emergency/press_to_accept.wav"/><br>
<anti-action application="set" data="group_confirm_key=1"/><br>
<div class="im"> <anti-action application="bridge"<br>
data="user/1000@${domain_name},sofia/gateway/1006_7217/${mobile_number}"/><br>
</condition><br>
</div> </extension><br>
<br>
<br>
SwK suggested that I use a script language, which is probably what<br>
I'll end up doing. However, I'm very interested in understanding why<br>
the scenarios above. Are these bugs or are they just counter intuitive<br>
rules that we must simply memorize?<br>
<br>
Thanks for your input.<br>
<span class="HOEnZb"><font color="#888888">Herman Griffin<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On Sat, Jan 14, 2012 at 11:42 AM, Jeff Lenk <<a href="mailto:jeff@jefflenk.com">jeff@jefflenk.com</a>> wrote:<br>
> By putting the break=never you are defeating the "and" processing. Remove<br>
> that.<br>
><br>
> Move the second group into its own extension.<br>
><br>
> --<br>
> View this message in context: <a href="http://freeswitch-users.2379917.n2.nabble.com/Stacked-conditions-are-not-acting-like-logical-AND-tp7188082p7188271.html" target="_blank">http://freeswitch-users.2379917.n2.nabble.com/Stacked-conditions-are-not-acting-like-logical-AND-tp7188082p7188271.html</a><br>
> Sent from the freeswitch-users mailing list archive at Nabble.com.<br></div></div></blockquote><br></div><br>