SIP в видеоконференциях 2026: архитектуры, цена и шлюзы

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

В компании Фора Софт мы 21 год создаём медиа-инфраструктуру для более чем 625 видеопродуктов: переговорные комнаты, телемедицинские консультации, залы суда, e-learning классы и корпоративные тренинговые платформы. Почти каждый корпоративный клиент рано или поздно задаёт один и тот же вопрос: «Сможет ли руководитель из переговорной Cisco подключиться к WebRTC-вызову?», «Смогут ли клиенты дозваниваться с обычного телефона?», «Будет ли ваша платформа работать с АТС, за которую мы уже заплатили?». Ответ — SIP-интеграция.

Это руководство — краткая версия внутреннего runbook, который мы выдаём новым инженерам по видео. В его основе — проекты вроде Valt (платформа удалённых допросов для правоохранительных органов США), наши решения для телемедицины, где пациентам нужно дозваниваться со стационарных телефонов, и корпоративные тренинговые платформы, где 40% участников до сих пор подключаются через устройства Cisco или Poly.

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

Что такое SIP в 2026 году (за 90 секунд)

SIP (Session Initiation Protocol, RFC 3261) — это протокол на уровне сигнализации в бизнес-телефонии. Он определяет, кто кому звонит, какой кодек использовать и через какой IP-адрес устанавливать соединение. Сам аудио- или видеопоток он не передаёт — этим занимается RTP. SIP инициирует вызов; RTP — это сам звук, который идёт с телефона.

Сама спецификация не менялась с 2002 года. Изменился способ передачи данных. В 2026 году WebRTC-браузер может использовать SIP поверх WebSocket (RFC 7118) и общаться с телефоном Polycom 2008 года через тот же Kamailio-прокси, что стоит перед вашей корпоративной АТС. Сигнализация остаётся прежней — отличается только транспорт.

Почему корпоративным заказчикам по-прежнему нужна SIP-интеграция в 2026

Мы постоянно слышим от корпоративных покупателей одни и те же пять причин. Каждая из них превращает отличный WebRTC-продукт в отказ — «хорошая демонстрация, но не проходит по требованиям закупки», если у вас нет моста к SIP.

1. Дозвон по ТФОП. Руководитель звонит с телефона в зале аэропорта. Свидетель набирает номер на судебное заседание. Врач звонит со стационарного телефона из клиники. Ни один из этих сценариев не сработает без SIP-транка и шлюза, поддерживающего ТФОП.

2. Системы переговорных (Cisco, Poly, Lifesize, Yealink). Большинство переговорных, оборудованных в 2012–2022 годах, — это устройства H.323 / SIP. Они надёжны, оборудование уже окупилось, и ИТ-специалисты не собираются их заменять. Zoom Room Connector, шлюз SIP/ H.323 для Teams Rooms и Meet через Pexip существуют именно потому, что интеграция с ними — единственный способ подключения.

3. Гостиничные, противопожарные и аварийные телефоны. Панели пожарной сигнализации по закону обязаны звонить по ТФОП. Телефоны в гостиничных номерах подключены к АТС объекта через SIP. Когда телемедицинская платформа приходит в больницу, в половине отделений по-прежнему висят настенные трубки.

4. Интеграция с колл-центрами и контакт-центрами. Genesys, Avaya, Five9, Amazon Connect, контакт-центры на базе Asterisk — все используют протокол SIP. Путь от «клиент ждёт в IVR» до «клиент подключился к видеоагенту» проходит через SIP-мост.

5. Запись для compliance и аналоговый факс. Платформы записи для аудитов HIPAA, PCI-DS и SOC 2 подключаются к SIP-транку. Некоторые юридические и медицинские процессы до сих пор требуют факса. И то, и другое работает на SIP, а не на WebRTC.

Три архитектуры моста — выберите ровно одну

Каждый продакшен SIP–WebRTC мост построен по одной из трёх схем. Смешивать их — обжечься. Выбирайте схему в зависимости от масштаба, требований к соответствию стандартам и того, сколько SIP-инфраструктуры вы готовы держать у себя.

Согласование кодеков: где мосты тихо умирают

Сторона SIP использует кодек G.711 (μ-law / A-law, 64 кбит/с, без сжатия), иногда — G.729 (8 кбит/с, с лицензией), редко — G.722 (широкополосный). Сторона WebRTC работает с кодеком Opus, битрейт которого варьируется от 10 до 120 кбит/с. Некоторые устройства поддерживают видео в форматах VP8, VP9 или H.264; при этом многие SIP-системы переговорных комнат понимают только H.264. Если ваш SBC не умеет проводить транскодирование, сессия установится, но звука не будет — как раз тот самый известный случай вызова с односторонним звуком или вообще без звука.

Asterisk 13.12+ поддерживает нативную транскодировку Opus. FreeSWITCH 1.10+ использует для этого модуль mod_opus. RTPEngine транскодирует Opus↔G.711 примерно за 5 мс на прыжок на современном процессоре Xeon. Видеотранскодинг — ресурсоёмкая операция: конвертация H.264↔VP9 требует 0,5–1 vCPU на каждый одновременный вызов. Учитывайте это при планировании ресурсов.

Практичные настройки по умолчанию

Аудио: указывайте Opus первым, G.711 — как запасной вариант, G.722 — только если вы контролируете обе стороны соединения. Избегайте G.729, если заказчик явно не требует его (из-за лицензионных отчислений за каждый канал).
Видео: используйте H.264 constrained baseline на мосте, VP8 — как запасной вариант. Оставьте VP9 и AV1 только для WebRTC, если не готовы платить за транскодинг.

Сравнение операторов ТФОП — Twilio, Telnyx, Bandwidth, Vonage

Для новых проектов по умолчанию используем Telnyx — из-за выгодной цены. Twilio выбираем, если у клиента уже есть аккаунт или требуется надёжное глобальное покрытие DID. Bandwidth подключаем, когда в задаче есть E911. Резервирование между несколькими провайдерами (через DNS SRV и health-проверки) занимает 2–3 рабочих дня инженера, но сильно снижает риск простоя из-за сбоя у одного оператора.

Сравнение управляемых SIP–WebRTC шлюзов

Безопасность: SIP поверх TLS, SRTP и реальные требования HIPAA

Сигнализация. SIP поверх TLS 1.3 на порту 5061 — обязательное условие для всего, что выходит за пределы вашего VPC. Обычный 5060 допустим только во внутренней сети за строгим файрволом.

Медиа. На стороне WebRTC используется DTLS-шифрование и SRTP, на стороне SIP — SRTP с SDES. RTPEngine или ваш SBC обрабатывают оба протокола и обмениваются ключами заново. Если где-то по пути происходит переход на обычный RTP — вы не прошли аудит HIPAA.

End-to-end шифрование. Настоящее E2EE (SFrame, MLS) по-прежнему невозможно, если на одном конце используется обычный SIP-телефон — SBC вынужден расшифровывать поток для транскодирования. Будьте честны с заказчиками: мост обеспечивает шифрование от узла к узлу, а не от конца до конца.

Обновление HIPAA 2025. С каждым поставщиком в цепочке обработки данных (Twilio, AWS, Telnyx — у всех есть соответствующие соглашения) необходимо заключить подписанное соглашение о защите данных (BAA). Шифрование при хранении обязательно для медицинских записей, двухфакторная аутентификация — на всех административных консолях, а журналы аудита доступа должны храниться не менее 6 лет.

Бюджет качества и задержки

По ITU-T G.114 задержка «рот-ухо» <150 мс воспринимается пользователем как прозрачная, 150–400 мс — допустима при усилиях, >400 мс — заметно ухудшает качество. Каждый переход в SIP–WebRTC-мосте добавляет: 20–50 мс на перекодирование кодека, 20–50 мс на буферизацию джиттера, 30–80 мс на сетевую задержку между регионами. Эти значения нужно учитывать при расчёте общего времени задержки заранее.

Передача DTMF. По умолчанию используйте RFC 2833 (внутриполосные RTP-события); переключайтесь на SIP INFO только для шлюзов, которые не поддерживают RTP-события. Передача тонов через аудиопоток (in-band audio) не работает с кодеком Opus — никогда не применяйте этот способ.

Устойчивость к потерям. Включите RED/FEС на Opus, PLC на линиях G.711 и настройте jitter-буферы на 60–120 мс для мобильных SIP-клиентов. Эхоподавление работает на стороне WebRTC; SIP-телефоны, как правило, справляются с этим самостоятельно.

Три сценария вызовов, которые вы реально внедрите

Сценарий 1 — вызов по клику из веб-приложения в ТФОП

Браузер → SIP.js поверх WSS → Kamailio/OpenSIPS → RTPEngine (DTLS-SRTP ↔ SRTP, Opus ↔ G.711) → SIP-транк Telnyx / Twilio → номер в ТФОП. Round-trip: 120–200 мс в пределах одного региона. Это стандартная настройка для звонков от дозвонщиков отдела продаж, обратных звонков техподдержки и напоминаний о записи.

Сценарий 2 — вызов из ТФОП в WebRTC-комнату по PIN

Пользователь набирает DID → SIP-транк → ваш SBC → IVR (FreeSWITCH или Chime SIP Media App) запрашивает PIN комнаты → пользователь подключается к WebRTC-комнате как участник с аудио. Ваш SFU (LiveKit, Janus, mediasoup) получает бота-участника, который транслирует аудио Opus, перекодированное с G.711-канала.

Сценарий 3 — система переговорной Cisco / Poly подключается к WebRTC-встрече

Система переговорной набирает URI (sip:meeting-123@conf.example.com) → ваш SBC проводит аутентификацию → шлюз подключается к WebRTC-комнате как видеоучастник с кодеком H.264 baseline. Камера переговорной отображается в интерфейсе WebRTC как обычный участник; демонстрация экрана работает через BFCP или через шлюз, который повторно публикует второй поток.

Масштабирование и инфраструктура: планирование ёмкости на одной странице

Целевые показатели concurrency. Один Kamailio-прокси обрабатывает более 1000 CPS сигнализации на скромном железе. RTPEngine обеспечивает 500–1000 одновременных аудиомедиа-сессий на ядро на современном AMD EPYC. При видеотранскодинге эта цифра снижается до 50–100 сессий на ядро — в зависимости от разрешения.

Порты. Диапазон RTP 16384–32767 позволяет поддерживать около 8 000 одновременных медиапотоков на интерфейс. Сигнализация работает на портах 5060/5061, а WSS — на 443.

NAT / TURN. TURN на стороне браузера (coturn) для сложных сетей, статические IP на SBC для белого списка SIP-транка и — отключите SIP ALG на каждом маршрутизаторе по пути. ALG переписывают заголовки SIP нестандартным и некорректным образом; у каждого SIP-инженера есть шрамы в подтверждение.

Географический failover. Записи DNS SRV для сигнализации, Anycast IP для TURN, пара SBC в нескольких регионах в режиме active-active по сигнализации и «липкой» медиа (медиа следует туда, где RTP приземлился впервые). Раз в квартал измеряйте p99 round-trip сигнализации для каждого транка.

Мини-кейс — подключение 600 залов суда к платформе на WebRTC

Ситуация. Государственному заказчику нужно было, чтобы удалённые адвокаты и свидетели могли подключаться к судебным заседаниям с ТФОП-телефонов, через переговорные системы Cisco в региональных судах и из браузерного WebRTC-приложения. У них был единый вендорский SBC, который не поддерживал транскодирование Opus и тарифицировал трафик поканально.

План на 12 недель. Перенесли сигнализацию на пару Kamailio в режиме active-active, внедрили RTPEngine для обработки медиа с транскодированием Opus ↔ G.711, подключили Bandwidth как основной транк и Telnyx как резервный с переключением по DNS SRV. Запись для соответствия требованиям вывели с SBC через SIPREC в S3-бакет с object-lock и сроком хранения 7 лет. К WebRTC-комнатам подключались через бот-шлюз на базе LiveKit.

Результат. Поканальные лицензионные платежи обнулились. Одновременная ёмкость ТФОП выросла с 120 до 1 200 без замены оборудования. Системы переговорных Cisco подключаются по SIP менее чем за 3 секунды (раньше — 11 с). Экономия в месяц: около 1 050 000 ₽ по сравнению со старым вендорским SBC. Хотите такую же оценку для своей системы? Позвоните или напишите нам — контакты ниже.

Модель затрат — 100 одновременных ТФОП-линий на современном мосту

Закладывайте ~825–1 875 ₽ за одну одновременную линию в месяц при стабильной нагрузке. На подходе Agent Engineering мы обычно укладываемся в 6–10 недель сфокусированной работы на начальную задачу по интеграции моста; точный срок зависит от объёма требований compliance и готовности вашего SFU.

Пять подводных камней, которые мы видим в каждом аудите SIP-моста

1. SIP ALG на firewall. Потребительские и средние корпоративные маршрутизаторы включают SIP ALG по умолчанию. Он переписывает заголовки, ломает ICE, портит SDP и вызывает прерывистый односторонний звук. Отключайте его на всех участках пути.

2. Нет транскодинга — тихие вызовы. Если Opus анонсируется устройству, которое поддерживает только G.711, сессия установится, но будет полностью тихой. Всегда принудительно используйте проверенный кодек на стороне моста.

3. Несовпадение DTMF. Внутриполосные тоны на Opus-линиях кодек уничтожает. Настройте преобразование в RFC 2833 на SBC; используйте SIP INFO только для тех транков, где это необходимо.

4. Асимметрия NAT на старых устройствах. Старые SIP-телефоны не поддерживают ICE. Используйте SBC с публичным IP или медиа-якорь по типу TURN, чтобы телефон видел только одну пару IP:порт.

5. Недостаточный диапазон портов. Стандартный диапазон RTP 16384–32767 — около 16 000 портов, что позволяет обслуживать до 8 000 одновременных медиапотоков на сетевой карте. Если система масштабируется без увеличения диапазона, на пиковых нагрузках начинаются сбои и отбрасывание вызовов.

KPI: что измерять на SIP-мосту

Качество. Односторонняя задержка «рот-ухо» p95 < 250 мс через мост. Время ожидания после набора номера (PDD) < 2 с на входящих вызовах. MOS ≥ 4,0 (POLQA или ITU-T P.863) для аудио, ≥ 3,8 — для транскодированного видео.

Бизнес. Answer Seizure Ratio (ASR) ≥ 60%, Network Efficiency Ratio (NER) ≥ 95%. Стоимость одной линии в месяц сравнивается с целевым диапазоном (1 125–1 875 ₽).

Надёжность. Доступность сигнализации — 99,99% (4,3 минуты простоя в месяц). Ни один транк не должен использовать более 70% всех минут — подключайте резервирование между несколькими провайдерами. Успешность установления вызова на зарегистрированных устройствах — выше 99,5%.

Когда стоит отказаться от SIP и использовать только WebRTC

SIP оправдывает усилия, когда в реальных требованиях есть корпоративные закупки, дозвон по ТФОП, системы переговорных, колл-центры или запись для compliance. Это потеря времени, если ничего из перечисленного нет.

Если ваши пользователи — mobile-first, весь трафик идёт от браузера к браузеру или от браузера к нативному приложению, и никто не требует дозвонов через ТФОП, используйте чистый WebRTC на LiveKit, mediasoup или Janus. SIP можно добавить позже — а вот избавиться от собственного SIP-слоя, который уже глубоко интегрирован, может занять полгода.

FAQ

SIP устарел в 2026 году?

Нет. SIP — сигнальный протокол более чем 70% корпоративной телефонии и единственный способ подключения к ТФОП. Базовый RFC (3261) стабилен; изменился транспорт — WebSocket и TLS теперь по умолчанию, а современные устройства поддерживают ICE и DTLS-SRTP.

Нужно ли строить собственный SBC?

Обычно нет. Начните с Kamailio или OpenSIPS плюс RTPEngine для самостийного развёртывания или используйте готовый SIP SDK — LiveKit SIP, Chime SDK SIP Media App, Twilio Voice. Коммерческие SBC (Oracle, AudioCodes, Ribbon) оправданы только на очень больших масштабах или при необходимости конкретной сертификации.

Сколько времени уходит на постройку SIP–WebRTC моста?

С готовой WebRTC-инфраструктурой и управляемым SIP SDK: 2–4 недели до запуска продакшен-дозвона из ТФОП. Самостоятельный мост на Kamailio + FreeSWITCH с транскодингом, отказоустойчивостью и записью для соответствия требованиям обычно требует 8–12 недель работы сфокусированной команды по методологии Agent Engineering.

Могут ли переговорные системы Cisco и Poly подключаться к Zoom, Teams и Meet по протоколу SIP?

Да. Zoom Room Connector и Microsoft Teams Rooms поставляют шлюзы SIP/H.323. Google Meet использует Pexip как партнёра по совместимости. Если вы создаёте четвёртую платформу, рассчитывайте, что для корпоративных сделок придётся реализовать аналогичный шлюз.

Какой кодек выбрать на стороне SIP?

Анонсируйте Opus первым (если другая сторона его поддерживает), а G.711 μ-law — как гарантированный резервный вариант. Избегайте G.729, если это не требуется конкретным заказчиком: лицензионные платежи за канал не оправдывают выигрыш в ~7 кбит/с.

Поддерживает ли SIP сквозное шифрование?

Сигнализация SIP шифруется через TLS, а медиа — через SRTP/DTLS-SRTP, но как только вызов проходит через транскодирующий шлюз, настоящее E2EE (SFrame, MLS) перестаёт работать. Честно говорите заказчикам: мост обеспечивает шифрование от узла к узлу, а не сквозное (end-to-end).

Что такое SIP ALG и почему его нужно отключать?

SIP ALG — это «Application Layer Gateway» во многих маршрутизаторах, который переписывает заголовки SIP, считая, что помогает. Обычно он портит SDP, ломает ICE и вызывает односторонний звук. Любой опытный SIP-инженер скажет вам отключить его на firewall и обрабатывать NAT в своём SBC.

Как соблюдать HIPAA при работе с SIP-мостом?

Подпишите соглашение о обработке данных (BAA) с каждым поставщиком в цепочке (Twilio, Telnyx, AWS Chime — у всех оно доступно). Используйте TLS 1.3 для сигнализации, SRTP/DTLS-SRTP для передачи медиа, шифрование при хранении для записей, двухфакторную аутентификацию (MFA) на всех административных панелях и храните логи доступа в течение 6 лет.

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

Готовы подключить SIP к своей видеоплатформе?

Выбирайте одну архитектуру, а не три. Self-hosted Kamailio + RTPEngine — для контролируемого масштабирования, управляемый SBC + SIP SDK — для корпоративной доступности без команды поддержки, встроенные модули платформ (LiveKit SIP, Chime, JIGASI, Twilio) — для быстрого выхода на рынок. Закладывайте 1 125–1 875 ₽ за одну одновременную линию в месяц при стабильной нагрузке. На границе сети форсируйте проверенный кодек, отключайте SIP ALG везде и с первого дня измеряйте PDD, MOS и ASR.

Сделанный правильно SIP-мост открывает каждую корпоративную сделку, каждый дозвон по ТФОП и каждую переговорную с Cisco в углу. Сделанный плохо — даёт тихие вызовы, односторонний звук и шесть месяцев ночных пейджеров. Разница в основном в инженерной дисциплине и в том, что эту картину вы уже видели.