Автор: sergey

15 лет работы с японским телекомом — это опыт, который меняет взгляд на привычные инженерные процессы. Александр Волков расскажет, как японский культурный код влияет на разработку и эксплуатацию VoIP-платформ: от архитектуры и релизов до мониторинга, инцидентов и общения с клиентами. И почему в этой культуре качество, ответственность и доверие часто оказываются важнее скорости изменений.

архитектура и эксплуатация облачной VoIP-платформы;
чем японский подход отличается от принципа «move fast and break things»;
как устроены релизы, мониторинг и работа с инцидентами;
как культурные особенности проявляются в телефонии и коммуникации;
почему качество, ответственность и доверие становятся частью инженерного подхода.

На мастер-классе участники подготовят документацию небольшой компании, загрузят ее в RAG-подсистему, настроят промпты и подключат ИИ-ассистента к call-center, созданному на первом мастер-классе.

В результате можно будет увидеть весь процесс создания локального ИИ-решения для телефонии — от базовой инфраструктуры до ассистента, который работает с корпоративными знаниями и может использоваться для автоматизации типовых обращений, снижения нагрузки на сотрудников и сокращения операционных издержек.

Интеграция Asterisk с CRM, информационными системами и другими внешними сервисами часто требует выбора между несколькими техническими подходами. На мастер-классе разберем основные варианты передачи данных о звонках, их преимущества, ограничения и области применения.

Разберемся, в каких ситуациях для интеграции стоит использовать не стандартные возможности AMI, ARI и AGI, а специализированные сторонние инструменты.

В практической части участники увидят, как за 10 минут связать Asterisk со сторонней системой через HTTP API сервиса «Простые звонки». Также разберем инструменты и приемы, которые помогают тестировать интеграцию и находить ошибки.

Основные тезисы
— Клиент-сервер и сервер-сервер: основные различия, преимущества и ограничения каждого подхода.
— Как определить, какой вариант интеграции лучше подходит для конкретной задачи.
— AMI, ARI, AGI и интеграция своими силами: аргументы "за" и "против".
— Сервис интеграции как альтернатива разработке собственного сервер-серверного решения.
— Как передавать данные о звонках во внешнюю систему через HTTP API.
— Практическая настройка интеграции Asterisk с сервисом «Простые звонки».
— Как протестировать интеграцию и провести отладку.
— Как сократить время и трудозатраты на подключение Asterisk к CRM и другим сторонним системам.

CDR показывает итог звонка, но плохо подходит для восстановления его полного сценария: очередей, переводов, удержаний и взаимодействия нескольких каналов. В докладе разберём, как использовать CEL и преобразовать технические события Asterisk в понятный Call Flow и итоговую карточку звонка.

На практическом примере покажем, как группировать события очередей, bridge, transfer, hold и каналов, рассчитывать временные метрики и формировать структуру данных для отчётности и аналитики.

Тезисы
— Почему CDR недостаточно для сложных сценариев звонка.
— Как декомпозировать звонок на очереди, ответ, разговор, удержания и переводы.
— Как группировать CEL-события в смысловые сущности.
— Как определить участников звонка и восстановить его последовательность.
— Как рассчитать время дозвона, разговора, удержания и общую длительность.
— Как сформировать итоговую карточку звонка и Call Flow для аналитики и отчётности.

В докладе будет показано, как получать ключи дешифрования с помощью eBPF и использовать pcap-sip для разбора защищённого VoIP-трафика. На практическом примере разберём дешифрование WebRTC-звонка: от сигнализации до RTP-медиа, а затем подготовим полученный трафик для удобного анализа в Wireshark.
Отдельно рассмотрим обработку длительных TLS-соединений и подходы, которые помогают заметно ускорить анализ больших PCAP-файлов в условиях высокой нагрузки.

Тезисы
— получение ключей дешифрования с помощью eBPF;
— дешифрование WebRTC-звонков и длительных TLS-соединений;
— разбор сигнализации и RTP-медиа;
— применение pcap-sip для обработки и дешифрования трафика;
— подготовка результатов для дальнейшего анализа в Wireshark;
— ускорение анализа больших PCAP-файлов на высоконагруженных серверах;
— практическая методика диагностики проблем в WebRTC- и VoIP-системах.

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

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

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

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

Доклад показывает разработку локального голосового 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 без замены самой модели.

Плохое качество голоса не всегда можно заметить по стандартным техническим метрикам. Шум, искажение тембра, прерывистость или проблемы с громкостью могут возникать у отдельных пользователей и оставаться незаметными для привычного мониторинга.
В докладе будет рассмотрен подход к автоматической оценке качества разговоров с помощью NISQA-s. Будет показано, как получать метрики Noisiness, Coloration, Discontinuity, Loudness и MOS, обрабатывать аудио с помощью FFmpeg и Python, сохранять результаты в ClickHouse и визуализировать их в Grafana.
Также будут разобраны первые результаты такого мониторинга и то, какие проблемы удалось увидеть благодаря новым метрикам.

Тезисы
— Почему стандартного мониторинга недостаточно для оценки качества голоса.
— Как NISQA-s позволяет автоматически оценивать качество аудио.
— Какие метрики можно получить: Noisiness, Coloration, Discontinuity, Loudness и MOS.
— Как устроен пайплайн обработки аудио на FFmpeg и Python.
— Какие новые сигналы о проблемах качества дает такой подход.

На мастер-классе разберем полный цикл создания DECT-системы: от планирования покрытия в Yealink DECT Designer до настройки базовых станций, синхронизации и централизованного управления.
На примере склада или производственного цеха покажем, как учитывать особенности помещения, автоматически рассчитывать количество и расположение базовых станций и проверять качество будущего покрытия.

Тезисы
— Планирование DECT-системы с помощью Yealink DECT Designer.
— Архитектура мультисотовых решений Yealink W80 и W90.
— Расчет количества и оптимального размещения базовых станций.
— Настройка синхронизации, Sync Levels и бесшовного хэндовера.
— Практический кейс проектирования системы для сложного объекта.
— Централизованное управление и лицензирование с помощью VIM.
— Диагностика покрытия и проверка корректности конфигурации.
Участники получат понятную методику проектирования и настройки мультисотовых DECT-систем, которую смогут применять в реальных проектах.