Telephony integration in distributed call centers

Foreword

This article focuses on the integration of CRM systems with Asterisk-based telephony servers.
The article does not address issues related to the configuration of the Asterisk server or the nuances of the CRM-systems, only general options for organizing interaction with all their pros and cons.

Introduction

How companies “reach” to the development of CRM “for themselves” and their own telephony is a political and business rather than technical question, so I can’t give answers to why. But the fact remains that - one day we needed a solution that could ensure 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, let's say, in Estonia)
• about 500 simultaneously working operators in each (incoming and outgoing calls)
• one entry point (for simplicity, assume that the CRM server is only one)
• both CC handle calls in the Russian Federation
• each CC has its own Asterisk server (for simplicity, we will assume that all Asterisk are configured and in fully working mode)
• CRM is a client-server application with a web-muzzle

What should have been done:

• provide operator interaction with telephony from one entry point, i.e. from the operator's working interface
• receive call data from Asterisk (call duration, call duration, status, etc.)
• ensure sufficient stability of telephony operation (various aspects of “stability” will be discussed further)

')

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 just here the WebRTC specification arrived with plugins for popular browsers.
The idea is undoubtedly good, but not suitable for business due to the fact that when the browser hangs / closes or the page is refreshed, we lose connection, call and client.
For the same reasons, none of the “classic” SIP web clients was selected.

SIP Phone + AGI + Web Socket

The idea of ​​having a separate SIP phone has an obvious business advantage - in almost any unforeseen situation, we save the call. There are difficulties in ensuring interaction with CRM, but this is a solvable problem.

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

Tell me, how to make a siphon on a computer make an outgoing call from a browser? None? Exactly.
That is why we began to send a command to an asterisk 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 incoming with the auto answer command from the telephony server.

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

The stage of introducing outgoing telephony in Russia was not without its roughness, but rather successfully, after which it was necessary to begin work with incoming calls.

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

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

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

• Security. We did not want to show the operator what queues are being registered in it, what is the current status of the call. The operator does not make decisions, so for him enough information can work or not.
• One entry point. Manage all telephony servers from one point, consolidating information "here and now."
• Synchronous data acquisition and processing. 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 CC in Estonia began to make 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 team, did not know if the team reached it at all.

After a week 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 decision was made to completely switch to managing telephony via the Web Socket.

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

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

Total

1. The 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 suitable if, in addition to the previous paragraph, there is a need to receive incoming calls.
3. The option on the “clean” Web Socket remains the only possible option, while ensuring the operability of distributed CCs within several countries or regions, you will not get a perfectly stable connection even with 2-3 backup channels due to the fact that Asterisk’s AGI interface works only stably at local connection limits (on the same machine), worse within the same local network and very bad in all other cases. The Web Socket server is exactly what works on the Asterisk machine exactly because in this way we do not lose packets, do not break connection.

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