Предисловие
Данная статья посвящена вопросу интеграции 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 и опосредованно через асинхронные запросы из операторской панели.
Итого
- Реализация интеграции только через AGI возможна, если необходимо обеспечить работу небольшого КЦ в пределах одной локальной сети только на исходящих звонках.
- Комбинированный вариант с AGI + Web Socket скорее всего подойдет, если дополнительно к предыдущему пункту есть потребность принимать входящие звонки.
- Вариант на «чистом» Web Socket остаётся единственным возможным, при обеспечении работоспособности распределенных КЦ в пределах нескольких стран или регионов, идеально стабильного коннекта вы не получите даже при 2-3 резервных каналах в силу того, что AGI-интерфейс Asterisk достаточно стабильно работает только в пределах локальных соединений (на одной машине), хуже в пределах одной локальной сети и совсем плохо во всех остальных случаях. Web Socket сервер как раз и работает на машине с Asterisk ровно потому, что таким образом мы не теряем пакеты, не рвем коннект.
P.S. К сожалению, чукча не очень художник и не обладает достаточным количеством свободного времени, чтобы нарисовать общие схемы взаимодействия прямо сейчас, но обещает сделать это, если читателей заинтересуют затронутые в статье вопросы.
Автор: maxru
