asterisk.ru

?Анонс докладов на AsterConf 2026

Голосовой AI в реальном мире: задержки, перебивания и другие грабли

Описание
Практический разбор разработки голосового AI-оператора с архитектурой:
MTT/Exolve → Asterisk → AudioSocket → STT → LLM → TTS
На примере работающего проекта расскажу, как мы создавали роботов для холодного обзвона на базе локального AI и масштабировали систему до 30+ одновременных разговоров.
Поговорим о том, как боролись с задержкой голоса, шумами и перебиваниями, снижали нагрузку на серверы, выбирали LLM и настраивали промты. Отдельно разберём решения, которые хорошо выглядели на бумаге, но не выдержали реальной эксплуатации, и подходы, которые сначала казались «костылями», но в итоге помогли довести проект до продакшена.
Также расскажу, как полученный опыт мы использовали при создании IP-звонилки для Windows с AI-суфлёром для менеджеров продаж.

Тезисы
- Архитектура голосового AI-оператора: от телефонии до STT, LLM и TTS.
- Как уменьшить задержки, бороться с перебиваниями и шумами.
- Как выбирать LLM и настраивать промты без потери скорости.
- Как снизить нагрузку на серверы при 30+ одновременных разговорах.
- Какие решения сработали в продакшене, а какие пришлось отбросить.
- Почему временные «костыли» иногда оказываются лучшим практическим решением.

Купить билет пока можно по цене прошлого года

STT -> LLM на одной nvidia v100 sxm2 32gb предел 50

Коллеги, вопрос по тишине после 200 OK на объёме. Прошу проверить логику, всё своё уже перебрал.

Стенд: Asterisk 20.21 в докере, host network, предиктивный дайлер через ARI. Два транка,
Билайн и МТС, alaw. Внешний детектор автоответчика работает петлёй: мы шлём INVITE детектору,
он встречным вызовом набирает абонента через наш же транк.

Симптом. При темпе выше примерно 15 вызовов в секунду часть исходящих приходит с 200 OK,
тарифицируется, а голоса после ответа нет. Это не «нет пакетов»: RTP идёт непрерывно, 50 пакетов
в секунду, без потерь и без разрывов последовательности, один SSRC, в нагрузке alaw-тишина 0xD5.
Громкость (RMS после декодирования, окно +1..+9 с от ответа) равна 8 из 32768 против 900-2400
на нормальных вызовах.

Зависимость от темпа резкая: до 15 вызовов в секунду доля таких вызовов около процента,
на 15-20 — 21%, свыше 20 — 44%. Порог одинаковый у двух независимых операторов связи.

Что проверено на своей стороне и оказалось чистым:
- Asterisk работает зеркалом: по вызовам с тишиной 95,9% «тишина на входе от оператора связи —
тишина на выходе», медиана громкости 8 на входе и 8 на выходе, свои потери 2%;
- сигнализация под нагрузкой: 2827 вызовов, повторных отправок 0%, задержка первого ответа
24 мс медиана и не растёт на пике, SDP приходит по всем отвеченным, адрес медиа единственный;
- ICE на транках выключен, strictrtp = no, taskprocessors без очередей, CPU 3 ядра из 24;
- ядро: ноль отброшенных и ноль переполнений буферов за трое суток, на интерфейсе ноль ошибок;
- канал 546 Мбит/с, используется около пятой части; пинг до обоих операторов под нагрузкой
0% потерь, задержка не растёт.

Две детали, из-за которых и пишу:

1. У части таких вызовов КПВ (гудок от оператора связи) слышен нормально ДО ответа и пропадает
ровно в момент 200 OK. То есть тракт был, и рвётся он именно на переключении на абонента.
2. С ростом темпа первым исчезает живой дозвон (доля живых разговоров падает втрое), а доля
автоответчиков держится. Похоже, что вызовы, которые обслуживает платформа самого оператора
связи, механизм не задевает, а те, где нужно доанкеровать медиа до абонента, — задевает.

Вопросы:
1. Сталкивался ли кто-то с таким на объёме? Это переанкеровка медиа на их SBC/медиашлюзе под
нагрузкой, антифрод, CAC по CPS — или что-то ещё?
2. Как правильно формулировать запрос оператору связи, чтобы не получить «вызов доставлен и
оттарифицирован, у нас всё хорошо»? Какие доказательства они реально принимают: pcap с нашей
стороны, список Call-ID с временем, что-то ещё?
3. Отдельно про петлю детектора автоответчика: при одном и том же среднем темпе прямой набор
в транк даёт 6-11% вызовов без звука, а через петлю — 37%. Есть подозрение, что петля рвёт
равномерность и мгновенный темп на транке становится всплесками. Кто-нибудь мерил мгновенный
CPS на транке корзинами по 100-200 мс и видел разницу с тем, что показывает свой дайлер?

Дампы обоих плеч и сигнализации есть, готов показать выдержки.

Спамеры вроде раньше не в почете были в группе)

Коллеги, вопрос по тишине после 200 OK на объёме. Прошу проверить логику, всё своё уже перебрал.

Стенд: Asterisk 20.21 в докере, host network, предиктивный дайлер через ARI. Два транка,
Билайн и МТС, alaw. Внешний детектор автоответчика работает петлёй: мы шлём INVITE детектору,
он встречным вызовом набирает абонента через наш же транк.

Симптом. При темпе выше примерно 15 вызовов в секунду часть исходящих приходит с 200 OK,
тарифицируется, а голоса после ответа нет. Это не «нет пакетов»: RTP идёт непрерывно, 50 пакетов
в секунду, без потерь и без разрывов последовательности, один SSRC, в нагрузке alaw-тишина 0xD5.
Громкость (RMS после декодирования, окно +1..+9 с от ответа) равна 8 из 32768 против 900-2400
на нормальных вызовах.

Зависимость от темпа резкая: до 15 вызовов в секунду доля таких вызовов около процента,
на 15-20 — 21%, свыше 20 — 44%. Порог одинаковый у двух независимых операторов связи.

Что проверено на своей стороне и оказалось чистым:
- Asterisk работает зеркалом: по вызовам с тишиной 95,9% «тишина на входе от оператора связи —
тишина на выходе», медиана громкости 8 на входе и 8 на выходе, свои потери 2%;
- сигнализация под нагрузкой: 2827 вызовов, повторных отправок 0%, задержка первого ответа
24 мс медиана и не растёт на пике, SDP приходит по всем отвеченным, адрес медиа единственный;
- ICE на транках выключен, strictrtp = no, taskprocessors без очередей, CPU 3 ядра из 24;
- ядро: ноль отброшенных и ноль переполнений буферов за трое суток, на интерфейсе ноль ошибок;
- канал 546 Мбит/с, используется около пятой части; пинг до обоих операторов под нагрузкой
0% потерь, задержка не растёт.

Две детали, из-за которых и пишу:

1. У части таких вызовов КПВ (гудок от оператора связи) слышен нормально ДО ответа и пропадает
ровно в момент 200 OK. То есть тракт был, и рвётся он именно на переключении на абонента.
2. С ростом темпа первым исчезает живой дозвон (доля живых разговоров падает втрое), а доля
автоответчиков держится. Похоже, что вызовы, которые обслуживает платформа самого оператора
связи, механизм не задевает, а те, где нужно доанкеровать медиа до абонента, — задевает.

Вопросы:
1. Сталкивался ли кто-то с таким на объёме? Это переанкеровка медиа на их SBC/медиашлюзе под
нагрузкой, антифрод, CAC по CPS — или что-то ещё?
2. Как правильно формулировать запрос оператору связи, чтобы не получить «вызов доставлен и
оттарифицирован, у нас всё хорошо»? Какие доказательства они реально принимают: pcap с нашей
стороны, список Call-ID с временем, что-то ещё?
3. Отдельно про петлю детектора автоответчика: при одном и том же среднем темпе прямой набор
в транк даёт 6-11% вызовов без звука, а через петлю — 37%. Есть подозрение, что петля рвёт
равномерность и мгновенный темп на транке становится всплесками. Кто-нибудь мерил мгновенный
CPS на транке корзинами по 100-200 мс и видел разницу с тем, что показывает свой дайлер?

Дампы обоих плеч и сигнализации есть, готов показать выдержки.

мне не нравится такая тема. давайте ее где-то обсудите, где у меня нет банхаммера

Спамеры вроде раньше не в почете были в группе)

ИИ наверное не нашёл ответа, обратился за помощью ?