Рубрика: Без рубрики

Доклад показывает разработку локального голосового SIP-ассистента с потоковым ASR, LLM с RAG, TTS, поддержкой контекста, перебивания и перевода звонка оператору.
Главная тема — не сам ассистент, а инженерный процесс его создания: как специалист, используя AI, быстро проходит путь от требований и архитектурных границ до рабочего прототипа, тестов и live-демонстрации.
На практическом примере рассматриваются реальные сложности интеграции SIP/RTP и нейросетевых компонентов, роль экспертного контроля и границы применимости AI-ускорения.

Тезисы
— Посмотрим, как заставить независимые потоковые компоненты — SIP/RTP, ASR, TTS и диалоговый автомат — взаимодействовать в реальном времени, не блокируя звонок из-за медленной нейросети.
— Покажу, как специалист превращает AI из генератора правдоподобного кода в ускоритель прикладной разработки — через требования, границы компонентов, тесты и живые проверки.
— Расскажу, как собрать локальный голосовой контур с ASR, TTS и RAG так, чтобы модели можно было заменять, а поведение системы оставалось контролируемым.
— Покажу, как найти дефект на границе потокового TTS и тактового PJMEDIA, который не виден по формальному egress_underruns, но превращает ответ бота в тишину.
— Расскажу, как управление prompt и skills позволяет заметно сократить задержку ответа LLM без замены самой модели.

Информация о мониторинге Asterisk часто разрознена: отдельно рассматриваются метрики, логи и SIP-трафик, но не всегда понятно, как объединить эти подходы в рабочую систему. В докладе будет представлен обзор инструментов, которые применяются сегодня, а также их преимуществ, ограничений и сценариев использования.
Рассмотрим Zabbix, Prometheus, Grafana, Loki, Elasticsearch, rsyslog, SIP3, Homer, AMI и Bash-скрипты, как инструменты сбора диагностических данных. Обсудим, какие решения подходят для небольшой инфраструктуры, что меняется при росте числа серверов и объема данных и почему в крупных системах одного инструмента обычно недостаточно. Отдельное внимание будет уделено централизованному сбору логов, мониторингу SIP-трафика и сочетанию разных источников данных для диагностики прохождения звонка.

Основные тезисы
— Универсального инструмента для мониторинга Asterisk не существует.
— Выбор решения зависит от размера и сложности инфраструктуры.
— Разница при использовании Zabbix как одиночного сервера, и как компонента сложных систем мониторинга.
— Централизованный сбор метрик и логов, а также SIP-мониторинг как компоненты эффективной диагностики возникающих проблем.
— Телеметрия — что она добавляет, кому и для чего она нужна.
— Не все привычные инструменты одинаково эффективны в современных enterprise-инфраструктурах.

Начнём с Asterisk и Kamailio и посмотрим, как далеко на них можно масштабировать массовый обзвон. Затем разберём переход к собственному SIP- и RTP-серверу на Go, оптимизацию UDP-трафика и генерации RTP.
Отдельно обсудим, почему FFmpeg плохо подходит для большого числа медиапотоков, как перейти к репликации RTP и в каких случаях имеет смысл использовать eBPF/XDP.
По ходу разберём устройство SIP- и RTP-пакетов, диалоги, транзакции, CSeq, теги, контрольные суммы и хранение метаданных в AVL-деревьях. Главный вопрос — какие части стандартного SIP-стека действительно нужны, а от каких можно отказаться ради производительности.

Тезисы
— Массовый обзвон порядка 40 000 устройств.
— Масштабирование Asterisk и Kamailio и их пределы.
— SIP- и RTP-сервер на Go.
— Генерация и репликация RTP, ограничения FFmpeg.
— Оптимизация UDP, ptime, параметры ядра.
— eBPF/XDP для высокопроизводительной работы с пакетами.
— SIP и RTP изнутри: заголовки, транзакции, диалоги, CSeq, checksum.
— AVL-деревья для хранения метаданных диалогов.
— Когда можно упростить SIP-модель ради производительности.

Расскажем, как внедрение продукта для КЦ заняло около трёх лет из-за требований информационной безопасности, ограничений закрытого контура и необходимости интеграции с существующей VoIP-инфраструктурой. Разберём, почему типовая архитектура не прошла согласование, какие технические и организационные проблемы возникли в процессе и какие доработки потребовались для запуска системы.

Тезисы:
— Почему успешный пилот не гарантирует готовность к промышленной эксплуатации.
— Как адаптировали архитектуру под требования ИБ и закрытый контур.
— Как интегрировали CallForce с Asterisk, SIP/RTP, VPN и внутренними системами.
— Какие технические проблемы выявились во время внедрения.
— Как распределяли ответственность между заказчиком и поставщиком.
— Что необходимо предусмотреть заранее: мониторинг, резервирование, SLA, обновления и поддержку.
— Какие ошибки стоит учесть при аналогичных внедрениях.

За последний год Asterisk получил ряд заметных обновлений — от новых возможностей до оптимизаций производительности в критичных подсистемах, включая CDR/CEL и taskprocessor.

В докладе разберём ключевые изменения последних релизов, текущий статус LTS и Standard-веток и то, что важно учитывать при планировании обновлений.

Отдельно посмотрим на активность проекта в GitHub, основные направления развития Asterisk и традиционные вопросы: кластеризация, долгожданные возможности и почему Sangoma снова не реализовала X и Y.

Тезисы
— Ключевые изменения Asterisk за прошедший год.
— Оптимизации производительности: CDR/CEL, taskprocessor и другие чувствительные подсистемы.
— Статус LTS и Standard-веток и планирование обновлений.
— Как понять, стоит ли обновлять существующую систему.
— Основные направления развития проекта и активность сообщества.
— Кластеризация и другие традиционные вопросы к Asterisk и Sangoma.

С ростом количества пользователей и звонков система на базе Homer перестала обеспечивать необходимую скорость работы. В докладе разберём новую архитектуру обработки SIP-трафика: децентрализованный захват, PCAP как единицу обработки, ClickHouse для хранения и аналитики, а также использование S3, Redis и курсорной пагинации.
На практическом примере покажем, как новая система помогает в несколько раз ускорить работу технической поддержки.

Тезисы
— Децентрализованный захват VoIP-трафика с sip_dumps.
— PCAP как единица пакетной обработки.
— ClickHouse для быстрого хранения и анализа больших объёмов данных.
— Курсорная пагинация без лишней нагрузки на API и СУБД.
— S3 и Redis-очередь для хранения, асинхронной обработки и горизонтального масштабирования.
— Практический эффект: ускорение поиска и анализа звонков для технической поддержки.

Обзор решений Yealink для построения корпоративной IP-телефонии: от SIP-телефонов до DECT-систем для офисов, складов и распределённых объектов. Рассмотрим актуальную линейку оборудования, возможности масштабирования и инструменты проектирования беспроводной инфраструктуры.

Тезисы

— Актуальная линейка SIP- и DECT-решений Yealink.
— Сценарии применения оборудования на объектах разного масштаба.
— Построение и масштабирование мультисотовых DECT-систем.
— Бесшовный роуминг и мобильность сотрудников.
— Подбор и проектирование оборудования под конкретную задачу.

Как перевести около 160 000 корпоративных телефонов Avaya и Unify на собственную платформу — без массовой замены оборудования и заметных изменений для пользователей?
В докладе — реальная история Сбера: от команды из VoIP-инженеров и первого MVP до Enterprise-платформы на Open Source. Разберём архитектуру решения, реверс-инжиниринг вендорской логики и стратегию бесшовной миграции десятков тысяч устройств.

Тезисы
— Как построить голосовое ядро на Open Source и сохранить работу существующих телефонов.
— Как определить минимальный набор функций для быстрого выхода в продакшн.
— Как организовать реверс-инжиниринг закрытых вендорских решений.
— Как провести бесшовную миграцию 160 000 устройств без потери пользовательского функционала.
— Как за 2,5 года вырастить решение от MVP до масштабной Enterprise-платформы.

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

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