Интеграция с речевыми сервисами, интеграция с CRM

Введение

Доклад посвящён техническому заданию на разработку интеграции Asterisk с CRM-системой. Рассмотрены ключевые вопросы: с чем мы работаем, что ожидаем получить, как это должно работать и какие для этого потребуются инструменты.

Основные задачи интеграции

1. Определить «эффективную сущность» в CRM. При поступлении звонка CRM возвращает список связанных объектов (сделки, компании, контакты и пр.). Необходимо выбрать один «эффективный» объект, наиболее релевантный текущему звонку.
2. Привести телефонные номера к единому формату. Разные каналы могут возвращать номера с «+7», «8», «7» и без кода страны. Нужен механизм нормализации, чтобы избежать дублей в CRM.
3. Организовать авторизацию и кэширование токенов. CRM могут использовать статический токен или двухфазную авторизацию с ограниченным временем жизни ключа. Требуется хранить токен, отслеживать срок его действия и вовремя обновлять.
4. Сопоставление внутренних номеров Asterisk и идентификаторов пользователей в CRM. Необходима таблица соответствий «внутренний номер ↔ CRM-ID пользователя» для быстрого доступа без перебора большого списка.

Мультифилиальные структуры

В случае, когда CRM-база разделена на несколько филиалов (например, школа английского языка с единой АТС, но разными подразделениями), каждому филиалу соответствует свой токен и набор пользователей. Внутри приложения нужно хранить вторую «учётную книгу» соответствий:

• Филиал → токен доступа
• Филиал → список внутренних номеров сотрудников → CRM-ID

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

Различия API у CRM-систем

• REST-API (внешний и внутренний).
• Web-хуки для «звонка по щелчку».
• Встраиваемые SDK и плагины (например, в amoCRM или Мегаплан).
• Наличие детализации звонков: прикрепление записи к сделке.
• Типы интерфейсов: десктопные (1С-наборки) и веб-интерфейсы с разными требованиями к безопасности и CORS.

Требуемая функциональность

1. Отображение карточки клиента при входящем или исходящем звонке: Поднятие карточки по внутреннему номеру (в CRM-ID), Создание/обновление сделок в момент звонка и переназначение ответственного с администратора на конкретного менеджера.
2. Добавление звонка в сделку и «click-to-call» из CRM.
3. Получение записи разговора и детализации (длительность, направление, участники).
4. Обеспечение доступа к API из любых сетей (веб-клиенты), с HTTPS и аутентификацией.

Схемы взаимодействия

Схема «событие из Asterisk → CRM»:

1. Asterisk генерирует событие начала и конца звонка (через Dialplan-хуки или AMI).
2. Хук в CRM передаёт параметры звонка (номер, время, link-ID).
3. CRM обращается к нашему API (при необходимости) для расширения данных и отображения карточки.

Схема «событие из CRM → Asterisk»:

1. Пользователь нажимает «позвонить» в CRM.
2. В CRM приходит webhook-запрос к API Asterisk для инициирования первой «ноги» звонка.
3. При поднятии трубки телефон автоматически соединяется со второй «ногой» к клиенту.
4. Можно реализовать «автоподъём» трубки у менеджера для ускорения работы.

Работа с AMI (Asterisk Manager Interface)

• AMI — текстовый протокол, генерирующий сообщения (Event: Newstate, Hangup и др.) с полем LinkID.
• Необходимо подписаться на категории Dialplan, Call, Core с фильтрацией по событиям Newstate и Hangup для минимизации трафика.
• Лучше использовать промежуточный прокси (например, AMI-WebSocket), который преобразует AMI-сообщения в JSON/WebSocket, удобный фронтенд-разработчикам.

Альтернативный метод — SIP-SUBSCRIBE

• SIP-SUBSCRIBE позволяет подписаться на состояние конечных точек (BLF).
• При изменении состояния Asterisk отправляет уведомления в XML-формате с Content-Type: application/pidf+xml.
• Такой подход снижает нагрузку по сравнению с AMI, но даёт только информацию об изменении статуса (не детали звонка).
• Обычно используется в SIP-телефонах для индикации «занято/свободно».

Прокси-сервер и безопасность

• Рекомендуется реализовать собственный прокси-сервер (на Go, Node.js, C и др.), который: Подключается к AMI/SIP-SUBSCRIBE, фильтрует события, Предоставляет веб-клиентам JSON-события через WebSocket.
• При этом первая «нога» звонка всегда должна идти на внутренний номер, вторая — в публичный PSTN, чтобы избежать неправомерного инициирования звонков в обход.

Интеграция с голосовыми сервисами (Text-to-Speech и STT)

Пример на базе Yandex SpeechKit:

• Text-to-Speech:

curl -X POST \
-H "Authorization: Api-Key " \
-H "Content-Type: application/json" \
-d '{"text":"Здравствуйте! Чем могу помочь?","voice":"oksana","speed":1.0,"format":"opus"}' \
"https://tts.api.cloud.yandex.net/speech/v1/tts:synthesize"

Результат сохраняется в файл response.opus и проигрывается абоненту.

• Speech-to-Text:

curl -X POST \
-H "Authorization: Api-Key " \
-H "Content-Type: application/json" \
-d '{"config":{"specification":{"languageCode":"ru-RU","format":"LINEAR16","sampleRateHertz":8000}},"audio":{"data":""}}' \
"https://stt.api.cloud.yandex.net/speech/v1/stt:recognize"

PCM-поток из Asterisk передаётся на распознавание, результат в JSON анализируется приложением.

Комбинируя TTS и STT в AGI/RGI-скриптах Asterisk, можно реализовать голосового бота: формировать текстовые запросы, проигрывать их абоненту, записывать ответ и распознавать речь, повторяя цикл.

Заключение

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

Технически это достигается через фильтрацию ключевых событий (начало и завершение звонка) в AMI или через SIP-SUBSCRIBE, проксирование их в удобный для веб-клиента JSON-формат и безопасную маршрутизацию первой «ноги» на внутренний номер. При желании можно расширить систему голосовыми сервисами для синтеза и распознавания речи — это позволит реализовать интерактивные голосовые боты и автоматические IVR-меню.

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