asterisk.ru

Добрый вечер!
Разрабатываю голосового бота (ASR, LLM, TTS).
Одной из функций бота является то, что если он не может решить проблему самостоятельно, он переводит звонок на оператора. Радовался, что через AudioSocket все реализуется просто, пока не дошел до момента, что нужно как раз и перевести звонок на человека. Ознакомился с информацией в сети и истории чата, и понял, что просто чистым AudioSocket не обойтись (не ошибаюсь ли?).
Правильно ли я понимаю, что для решения моей проблемы нужно задействовать External Media и ARI? Есть ли какие-то другие способы? За полезные ссылки и примеры реализации на ЯП буду премного благодарен.

Всем добрый день!
Ранее я уже обращался с вопросом.
Использую ARI c Bridge и ExternalMedia.
Клиент общается с ботом через созданный UDP-сокет, читает и записывает.
Клиент посылает аудио непрерывно, а бот кусками, т.е когда бот молчит, тишина в виде аудио не отправляется. Нумерация и таймстемпы пакетов между фразами бота последовательные. Бот генерирует аудио сразу большими порциями аудио, которого хватает на много RTP-пакетов.
Я написал простую структуру данных для поддержания темпа отправки пакетов от бота. Принцип работы - отправляем пакет, ждем 20 мс (его длина), снова отправляем. Я надеюсь, что у клиентов и asterisk после того, как я отправил в UDP-сокет аудио есть jitter-buffer и иные штуки, а значит можно ограничиться моей такой простой структурой данных.

Собственно проблема как раз, что темп отправки нужно регулировать самостоятельно.
Если вообще не задавать темп отправки, а сразу отправить N пакетов, то много данных будет просто выкидываться принимающей стороной.
В моем случаем все еще возможно накопление погрешности в темпе отправки, в этом случае клиент рано или поздно получит звуковой артефакт.

Есть что-то что я упускаю? Нужен ли такой велосипед?

Всем добрый день!
Ранее я уже обращался с вопросом.
Использую ARI c Bridge и ExternalMedia.
Клиент общается с ботом через созданный UDP-сокет, читает и записывает.
Клиент посылает аудио непрерывно, а бот кусками, т.е когда бот молчит, тишина в виде аудио не отправляется. Нумерация и таймстемпы пакетов между фразами бота последовательные. Бот генерирует аудио сразу большими порциями аудио, которого хватает на много RTP-пакетов.
Я написал простую структуру данных для поддержания темпа отправки пакетов от бота. Принцип работы - отправляем пакет, ждем 20 мс (его длина), снова отправляем. Я надеюсь, что у клиентов и asterisk после того, как я отправил в UDP-сокет аудио есть jitter-buffer и иные штуки, а значит можно ограничиться моей такой простой структурой данных.

Собственно проблема как раз, что темп отправки нужно регулировать самостоятельно.
Если вообще не задавать темп отправки, а сразу отправить N пакетов, то много данных будет просто выкидываться принимающей стороной.
В моем случаем все еще возможно накопление погрешности в темпе отправки, в этом случае клиент рано или поздно получит звуковой артефакт.

Есть что-то что я упускаю? Нужен ли такой велосипед?

Это не велосипед, а слабо документированная особенность. Данные в socket нужно слать каждые 20 ms. Можно попробовать перейти на chan websocket, там этой проблемы нет, но есть другие особенности. Не помню вышел ли уже астер с этой обновой или вот-вот выйдет.

Это не велосипед, а слабо документированная особенность. Данные в socket нужно слать каждые 20 ms. Можно попробовать перейти на chan websocket, там этой проблемы нет, но есть другие особенности. Не помню вышел ли уже астер с этой обновой или вот-вот выйдет.

Это в качестве Transport для External Media пытаться websocket использовать?
https://github.com/asterisk/asterisk/blob/master/rest-api/api-docs/channels.json#L1980

На Измайловском рынке продают)))

Мини-музей?

Мини-музей?

Стенд

ТКМС с блоком питания?

Всем добрый день!
Ранее я уже обращался с вопросом.
Использую ARI c Bridge и ExternalMedia.
Клиент общается с ботом через созданный UDP-сокет, читает и записывает.
Клиент посылает аудио непрерывно, а бот кусками, т.е когда бот молчит, тишина в виде аудио не отправляется. Нумерация и таймстемпы пакетов между фразами бота последовательные. Бот генерирует аудио сразу большими порциями аудио, которого хватает на много RTP-пакетов.
Я написал простую структуру данных для поддержания темпа отправки пакетов от бота. Принцип работы - отправляем пакет, ждем 20 мс (его длина), снова отправляем. Я надеюсь, что у клиентов и asterisk после того, как я отправил в UDP-сокет аудио есть jitter-buffer и иные штуки, а значит можно ограничиться моей такой простой структурой данных.

Собственно проблема как раз, что темп отправки нужно регулировать самостоятельно.
Если вообще не задавать темп отправки, а сразу отправить N пакетов, то много данных будет просто выкидываться принимающей стороной.
В моем случаем все еще возможно накопление погрешности в темпе отправки, в этом случае клиент рано или поздно получит звуковой артефакт.

Есть что-то что я упускаю? Нужен ли такой велосипед?

небольшой джиттер при отправке допустим я полагаю. Так что по таймеру слать каждые 20 мс пакеты и норм. Яб попробовал так сделать

Это в качестве Transport для External Media пытаться websocket использовать?
https://github.com/asterisk/asterisk/blob/master/rest-api/api-docs/channels.json#L1980

Да, при сборке астера должен быть указан chan_websocket

Спасибо , за еще один АстерКонф!