asterisk 表达式应用:
cp from this link:
http://www.voip-info.org/wiki/view/Asterisk+Expressions
Asterisk dialplan expressions are special expressions that can be used in the dialplan of Asterisk.
$[expr1 operator expr2]
Since most user input will come via config files to Asterisk, some filtering and substitutions are done
as the config files are read.
Next, as the dialplan is executed, the ${ ... } variables and functions are evaluated and substituted.
And lastly, the contents of $[ .. ] expressions are evaluated and substituted.
In 1.6 and above, we upgraded the $[] expressions to handle floating point numbers. Because of this, folks counting on integer behavior would be disrupted. To make the same results possible, some rounding and integer truncation functions have been added to the core of the Expr2 parser. Indeed, dialplan functions can be called from $.. expressions without the ${...} operators. The only trouble might be in the fact that the arguments to these functions must be specified with a comma. If you try to call the MATH function, for example, and try to say 3 + MATH(7*8), the expression parser will evaluate 7*8 for you into 56, and the MATH function will most likely complain that its input doesn't make any sense. We also provide access to most of the floating point functions in the C library. (but not all of them).
While we don't expect someone to want to do Fourier analysis in the dialplan, we don't want to preclude it, either.
Here is a list of the 'builtin' functions in Expr2. All other dialplan functions are available by simply calling them (read-only). In other words, you don't need to surround function calls in $... expressions with ${...}. Don't jump to conclusions, though! - you still need to wrap variable names in curly braces!
THE DOCUMENTATION ABOVE FOR REGULAR EXPRESSIONS IS WOEFULLY INADEQUATE. The problem seems to be that the regular expression syntax conflicts with Asterisk expression syntax. As a result, one must backslash escape anything which looks like it might be an expression operator. Also, contrary to what is suggested above, it does not seem to be necessary to backslash escape the parentheses.
Here is one example that works:
exten => stripcidtext,n,Set(regx="([0-9]+)") ; Note the quotes -- and note that parentheses are REQUIRED if you want to return the matched string
exten => stripcidtext,n,Set(cid2=$["${cid}" : ${regx}]) ; Returns numeric beginning to string
So if ${cid} contains 123foo then ${cid2} will contain just 123.
However, if ${cid} contains foo123 then ${cid2} will be empty. Supposedly you could use =~ instead of : and the string matching would work anywhere, but I don't think that works correctly (at least, I could not get =~ to work).
Here is another example:
exten => s,n,Set(enum-protocol=$["${enum-record}" : "([a-zA-Z0-9]/+)/:"])
If enum-record contains "sip:[email protected]", then this command will set enum-protocol to "sip".
Parentheses are used for grouping in the usual manner.
There are now several conditional applications-- an example is the conditional gotoIf :
exten => 1,2,GotoIf,condition?label1:label2
If condition is true go to label1, else go to label2. Labels are interpreted exactly as in the normal goto command.
"condition" is just a string. If the string is empty or "0", the condition is considered to be false, if it's anything else, the condition is true. This is designed to be used together with the expression syntax described above, eg :
exten => 1,2,GotoIf,$[${CALLERID} = 123456]2|1:3|1
After the sequence:
exten => 1,1,SetVar(lala=$[1 + 2]);
exten => 1,2,SetVar(koko=$[2 * ${lala}]);
the value of ${koko} is "6".
This next pages example is :
Conditional goto
GotoIf(condition?label1[:label2])
GotoIf(condition?context1,extension1,priority1:context2,extension2,priority2)
Go to label1 if condition is true or to next step (or label2 if defined) if condition is false, or
GotoIf(condition?[label1]:label2)
Go to next step (or label1 if defined) if condition is true or to label2 if condition is false.
Either label1 or label2 may be omitted (in that case, we just don't take the particular branch), but not both.
condition is just a string. If the string is empty or "0", the condition is considered to be false. If it is anything else, the condition is true. This is designed to be used together with expression syntax.
Labels take the form '[[context,]extension,]priority', so they can be (a) a priority, (b) an extension and a priority, or (c) a context, an extension and a priority. This is the same syntax as for the Goto command.
exten => 206,1,GotoIf($["${CALLERID(num)}" = "303"]?dial1) exten => 206,n,GotoIf($["${CALLERID(num)}" != "304"]?moh:dial2) exten => 206,n(dial1),Dial(${SPHONE1},15,rt) exten => 206,n,Hangup() exten => 206,n(dial2),Dial(${PHONE2},15,rt) exten => 206,n,Hangup() exten => 206,n(moh),MusicOnHold(default)
20050427 - Note that ${CALLERID(num)} can contain spaces (e.g. "No CID available" from some Zap channels), and the example above has been corrected to cope with this situation - without the quotes around ${CALLERID(num)} it doesn't work!
; Are the first three digits of the returned value of ${ENUM} are ; either SIP or IAX? If not, we ignore and pass to normal ; dialing path at priority 4. ; exten => _011X.,2,GotoIf($[$["${ENUM:0:3}" = "SIP"] | $["${ENUM:0:3}" = "IAX"]]?3:4)
; This example checks for blank caller ID or 800 numbers. ; Callers from 800 numbers (usually telemarketers) or those ; with no caller ID are asked to press 1 to speak with me. exten => s,1,NoOp(${CALLERID}) ; log callerID string ; check for callerID. If none, make them hit 1. exten => s,n,GotoIf($["${CALLERID(num)}" = ""]?1000) ; If 800 number, make them hit 1. exten => s,n,GotoIf($["${CALLERID(num):0:3}" = "877"]?1000) exten => s,n,GotoIf($["${CALLERID(num):0:3}" = "800"]?1000) ; OK, we have valid caller ID and it's not an 800 number. ; Let's ring our phones now: exten => s,n,Dial(SIP/604&SIP/602,25,tr) exten => s,1000,Background(press1tospeaktome)
in func_odbc.conf:
[ISLOCAL]
dsn=foo
read=SELECT COUNT(*) FROM localexchanges WHERE prefix='${ARG1:0:6}'
in extensions.conf:
exten => _011-1-NXX-NXX-XXXX,1,GotoIf(${ODBC_ISLOCAL(${EXTEN:4})}?${EXTEN:4},1:${EXTEN:3},1)
It is worthwhile adding a test for null values, even though modern versions of Asterisk and/or Bison are known to work,
It seems that some still require a hack to test for null values:
For example, assume that the function CALLERID(num) returns an empty string
GotoIf($[${CALLERID(num)} = 123456789]?3:2)
will cause an error. Instead, use either
GotoIf($[foo${CALLERID(num)} = foo123456789]?3:2)
or
GotoIf($["${CALLERID(num)}" = "123456789"]?3:2)
Note that if CALLERID(num) contains a space, the first alternative (foo${CALLERID(num)}) will fail with an error. The use of speech-marks ("") is therefore the recommended method.
Likewise you might want to add a leading 0 if you need to perform a numeric comparison:
$[0${GROUP_COUNT(numcalls)} > 40]
Also, the use of spacing is very important if you're not using quoted values on both sides of the comparison. So, when testing characters 2 and 3 of ARG1 when ARG1 = "u6432" :
; will correctly evaluate to false (and carry on at step 3): exten => s,2,GotoIf($[${ARG1:1:2} = 61]?6100) ; will always evaluate true (and wrongly jump to step 6100): exten => s,2,GotoIf($[${ARG1:1:2}=61]?6100) ; will complain about a mismatched number of characters in ; the comparison (notice the space), thus: exten => s,2,GotoIf($[${ARG1:1:2} =61]?6100)