Telephony Integration in Distributed Call Centers

Foreword

This article is devoted to the issue of integrating CRM systems with Asterisk-based telephony servers.
The article does not address issues related to setting up an Asterisk server or the nuances of CRM systems, only general options for organizing interaction with all their pros and cons are considered.

Introduction

How companies “get to” developing CRM “for themselves” and their own telephony is a political and business question rather than a technical one, therefore I can’t give answers to the questions “why”. But the fact remains - one fine day we needed a solution capable of ensuring the interaction of the telephone part with CRM.

Initial data:

• 2 call centers (hereinafter - KC) at a great distance (one in the Russian Federation, the second, say, in Estonia)
• about 500 simultaneously working operators in each (incoming and outgoing calls)
• one entry point (for simplicity, consider that there is only one CRM server)
• both KC process calls in the Russian Federation
• each KC has its own Asterisk server (for simplicity, we assume that all Asterisk are configured in fully working mode)
• CRM is a client-server application with a web-muzzle

What had to be done:

• to provide operator interaction with telephony from one entry point, i.e. from the operator’s working interface
• receive data about calls from Asterisk (call duration, call duration, status, etc.)
• ensure sufficient stability of the telephony (various aspects of "stability" will be discussed later)

Implementation options

WebRTC / Web-SIP

The first thing that came to mind was the implementation of the “dialer” directly in the browser (we remember that interaction with CRM is carried out through the web interface). And here just the WebRTC specification arrived in time with plug-ins for popular browsers.
The idea is undoubtedly good, but not suitable for business due to the fact that when we freeze / close the browser or refresh the page, we lose the connection, the call and the client.
For the same reasons, none of the "classic" SIP web clients was selected.

SIP Phone + AGI + Web Socket

The idea with a separate SIP phone has an obvious advantage for business - in almost any unforeseen situation we save a call. There are difficulties in ensuring interaction with CRM, however, this is a solvable task.

It remains to teach the siphon to call from the operator interface.

Tell me, how to make the siphon on the computer make an outgoing call from the browser? No way? That's right.
That is why we began to send the asterisk command through the AGI interface, by which he organized an outgoing call to the subscriber, and then connected to the operator’s channel. So for the siphon, the outgoing call became an incoming call with the auto answer command from the telephony server.

Everything became good, the operator started working with a certain essence of the CRM system (for simplicity we call it “Call”), then a command to initiate an “outgoing” call through agi was sent manually or automatically, and at the end of the call asterisk sent us information about the call (options a lot, from a GET request to a WebSocket).

The implementation phase of outgoing telephony in Russia was not without roughness, but rather successfully, after which it was necessary to start working with incoming calls.

It remains to teach the operator to accept an incoming call from the interface, and not through a siphon.

Then I already had to start working on Asterisk directly with the browser, at least until the call was successfully received, as a result of which the Web Socket server appeared on the telephony server.
Thus, the information about the incoming call to the operator went directly to the browser, and the rest of the commands went to Asterisk through the CRM server and then through the AGI interface.

The decision to organize telephony management through the CRM server was associated with the following requirements:

• Security. We did not want to show the operator in which queues he is registered, what is the current status of the call. The operator does not make decisions, so for him enough information you can work or not.
• One entry point. Manage all telephony servers from one point, consolidate information here and now.
• Synchronous receipt and processing of data. The state of the interface is known before sending data to the operator (in the browser).

The above scheme worked quite well in Russia, however, when the KC in Estonia began making calls through the CRM system, we found a large number of problems with calls caused by the incorrect operation of AGI. Packages from Estonian Asterisk did not reach our CRM server, as a result of which we did not receive any information about the execution of the command, we did not know if the team reached at all.

A week later, it became obvious that the situation would not improve, we could not affect the quality of communication between the Russian and Estonian servers, as a result of which a strong-willed decision was made to completely switch to telephony management via Web Socket.

A week later, we got a working scheme, where each Asterisk had its own Web Socket server, with which the operator’s browser contacted within the same local network. The CRM server as it was, and remained in the Russian Federation.

Thus, the communication of the operator interface with the telephony server occurs within the same local network without delays and all telephony management commands and events are sent and come back to the operator’s browser.
The interaction of CRM and telephony takes place directly through callbacks from Asterisk and indirectly through asynchronous requests from the operator panel.

Total

1. Implementation of integration only through AGI is possible if it is necessary to ensure the operation of a small CC within the same local network only on outgoing calls.
2. The combined version with AGI + Web Socket is most likely to be suitable if, in addition to the previous paragraph, there is a need to receive incoming calls.
3. The option on a “clean” Web Socket remains the only possible one, while ensuring the functioning of distributed data centers within several countries or regions, you will not get an ideally stable connection even with 2-3 backup channels due to the fact that the Asterisk AGI interface works stably enough only in within local connections (on the same machine), worse within the same local network and very bad in all other cases. The Web Socket server just works on the machine with Asterisk precisely because in this way we do not lose packets, we do not break the connection.

PS Unfortunately, the Chukchi is not a very artist and does not have enough free time to draw general patterns of interaction right now, but promises to do so if readers are interested in the issues raised in the article.