Understanding break="never" in condition-tag
Hi All, I'm struggling understanding the 'break' attribute in condition tags. Am I correct saying the following condition tag is useless? It doesn't influence the routing/application stack at all. For this example the check is on 'wday', but it could be any other field/expression, my question is about the 'break="never"' part: <condition wday="1" break="never" /> ( though it could be used for clarity or debugging, since it does get evaluated) regards, Egbert.
On Sun, Mar 20, 2011 at 2:10 PM, [Redhosting] Egbert Groot <egbert@redhosting.nl> wrote:
Hi All,
I'm struggling understanding the 'break' attribute in condition tags. Am I correct saying the following condition tag is useless? It doesn't influence the routing/application stack at all. For this example the check is on 'wday', but it could be any other field/expression, my question is about the 'break="never"' part:
<condition wday="1" break="never" />
( though it could be used for clarity or debugging, since it does get evaluated)
It makes sense if you use the form <condition wday="1" break="never"> (some actions) </condition> - Dmitry Bely
Dmitry Bely schreef:
On Sun, Mar 20, 2011 at 2:10 PM, [Redhosting] Egbert Groot <egbert@redhosting.nl> wrote:
Hi All,
I'm struggling understanding the 'break' attribute in condition tags. Am I correct saying the following condition tag is useless? It doesn't influence the routing/application stack at all. For this example the check is on 'wday', but it could be any other field/expression, my question is about the 'break="never"' part:
<condition wday="1" break="never" />
( though it could be used for clarity or debugging, since it does get evaluated)
It makes sense if you use the form
<condition wday="1" break="never"> (some actions) </condition>
Indeed, with adding an action, it is/can be usefull. I was reading in wiki: http://wiki.freeswitch.org/wiki/Dialplan_XML#Nesting_Conditions_-OR_.7C.7C I think the example is not the most clear explanation of the workings of 'break'. It does use 'break-never' without any action. Even more, am I correct stating the provided example doesn't do what one might want to accomplish? It seems to me the week days are of no use at all? I'd like to improve the wiki, problem is I'm not sure I understand the working enhough. regards, Egbert.
No, I'm pretty sure that example works as intended.. I created it. break="never" is NOT "ignore this condition" but rather "keep processing the extension even if this doesn't match". So in the example you linked to, if both wday's don't match, it goes to the "catch-all" at the end. And if it does match the wday, it still has to match the rest of the nested conditions to perform the action. -Avi On Sun, Mar 20, 2011 at 2:45 PM, [Redhosting] Egbert Groot < egbert@redhosting.nl> wrote:
On Sun, Mar 20, 2011 at 2:10 PM, [Redhosting] Egbert Groot<egbert@redhosting.nl> <egbert@redhosting.nl> wrote:
Indeed, with adding an action, it is/can be usefull. I was reading in wiki: http://wiki.freeswitch.org/wiki/Dialplan_XML#Nesting_Conditions_-OR_.7C.7C I think the example is not the most clear explanation of the workings of 'break'. It does use 'break-never' without any action. Even more, am I correct stating the provided example doesn't do what one might want to accomplish? It seems to me the week days are of no use at all? I'd like to improve the wiki, problem is I'm not sure I understand the working enhough.
regards, Egbert.
_______________________________________________ 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
On Sun, Mar 20, 2011 at 10:45 PM, Avi Marcus <avi@avimarcus.net> wrote:
No, I'm pretty sure that example works as intended.. I created it
Really? Correct me if I'm wrong but for wday=1 and hour=9 an action in <condition wday="6" break="never"/> <condition hour="8-12" break="on-true"> <action application="transfer" data="1105 XML default"/> </condition> will be executed and further processing will be stopped. Actually the first condition is a sort of (misleading) comment here. - Dmitry Bely
We have two items going on - extensions, and condition-groups within the extension. For wday=1, if it was set to on-false - the default - it would end evaluating this extension and move on to the next. However, since it says "break=never" it moves to evaluate the *next* *condition-group* rather than executing or skipping the extension entirely. -Avi On Mon, Mar 21, 2011 at 8:59 AM, Dmitry Bely <dmitry.bely@gmail.com> wrote:
On Sun, Mar 20, 2011 at 10:45 PM, Avi Marcus <avi@avimarcus.net> wrote:
No, I'm pretty sure that example works as intended.. I created it
Really? Correct me if I'm wrong but for wday=1 and hour=9 an action in
<condition wday="6" break="never"/> <condition hour="8-12" break="on-true"> <action application="transfer" data="1105 XML default"/> </condition>
will be executed and further processing will be stopped. Actually the first condition is a sort of (misleading) comment here.
- Dmitry Bely
_______________________________________________ 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
NOTE: break "on-true, on-false, never" don't change the *condition*, merely the *hunting*. You need ALL the conditions to match for freeswitch to do the action, and you can't change that! The break is how to handle failure - "Does 1 failure to match a condition mean should move on to the next condition extension (on-false) or keep evaluating this extension? (never)" -Avi On Mon, Mar 21, 2011 at 10:13 AM, Avi Marcus <avi@avimarcus.net> wrote:
We have two items going on - extensions, and condition-groups within the extension. For wday=1, if it was set to on-false - the default - it would end evaluating this extension and move on to the next. However, since it says "break=never" it moves to evaluate the *next* *condition-group* rather than executing or skipping the extension entirely. -Avi
On Mon, Mar 21, 2011 at 8:59 AM, Dmitry Bely <dmitry.bely@gmail.com>wrote:
On Sun, Mar 20, 2011 at 10:45 PM, Avi Marcus <avi@avimarcus.net> wrote:
No, I'm pretty sure that example works as intended.. I created it
Really? Correct me if I'm wrong but for wday=1 and hour=9 an action in
<condition wday="6" break="never"/> <condition hour="8-12" break="on-true"> <action application="transfer" data="1105 XML default"/> </condition>
will be executed and further processing will be stopped. Actually the first condition is a sort of (misleading) comment here.
- Dmitry Bely
_______________________________________________ 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
On Mon, Mar 21, 2011 at 11:18 AM, Avi Marcus <avi@avimarcus.net> wrote:
NOTE: break "on-true, on-false, never" don't change the *condition*, merely the *hunting*.
If wday=1 and hour=9, will transfer to 1105 be executed in your example? If you think it won't, why?
You need ALL the conditions to match for freeswitch to do the action, and you can't change that!
I don't think so. If some condition evaluates to true, its nested actions are always executed no matter what preceded it. But of course the condition should be evaluated first, that's where various break values come into play.
The break is how to handle failure - "Does 1 failure to match a condition mean should move on to the next condition extension (on-false) or keep evaluating this extension? (never)" -Avi
On Mon, Mar 21, 2011 at 10:13 AM, Avi Marcus <avi@avimarcus.net> wrote:
We have two items going on - extensions, and condition-groups within the extension. For wday=1, if it was set to on-false - the default - it would end evaluating this extension and move on to the next. However, since it says "break=never" it moves to evaluate the *next* *condition-group* rather than executing or skipping the extension entirely. -Avi
On Mon, Mar 21, 2011 at 8:59 AM, Dmitry Bely <dmitry.bely@gmail.com> wrote:
On Sun, Mar 20, 2011 at 10:45 PM, Avi Marcus <avi@avimarcus.net> wrote:
No, I'm pretty sure that example works as intended.. I created it
Really? Correct me if I'm wrong but for wday=1 and hour=9 an action in
<condition wday="6" break="never"/> <condition hour="8-12" break="on-true"> <action application="transfer" data="1105 XML default"/> </condition>
will be executed and further processing will be stopped. Actually the first condition is a sort of (misleading) comment here.
- Dmitry Bely
<extension name="YLE"> <condition field="destination_number" expression="^\*1105$" break="on-false"/> <--if this is false, FreeSWITCH skips to the next extension. <condition wday="6" break="never"/> <--The default "on-false" would make FreeSWITCH move to the next extension, rather than evaluating the next condition set. <condition hour="8-12" break="on-true"> <--Don't evaluate the next condition set if this is true. <action application="transfer" data="1105 XML default"/> </condition> <condition wday="1-5" break="never"/> <condition hour="8-21" break="on-true"> <action application="transfer" data="1105 XML default"/> </condition> <condition> <-- this is a catch all. If they didn't dial *1105, they aren't here anymore. <action application="voicemail" data="default ${domain} 1105"/> </condition> </extension> On Mon, Mar 21, 2011 at 11:40 AM, Dmitry Bely <dmitry.bely@gmail.com> wrote:
On Mon, Mar 21, 2011 at 11:18 AM, Avi Marcus <avi@avimarcus.net> wrote:
NOTE: break "on-true, on-false, never" don't change the *condition*, merely the *hunting*.
If wday=1 and hour=9, will transfer to 1105 be executed in your example? If you think it won't, why?
It will go to 1105 - from the second condition-group. But the first condition-group fails. I'm pretty sure I've seen it in the logs work as I'm describing..
You need ALL the conditions to match for freeswitch to do the action, and you can't change that!
I don't think so. If some condition evaluates to true, its nested actions are always executed no matter what preceded it. But of course the condition should be evaluated first, that's where various break values come into play.
No way - the dialplan is always run on a "match all conditions" to do the actions! How else would multiple conditions EVER work? This is a slight edge-case though - the on-true, on-fail, never.. they only matter when you want MULTIPLE condition-groups within ONE extension. If you specify your settings as multiple serial extensions, then this stuff doesn't really matter... -Avi
The break is how to handle failure - "Does 1 failure to match a condition mean should move on to the next condition extension (on-false) or keep evaluating this extension? (never)" -Avi
On Mon, Mar 21, 2011 at 10:13 AM, Avi Marcus <avi@avimarcus.net> wrote:
We have two items going on - extensions, and condition-groups within the extension. For wday=1, if it was set to on-false - the default - it would end evaluating this extension and move on to the next. However, since it says "break=never" it moves to evaluate the *next* *condition-group* rather than executing or skipping the extension
entirely.
-Avi
On Mon, Mar 21, 2011 at 8:59 AM, Dmitry Bely <dmitry.bely@gmail.com> wrote:
On Sun, Mar 20, 2011 at 10:45 PM, Avi Marcus <avi@avimarcus.net>
wrote:
No, I'm pretty sure that example works as intended.. I created it
Really? Correct me if I'm wrong but for wday=1 and hour=9 an action in
<condition wday="6" break="never"/> <condition hour="8-12" break="on-true"> <action application="transfer" data="1105 XML default"/> </condition>
will be executed and further processing will be stopped. Actually the first condition is a sort of (misleading) comment here.
- Dmitry Bely
_______________________________________________ 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
On Mon, Mar 21, 2011 at 1:01 PM, Avi Marcus <avi@avimarcus.net> wrote:
You need ALL the conditions to match for freeswitch to do the action, and you can't change that!
I don't think so. If some condition evaluates to true, its nested actions are always executed no matter what preceded it. But of course the condition should be evaluated first, that's where various break values come into play.
No way - the dialplan is always run on a "match all conditions" to do the actions! How else would multiple conditions EVER work?
Completely wrong. And I don't see relevant logs in your message. Here is mine. A dialplan fragment: <extension name="condition-test"> <condition wday="6" break="never"/> <condition hour="9-18" break="on-true"> <action application="info"/> </condition> </extension> log: Dialplan: sofia/internal/1000@192.168.121.66 parsing [default->condition-test] continue=false Dialplan: sofia/internal/1000@192.168.121.66 Date/Time Match (FAIL) [condition-test] break=never Dialplan: sofia/internal/1000@192.168.121.66 Date/Time Match (PASS) [condition-test] break=on-true Dialplan: sofia/internal/1000@192.168.121.66 Action info() Guess what? The first condition fails but the action is still scheduled for execution (and indeed executed later) - Dmitry Bely
Hmm, looking at your log and mine from the past, you appear to be correct. It looks like break=never means to ignore the condition. So then.. I'm left with the original question - what's the point? And another - how can you do groups of conditions, like I intended to show in the example? I tried setting it to break on-false, or break on-true, but I can never get to the second condition set. Am I supposed to create it as separate extensions? On Mon, Mar 21, 2011 at 12:44 PM, Dmitry Bely <dmitry.bely@gmail.com> wrote:
On Mon, Mar 21, 2011 at 1:01 PM, Avi Marcus <avi@avimarcus.net> wrote:
You need ALL the conditions to match for freeswitch to do the action, and you can't change that!
I don't think so. If some condition evaluates to true, its nested actions are always executed no matter what preceded it. But of course the condition should be evaluated first, that's where various break values come into play.
No way - the dialplan is always run on a "match all conditions" to do the actions! How else would multiple conditions EVER work?
Completely wrong. And I don't see relevant logs in your message. Here is mine. A dialplan fragment:
<extension name="condition-test"> <condition wday="6" break="never"/> <condition hour="9-18" break="on-true"> <action application="info"/> </condition> </extension>
log:
Dialplan: sofia/internal/1000@192.168.121.66 parsing [default->condition-test] continue=false Dialplan: sofia/internal/1000@192.168.121.66 Date/Time Match (FAIL) [condition-test] break=never Dialplan: sofia/internal/1000@192.168.121.66 Date/Time Match (PASS) [condition-test] break=on-true Dialplan: sofia/internal/1000@192.168.121.66 Action info()
Guess what? The first condition fails but the action is still scheduled for execution (and indeed executed later)
- Dmitry Bely
_______________________________________________ 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
On Mon, Mar 21, 2011 at 3:08 PM, Avi Marcus <avi@avimarcus.net> wrote:
Hmm, looking at your log and mine from the past, you appear to be correct. It looks like break=never means to ignore the condition. So then.. I'm left with the original question - what's the point?
I can only replicate my answer to the original poster: It makes sense if you use the form <condition wday="1" break="never"> (some actions) </condition>
And another - how can you do groups of conditions, like I intended to show in the example? I tried setting it to break on-false, or break on-true, but I can never get to the second condition set. Am I supposed to create it as separate extensions?
Probably so.
On Mon, Mar 21, 2011 at 12:44 PM, Dmitry Bely <dmitry.bely@gmail.com> wrote:
On Mon, Mar 21, 2011 at 1:01 PM, Avi Marcus <avi@avimarcus.net> wrote:
You need ALL the conditions to match for freeswitch to do the action, and you can't change that!
I don't think so. If some condition evaluates to true, its nested actions are always executed no matter what preceded it. But of course the condition should be evaluated first, that's where various break values come into play.
No way - the dialplan is always run on a "match all conditions" to do the actions! How else would multiple conditions EVER work?
Completely wrong. And I don't see relevant logs in your message. Here is mine. A dialplan fragment:
<extension name="condition-test"> <condition wday="6" break="never"/> <condition hour="9-18" break="on-true"> <action application="info"/> </condition> </extension>
log:
Dialplan: sofia/internal/1000@192.168.121.66 parsing [default->condition-test] continue=false Dialplan: sofia/internal/1000@192.168.121.66 Date/Time Match (FAIL) [condition-test] break=never Dialplan: sofia/internal/1000@192.168.121.66 Date/Time Match (PASS) [condition-test] break=on-true Dialplan: sofia/internal/1000@192.168.121.66 Action info()
Guess what? The first condition fails but the action is still scheduled for execution (and indeed executed later)
- Dmitry Bely
Dmitry Bely schreef:
On Mon, Mar 21, 2011 at 3:08 PM, Avi Marcus <avi@avimarcus.net> wrote:
Hmm, looking at your log and mine from the past, you appear to be correct. It looks like break=never means to ignore the condition. So then.. I'm left with the original question - what's the point?
I can only replicate my answer to the original poster:
It makes sense if you use the form
<condition wday="1" break="never"> (some actions) </condition>
And another - how can you do groups of conditions, like I intended to show in the example? I tried setting it to break on-false, or break on-true, but I can never get to the second condition set. Am I supposed to create it as separate extensions?
Probably so.
On Mon, Mar 21, 2011 at 12:44 PM, Dmitry Bely <dmitry.bely@gmail.com> wrote:
On Mon, Mar 21, 2011 at 1:01 PM, Avi Marcus <avi@avimarcus.net> wrote:
You need ALL the conditions to match for freeswitch to do the action, and you can't change that!
I don't think so. If some condition evaluates to true, its nested actions are always executed no matter what preceded it. But of course the condition should be evaluated first, that's where various break values come into play.
No way - the dialplan is always run on a "match all conditions" to do the actions! How else would multiple conditions EVER work?
Completely wrong. And I don't see relevant logs in your message. Here is mine. A dialplan fragment:
<extension name="condition-test"> <condition wday="6" break="never"/> <condition hour="9-18" break="on-true"> <action application="info"/> </condition> </extension>
log:
Dialplan: sofia/internal/1000@192.168.121.66 parsing [default->condition-test] continue=false Dialplan: sofia/internal/1000@192.168.121.66 Date/Time Match (FAIL) [condition-test] break=never Dialplan: sofia/internal/1000@192.168.121.66 Date/Time Match (PASS) [condition-test] break=on-true Dialplan: sofia/internal/1000@192.168.121.66 Action info()
Guess what? The first condition fails but the action is still scheduled for execution (and indeed executed later)
I can't/didn't contribute much to this discussion, but I do follow it. My idea and (little) testing experience supports the explanation of Dimitry. Either way, it 'proofs' there is confusion about the working of the 'break' in condition tags. If I can find the time, I will try to do some tests / build an example myself. Thank you both for the answers and insights so far. regards, Egbert.
I can't/didn't contribute much to this discussion, but I do follow it. My idea and (little) testing experience supports the explanation of Dimitry. Either way, it 'proofs' there is confusion about the working of the 'break' in condition tags. If I can find the time, I will try to do some tests / build an example myself. Thank you both for the answers and insights so far.
Okay, for those of you who have the bridge book, please go to page 167-168. Darren did a really good job of explaining this. For those of you who don't have the book, SHAME! :) The break flag determines what happens on processing conditions within a single extension. Let's say that chan var ${freeswitch} has the value "rocks" and ${foo} has the value "bar". <extension name="break_flag_is_not_confusing"> <condition "${freeswitch}" expression="^lame$"> <!-- this does not get executed --> </condition> <!-- the following condition is not even evaluated --> <condition "${foo}" expression="bar"> ... </condition> </extension> Look at the above snipped. The first condition evaluates to false, which means all processing for this particular extension stops. The parse "breaks" out of this extension and moves on to the next one. Now look at this extension with the the break-flag set to "never"... <extension name="break_flag_is_not_confusing"> <condition "${freeswitch}" expression="^lame$" break="never"> <!-- this does not get executed --> </condition> <!-- the following condition *is* evaluated --> <condition "${foo}" expression="bar"> ... </condition> </extension> See the difference? With the break flag set to "never" then it does not matter whether the condition is evaluated as true or false - the extension's next condition gets evaluated. Why do you need the break="never"? Simple: when no "break" is specified there is an implied break="on-false" for the condition. In other words, by default, if one condition inside of an extension evaluates to false then all processing for that extension stops. This has the effect of allowing you to "stack" conditions to create a logical AND. So, in summary, the break flag will control how the parser behaves when evaluating conditions. Normally when a single condition fails, the whole extension is skipped, however when you do break="never" on a condition then it does not matter if that particular condition is true or false - extension processing will continue. Hope this helps. If it doesn't then read chapters 5 and 8 of the book. Chapter 5 (me) is a gentle intro into the dialplan. Chapter 8 (Darren) talks more extensively about the advanced concepts of dialplan processing. -MC
The simple way to put it is that in the example in this email that is from the wiki, using an empty condition with break=never is a noOP. The typical usage of break=never would be if you wanted to execute some extra options when a condition was true and skip it but keep going when its not true. <extension> <!-- because break=never even when the destionation does not begin with 1 we just don't execute these actions and keep going --> <condition field="destination_number" expression="^1(\d+)$" break="never"> <action application="set" data="begins_with_one=true"/> </condition> <condition field="destination_number" expression="^(\d+)$"> <action application="bridge" data="sofia/internal/$1@foobar.com"/> </condition> </extension> So stacking conditions with no actions in them and putting break=never on them is the same as if they do not exist. On Mon, Mar 21, 2011 at 3:10 PM, Michael Collins <msc@freeswitch.org> wrote:
I can't/didn't contribute much to this discussion, but I do follow it. My idea and (little) testing experience supports the explanation of Dimitry. Either way, it 'proofs' there is confusion about the working of the 'break' in condition tags. If I can find the time, I will try to do some tests / build an example myself. Thank you both for the answers and insights so far.
Okay, for those of you who have the bridge book, please go to page 167-168. Darren did a really good job of explaining this. For those of you who don't have the book, SHAME! :) The break flag determines what happens on processing conditions within a single extension. Let's say that chan var ${freeswitch} has the value "rocks" and ${foo} has the value "bar". <extension name="break_flag_is_not_confusing"> <condition "${freeswitch}" expression="^lame$"> <!-- this does not get executed --> </condition> <!-- the following condition is not even evaluated --> <condition "${foo}" expression="bar"> ... </condition> </extension> Look at the above snipped. The first condition evaluates to false, which means all processing for this particular extension stops. The parse "breaks" out of this extension and moves on to the next one. Now look at this extension with the the break-flag set to "never"... <extension name="break_flag_is_not_confusing"> <condition "${freeswitch}" expression="^lame$" break="never"> <!-- this does not get executed --> </condition> <!-- the following condition *is* evaluated --> <condition "${foo}" expression="bar"> ... </condition> </extension> See the difference? With the break flag set to "never" then it does not matter whether the condition is evaluated as true or false - the extension's next condition gets evaluated. Why do you need the break="never"? Simple: when no "break" is specified there is an implied break="on-false" for the condition. In other words, by default, if one condition inside of an extension evaluates to false then all processing for that extension stops. This has the effect of allowing you to "stack" conditions to create a logical AND. So, in summary, the break flag will control how the parser behaves when evaluating conditions. Normally when a single condition fails, the whole extension is skipped, however when you do break="never" on a condition then it does not matter if that particular condition is true or false - extension processing will continue. Hope this helps. If it doesn't then read chapters 5 and 8 of the book. Chapter 5 (me) is a gentle intro into the dialplan. Chapter 8 (Darren) talks more extensively about the advanced concepts of dialplan processing. -MC
_______________________________________________ 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
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
Michael Collins schreef:
I can't/didn't contribute much to this discussion, but I do follow it. My idea and (little) testing experience supports the explanation of Dimitry. Either way, it 'proofs' there is confusion about the working of the 'break' in condition tags. If I can find the time, I will try to do some tests / build an example myself. Thank you both for the answers and insights so far.
Okay, for those of you who have the bridge book, please go to page 167-168. Darren did a really good job of explaining this. For those of you who don't have the book, SHAME! :)
Thanks for the explanation, and I just ordered the book :) regards, Egbert.
The break flag determines what happens on processing conditions within a single extension. Let's say that chan var ${freeswitch} has the value "rocks" and ${foo} has the value "bar".
<extension name="break_flag_is_not_confusing"> <condition "${freeswitch}" expression="^lame$"> <!-- this does not get executed --> </condition> <!-- the following condition is not even evaluated --> <condition "${foo}" expression="bar"> ... </condition> </extension>
Look at the above snipped. The first condition evaluates to false, which means all processing for this particular extension stops. The parse "breaks" out of this extension and moves on to the next one. Now look at this extension with the the break-flag set to "never"...
<extension name="break_flag_is_not_confusing"> <condition "${freeswitch}" expression="^lame$" break="never"> <!-- this does not get executed --> </condition> <!-- the following condition *is* evaluated --> <condition "${foo}" expression="bar"> ... </condition> </extension>
See the difference? With the break flag set to "never" then it does not matter whether the condition is evaluated as true or false - the extension's next condition gets evaluated. Why do you need the break="never"? Simple: when no "break" is specified there is an implied break="on-false" for the condition. In other words, by default, if one condition inside of an extension evaluates to false then all processing for that extension stops. This has the effect of allowing you to "stack" conditions to create a logical AND.
So, in summary, the break flag will control how the parser behaves when evaluating conditions. Normally when a single condition fails, the whole extension is skipped, however when you do break="never" on a condition then it does not matter if that particular condition is true or false - extension processing will continue.
Hope this helps. If it doesn't then read chapters 5 and 8 of the book. Chapter 5 (me) is a gentle intro into the dialplan. Chapter 8 (Darren) talks more extensively about the advanced concepts of dialplan processing.
-MC
------------------------------------------------------------------------
_______________________________________________ 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
On Wed, Mar 23, 2011 at 5:03 AM, [Redhosting] Egbert Groot < egbert@redhosting.nl> wrote:
Michael Collins schreef:
I can't/didn't contribute much to this discussion, but I do follow it. My idea and (little) testing experience supports the explanation of Dimitry. Either way, it 'proofs' there is confusion about the working of the 'break' in condition tags. If I can find the time, I will try to do some tests / build an example myself. Thank you both for the answers and insights so far.
Okay, for those of you who have the bridge book, please go to page 167-168. Darren did a really good job of explaining this. For those of you who don't have the book, SHAME! :)
Thanks for the explanation, and I just ordered the book :)
Glad to hear it! Also, it turns out that Darren and I both discuss this in the book. I wrote chapter 5, and I talk about this on page 89. When Packt did the index on the word "break" they got confused because Darren and I used the expressions "break attribute", "break flag", and "break parameter" all referring to the same thing. I have my copy of the book and I write notes on every page where I find something wrong or otherwise needs to be changed. Hopefully if/when we do a 2nd edition of this book we will be more consistent so that the index is more useful. -MC
condition can't be inclusive, only stacked ----- Original Message ----- From: "Dmitry Bely" <dmitry.bely@gmail.com> To: "FreeSWITCH Users Help" <freeswitch-users@lists.freeswitch.org> Sent: Monday, March 21, 2011 6:44 AM Subject: Re: [Freeswitch-users] Understanding break="never" in condition-tag
On Mon, Mar 21, 2011 at 1:01 PM, Avi Marcus <avi@avimarcus.net> wrote:
You need ALL the conditions to match for freeswitch to do the action, and you can't change that!
I don't think so. If some condition evaluates to true, its nested actions are always executed no matter what preceded it. But of course the condition should be evaluated first, that's where various break values come into play.
No way - the dialplan is always run on a "match all conditions" to do the actions! How else would multiple conditions EVER work?
Completely wrong. And I don't see relevant logs in your message. Here is mine. A dialplan fragment:
<extension name="condition-test"> <condition wday="6" break="never"/> <condition hour="9-18" break="on-true"> <action application="info"/> </condition> </extension>
log:
Dialplan: sofia/internal/1000@192.168.121.66 parsing [default->condition-test] continue=false Dialplan: sofia/internal/1000@192.168.121.66 Date/Time Match (FAIL) [condition-test] break=never Dialplan: sofia/internal/1000@192.168.121.66 Date/Time Match (PASS) [condition-test] break=on-true Dialplan: sofia/internal/1000@192.168.121.66 Action info()
Guess what? The first condition fails but the action is still scheduled for execution (and indeed executed later)
- Dmitry Bely
_______________________________________________ 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
Using "on true" or "on false" would stop evaluating the entire extension. This is really best for *nested* extensions as you'll see the two examples on the wiki are for when you want to keep evaluating the extension in it's entirety. -Avi On Sun, Mar 20, 2011 at 2:30 PM, Dmitry Bely <dmitry.bely@gmail.com> wrote:
On Sun, Mar 20, 2011 at 2:10 PM, [Redhosting] Egbert Groot <egbert@redhosting.nl> wrote:
Hi All,
I'm struggling understanding the 'break' attribute in condition tags. Am I correct saying the following condition tag is useless? It doesn't influence the routing/application stack at all. For this example the check is on 'wday', but it could be any other field/expression, my question is about the 'break="never"' part:
<condition wday="1" break="never" />
( though it could be used for clarity or debugging, since it does get evaluated)
It makes sense if you use the form
<condition wday="1" break="never"> (some actions) </condition>
- Dmitry Bely
_______________________________________________ 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
participants (6)
-
[Redhosting] Egbert Groot
-
Anthony Minessale
-
Avi Marcus
-
Dmitry Bely
-
Madovsky
-
Michael Collins