Предисловие


Данная статья посвящена вопросу интеграции CRM-систем с серверами телефонии на базе Asterisk.
В статье не рассматриваются вопросы, связанные с настройкой сервера Asterisk или нюансами работы CRM-систем, рассматриваются лишь общие варианты организации взаимодействия со всеми их плюсами и минусами.

Введение


Как компании «доходят» до разработки CRM «под себя» и собственной телефонии — вопрос скорее политический и бизнесовый, чем технический, поэтому на вопросы «зачем» ответов дать не смогу. Но факт остаётся фактом — в один прекрасный день нам понадобилось решение, способное обеспечить взаимодействие телефонной части с CRM.

Исходные данные:
  • 2 колл-центра (далее — КЦ) на большом расстоянии (один в РФ, второй, скажем, в Эстонии)
  • порядка 500 одновременно работающих операторов в каждом (входящие и исходящие звонки)
  • одна точка входа (для простоты считайте, что сервер CRM всего один)
  • оба КЦ обрабатывают звонки по РФ
  • у каждого КЦ — свой сервер Asterisk (для простоты будем считать, что все Asterisk настроены и в полностью рабочем режиме)
  • CRM является client-server приложением с web-мордой


Что нужно было сделать:
  • обеспечить взаимодействие оператора с телефонией из одной точки входа, т.е. с рабочего интерфейса оператора
  • получать данные о звонках из Asterisk (длительность звонка, длительность разговора, статус и т.д.)
  • обеспечить достаточную стабильность работы телефонии (различные аспекты «стабильности» будут рассмотрены далее)


Варианты реализации


WebRTC / Web-SIP

Первое, что пришло в голову — реализация «звонилки» прямо в браузере (мы же помним, что взаимодействие с CRM осуществляется через веб-интерфейс). А тут как раз спецификация WebRTC подоспела с плагинами для популярных браузеров.
Идея, несомненно, хорошая, но для бизнеса не подходящая в силу того, что при подвисании / закрытии браузера или обновлении страницы мы теряем коннект, звонок и клиента.
По тем же причинам не был выбран ни один из «классических» SIP веб-клиентов.

SIP-телефон + AGI + Web Socket

Идея с отдельным SIP-телефоном обладает очевидным для бизнеса преимуществом — практически в любой непредвиденной ситуации мы сохраняем звонок. Возникают сложности с обеспечением взаимодействия с CRM, однако это решаемая задача.

Осталось научить сипфон звонить из интерфейса оператора.

Скажите, как заставить сипфон на компьютере сде��ать исходящий звонок из браузера? Никак? Совершенно верно.
Именно поэтому мы стали посылать команду астериску через AGI-интерфейс, по которой он организовывал исходящий вызов до абонента, а затем подключал к каналу оператора. Так для сипфона исходящий звонок стал входящим с командой автоответа от сервера телефонии.

Всё стало хорошо, оператор, начинал работу с некой сущностью CRM-системы (для простоты назовём её «Звонок»), далее вручную или автоматически отправлялась команда инициации «исходящего» звонка через agi, а по завершению звонка asterisk присылал нам информацию о звонке (вариантов много, начиная от GET-запроса и заканчивая WebSocket).

Этап внедрения исходящей телефонии в России прошел не без шероховатостей, но довольно успешно, после чего было необходимо начинать работу со входящими звонками.

Осталось научить оператора принимать входящий звонок из интерфейса, а не через сипфон.

Тут уже пришлось завязаться на работу Asterisk непосредственно с браузером, по крайней мере до успешного принятия звонка, в результате чего на сервере телефонии появился еще и Web Socket сервер.
Таким образом информация о поступлении входящего звонка к оператору поступала непосредственно в браузер, а остальные команды шли в Asterisk через сервер CRM и затем через AGI интерфейс.

Решение организовать управление телефонией через сервер CRM было связано со следующими требованиями:
  • Безопасность. Мы не хотели показывать оператору, в каких он очередях регистрируется, какой текущий статус звонка. Оператор не принимает решений, поэтому для него достаточно информации можно работать или нельзя.
  • Одна точка входа. Управление всеми серверами телефонии из одной точки, консолидирование информации «здесь и сейчас».
  • Синхронное получение и обработка данных. Состояние интерфейса известно до отправки данных оператору (в браузер).


Вышеописанная схема достаточно хорошо работала в России, однако когда КЦ в Эстонии стал осуществлять звонки через CRM-систему мы обнаружили большое количество проблем со звонками, вызванных не корректной работой AGI. Пакеты от Эстонского Asterisk не доходили до нашего сервера CRM, в результате чего мы не получали никакой информации о выполнении команды, не знали дошла ли команда вообще.

Через неделю стало очевидно, что ситуация не улучшится, повлиять на качество связи ��ежду Российским и Эстонским серверами мы не могли, в результате чего было принято волевое решение о полном переходе на управление телефонией через Web Socket.

Еще через неделю мы получили работающую схему, где у каждого Asterisk был свой Web Socket сервер, с которым браузер оператора связывался в пределах одной локальной сети. Сервер CRM как был, так и остался в РФ.

Таким образом связь интерфейса оператора с сервером телефонии происходит в пределах одной локальной сети без задержек и все команды управления телефонией и события отправляются и приходят обратно в браузер оператора.
Взаимодействие CRM и телефонии непосредственно происходит через callback'и от Asterisk и опосредованно через асинхронные запросы из операторской панели.

Итого


  1. Реализация интеграции только через AGI возможна, если необходимо обеспечить работу небольшого КЦ в пределах одной локальной сети только на исходящих звонках.
  2. Комбинированный вариант с AGI + Web Socket скорее всего подойдет, если дополнительно к предыдущему пункту есть потребность принимать входящие звонки.
  3. Вариант на «чистом» Web Socket остаётся единственным возможным, при обеспечении работоспособности распределенных КЦ в пределах нескольких стран или регионов, идеально стабильного коннекта вы не получите даже при 2-3 резервных каналах в силу того, что AGI-интерфейс Asterisk достаточно стабильно работает только в пределах локальных соединений (на одной машине), хуже в пределах одной локальной сети и совсем плохо во всех остальных случаях. Web Socket сервер как раз и работает на машине с Asterisk ровно потому, что таким образом мы не теряем пакеты, не рвем коннект.


P.S. К сожалению, чукча не очень художник и не обладает достаточным количеством свободного времени, чтобы нарисовать общие схемы взаимодействия прямо сейчас, но обещает сделать это, если читателей заинтересуют затронутые в статье вопросы.