Это не велосипед, а слабо документированная особенность. Данные в socket нужно слать каждые 20 ms. Можно попробовать перейти на chan websocket, там этой проблемы нет, но есть другие особенности. Не помню вышел ли уже астер с этой обновой или вот-вот выйдет.
Мини-музей?
Всем добрый день!
Ранее я уже обращался с вопросом.
Использую ARI c Bridge и ExternalMedia.
Клиент общается с ботом через созданный UDP-сокет, читает и записывает.
Клиент посылает аудио непрерывно, а бот кусками, т.е когда бот молчит, тишина в виде аудио не отправляется. Нумерация и таймстемпы пакетов между фразами бота последовательные. Бот генерирует аудио сразу большими порциями аудио, которого хватает на много RTP-пакетов.
Я написал простую структуру данных для поддержания темпа отправки пакетов от бота. Принцип работы - отправляем пакет, ждем 20 мс (его длина), снова отправляем. Я надеюсь, что у клиентов и asterisk после того, как я отправил в UDP-сокет аудио есть jitter-buffer и иные штуки, а значит можно ограничиться моей такой простой структурой данных.
Собственно проблема как раз, что темп отправки нужно регулировать самостоятельно.
Если вообще не задавать темп отправки, а сразу отправить N пакетов, то много данных будет просто выкидываться принимающей стороной.
В моем случаем все еще возможно накопление погрешности в темпе отправки, в этом случае клиент рано или поздно получит звуковой артефакт.
Есть что-то что я упускаю? Нужен ли такой велосипед?
Это в качестве Transport для External Media пытаться websocket использовать?
https://github.com/asterisk/asterisk/blob/master/rest-api/api-docs/channels.json#L1980
