Перейти к содержанию
воскресенье, 4 октября 2026 г.

ИИ Вестник

Главные новости о развитии искусственного интеллекта в России

Разработчик собрал WebRTC-бота для Яндекс.Телемоста на базе Go и ElevenLabs

Источник: Все публикации в потоке Разработка
Backend developer coding Go WebRTC bot in home office at night.
Generated by Sourceful Riverflow (RouterAI)

Разработчик Алексей из небольшого рекламного агентства превратил пет-проект по расшифровке созвонов в полноценного бота для Яндекс.Телемоста. Изначально задуманный как простой транскрибатор на базе ElevenLabs Scribe, проект оброс WebRTC-подключением, диаризацией спикеров, нейросетевыми заметками и даже MCP-сервером.

Инициатором выступил backend-разработчик по имени Алексей, работающий в небольшом рекламном агентстве и увлекающийся реверс-инжинирингом в свободное время. Его основной стек — PHP, немного JavaScript с TypeScript и Python — со временем показался ему предсказуемым и скучным, поэтому он решил освоить Go. Летом 2026 года Алексей вернулся к старому пет-проекту — питоновскому скрипту для расшифровки записей созвонов через API ElevenLabs, собранному ещё два года назад, когда сервис только появился. Изначально планировалось собрать нормальное портфолио, однако в процессе работы проект неожиданно трансформировался в многофункционального бота, способного самостоятельно подключаться к видеовстречам в Яндекс.Телемосте. По словам автора, бот оброс диаризацией, нейросетевыми заметками, Telegram-ботом, MCP-сервером и даже возможностью подключения к встрече через звонок на специальный номер с вводом кода — сказался имеющийся опыт с IP-телефонией.

Первая версия расшифровщика была создана за пару вечеров. Архитектура включала загрузку аудиофайла через multipart, постановку задачи в очередь, воркер для обращения к API ElevenLabs Scribe и сохранение результата в Postgres. Фронтенд написан на React, бэкенд — на Go с использованием chi и pgx. Автор признаётся, что не занимается фронтендом профессионально, поэтому интерфейс пришлось делать с помощью AI, опираясь на ранее созданную библиотеку компонентов, похожую на OpenWebUI. Для авторизации был выбран простой сценарий: проверка пользователя по корпоративной почте через IMAP и выдача JWT. Изначально проверка могла занимать до пяти минут из-за таймаута, но позже была оптимизирована до 15 секунд — в коде функции VerifyIMAPCredentials используется dialer с таймаутом 10 секунд и таймаутом соединения 15 секунд.

Ключевым техническим вызовом стало подключение бота непосредственно к созвонам в Яндекс.Телемосте. Внутри сервис использует WebRTC: медиа передаётся по SRTP, а сигнализация (информация о комнате, активных дорожках, ICE-кандидатах) идёт по WebSocket через собственный JSON-протокол без публичной документации. Разработчику пришлось вручную разбирать бандл и анализировать WS-трафик. Бот маскируется под веб-клиент с версией приложения 3.2.0, поднимает RTCPeerConnection и обменивается сигналами. Первый серьёзный баг заключался в том, что соединение обрывалось ровно через пять секунд: оказалось, что instance-id генерировался заново на каждый запрос, и сервер не узнавал сессию. Решение — фиксация идентификатора на всю сессию. Для записи голоса каждого участника используется отдельный .ogg-файл, а демонстрация экрана пишется в .ivf с применением samplebuilder для сборки кадров VP8, ручным захватом первого ключевого кадра и запросом высокого разрешения, иначе запись стартует с артефактов и прилетает «мыло». Затем ffmpeg сводит дорожки в один файл, который отправляется на расшифровку.

После успешного подключения бота автор начал наращивать функциональность. Он интегрировал Gemini Live, что позволило участникам созвона обращаться к боту за информацией или просить запомнить важные моменты прямо во время встречи. Также был подключён Gemini Flash 3.8 для создания саммари, mindmap и автоматического названия встречи. Для кодирования голоса в дорожку бота без использования cgo и libopus разработчик задействовал ffmpeg, который на лету сжимает PCM в Opus, после чего поток нарезается на пакеты по 20 мс. Эта схема, названная автором костылём, впоследствии пригодилась для реализации самой необычной функции — подключения к встрече через телефонный звонок. Кроме того, был создан MCP-сервер, хотя подробности его работы в исходном тексте обрываются. Отдельно автор отмечает, что гостевой вход работает не везде: если у встречи включён «зал ожидания» или подтверждение входа, бот как гость не зайдёт и нужны куки хозяина.

На российском рынке видеоконференцсвязи подобные решения могут быть востребованы, поскольку многие компании используют Яндекс.Телемост как корпоративный стандарт. Однако отсутствие официального API для ботов и необходимость реверс-инжиниринга создают риски: обновления сервиса могут нарушить работу бота, а использование гостевого доступа ограничено при включённом зале ожидания. Тем не менее проект демонстрирует потенциал интеграции ИИ-ассистентов в рабочие созвоны без необходимости менять привычные инструменты. В отличие от готовых решений вроде OBS с последующей конвертацией, бот работает автономно и в реальном времени, что снижает трудозатраты и расширяет сценарии использования. На фоне зарубежных аналогов, требующих отдельных платформ или ручной записи, такой подход выглядит шагом к «невидимому» ассистенту, встроенному прямо в привычный корпоративный инструмент.

Стоит отметить, что история Алексея — не единичный случай. На фоне импортозамещения и роста популярности отечественных сервисов для совместной работы, интерес к интеграции ИИ в повседневные инструменты растёт. Однако отсутствие открытых API у многих российских платформ вынуждает разработчиков идти путём реверс-инжиниринга, что создаёт правовые и технические риски. В случае с Яндекс.Телемостом бот использует гостевой доступ, который может быть ограничен настройками встречи. Это означает, что для полноценного использования в корпоративной среде потребуется либо согласие организатора, либо использование куки хозяина, что не всегда удобно и безопасно. Тем не менее, подобные проекты показывают, что даже без официальной поддержки можно создавать работающие решения, которые автоматизируют рутинные задачи и повышают эффективность встреч. Возможно, в будущем платформы начнут предоставлять официальные боты-API, но пока такие энтузиасты, как Алексей, прокладывают путь.

В перспективе автор планирует исправить задержки, связанные с ffmpeg-кодированием, и, вероятно, продолжить развитие MCP-сервера. Открытыми остаются вопросы масштабируемости, безопасности и легальности подобных ботов с точки зрения политики Яндекс.Телемоста. Пока проект существует как пет-портфолио, но его архитектура и подход могут вдохновить других разработчиков на создание аналогичных инструментов для других платформ. История Алексея показывает, как хобби-проект может перерасти в сложную систему, объединяющую WebRTC, нейросети и телефонию, и стать примером практического применения ИИ в повседневной рабочей коммуникации.

Читайте также