Asterisk and CTI, what’s that all about??

Asterisk is a wonderful piece of software, doing all the magical stuff you can imagine with VoIP, including –but not limited to– IVR, call queues, routing, billing, trans-coding, registrar, and much more…

One of the most advanced features in asterisk and is generally overlooked, and taken for granted, is the asterisk manager interface (AMI for short), this gives rise to a whole new dimension for applications to integrate with Asterisk, using CTI…

CTI is just a terminology, it stands for Computer Telephony Integration, there’s no special piece of software you can call CTI, any application that can integrate with a VoIP system, this integration can be called CTI…

However, CTI usually refers to call management from within the application, adding extensions to queues, removing them, initiate calls, transfer calls…

You might think and say “any SIP phone can do this”, I’m not talking about making a call, and receiving it, I’m taking about application integration…

Asterisk provides an interface called manager interface, upon connecting and authenticating to it, asterisk would send you about events, and you can send commands to it…

Examples always explain better than just talking…

Take this simple scenario – Timesheet application

In a call center, or a support department, a timesheet application, where in the morning the user signs in, and signs out when he finishes work…

During employee signing in, the application can inform the VoIP PBX to add the user’s extension to the call queue, and then he’s ready automatically to receive calls, when he signs out, the application can inform the PBX to remove the user’s extension from the call queues, so no more calls is routed to it…

In this simple scenario, the application looks up the user’s extension from its DB, sends a request to add the extension to a predefined call queue to asterisk’s manager interface using APIs, or even via telnet…

A bit more complex scenario – CRM

In the CRM’s DB, each user (CSR – Customer Service Representative) is associated with an extension, upon CSR’s login to CRM, the application binds to asterisk to listen to events related to this extension…

Upon receiving a call, Asterisk would send a notification to the application telling it that extension X is ringing, and the caller ID is (yyy)-zzz-zzzz…

The application would look up its DB of customers, and display all information needed about this customer calling from this caller ID, this would give a better overall customer experience and makes CSR’s life much easier…

When the CSR logs off the application, the application stops listening for events…

One more complex system – Directory

This is a real life application, used in lots of call centers and phone operators…

When the CSR login to the application, the application looks up the languages this CSR can talk, and his extension from its DB…

The application would add the CSR’s extension to the queues of the languages he can speak…

When the CSR’s phone rings, the application will receive notification from asterisk telling it the caller ID of the calling party, and the queue the call came from, which is translated into the language requested by the customer…

The application looks up its DB of customers, and displays the following information, client number, client name, address (if possible), and the language the customer expects to hear…

After the call finishes, the CSR might still need to do some work for the customer, so it won’t be a good idea to receive a call right away, so the application removes extension from the call queues temporarily, until the CSR presses “Ready”…

Upon pressing “Ready”, the application adds the extension again into the call queues of the languages the CSR speaks…

Yet another more complex example – Roaming profiles

In the previous examples, it was assumed that the CSR always uses the same extension, and everyday goes to the same desk, using the same phone…

In fact the CSR can have some sort of free seating, in this case the extensions are bound to the machines’ MAC addresses (or IPs if you like), and the CSRs are bound to languages…

During login, the application reads the machine’s MAC, and obtains the associated extension (X for example), and the CSR’s login with the language he speaks (Arabic and English)…

And sends request to asterisk to add extension X to the Arabic and English queues…

Enhancing the performance and security

Assuming that you have a 100 CSR, this will mean a 100 connections to asterisk, all using the same manager username/password, not to mention that the traffic passes unencrypted, this would likely to cause load on asterisk machine, and could lead to several problems…

So my suggestion is to create some middle layer between the application(s) and asterisk, let’s call it CTI server, this CTI server will only create one connection to asterisk and listen to all events, this CTI server can then have its own authentication DB, or any other global authentication DB…

The CTI server can also store the events received from asterisk into DB for future processing and/or archival…

Each application logs into the CTI server with its own credentials, CTI server will authenticate the connection and authorizes it, and only sends back the events that related to this specific connection…

An admin CTI application can manage the call flows through this CTI server, gather statistics, create reports, etc etc etc…

The bottom line

If you really think about it, you’ll find it quite easy to understand and fairly easy enough to implement esp. if you know that there’re APIs and libraries available for almost all programming languages, including JAVA, PHP (another implementaion), .NET connector and more…

For more information on Manager API…

Also the guys here did quite a good job creating CTI integration from vTiger CRM…

Also an implementation for CTI server and CTI client…

Hope you find this useful…