А, тогда нет удивления, и в целом можно ещё дешевле даже
Да что за операторы у вас, откуда цены такие? У нас вестколл, север телеком, северен, ртт, телестор, комфортел - ну нет таких цен, минималка от 1.5р/м
А, тогда нет удивления, и в целом можно ещё дешевле даже
Да что за операторы у вас, откуда цены такие? У нас вестколл, север телеком, северен, ртт, телестор, комфортел - ну нет таких цен, минималка от 1.5р/м
Доброе утро! Наш Александр ждет уже вас, чтобы доставить на конференцию AsterConf
Метро ВДНХ выход №4
В Москве не везде плитку обновили? Недоработка...
В bash скрипте не увидел про регистрацию транков, это боевой скрипт?
Добрый вечер!
Разрабатываю голосового бота (ASR, LLM, TTS).
Одной из функций бота является то, что если он не может решить проблему самостоятельно, он переводит звонок на оператора. Радовался, что через AudioSocket все реализуется просто, пока не дошел до момента, что нужно как раз и перевести звонок на человека. Ознакомился с информацией в сети и истории чата, и понял, что просто чистым AudioSocket не обойтись (не ошибаюсь ли?).
Правильно ли я понимаю, что для решения моей проблемы нужно задействовать External Media и ARI? Есть ли какие-то другие способы? За полезные ссылки и примеры реализации на ЯП буду премного благодарен.
Всем добрый день!
Ранее я уже обращался с вопросом.
Использую ARI c Bridge и ExternalMedia.
Клиент общается с ботом через созданный UDP-сокет, читает и записывает.
Клиент посылает аудио непрерывно, а бот кусками, т.е когда бот молчит, тишина в виде аудио не отправляется. Нумерация и таймстемпы пакетов между фразами бота последовательные. Бот генерирует аудио сразу большими порциями аудио, которого хватает на много RTP-пакетов.
Я написал простую структуру данных для поддержания темпа отправки пакетов от бота. Принцип работы - отправляем пакет, ждем 20 мс (его длина), снова отправляем. Я надеюсь, что у клиентов и asterisk после того, как я отправил в UDP-сокет аудио есть jitter-buffer и иные штуки, а значит можно ограничиться моей такой простой структурой данных.
Собственно проблема как раз, что темп отправки нужно регулировать самостоятельно.
Если вообще не задавать темп отправки, а сразу отправить N пакетов, то много данных будет просто выкидываться принимающей стороной.
В моем случаем все еще возможно накопление погрешности в темпе отправки, в этом случае клиент рано или поздно получит звуковой артефакт.
Есть что-то что я упускаю? Нужен ли такой велосипед?