Hunatech Engineering Knowledge base

Ive been administering Asterisk servers for many years and everyday Im learning something new. As the size of the projects have gotten bigger, so have the demands of my customers. One common request is database integration. In the past Ive used external AGI scripts to run database queries to return values to Asterisk. But more recently Ive been avoiding AGI in favor of direct access SQL. This is achieved by building ODBC modules into Asterisk at build time. Let me tell you, its worth it!

Asterisk & ODBC provide the ability to easily update and retrieve data by defining SQL statements as special variables that can be called from the dial plan. For instance, we could bill distance, long distance, take credit cards and let Asterisk access other types of information. In my tutorial we will configure Asterisk to dial a variable that represents a SQL statement. This could also be done by calling an AGI script, but why do the extra work? This How to is specifically geared towards MySQL. MySQL. However, if you set the up the ODBC driver correctly you can use any SQL server you like. Which leads me to my next thought, before you start, make sure ODBC is set up correctly. Follow one of my previous tutorials:

1- Configure Linux ODBC for MS-SQL MS2- Configure Linux ODBC for MYSQL Once youve done this we are ready to continue

- Create MySQL table with example data - Configure res_odbc.conf - Configure func_odbc.conf - Configure extensions.conf for query

We will do this with as much simplicity as possible, once you got the process down you can connect Asterisk to any SQL table you want. Our example will be a list of extensions. Each extension has an ID number. Asterisk will dip the database for a ID. specific extension ID. Below is the data in our example table.

mysql> select * from extensions; +++ | extensionsID | ext | +++ | 1 | 8888 | 2 | 8889 | | 3 | 8890 | | +++ 3 rows in set (0.00 sec)

We must define the DSN for Asterisk. In the /etc/asterisk directory locate res_odbc.conf file and replace it with my example below.

[asterisk] enabled => yes dsn => asterisk-connector pre-connect => yes

The DSN in res_odbc.conf points to the DSN in /etc/odbc.ini, /etc/odbc.ini, which in turn points to a driver configuration file(odbcinst.ini). Please see my file(odbcinst.ini). previous tutorials on odbc! I have links at the top of the page and I strongly suggest you read them. You can view DSNs from the Asterisk DSNs CLI, CLI,

*CLI> odbc show ODBC DSN Settings Name: asterisk DSN: asterisk-connector *CLI>

The func_odbc.conf is the file where we define the SQL statement. This could be doing a database insert or a simple read. we can define special variables so that Asterisk can access dynamic data; without having to call an external AGI script. There are so many situations this could be useful, from emergency call routing to credit card processing. I could for instance, setup an Asterisk PBX at a insurance agency to read Caller ID from incoming calls. Asterisk can match it to a TAPI compliant CRM. CRM. As soon as the insurance agent picks up the phone he can see the customer file. My example will be far more limited in scope.

[TEST] dsn=asterisk readsql=SELECT ext from extensions WHERE extensionsID = 1

This contest defines the variable name we will call in the dial plan. The entry dsn=asterisk refers to the dsn=asterisk res_odbc.conf context asterisk. The readsql= is the readsql= juicy part of this post. Its the rub. This section defines the variable we call in asterisk. When we call this variable it will be named ${ODBC_TEST}. $ ODBC_TEST}.

In fact you must propend ${ODBC_ to every $ variable you define. So for instance we could make a new variable based on the query below,

[A-NEW-TEST] dsn=asterisk readsql=SELECT ext from extensions WHERE extensionsID =3

We would call this variable, $ODBC_A-NEWvariable, $ODBC_A-NEWTEST TEST in the dial plan.

Add a context for out test like this your extensions.conf file,

[ODBC-test] exten => s,1,wait(5) exten => s,n,saydigits(${ODBC_TEST()}) exten => s,n,Dial(SIP/${ODBC_TEST()}) exten => s,n,Voicemail(${ODBC_TEST()}) exten => s,n,hangup

This context will read ${ODBC_TEST()} calls ODBC_TEST()} extensionID database(8888) extensionID 1 from the database(8888) and use this variable with three separate Asterisk apps.

mysql> select * from extensions; +++ | extensionsID | ext | +++ | 1 | 8888 | | 2 | 8889 | | 3 | 8890 | +++ 3 rows in set (0.00 sec)

In this tutorial we demonstrated how to call a variable from a SQL database. This saves much time from developing AGI and PHP for a function already built-in to Asterisk! I used builtthis same method to create a calling card application last weekend without a sing external script! The SQL database doesnt need to reside on the Asterisk; giving you another option to reduce overhead by relocating your Asterisk SQL database to another server. I hope this tutorial helps someone out there! take care.

Method 1: MS-SQL MS-

Last week at work(VoiceIP Solutions) I did work(VoiceIP Solutions) some research for Asterisk PBX integration with Microsoft CRM. The customer likes CRM. open source Asterisk because of the cost savings, but they requires screen pop-ups, popand click to dial from their Customer Relationship Management software. So while my manager worked on the TAPI middleware, I was charged with figuring out how to connect to the MS SQL database.

This article was prompted by a desire to connect an SQL, Asterisk PBX to MS SQL, but the tutorial applies to Apache, Postfix, CRM, PHP or any Linux app that CRM, needs to do a remote query. Also, while the focus of this article is aimed at MS SQL the same steps(with a few tweaks) can be used for connecting PostgreSQL, MySQL, to PostgreSQL, Sybase, MySQL, etc Im a lot more familiar with MySQL & PostgreSQL, but MS SQL I havent touched since I had the silly notion about 10 years ago to become a Windows 2000 MCSE. Incidentally, I never did take the exams, because I was a broke student at the time and I was becoming increasingly interested in Linux and Cisco.

The logical choice is to use the UNIX ODBC driver. ODBC stands for Open Database Connectivity. ODBC is a well documented set of APIs that is available on many platforms. However, their are subtle differences in its implementation and the protocols that run at application layer. In other words ODBC is encapsulated when making calls to a database over a network (in this case, the TDS protocol).

I did some googling and found a number of incomplete tutorials for connecting Linux to MS SQL. This article is intended to clarify some common configuration errors and will present you with example files. For my demonstration Im running Fedora 10 with the latest updates as of this writing. This article assumes you have a working MS SQL database with the proper user permissions in mixed mode. I put this one in bold because it mode. stumped the MCSE database guy for a while. Again, I want to point out Im not a Microsoft DBA and will likely not be able to help you on that side of the configuration. Also, there are many versions of SQL out there and the syntax to pull data differs slightly from one version to the next. So you may need to do a little research to make the proper pulls.

- install ODBC and TDS on Fedora 10 - verify TDS can login into MS SQL server - configure (the configuration files):

odbcinst.ini, odbcinst.ini, odbc.ini and freetds.conf

We will start by using yum to install the necessary packages. All the necessary packages should be available in the Fedora/Ubuntu Fedora/Ubuntu repositories

[root@mattop1 ~]# yum list unixodbc* Loaded plugins: refresh-packagekit Installed Packages unixODBC.i386 2.2.12-9.fc10 unixODBC-devel.i386 2.2.12-9.fc10

installed installed

[root@mattop1 ~]# yum list freetds* Loaded plugins: refresh-packagekit Installed Packages freetds.i386 0.82-4.fc10 freetds-devel.i386 0.82-4.fc10 freetds-doc.i386 0.82-4.fc10

installed installed installed

After these packages are installed we should be able to use freetds to test authentication network authentication with the MS SQL server. If you cant authenticate there is no point in going to the trouble to configure ODBC. If you get errors check ODBC. the MS SQL logs on the Windows server. By default remote terminal connections are turned off. So remember to turn your MS SQL server to mixed mode, and restart the service. Then create a windows user with permissions to access the database. Now TDS is ready to go!

[root@mattop1 ~]# tsql -S your.server.com -p 1433 -U WINDOWS-SQL-USERNAME -P PASSWORD locale is en_US.UTF-8 locale charset is UTF-8 1>

If you made it this far you are just a few steps away from success. Our last task is to configure the freetds.conf, odbc.ini, and the odbcinst.ini. Many help articles on the web suggest using the ODBCConfig ODBCConfig utility. Dont waste your time! Again I resort to using bold! The ODBCConfig utility sucks. The interface takes more time to explain than just manually editing the files.

Now that we have avoided this pitfall we can get to business. Launch your favorite text editor and open the /etc/odbc.ini file. On Fedora/Red Hat systems this would be the /etc/ directory.

the Driver field refers to /etc/odbcinst.ini context named [ms-sql]. The driver [ms-sql]. information is pulled from that file. The Servername field refers to the Servername /etc/freeItds.conf /etc/freeItds.conf context that I also named [ms-mysql]. [ms-mysql]. This threw me off for a couple days, as many posts online fail to mention this. If either of these are lines in odbc.ini are misconfigured you will see an error like this:

[root@mattop1 ~]# isql -v odbc-test Your-Username YourPassword [IM002][unixODBC][Driver Manager]Data source name not found, and no default driver specified [ISQL]ERROR: Could not SQLConnect [root@mattop1 ~]#

Now we have to define the location of the ODBC drivers in the /etc/odbcinst.ini file. Keep in odbc/tds mind that actual path of the odbc/tds drivers may differ between Linux distros. distros.

The odbcinst.ini file simply directs the odbc.ini file to the appropriate driver. Above you can see that I have an entry for Postgre and MS SQL. Our last Step is to configure the freetds.conf file. Freetds is the open source version of the Tabular Data System protocol. TDS is the application layer protocol to connect ODBC over networks. Different SQL server may require a different version of the freetds protocol. This doesnt require a different software package, you can specify in the /etc/freetds.conf file what version to use. In most cases tds version = 7.0 should work. See tds below.

[root@mattop1 ~]# isql -v odbc-test VIPS P@ssword1234 | Connected! | | sql-statement | help [tablename] | quit | | | | | | |

++ SQL>

With a little luck, you should get the MS SQL CLI. Just a reminder, the odbc-test portion of odbcthe isql command was defined in the odbc.ini file. The isql command can now be added to any script(PHP, BASH,etc) for dipping into a database. I hope this helps someone else please comment if you have any suggestions or questions.

/etc/odbc.ini /etc/odbcinst.ini /etc/freetds.conf

Other Useful Links:

http://www.linuxjournal.com/article/6636 http://freetds.org/ Of course the links would be dead you can search on internet snapshot and just start new keywords on a nice search engine like Google Go

A few weeks back I covered connecting ODBC to MS-SQL, but today we are going MS-SQL, MySQL. to do the same thing with MySQL. The process is very similar. One might ask, why use ODBC driver in the first place? The reason is simple, there are many flavors of SQL and the ODBC driver allows one standard to connect them. For that reason many software developers use ODBC for SQL. connecting their applications to SQL.

A few weeks back I covered connecting ODBC to MSMS-SQL, but today we are going to do the same thing with MySQL. The process is very similar. One might ask, why use ODBC driver in the first place? The reason is simple, there are many flavors of SQL and the ODBC driver allows one standard to connect them. For that reason many software developers use ODBC for connecting their applications to SQL. For my purposes, the Asterisk PBX platform can use ODBC to call dial plan functions from the database, but that is another article! This post assumes you have a working MySQL server and at least one table with data to pull from.

- Install ODBC driver for MySQL - configure odbc.ini - configure odbcinst.ini - verify connectivity with isql

To start we need to install the proper packages. Use yum or the Add/Remove Packages tool to install unixODBC and mysql-connectormysql-connector-odbc packages. Once this is ready open the odbcinst.ini. Comment out the Postgre SQL stuff with # and uncomment the MySQL example.

# Example driver definitinions # # Included in the unixODBC package #[PostgreSQL] #Description = ODBC for PostgreSQL #Driver = /usr/lib/libodbcpsql.so #Setup = /usr/lib/libodbcpsqlS.so #FileUsage = 1 # # # Driver from the MyODBC package # Setup from the unixODBC package [MySQL] Description = ODBC for MySQL Driver = /usr/lib/libmyodbc.so Setup = /usr/lib/libodbcmyS.so FileUsage = 1

One thing to note, libmyodbc.so does not ship on Fedora 10. If you do a search, you will find /usr/lib/libmyodbc3.so a driver called /usr/lib/libmyodbc3.so If you use Fedora 10 make sure to replace Driver = /usr/lib/libmyodbc.so /usr/lib/libmyodbc.so with Driver = /usr/lib/libmyodbc3.so. /usr/lib/libmyodbc3.so. Otherwise isql will complain, it cannot find the driver when you attempt to connect. Remember, there are many versions of SQL and many different ODBC drivers to connect them.

# Driver from the MyODBC package # Setup from the unixODBC package [MySQL] Description = ODBC for MySQL Driver = /usr/lib/libmyodbc3.so # < note the 3 missing from default example file Setup = /usr/lib/libodbcmyS.so FileUsage = 1

The odbcinst.ini file lets the user specify as many different drivers as he wants. Say, you had a Microsoft MS-SQL server that stored MSvoicemail for Asterisk. That same Asterisk server could query for its dial plan from an internal MySQL database with a different ODBC driver. Below is a example of an Asterisk phone system that stores voicemail on MS-SQL and MSqueries MySQL for dial plan.

# Driver from the MyODBC package # Setup from the unixODBC package [MySQL] Description = ODBC for MySQL Driver = /usr/lib/libmyodbc3.so Setup = /usr/lib/libodbcmyS.so FileUsage = 1 # # [ms-sql] Description = TDS connection Driver = /usr/lib/libtdsodbc.so Setup = /usr/lib/libtdsS.so UsageCount = 1 FileUsage = 1

Next, we need to configure the /etc/odbc.ini. This file contains parameters for ODBC connections - such as, user name, password, database and host. Each application that requires a odbc connection can have its own entry or share one. The following I have defined a database for Asterisk to connect on the localhost.

[asterisk-connector] driver = MySQL Database = asterisk Server = localhost Socket = /var/lib/mysql/mysql.sock User = odbctest Password = koala1

Our final task is to utilize the isql isql command to connect to our MySQL database. isql will call on the specified profile stated in the /etc/odbc.ini file. In the /etc/odbc.ini case below we are calling on: [asterisk-connector]. asterisk-connector]

[root@localhost ~]# isql -v asterisk-connector ++ | Connected! | | | | sql-statement | | help [tablename] | | quit | | | ++ SQL> show databases; ++ | Database | ++ | information_schema | | asterisk | | test | ++ SQLRowCount returns 3 3 rows fetched SQL>

[MYODBCUtilReadDataSource.c][233][ERROR] MYODBCUtilReadDataSource.c][233][ERROR] Unknown attribute (Servername) (Servername) or [MYODBCUtilReadDataSource.c][233][ERROR] MYODBCUtilReadDataSource.c][233][ERROR] Unknown attribute (Username) (Username) These errors will pop up when you use the wrong directives in odbc.ini. For instance a Google search will odbc.ini. show examples like, UserName = <mysql user>, when user>, User the mysql ODBC driver is expecting, User = <mysql user>. user>. Likewise, ServerName should be Server. It may be Server. that other versions of this driver expect different names not sure, but something to think about if you see a similar error.

I hope this quick tutorial helps someone. Im posting my configuration files as well:
/etc/odbcinst.ini /etc/odbc.ini