SIP-интеграция перевода: плейбук 2026 для инженеров

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

Фора Софт занимается разработкой программного обеспечения для видео и голоса в реальном времени с 2005 года: 250+ проектов, 2 миллиона часов разработки, заказчики из 17+ стран, 50 специалистов в штате без субподряда.

Мы разработали ТрансЛингвист: платформу для живого многоязычного перевода, которая объединяет ИИ и работу 8 000+ проверенных переводчиков по 62 языковым парам, сочетая режимы «только ИИ» и «ИИ с проверкой человеком» на мероприятиях и учебных занятиях. Тот же опыт с потоковым голосовым каналом в реальном времени лежит в основе Таннел, нашего сервиса p2p видеозвонков на WebRTC с входом по номеру комнаты. Мы также разработали ядро для трансляций в реальном времени для БрейнСерт, платформы для уроков в реальном времени с доступностью 99,995% и свыше 500 миллионов минут проведённых занятий, где бюджет задержки был таким же критичным параметром, как и в SIP-переводе.

Мы применяем агентную разработку на всех этапах: под контролем ведущих инженеров она ускоряет сборку интеграций реального времени в 4-10 раз по сравнению с классическим подходом. Если вы реализуете функцию SIP-перевода, скорость здесь особенно важна: рынок вендоров ASR, MT и TTS меняется буквально каждую неделю.

Продукт в реестре отечественного ПО Минцифры, программа «Мундиаль», реестровая запись № 21522.

Что на самом деле такое SIP-интеграция перевода

Если убрать маркетинг, SIP-интеграция перевода: четырёхэтапный потоковый конвейер, подключённый к SIP- или WebRTC-каналу передачи медиа, с чёткой маршрутизацией, определяющей, кто что слышит.

Захват. Медиасервер форкует аудиопоток каждого участника в ИИ-сайдкар. Форк предпочтительнее перехвата: если с пайплайном что-то пойдёт не так, оригинальный звонок продолжит работать.

Streaming ASR. Сайдкар запускает автоматическое распознавание речи, которое почти в реальном времени выдаёт промежуточные и финальные гипотезы, а не полный транскрипт после окончания фразы, который для разговора уже слишком медленный.

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

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

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

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

Бюджет задержек, который решает всё

Весь пользовательский опыт SIP-перевода зависит от сквозной задержки: от момента, когда человек начинает говорить, до момента, когда его слышат на другом конце через мост. Все решения по вендорам и архитектуре системы сводятся к тому, чтобы уложиться в этот один ключевой параметр.

Чтобы разговор был удобным, переведённое аудио должно доходить до слушателя через 1-2 секунды после произнесённой реплики. Задержка больше 3 секунд означает, что обе стороны начинают говорить одновременно, и функция ощущается неработающей. Ниже 800 мс: ощущение живого синхронного перевода. Путь от неудобного к комфортному: это накопительный бюджет по четырём этапам.

Задержки накапливаются, поэтому даже сокращение времени на каждой стадии на 20 процентов заметно улучшает UX. Самая большая упущенная возможность для большинства команд: размещение медиасервера и ИИ-сайдкара в разных облачных регионах. Половина «плохой» задержки в демо возникает из-за потока, который успевает пересечь два континента и вернуться обратно.

Четыре компонента пайплайна в деталях

Streaming ASR: основа. Качество ASR определяет качество последующего перевода: плохой транскрипт даёт уверенно звучащий, но неправильный перевод. Streaming ASR для SIP-перевода требует промежуточных гипотез каждые 100-300 мс, детектора голосовой активности, адаптированного под телефонную полосу, надёжного endpointing и определения языка, если исходный язык заранее неизвестен.

Сильные кандидаты сегодня: Deepgram Nova, AssemblyAI Universal-Streaming, Google Cloud Speech-to-Text Chirp и Azure Speech (обе платформы напрямую недоступны для оплаты российскими юрлицами), NVIDIA Parakeet и Canary, Speechmatics, а также открытый Whisper на собственном хостинге. Whisper отлично работает офлайн, но «из коробки» не поддерживает потоковую обработку без доработки архитектуры. Deepgram и AssemblyAI предлагают готовые потоковые API.

Streaming MT: движок диалога. Машинный перевод для живых звонков отличается от перевода документов. Он должен обрабатывать ввод по мере поступления, сохранять контекст между репликами одного участника, корректно работать с переключением языков и точно распознавать имена, названия и другие сущности. Стоит протестировать DeepL Translator API, Microsoft Azure Translator (приём платежей от российских юрлиц напрямую недоступен), Google Translate с поддержкой потока, LLM-решения на базе современных языковых моделей и open-source модели вроде NLLB-200 и M2M-100 с поддержкой потоковой передачи.

LLM всё чаще применяются в задачах разговорного машинного перевода, потому что лучше сохраняют контекст и соблюдают вежливые формулировки. Компромисс: задержка. Прямой вызов LLM на каждую реплику обычно слишком медленный. Рабочий паттерн: потоковый вызов LLM с коротким контекстом и кэшированным состоянием сессии.

Streaming TTS: голос, который слышит пользователь. TTS формирует общее впечатление от работы всей функции. Для SIP-перевода важны такие характеристики: первое аудио должно приходить за 300 мс или быстрее, хорошее качество в телефонной полосе 8-16 кГц и возможность разбивать текст и проговаривать части предложений без артефактов. ElevenLabs и Cartesia сегодня лидируют по естественности речи, а Amazon Polly Neural предлагает выгодное соотношение цены и качества на большом объёме синтеза.

Медиамост: где ASR встречается с SIP. Медиамост перенаправляет аудио из SIP-звонка в ИИ-обработку и возвращает переведённый звук обратно. Практические решения на 2026 год: FreeSWITCH с модулем mod_audio_fork, Asterisk с ARI и External Media, Kamailio как SIP-прокси перед медиасервером, Janus Gateway для WebRTC-моста и LiveKit Agents для ИИ-ориентированных сборок. Наша команда, работающая с ИИ-агентами LiveKit и кастомной WebRTC-архитектурой, ежедневно использует этот уровень. В чисто видеоплатформах те же четыре компонента собираются иначе: паттерны интеграции перевода в видео опираются на WebRTC-дорожки, где нет ни узкой телефонной полосы, ни DTMF.

Эталонная архитектура SIP-перевода

Схема ниже: та, что мы используем на большинстве SIP и WebRTC-проектов с переводом. Она имеет чёткие предпочтения, но не является экзотической: её сможет внедрить любая компетентная команда.

SIP / PSTN участник           WebRTC участники
        |                            |
        v                            v
Kamailio SIP proxy  --->  Media server (FreeSWITCH / LiveKit / Janus)
                                    |
                                    |-- форк аудио по каждому говорящему
                                    v
                          ИИ-сайдкар кластер (тот же регион)
                                    |
                                    |-- Streaming ASR (Deepgram / AssemblyAI / Whisper)
                                    |-- Определение языка и диаризация дикторов
                                    |-- Streaming MT (DeepL / Google Translate / LLM)
                                    |-- Streaming TTS (ElevenLabs / Cartesia / Polly)
                                    |
                                    v
                    Медиасервер вставляет переведённое аудио обратно
                    Языковые предпочтения по каждому участнику
                    Микс с оригиналом на низкой громкости (опционально)
                                    |
                                    v
                    Сервис транскриптов (архив, субтитры)
                    Журнал для регулируемых развёртываний

Три проектных решения в этой архитектуре дают непропорционально большой эффект. Первое: ИИ-сайдкар всегда размещается рядом с медиасервером, чтобы сократить сетевую задержку на 100-400 мс. Второе: диаризация дикторов выполняется на сайдкаре, а не отдельно: чтобы микшировать переведённое аудио, нужно знать, кому принадлежит каждый фрагмент речи. Третье: при подключении каждый участник указывает предпочитаемый язык, и медиасервер направляет нужный переведённый микс каждому: поэтому в конференции из четырёх человек на трёх языках получается четыре индивидуальных аудиопотока, а не один общий.

Особенности интеграции с SIP и PSTN

У SIP-стороны есть конкретные подводные камни, которые не видны в чисто WebRTC-демо. Часть из них проявляется уже при базовой интеграции SIP в платформу видеосовещаний, а перевод добавляет к ним свои.

Узкополосные кодеки и звук телефонного звонка. PSTN и многие SIP-транки используют G.711 на 8 кГц. Качество распознавания речи на узкополосном звуке заметно хуже, чем у Opus 48 кГц в широкополосном режиме. Выбирайте поставщика ASR, который явно поддерживает телефонное аудио, либо обучайте акустические модели на телефонных записях. Где возможно, используйте на SIP-транке G.722 или Opus: прирост точности транскрипции ощутим.

DTMF, IVR-подсказки и музыка на удержании. Эти сигналы не должны проходить через перевод: они создают шум и могут вызывать ложные распознавания. Используйте SIP-сигнализацию, чтобы отключать перевод в неречевых состояниях и включать его снова, когда разговор возобновляется.

Мост между WebRTC-клиентами и SIP-телефонами. WebRTC-участники ждут задержку «рот-ухо» ниже 200 мс, SIP-телефоны терпят 300 мс и выше, а соединение через PSTN часто добавляет ещё 150 мс. Перевод, добавляя 1-2 секунды, ломает эхоподавители при неаккуратной реализации. Решение: пускать переведённое аудио по отдельной дорожке, а не подмешивать его в основной путь звонка.

Сравнение вендоров

Матрица ниже: та, которой мы пользуемся с клиентами. Цены ориентировочные: в 2026 году условия в этой нише меняются буквально каждую неделю.

У части облачных вендоров из общего рейтинга рынка, включая крупные американские облачные платформы для ASR, MT и TTS, приём платежей от российских юридических лиц напрямую недоступен: это стоит учитывать на этапе выбора поставщика, а не после интеграции.

Мини-кейс: как мы это собираем в продакшене

Конкретный паттерн из нашего портфеля. В ТрансЛингвист многоязычные участники, работа с несколькими языковыми парами одновременно и переключение между режимами «только ИИ» и «ИИ с проверкой человеком»: это часть основного продукта, а не дополнительная функция. В Таннел тот же голосовой канал в реальном времени лежит в основе p2p видеозвонков по WebRTC. Из того же ряда SIP в платформе iMind, которую мы делали под регулярные рабочие встречи распределённых команд.

Во всех подобных сборках повторяется один и тот же подход: медиаслой на Kamailio, FreeSWITCH или LiveKit, ИИ-сайдкары в том же регионе, потоковый ASR, потоковый MT, потоковый TTS и маршрутизация языка для каждого участника при микшировании. Там, где у клиентов есть регуляторные ограничения, в медицине, финансах, образовании, мы добавляем в ИИ-пайплайн человека для критических моментов и резервную линию с квалифицированным переводчиком.

Когда оставлять переводчика-человека в контуре

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

Медицинские консультации и клинические решения. Ошибка в дозировке препарата или описании симптомов может навредить пациенту. Для медицинских сценариев в России действуют требования 323-ФЗ и профильных приказов Минздрава: ИИ может помогать при первичной коммуникации, но не должен заменять человека в клинически значимом разговоре.

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

Финансовые продажи и регулируемые консультации. Требования Банка России к фиксации коммуникаций с клиентами и точности раскрытия условий продукта означают, что автоматический перевод в регулируемом разговоре создаёт дополнительные вопросы к аудиту и ответственности: их нужно продумывать заранее вместе с юристами компании.

Качество, точность и смещения

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

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

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

Что регулирует закон

Голос и текст участника: биометрические и персональные данные по 152-ФЗ. Обработка требует отдельного согласия, а хранение и обработка данных российских пользователей должны быть организованы с учётом требований к локализации персональных данных.

Для медицинских сценариев дополнительно действуют требования 323-ФЗ и профильных приказов Минздрава. Для образовательных сценариев с участием несовершеннолетних применяются требования 273-ФЗ вместе с 152-ФЗ.

Для организаций, относящихся к критической информационной инфраструктуре, и для регулируемых развёртываний в контакт-центрах значение имеет соответствие требованиям ФСТЭК и 187-ФЗ: это стоит закладывать в архитектуру пайплайна с самого начала, а не добавлять после запуска.

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

Модель затрат: во что реально обходится минута переведённой конференции

Стоимость ИИ-пайплайна рассчитывается по минутам, и главным фактором, влияющим на цену, является выбор поставщика на каждом этапе.

Итоговая стоимость минуты на коммерческих API обычно в 3-5 раз выше, чем на self-hosted или гибридном пайплайне. Для небольшого развёртывания почти всегда лучше использовать коммерческие API: затраты на инженерию при запуске self-hosted-моделей перевешивают возможную экономию. Когда объём переводов превышает примерно 100 000 минут в месяц, self-hosted или гибридный пайплайн начинает окупаться.

Разработка SIP-интеграции перевода под ключ у Фора Софт начинается от 450 000 ₽: итоговая стоимость зависит от числа языковых пар, требований к self-hosted-компонентам и требований к соответствию.

Фреймворк принятия решений в пяти вопросах

Какие языковые пары реально нужны? Если четыре верхние пары покрывают 90 процентов трафика, начните с них и предусмотрите резервный путь для менее востребованных.

Каков бюджет задержек? Две секунды от начала речи до её восприятия: минимально допустимый порог. Если текущая архитектура не укладывается в этот лимит, смена поставщика ничего не исправит: нужно менять архитектуру.

Каков уровень риска у этих звонков? Бизнес-встречи, медицинские консультации, судебные допросы, поддержка клиентов. Чем выше риск, тем больше нужен человек в процессе и строже должны быть журналы событий.

Нужно ли качество голоса или достаточно читаемости? Субтитры вместе с TTS: это один продукт, только субтитры: совсем другой. Качество синтеза речи сильно влияет на стоимость и восприятие.

В каких регионах должны лежать данные? Требования 152-ФЗ и отраслевые требования к хранению данных ограничивают выбор поставщиков. Составляйте короткий список на основе соответствия требованиям, а не наоборот.

Ответы на эти пять вопросов складываются в план внедрения перевода речи для бизнеса, из которого уже видно, нужен ли отдельный SIP-контур или хватит перевода внутри WebRTC.

Пять подводных камней, тихо убивающих переведённые звонки

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

Межконтинентальные пайплайны. Участник на одном континенте, медиасервер на другом и ASR-эндпоинт на третьем почти наверняка дадут задержку в несколько секунд. Размещайте все компоненты как можно ближе друг к другу.

Отсутствие управления глоссарием. Продукт, который путает юридический термин или искажает название препарата, теряет доверие уже в первом демо. Создавайте подсистему глоссария с самого начала.

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

Восприятие перевода как кнопки, а не как UX. Пользователю нужны подсказки на экране: кто говорит, на каком языке, насколько уверенно модель, возможность вернуться к оригинальному голосу.

KPI: что измерять

Качественные KPI. Word Error Rate ASR на реальном телефонном звуке: цель ниже 10 процентов для топовых языковых пар, ниже 15 процентов для второго уровня. BLEU и COMET на курируемом тестовом наборе по каждой языковой паре, с обновлением ежеквартально. Mean Opinion Score на сэмплах TTS: выше 4,0.

KPI задержки. Медиана от начала до конца ниже 1,5 секунды, p95 ниже 2,5 секунды, p99 ниже 4 секунд. Рассчитывайте отдельно для каждого вендора, региона и языковой пары.

Бизнес-метрики. Рост конверсии при наличии перевода по сравнению с вариантом без перевода, стоимость минуты перевода, уровень удовлетворённости клиентов на звонках с переводом и без, сокращение времени, затрачиваемого переводчиками, там, где это возможно.

Когда не стоит браться за это сейчас

Не каждому продукту нужен встроенный SIP-перевод. Если межъязычный трафик составляет менее нескольких процентов, можно обойтись простым решением: пригласить переводчика как обычного участника звонка. Если регуляторные требования предписывают квалифицированных переводчиков-людей на всех этапах, ИИ-решение станет лишь дополнением, а не заменой. Если у команды нет ресурса на поддержку мультивендорного пайплайна, включая глоссарий и проверку соответствия, запуск демо принесёт больше разочарования, чем пользы. Во всех трёх случаях дешевле начать с архитектурного аудита перед стартом и понять, что выдержит текущий контур звонков.

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

FAQ

Какую минимальную задержку человек реально замечает в переведённом звонке?

Задержка в 500-800 мс переносится легко, 1-2 секунды воспринимаются как заметная пауза в конференц-связи, а выше 3 секунд стороны начинают перебивать друг друга. Целевые значения: p50 около 1,5 секунды, p95 около 2,5 секунды.

Стоит ли брать Whisper для потоковой обработки?

Whisper: хороший батчевой ASR и надёжная основа для множества языков, но он не готов к стримингу «из коробки»: для потоковой обработки нужно аккуратно настраивать чанкование, endpointing и задержку. Готовые потоковые сервисы обычно обеспечивают меньшую задержку при меньших инженерных усилиях.

Можно ли в проде использовать LLM для машинного перевода?

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

Как подключить звонящего из PSTN к переведённой конференции?

Подключите SIP-транк к Kamailio-прокси, завершите на FreeSWITCH или Asterisk, форкните аудио звонящего в ИИ-сайдкар и вставьте переведённое аудио по отдельному каналу. Используйте узкополосный кодек и ASR-модели, обученные на телефонном звуке.

Нужна ли диаризация дикторов?

Для звонков один на один нет: каждый участник говорит сам за себя. Для звонков с тремя и более участниками да: диаризация определяет, кому принадлежит каждая реплика, что важно для маршрутизации переведённого аудио и создания читаемых транскриптов.

Достаточно ли одного ИИ-перевода для медицинских или юридических звонков?

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

Сколько времени занимает MVP?

Демо на одну языковую пару в WebRTC с managed-стеком ASR, MT и TTS опытная команда собирает за 2-4 недели. Продакшн-готовое мультиязычное развёртывание с SIP-мостом, маршрутизацией дикторов, проверкой соответствия и мониторингом обычно занимает 8-16 недель.

Планируете внедрить перевод в реальном времени в SIP- или WebRTC-продукт?

Свяжитесь с Фора Софт: за 3 рабочих дня подготовим план MVP, аудит архитектуры и оценку стоимости бесплатно.