Как в 2026 году внедрить перевод видео в реальном времени: практическое руководство для инженеров

Почему Фора Софт написала этот плейбук по интеграции

Компания Фора Софт выпускает продукты на базе WebRTC с 2005 года. В телемедицине, e-learning, вещании и корпоративном видео мы хотя бы раз подключали агентов перевода в реальном времени к каждой крупной видеоплатформе — LiveKit, Agora, Mediasoup, Jitsi, Zoom Video SDK, Daily, а также к собственным SFU на Hetzner и AWS. Этот плейбук объединяет интеграционные решения, которые мы применяем в первый день каждого проекта.

У статьи два опорных кейса. BrainCert — глобальная HTML5-платформа виртуальных классов, которую мы переработали с использованием слоя агентов на базе LiveKit, обеспечивающего многоязычные субтитры в 190+ странах. CirrusMed — телемедицинский продукт в США, где интеграционная дисциплина — вопрос выживания: каждый субпроцессор, имеющий доступ к аудио пациентов, попадает под HIPAA BAA ещё до написания первой строки кода. Наша более широкая практика разработки ПО для обработки видео и аудио на заказ — это та среда, где и рождаются эти интеграционные паттерны.

Статья №306 разбирает стратегическую картину перевода видео в реальном времени — пайплайны, задержки, стоимость, выбор провайдера. Здесь же мы остаёмся в плоскости реализации: какой хук вызвать, как опубликовать обратно вторичную аудиодорожку, как масштабировать пул воркеров и как не сломать синхронизацию, когда пользователь переподключается.

Четыре паттерна интеграции, которые реально работают в продакшене

Любая интеграция перевода в реальном времени, которую мы запускали, сводится к одному из четырёх подходов. Сначала выбирайте подход, потом технологии.

1. Серверный бот-участник. Безголовый процесс подключается к звонку как обычный участник, подписывается на аудиодорожку каждого участника, запускает распознавание речи (ASR) и перевод (MT) на сервере и возвращает результат — либо в виде отдельной аудиодорожки с переводом, либо как субтитры через data channel. Это самый чистый подход — и наш стандартный выбор для LiveKit и Agora, потому что обе платформы предоставляют полноценный SDK для ботов.

2. Инлайн-преобразование медиа. Плагин, зарегистрированный в медиапайплайне, перехватывает аудио до кодирования или после декодирования, заменяет или накладывает переведённый звук и возвращает его в ту же дорожку. Сюда подходят Microsoft Teams Media Extensibility и mediasoup plain-transport. Плюс: используется один поток, без удвоения участников. Минус: жёсткие ограничения по задержке колбэков (Teams требует около 100 мс) и более тесная интеграция с внутренними механизмами вендора.

3. Egress из SFU во внешний воркер. SFU перенаправляет RTP в plain transport или RTP-эндпоинт, который читает воркер перевода. Воркер декодирует Opus, обрабатывает ASR, переводит текст (MT) и синтезирует речь (TTS), перекодирует аудио и отправляет RTP обратно в SFU как новый продюсер. Такой подход поддерживают Mediasoup, Janus и любые кастомные SFU. Это самый гибкий, но и самый трудоёмкий вариант — вам придётся самостоятельно управлять SSRC, джиттером, RTCP и FEC.

4. Захват на клиенте + облачный ASR. Браузер или мобильное приложение отправляет записанное аудио в Deepgram, AssemblyAI или Azure через WebSocket, получает расшифровку и передаёт её участникам по каналу данных WebRTC. Такой подход хорошо работает для звонков один на один и при небольшой нагрузке, но не масштабируется на вебинары с сотнями слушателей — за каждого из них придётся платить за обработку речи.

По платформам: где аудио попадает в ваш пайплайн

Вот точные хуки, которые мы используем в интеграциях 2026 года. Имена и API — как их предоставляет каждый вендор.

Большая ловушка, спрятанная в этой таблице: Twilio Programmable Video находится в режиме end-of-life (отключение в декабре 2026 года). Команды, у которых уже используется Twilio, должны прямо сейчас планировать переход на Zoom Video SDK, LiveKit или Daily. Если это про вас — добавляйте перевод в тот же проект: интегрироваться дважды расточительно.

LiveKit Agents: самый быстрый путь в 2026 году

LiveKit Agents — это фреймворк на Python и Node для запуска безголовых ИИ-участников в комнатах LiveKit. В 2026 году это первое, к чему мы обращаемся в новых проектах: базовые возможности фреймворка идеально подходят для пайплайна перевода — подписка на дорожки, встроенный VAD, полноценный data channel, публикация аудиодорожки обратно в комнату. Скелет выглядит так:

from livekit import agents, rtc

async def entrypoint(ctx: agents.JobContext):
    await ctx.connect()
    async for track_pub in ctx.room.remote_participants.tracks():
        if track_pub.kind == rtc.TrackKind.AUDIO:
            audio_stream = rtc.AudioStream(track_pub.track)
            async for frame in audio_stream:
                text = await asr.stream(frame.data)
                translated = await mt.translate(text, target="es")
                await ctx.room.local_participant.publish_data(
                    payload=translated.encode(),
                    topic="captions.es",
                )

Это реальный код, а не псевдокод — 20 строк до субтитров. Чтобы публиковать озвучку перевода, добавьте rtc.LocalAudioTrack, созданный на основе вывода TTS, и вызовите publish_track. Запустите агента как воркер — диспетчер LiveKit автоматически назначит по одному агенту на комнату.

Масштабирование: запускайте агентов как Kubernetes Deployment за диспетчером LiveKit. Один под поддерживает примерно 10–20 одновременных комнат — в зависимости от ASR-провайдера. Настройте автомасштабирование по загрузке CPU и количеству активных агентов. Оставляйте 25 % запаса на всплески переподключений, когда регион «дрожит».

Agora: сырые аудиофрагменты и Conversational AI Engine

Agora предоставляет две корректные точки интеграции. Agora Conversational AI Engine — управляемый вариант: внутри комнаты от вашего имени работает пайплайн STT/LLM/TTS, а снаружи доступны хуки для предварительной и последующей обработки. Наблюдатель сырых аудиокадров — автономный вариант: вы регистрируете AudioFrameObserver, получаете PCM в onPlaybackAudioFrameBeforeMixing и отправляете PCM в выбранный ASR.

Чтобы публиковать переведённый голос, зарегистрируйте кастомный аудиоисточник (setExternalAudioSource) и передавайте PCM-кадры с вывода TTS. Важно соблюдать временные интервалы: Agora перебуферизует данные под свой внутренний таймер, поэтому отправляйте кадры с шагом 10 мс — даже если TTS не успел, дополняйте тишиной.

Субтитры передаются через Agora Signaling (RTM) или по отдельному data stream в RTC-канале. По умолчанию используется отдельный поток: его доставка привязана к аудиосессии — если она прервана, клиент точно знает, что субтитры недоступны.

Доставка субтитров: четыре механизма без мерцания

1. WebRTC data channel. Стандартный способ доставки в реальном времени. Отправляйте JSON-сообщения вида {t: ts, s: speakerId, p: “partial”|“final”, x: “translated text”} каждые 150 мс. Персонально каждому участнику, с минимальной нагрузкой на сервер.

2. Нативный RPC у SFU. publish_data в LiveKit, Agora RTM, sendAppMessage в Daily, командный канал Zoom SDK. Семантика у всех одинаковая, различия — в поведении при сбоях. Такой подход подходит, если важна надёжность и порядок доставки, которые обеспечивает вендор.

3. Server-sent events. Для внешних наблюдателей — модераторских консолей, сервисов доступности, мониторинга комплаенса. Отделяет тайминг субтитров от RTC-сессии, устойчив к джиттеру, удобен для аудита.

4. WebVTT-дорожка. Полезна, когда вы дополнительно записываете звонок и хотите, чтобы плееры (HLS, DASH, Mux) отображали субтитры нативно. Генерируйте VTT-ку из того же потока промежуточных результатов; при записи повышайте до уровня only-final.

Ловушка с мерцанием субтитров, в которую попадает каждая команда — рендеринг сырых промежуточных результатов. Стриминговый ASR постоянно пересматривает свои предварительные расшифровки по мере поступления аудио, и текст на глазах меняется. Решение такое: буферизуйте промежуточные результаты на 150 мс, игнорируйте правки, старше текущего кадра, и отправляйте текст в финальную версию, когда ASR сообщает is_final=true.

Синхронизация: используйте часы RTCP, а не системные

Самый частый баг в продакшене первых версий интеграции: субтитры расходятся со звуком, потому что рендер субтитров использует системные таймстемпы, а аудио воспроизводится по медиа-часам SFU. Через 20 минут долгой встречи субтитры отстают на несколько секунд.

Правильный подход: помечать каждый субтитр таймстемпом RTP того аудиокадра, который обработал ASR, а на стороне получателя переводить его в NTP с помощью RTCP Sender Report. Такой функционал поддерживают все крупные клиенты и SFU: rtc.AudioFrame.timestamp в LiveKit, RTP-заголовок у consumer-объектов в mediasoup, renderTimestamp у Web Audio в MediaStreamTrackProcessor. Прикрепляйте таймстемп к каждому промежуточному результату — пусть рендер сам выравнивает субтитры по времени воспроизведения.

Для переведённого голоса применяется та же дисциплина, что и для оригинала, плюс одно важное условие: публикуйте сэмплы TTS с тем же шагом, что и исходное аудио — 10 мс при частоте 48 кГц. Если TTS отстаёт, дополняйте тишиной — так джиттер-буферу SFU работать удобнее. Отбрасывать кадры выгоднее, чем накапливать рассинхрон по времени.

Переподключения, повторные входы и согласованность состояния

Агент перевода, который переживает сетевой сбой, — это тот, кто держит продакшен в три часа ночи. Три правила:

1. Состояние живёт вне агента. Глоссарий, языковые настройки, персональные переопределения и метаданные встречи хранятся в Redis или базе данных сессии. Ключ — roomId. После переподключения агент восстанавливает состояние быстрее чем за 100 мс.

2. Идемпотентность вызовов перевода. Каждый промежуточный результат имеет порядковый номер по говорящему. Если агент переподключился и отправил тот же фрагмент повторно, MT-сервис видит тот же seq и возвращает закэшированный результат. Это устраняет мерцание при переподключениях.

3. Чистая семантика отключения. Когда агента вытесняют, отписывайтесь от дорожек, сбрасывайте буфер TTS и публикуйте финальный data-кадр «перевод приостановлен». Клиенты, не получившие кадров дольше 3 с, должны показывать чип «перевод переподключается», а не молча оставлять устаревший текст.

Клиентская сторона тоже важна: при переподключении пользователя (например, после сна ноутбука или смены сети) клиент должен запросить у агента текущее состояние субтитров через data channel, а не ждать следующего промежуточного результата. Тот, кто заходит в 40-минутную встречу, хочет контекст, а не только следующее предложение.

Масштабирование: пулы воркеров, шардирование, контроль расходов

Один процесс перевода на звонок не масштабируется. Закладывайте пул с самого начала.

Пул воркеров. Kubernetes Deployment с HPA. Для LiveKit каждый под — это воркер LiveKit Agent; диспетчер сам распределяет комнаты. Для Mediasoup и кастомных SFU используйте перед воркерами шард-роутер: сессия → под воркера, ключ — consistent-хеш от roomId. Масштабируйте автоматически по количеству активных сессий и по загрузке CPU.

Маршрутизация по парам языков. Не распределяйте все языки по всем воркерам. Создайте отдельные пулы для крупных языковых групп (латиница, CJK, индийские, арабский, германские), чтобы модели оставались в оперативной памяти, а ASR-провайдеры могли использовать региональную близость.

Региональное размещение. Размещайте воркеры в том же регионе, что и egress вашего SFU. Воркер во Франкфурте, обрабатывающий поток из токийского SFU, будет тратить 180 мс трансатлантической задержки на каждый кадр — одной такой задержки достаточно, чтобы превысить бюджет.

Контроль расходов. Считайте минуты перевода по тенантам и записывайте их в тот же спан, что и метрики биллинга. Ограничьте бесплатные тарифы на уровне ASR-воркера — нет смысла тратить кредиты Deepgram на пользователей, злоупотребляющих сервисом. Корпоративных клиентов направляйте на зарезервированные воркеры, чтобы нагрузка от бесплатных пользователей не нарушала SLA.

Мобильные платформы: ловушки интеграции на iOS и Android

Мобильная интеграция добавляет 300–600 мс к десктопному пайплайну и вносит платформенные особенности, из-за которых командам приходится тратить недели, если они выявляются поздно.

iOS. Используйте категорию AVAudioSession .playAndRecord с режимом .voiceChat. Включите фоновый режим voip и разрешение audio, чтобы перевод продолжал работать, когда приложение свернуто. Для интеграции с CallKit потребуется отдельный блок маршрутизации для дорожки переведённого голоса — по умолчанию система направляет только основное аудио звонка, а не вашу дополнительную дорожку.

Android. Используйте foreground service с FOREGROUND_SERVICE_PHONE_CALL (API 34+) или FOREGROUND_SERVICE_MEDIA_PROJECTION — в зависимости от задачи. AudioManager.MODE_IN_COMMUNICATION включите для подавления эха. Будьте осторожны с функцией Adapt Sound на устройствах Samsung — она может изменить аудиомаршрутизацию после отключения Bluetooth и незаметно отключить вторичную аудиодорожку, если не подтвердить её заново.

Общее. На мобильных устройствах локальный TTS (Apple Neural TTS, Google TTS) работает быстрее облачного — экономится 200–400 мс на запрос. При этом можно пожертвовать качеством: пользователи важнее считают, чтобы перевод не отставал, чем чтобы он звучал идеально.

Аутентификация, JWT и изоляция тенантов

Воркер перевода — это ещё один участник с особыми возможностями: ему нужен токен с минимально необходимыми правами, которые не должны делиться между тенантами.

LiveKit. Выдавайте JWT, привязанный к комнате, с правами canSubscribe, canPublish, canPublishData, без прав администратора. Срок действия — короткий (5–10 минут), с возможностью обновления. Идентификатор начинайте с префикса agent:, чтобы клиенты могли отфильтровывать его в интерфейсе.

Agora. Токен с ролью Role_Publisher и правом на передачу необработанного аудио; привязан к конкретному каналу; обновляйте перед событием onTokenPrivilegeWillExpire.

Изоляция тенантов. API-ключи для ASR/MT/TTS привязывайте к тенанту, а не к окружению. Учётные данные, с которыми воркер обрабатывает звонок тенанта A, не должны работать для тенанта B — даже если из-за ошибки конфигурации они станут доступны. Регулярно меняйте ключи по расписанию; настраивайте алерты при попытке их использования в другом тенанте.

Сетевой исход. Воркеры перевода должны иметь доступ только к эндпоинтам ASR/MT/TTS. Открытый исходящий трафик запрещён, уязвимость SSRF исключена. Security-группы VPC настроены с явным списком разрешённых адресов (allow-list); всё остальное — запрещено.

Тестирование: симуляция аудио, моки ASR, SLO по задержкам

Продакшен-пайплайнам перевода нужно три уровня тестирования, чтобы оставаться зелёными.

Уровень 1 — модульные тесты и моки. Подменяйте провайдеры ASR и MT детерминированными ответами. Запускайте на каждом PR. Проверяют корректность проводки, а не качество работы.

Уровень 2 — стенд с симулированным аудио. Тестовый стенд подключается к комнате LiveKit/Аgora как синтетический участник, воспроизводит размеченную аудиофикстуру и проверяет, что в канале данных субтитров появляется ожидаемый текст в пределах допустимой задержки. Запускайте такие тесты ночью против стейджинга. Они ловят регрессии в таймингах обработки аудио.

Уровень 3 — WER на эталонном датасете. Еженедельная выборка аудио из продакшена (с согласия пользователей) сравнивается с расшифровками, сделанными вручную, по каждому языку. Если 95-й перцентиль WER за неделю растёт более чем на 2 пункта — срабатывает алерт. Такой подход ловит регрессии в качестве ASR-провайдеров, которые не удаётся выявить другими способами.

Ставьте все три. Команды, которые отгружают только уровень 1, узнают о проблемах с задержками и качеством от пользователей.

Резервные провайдеры и плавная деградация

Любой провайдер ASR/MT/TTS будет терять качество минимум дважды в год. Создавайте резерв до первого сбоя, а не после.

Многопровайдерный ASR. Основной — Deepgram, резервный — Azure Speech. Circuit breaker на сессию: если задержка первого промежуточного результата превышает SLO N раз подряд, переключайтесь на резервный провайдер до конца сессии. Логируйте каждое переключение; алерт по частоте.

Деградированные режимы. Только субтитры, если не работает TTS. Только субтитры на оригинальном языке, если не работает MT. Баннер «перевод временно недоступен», если вышел из строя весь пайплайн. Молчаливая деградация всегда хуже честной ошибки.

Аварийный выключатель. Один конфиг-флаг отключает перевод для тенанта, региона или для всех сразу. Проверяйте его работу раз в квартал. Ничто так не помогает собраться, как потеря перевода в продакшене в 9 утра по Токио.

Субпроцессоры, DPIA и документы по соблюдению требований, которые возникают при интеграции

Подключение перевода в реальном времени добавляет субпроцессоры, а субпроцессоры требуют работы по комплаенсу. Не оставляйте это юристам за три дня до релиза.

DPIA. Голосовое аудио — это персональные данные. По GDPR это особая категория биометрических данных, если система может идентифицировать человека по голосу. Проводите оценку воздействия на защиту данных (DPIA) до подписания контрактов с поставщиками ASR/MT/TTS. Зафиксируйте цель обработки, сроки хранения, правила доступа и оставшиеся риски.

Список субпроцессоров. Каждый поставщик, участвующий в обработке аудио или расшифровке, включается в ваш публичный список субпроцессоров до запуска функции. Если по договору с клиентом требуется уведомлять о новых субпроцессорах за 30 дней, учитывайте это при планировании.

Соглашение о бизнес-ассоциировании (BAA) для HIPAA. У Deepgram, Azure, Google и AWS есть BAA. У DeepL и ElevenLabs на стандартных тарифах его пока нет — медицинское аудио отправляйте только через провайдеров с BAA, даже если качество чуть хуже.

Локализация данных. Сессии из ЕС направляйте на европейские эндпоинты вендоров, американские медицинские — на американские, с соблюдением BAA. Настройте маршрутизацию в диспетчере агентов, а не в сетевой инфраструктуре — так проще проводить аудит.

Каркас принятия решения — выберите паттерн интеграции по пяти вопросам

1. На какой вы платформе? LiveKit или Agora → серверный бот. Zoom или Teams → инлайн-обработка медиа. Mediasoup или собственное решение → egress из SFU. Daily или наследники Twilio SDK → захват на клиенте или бот — в зависимости от зрелости SDK.

2. Нужен ли переведённый голос или достаточно субтитров? Субтитры — достаточно data channel. Голос — убедитесь, что ваша платформа поддерживает публикацию вторичной аудиодорожки от серверного участника без отдельной лицензии.

3. Какой потолок одновременности на первый год? Меньше 100 одновременных комнат — одного регионального пула воркеров достаточно. Больше 500 — региональные пулы с первого дня, автомасштабирование и шардирование по roomId.

4. Мобильная платформа — поверхность первого класса? Да → вкладывайтесь в локальный TTS и работу с foreground-сервисами заранее, а не ретрофитом.

5. Регуляторный контур? HIPAA → только провайдеры с BAA, региональная маршрутизация, никакого долгосрочного хранения аудио. GDPR → европейские эндпоинты, опубликованный список субпроцессоров, DPIA на руках.

Пять интеграционных ловушек, которые топят проекты

1. Системные часы для синхронизации субтитров. На демо работает, в продакшене дрейфует. Опирайтесь на таймстемпы из RTCP Sender Report и прикрепляйте их к каждой полезной нагрузке субтитров.

2. Один воркер на комнату навсегда. Как только конкуренция превысит ёмкость воркера, одна комната «задушит» остальные. Размеряйте поды на 10–20 комнат и автомасштабируйте агрессивно.

3. Эхо в ASR. Переведённый голос возвращается в комнату, ASR его распознаёт, а пайплайн переводит собственный вывод. Помечайте синтетическую аудиодорожку метаданными и пропускайте её на уровне AudioFrameObserver.

4. Нет идемпотентности при переподключениях. Агент «дёрнулся» и переотправил промежуточные результаты — субтитры начали мерцать и откатываться назад. Порядковые номера по говорящему плюс кэш на стороне MT, ключ — содержимое промежуточного результата, полностью решают эту проблему.

5. Тишина в фоне на мобильных. iOS «усыпляет» приложение, и перевод обрывается на середине фразы. Проблема решается фоновыми режимами, foreground-сервисами и keep-alive аудиокадрами — а не надеждой.

KPI для интегрированного пайплайна перевода

KPI качества. Задержка первого промежуточного результата: P50 ≤ 500 мс, P95 ≤ 1 с. WER на еженедельной выборке эталонного датасета — не более 8 % по топ-10 языкам. Покрытие субтитрами — не менее 90 % произнесённых слов, дошедших до зрителей.

Бизнес-метрики. Доля сессий с включённым переводом. Рост выручки на неанглоязычных рынках по кварталам. Доля обращений в поддержку, связанных с переводом (цель — снизить после 6-й недели после запуска).

KPI надёжности. Успешность диспетчеризации агентов — не менее 99,5 %. Количество переключений провайдеров — не более 2 в месяц (если больше — стоит пересмотреть договорённости). Стоимость одной переведённой минуты отслеживается по тенантам и парам языков.

Когда НЕ стоит пока интегрировать перевод в реальном времени

Некоторым продуктам надо подождать. Если вы планируете мигрировать видеотранспорт (Twilio → LiveKit, Jitsi → Agora), сначала завершите переход на новый транспорт, а уже потом внедряйте изменения в стек. Совмещение двух миграций удваивает риски, но не приносит дополнительной ценности.

Если вы ещё не достигли product-market fit, а проблемы с локализацией не входят в тройку главных запросов пользователей — отложите. Перевод в реальном времени — это сайдквест на 10–14 недель; лучше потратьте это время на то, что действительно нужно рынку.

Если ваша платформа не поддерживает серверные хуки для аудио и не планирует их внедрять — так бывает у некоторых ранних managed-SDK — то субтитры, созданные на стороне клиента, остаются временным решением. Но не стоит инвестировать в озвучку с переводом, пока платформа не подготовится.

FAQ

Использовать LiveKit Agents или строить egress на Mediasoup?

Если у вас ещё нет Mediasoup, на LiveKit Agents проще и дешевле развернуть систему. Если Mediasoup уже используется по другим причинам — например, из-за цены, контроля или кастомного поведения SFU — поддержка egress есть. Менять SFU только ради перевода не имеет смысла.

Как опубликовать переведённый голос в Daily.co?

Подключите безголового участника Daily (Node.js с daily-js и аудиоисточник через Puppeteer или нативную интеграцию SDK). Публикуйте кастомную дорожку с переведённым звуком; клиенты подписываются по идентификатору участника. Паттерн сложнее, чем у LiveKit Agents, но работает.

Какой полезной нагрузкой передавать субтитры через data channel?

Маленький JSON на кадр: {t: rtpTs, s: speakerId, p: “partial”|“final”, l: “es”, x: “text”, seq: n}. RTP-таймстемп нужен для синхронизации, поле sequence — для упорядочивания и идемпотентности, language — чтобы поддерживать многоязычные комнаты, а флаг partial/final показывает клиенту, когда можно прекратить анимацию.

Сколько комнат может обслуживать один воркер перевода?

Для каскадного пайплайна с Deepgram Nova-3 (стриминговый ASR) и DeepL MT один воркер на 2 vCPU / 2 GB RAM спокойно справляется с 10–15 одновременными комнатами при двух говорящих в каждой. Самостоятельный ASR на GPU A10G обрабатывает 20–40 потоков — в зависимости от модели. Рассчитывайте мощности с запасом.

Как остановить эхо-обратную связь при публикации переведённого голоса?

Помечайте переведённую дорожку устойчивым идентификатором (идентификатор участника agent:translator:* в LiveKit, именованный аудиоисточник в Agora). Фильтруйте дорожки с этим идентификатором на уровне AudioFrameObserver или при подписке — тогда ASR никогда не будет обрабатывать собственный вывод. Делайте это в агенте, а не на клиенте: один централизованный фильтр проще проверить и поддерживать.

Можно ли встроить перевод в реальном времени в Zoom-встречи без использования приложения Zoom?

Чисто — нет. Правильный путь — Zoom Video SDK с сырым медиа, оформленный как приложение в Zoom Marketplace. Обходные пути через скрейпинг или постобработку существуют, но ломаются раз в несколько месяцев при обновлении клиента Zoom. Для нативной интеграции используйте именно Video SDK и закладывайте время на ревью.

Как обработать пользователя, который переподключается посреди встречи с длинным контекстом?

Держите скользящий транскрипт у агента на сервере. При переподключении клиент отправляет по data channel запрос на последние N секунд переведённых субтитров; агент отвечает одной нагрузкой-каплей. Пользователь видит пропущенный контекст, а не оказывается посреди фразы.

Реалистичные сроки интеграции для уже существующего WebRTC-продукта?

10–14 недель на интеграцию в продакшен с LiveKit или Agora при работе с командой Фора Софт и нашим инструментом Agent Engineering. Использование Zoom SDK, Teams или кастомных решений на базе Mediasoup добавляет 3–5 недель на платформенную разработку. Подход mobile-first требует дополнительно 2–4 недели на реализацию слоя под операционные системы.

Что почитать дальше

Готовы подключить перевод к видеостеку, не сломав продакшен?

Форма интеграции — серверный бот, инлайн-преобразование, egress из SFU или захват на клиенте — определяет всё остальное. LiveKit Agents и Agora Conversational AI Engine — самые быстрые решения в 2026 году; Zoom Video SDK и Teams Media Extensibility — лучший выбор для нативной интеграции с этими платформами; egress из SFU — оптимальный вариант, если медиаслой уже у вас. Субтитры передаются через WebRTC data channel с RTP-таймстемпами, без мерцания при промежуточных результатах. Голос публикуется отдельной дорожкой, с тем же темпом, что и исходное аудио, с эха-отфильтровкой по идентификатору.

Продукты, которые здесь побеждают, с самого начала решают задачи масштабирования, переподключения, идемпотентности и соответствия требованиям. Те, кто проигрывает, откладывают их на 90-й день. Интеграция в продакшен занимает 10–14 недель, если с самого начала выбран правильный паттерн; мы удерживаем такие сроки на платформах — от глобальных виртуальных классов до телемедицины с HIPAA.