Asterisk func_odbc or weird ael
Based on the results of the voting in the group, I begin the series of articles “Asterisk realtime” and the first article will be devoted to func_odbc or how to simplify my life.
The article is intended for people who already use asterisk and have "basic" skills.
And so why should I use Function_ODBC if I can make the same request in ael?
Otherwise, if you are comfortable with a house in the configuration, as well as writing or copying one request several times, then this article is not for you. For the rest, let's proceed:
We will consider the simplest example asterisk + mysql.
So we have sipuser (many sipusers) and they have an external cid number, which for reasons independent of us is constantly changing, and we need to ask it every time.
Second example: we need redirects.
We skip the odbc.ini and res_odbc.conf settings, as you already know how to do this.
We proceed to step 1:
We write in func_odbc.conf the following
And disassemble in parts
Now let's see what we got in ael:
Actually further your imagination in requests and variables.
Getting to Step 2:
Add func_odbc.conf
It should be noted that in this answer we get an array.
Now let's see what we got in ael:
Here, for re-addressing, I decided that it is more convenient to use macros
I intentionally missed the redirection configurations, as everyone can have it differently.
PS: This is certainly not realtime. But the bottom line is that you get some of the parameters at the right time during a specific call, and you do not need to go into the config to change cid and do reload to change cid.
PPS: besides readsql, there is writesql that works on the same principle.
The article is intended for people who already use asterisk and have "basic" skills.
Func_odbc why is it?
And so why should I use Function_ODBC if I can make the same request in ael?
- in extensions.ael it looks “tidier” if your request is repeated several dozen times in the configuration
- more convenient to work with multiple databases
Otherwise, if you are comfortable with a house in the configuration, as well as writing or copying one request several times, then this article is not for you. For the rest, let's proceed:
Func_odbc.conf
We will consider the simplest example asterisk + mysql.
So we have sipuser (many sipusers) and they have an external cid number, which for reasons independent of us is constantly changing, and we need to ask it every time.
Second example: we need redirects.
We proceed to step 1:
We write in func_odbc.conf the following
[cid]
dsn=asterisk
readsql=SELECT cid FROM sipusers WHERE username = ${ARG1}
And disassemble in parts
dsn=asterisk
- The DSN parameter is responsible for connecting Asterisk to the database specified in the /etc/odbc.ini file. readsql=SELECT cid FROM sipusers WHERE username = ${ARG1}
- sql query you need, but with a variable. Now let's see what we got in ael:
_89. => {
Set(cid=${ODBC_cid(${CALLERID(num)})});
SET(CALLERID(num)=${cid});
SET(CALLERID(name)=${cid});
......
}
Set(cid=${ODBC_cid(${CALLERID(num)})}); - собственно это SELECT cid FROM sipusers WHERE username = ${CALLERID(num)})} , думаю пояснения излишни.
SET(CALLERID(num)=${cid}) - устанавливаем CALLERID(num)
SET(CALLERID(name)=${cid}) - CALLERID(name)
Actually further your imagination in requests and variables.
Getting to Step 2:
Add func_odbc.conf
[forward]
dsn=asterisk
readsql=SELECT numforward, `type` FROM call_forwarding WHERE number = ${ARG1}
It should be noted that in this answer we get an array.
Now let's see what we got in ael:
macro redirect(number, from){
Set(ARRAY(forward,type)=${ODBC_forward(${number})});
}
if (${EXISTS(${forward})}) {
switch(${type}) {
case all:
....
case noanswer:
....
case noanswer-worktime:
....
break;
default:
break;
}
hangup;
}
return;
};
Here, for re-addressing, I decided that it is more convenient to use macros
Set(ARRAY(forward,type)=${ODBC_forward(${number})});
- we get two parameters from the request, therefore, we need to use an array. if (${EXISTS(${forward})})
- if there is a forwarding number, then proceed further ... switch(${type})
- we determine the type of forwarding and depending on the type you need, we make the conditions for forwarding. I intentionally missed the redirection configurations, as everyone can have it differently.
PS: This is certainly not realtime. But the bottom line is that you get some of the parameters at the right time during a specific call, and you do not need to go into the config to change cid and do reload to change cid.
PPS: besides readsql, there is writesql that works on the same principle.