asterisk.ru

А, тогда нет удивления, и в целом можно ещё дешевле даже

Да что за операторы у вас, откуда цены такие? У нас вестколл, север телеком, северен, ртт, телестор, комфортел - ну нет таких цен, минималка от 1.5р/м

Да что за операторы у вас, откуда цены такие? У нас вестколл, север телеком, северен, ртт, телестор, комфортел - ну нет таких цен, минималка от 1.5р/м

У нас Билайн, МТС, Мегафон
От 95 копеек до 1,1 за минуту.

И абонентка за номер очень и очень смешная -)))

Доброе утро! Наш Александр ждет уже вас, чтобы доставить на конференцию AsterConf
Метро ВДНХ выход №4

Доброе утро! Наш Александр ждет уже вас, чтобы доставить на конференцию AsterConf
Метро ВДНХ выход №4

В Москве не везде плитку обновили? Недоработка...

В Москве не везде плитку обновили? Недоработка...

Где нашли заначку под плиткой в обновление теряет смысл

В bash скрипте не увидел про регистрацию транков, это боевой скрипт?

В bash скрипте не увидел про регистрацию транков, это боевой скрипт?

если это вопрос спикеру, то его надо под окном траснляции писать, я тут, увы, не прочитаю(

Добрый вечер!
Разрабатываю голосового бота (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, там этой проблемы нет, но есть другие особенности. Не помню вышел ли уже астер с этой обновой или вот-вот выйдет.