Audiosocket в Asterisk

AudioSocket, как один из подходов к реализации стриминга аудиоданных в системах на базе Asterisk. С ростом интереса к автоматизации, распознаванию речи, аналитике звонков и интеграции с различными голосовыми ботами, подобные решения становятся всё более актуальными.
AudioSocket — не единственный возможный способ решения этих задач. Ранее подобные сценарии успешно реализовывались с использованием AGI, однако возможности AudioSocket позволяют по-новому взглянуть на взаимодействие Asterisk с внешними приложениями, особенно в контексте ARI.

Общий контекст

AudioSocket представляет собой двунаправленный TCP-стрим, через который аудиоданные могут как передаваться во внешнее приложение, так и приниматься обратно. При использовании, например, RTP Engine, такой двусторонней передачи добиться сложно: возможно только однонаправленное ретранслирование потока. Это ключевое преимущество AudioSocket при построении сложных сценариев с участием внешней обработки.

Структура протокола AudioSocket

Минимальная полезная нагрузка TCP-стрима составляет 3 байта:

1. Первый байт — тип пакета (например, 0x00 — завершение звонка, 0x01 — начало UID-потока).
2. Второй и третий байты — длина последующей полезной нагрузки.
3. Далее — сама полезная нагрузка.

Изначально аудиоформат — PCM 16-bit, 16 кГц. Пример передачи можно наблюдать в WireShark, при этом удобнее использовать отображение в формате CRA, где все поля более наглядны.

Размер чанка

Интересной и слабо документированной особенностью является размер чанка аудиоданных. В открытых репозиториях (например, в проектах команды CyCore Systems) указано значение в 320 байт, что соответствует:

• 8000 Гц (частота дискретизации)
• 20 мс (packetization time)
• 16 бит / 2 байта на отсчёт
• моно-аудио

Формула: 8000 * 0.02 * 2 = 320 байт

На практике встречались попытки подбора размера чанка опытным путём, например, 1012 байт, что приводило к нестабильной работе. Важно придерживаться согласованного размера, соответствующего аудиокодеку и времени фрейма.

Реализация в Asterisk

AudioSocket реализуется с помощью следующих приложений:

• Application AudioSocket — для использования в dialplan. Требует предварительного ответа (Answer или Progress), является блокирующим.
• Channel AudioSocket — используется в ARI, создаёт внешнюю медиа-сессию, которая управляется через ARI-приложение.

Недокументированной, но доступной является опция c= — кодек, в котором будут передаваться аудиоданные. Это позволяет, например, использовать 16 кГц, как рекомендовано для улучшения распознавания в системах типа Vosk.

Сравнение с RTP

В рамках encapsulation доступны два режима:

• encapsulation=audio-socket
• encapsulation=rtp

Последний реализован как chan-unicast-rtp, но в большинстве случаев предпочтение отдаётся TCP-варианту из-за более простой реализации и отладки. Тем не менее, RTP может обеспечить более низкое время отклика (latency), что критично для realtime-приложений и голосовых роботов.

Форматирование и кодеки

• ulaw
• alaw
• slin

Asterisk способен самостоятельно перекодировать данные в нужный формат.

Проблемы и патчи

Первая версия модуля AudioSocket появилась в 2018 году благодаря CyCore Systems. В основную ветку Asterisk он был принят только к 2020 году. С тех пор значительных изменений в нём не происходило. Тем не менее, были выявлены серьёзные проблемы:

• Использование неоптимального цикла while, вызывавшего повышенную нагрузку на CPU.
• Неправильная обработка завершения канала: при получении hangup AudioSocket не закрывался, в результате чего процесс потреблял ядро процессора.

При наличии нескольких таких зависших сокетов система быстро исчерпывала ресурсы. Проблемы были решены с помощью патчей:

• Патч под Asterisk 20.7 опубликован на GitHub (QR-код со ссылкой приводился на слайде).
• Патч под Asterisk 18.9 распространялся через Telegram-группу Asterisk.

После применения патча:

• Нагрузка на процессор снижается.
• Каналы корректно завершаются.

Нагрузка и производительность

По оценкам, при умеренной нагрузке (~20 одновременных соединений) AudioSocket не создаёт значимой нагрузки на систему. На практике большая часть ресурсов потребляется внешним приложением, обрабатывающим поток (например, системой распознавания речи).