A happy ending story: Bitrix24 integration with Asterisk

Today, the integration of CRM and telephony is vital. If the client listens for an automatic greeting for too long or you do not call back on the application they left on the site, you will lose it.

As we, the integrator informUnity , we came to the creation of a mass product for the integration of "Bitrix24" and Asterisk running FreePBX, and what came of it - under the cut.

Prehistory

By the end of 2016, we had an almost ready solution for contact centers based on the boxed “Bitrix24” and Asterisk. Practically - because the SIPML5 fork used to process WebRTC in the browser has not yet been debugged.
')
We have already planned final testing and launch of the replicated product, when telephony support appeared in December in the REST API Bitrix24. And along with it, colleagues needed to integrate Asterisk and Bitrix24 with the help of new REST methods.

In the meantime, the need for such integration is overdue. The bundle through VoxImplant included an extra link, demanded “dances with a tambourine” in the tuning and deprived the “asteriskers” of freedom. Since part of the call processing logic together with SIP traffic was sent to the external system.

We decided that the contact centers would wait. We carry out a specific order. According to the results of which we are preparing an integration product for everyone.

MVP

It turned out that colleagues used as many as three Asterisk:

• one with custom contexts
• two connected to the first

This made it difficult in essence to have a simple task:

• identify responsible
• open card
• record a call to CRM

Really simple - you say. Hour on four work. So it is: if you write for yourself, then you can limit yourself to the scenarios you need. But any step to the side adds another four hours. However, we did for everyone. So our goal is not an easy path for a developer. And the easy way for the user.

The solution is based on the FreePBX v.13 framework. It is the most popular among analogs today. Actively developing and includes everything necessary for our decision.

We designed the main part as a module for FreePBX.

Pros of the thirteenth version of FreePBX:

• modern interface
• convenient alerts when configuring the module
• AJAX support and
• simple process of updating a module with changing the structure of tables

The most important thing for the module to work is to determine the appropriate contexts for integration. After all, each client has its own call processing scheme.

Today, the main work goes with ext-did-001, ext-did-002 and macro-dial-one contexts for incoming calls and outrt-, macro-dialout-trunk - for outgoing.

In two months, Asterisk and Bitrix24 were integrated. CRM "Bitrix24" is now watching with an all-seeing eye for incoming and outgoing calls.

We got a lot of experience in the course of working together. Numerous discussions of different scenarios were not in vain. And some bug reports closed during the day. By the end of March, we had a product that we could already give to the application directory with a “beta” mark.

First results

Creating MVP, we focused on simple and transparent logic. For example, the time of the beginning and end of a call is tied to the external subscriber channel (for incoming - the first opened channel, for outgoing - the channel where the called number is located). The MVP backlog does not include support for Ring Groups and FollowMe. But this did not affect the functionality, as they are replaced with Queues.

The result was not long in coming: from the first days we get 15–20 installations per day. For us, this was a hypothesis test. The first beta was a fairly raw MVP. Therefore, this result gave us strength and confidence. And along with confidence came a flurry of questions on the first line.

With user care

Most Asterisk installations are cut off from the world and work quietly for NAT. Nevertheless, getting dozens of questions from system administrators on how to configure the Firewall for integration was quite surprising.

“ Port forwarding? Of course you heard. And what to forward? Where? What for? ".

The problem was not in the qualifications of users. And in the presentation of information. And amendments to the instructions here will not get off. Such questions practically ceased after processing the interface.

It is considered that the sysadmin does not care which interface to work with. This view has not stood the test of practice. It doesn't matter if the user is a sysadmin or a housewife. The simpler and clearer the interface, the more loyalty to the application. At the same time, making the interface simple is incredibly difficult. Especially with regular changes. During the beta testing period, we tried to release at least one update per week.


Module interface evolution

Every week new functionality was added, the internal logic was changed. The product developed incredibly fast. The analyst collected during the week became irrelevant with the release of the new version. Sometimes technical innovations outpaced changes in the interface. Then you had to edit or completely revise user scripts. This led to major interface changes.

High dynamics of development imposes restrictions on the design of interfaces. We have set ourselves an ambitious task - to make a convenient application for a bunch of “Bitrix24” with Asterisk. And we managed - now anyone can make them friends.

Instead of an afterword

For a month and a half of beta testing, we tested many hypotheses and implemented dozens of scenarios. This is thanks to the support service.

We immediately refused tickets and emails. Such correspondence does not imply a quick response. And consideration of one simple question can be delayed for several days.

The open lines in Bitrix24 helped us a lot. Both we and our customers use the same product. The client can always find our open line in the list of his chats and see the entire history of correspondence. We get tasks, internal communications and communication with the client in one ecosystem.

Thanks to this format, customers receive an answer to an appeal within an average of three minutes. And the client is pleased with the support and willingly shares not only problems, but also ideas for improving the product.

With the release of the stable-version, we had to artificially reduce the dynamics in favor of quality: the responsibility to commercial users does not allow us to experiment on the same scale.

The assembly and testing, as well as the installation and operation of the module in Docker containers, have been automated based on GitLab CI (we plan to write about this separately). Updates are trying to release once a week, but all the experiments carried in the beta branch. By the way, we invite beta testers for collaboration.



This is the end of this tale, but the story of our decision is just beginning.
The product itself: link .