В этой небольшой статье не будет ничего про dialplan Asterisk. Речь пойдёт про ARI - гибкий интерфейс для управления Asterisk.
Как только Asterisk получает INVITE и вызов уходит в наше приложение (Stasis), у нас появляется возможность собирать звонок на низком уровне.
Работа с ARI строится так: получаем события от Asterisk по WebSocket, обрабатываем их и создаём новые через HTTP REST API в сторону ARI.
StasisStart
Событие, которое получает наша программа, когда канал попадает в контекст Stasis, - StasisStart. Оно может сигнализировать, например, о начале исходящего или входящего вызова, и в ответ мы запускаем низкоуровневую логику: создаём канал в сторону другого абонента, добавляем его в бридж с каналом инициатора и делаем вызов.
Упрощённый сценарий обычного звонка
- Получили от ARI событие StasisStart о том, что создан канал A.
- Создали канал B с эндпоинтом в сторону SIP-пира или локального прокси (пример: SIP/MY_PEER/331234567890).
- Объединили канал A из шага 1 и канал B из шага 2 в бридж.
- Запустили dial в канал B.
- Дождались от ARI события ChannelStateChange по каналу B. Если состояние ‘Up’, делаем answer в канале A, и начинается разговор.
- При получении события ChannelHangupRequest по каналу A или B завершаем звонок.
Сессия звонка
Может понадобиться хранить данные о ходе звонка, включая CDR, по каждому каналу.
В качестве хранилища я бы рекомендовал Redis: при высоком CPS интенсивные запросы в базу могут сильно нагрузить диски и просадить производительность.
Оптимизация
Чтобы ARI-приложение нормально работало при высоком CPS, я бы советовал свести к минимуму запросы в реляционную базу. У меня на практике запросы шли только для небольшой логики лимитов при инициализации звонка и для записи CDR после его завершения. Всё остальное - в Redis.
Ещё рекомендую с точки зрения инфраструктуры держать ARI-приложение на одном хосте с Asterisk, чтобы снизить задержки.
Нагрузочный тест
Для теста я взял консольную утилиту baresip и bash-скриптом запустил 200 звонков на пул тестовых номеров, которые отвечают asterisk-овскими tt-monkeys.
200 параллельных звонков в сумме съели около 5% CPU. Все звонки завершились успешно, CDR записались.
