Главная/Блог/WebRTC технология

WebRTC: как работают корпоративные видеозвонки изнутри

16 марта 2026 · 19 мин чтения

Вы нажимаете кнопку «Позвонить» в мессенджере. Через 2 секунды видите лицо коллеги и слышите его голос. Ничего не устанавливали — звонок работает прямо в браузере. Качество — как в Zoom или лучше. Что за магия?

Никакой магии. Это WebRTC — открытый стандарт для аудио и видеокоммуникаций в реальном времени. Технология, которая работает в каждом браузере (Chrome, Firefox, Safari, Edge), не требует плагинов и поддерживает шифрование из коробки.

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

Что такое WebRTC (без маркетинга)

WebRTC (Web Real-Time Communication) — набор API и протоколов для передачи аудио, видео и произвольных данных между браузерами напрямую, без промежуточных серверов. Технически это три API:

Ключевое слово — «напрямую». В классической архитектуре (Zoom, Teams) видеопоток идёт от вашего браузера на сервер, а сервер передаёт его собеседнику. В WebRTC при P2P-соединении поток идёт от вашего браузера напрямую в браузер собеседника. Сервер нужен только для начального «знакомства» (signaling).

Зачем это важно для бизнеса

P2P-соединение даёт три практических преимущества:

Низкая задержка. Данные не проходят через промежуточный сервер — путь короче. Для звонка между Москвой и Петербургом задержка P2P составляет 5-15 мс. Через сервер в Амстердаме — 40-60 мс. Разница ощутима: при задержке выше 150 мс разговор становится некомфортным, люди начинают перебивать друг друга.

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

Стоимость. Медиасерверы дороги — они обрабатывают большие объёмы трафика и требуют мощного железа. P2P-звонки разгружают серверную инфраструктуру. Для self-hosted развёртываний это ощутимая экономия.

Краткая история: от Google до W3C-стандарта

2010 год. Google покупает компании GIPS (кодеки) и On2 Technologies (видеокодек VP8) за $124 млн. На базе их технологий начинает разработку открытого проекта.

2011 год. Google выпускает WebRTC как open-source проект. Ericsson демонстрирует первый видеозвонок между двумя браузерами.

2012-2014 годы. Chrome и Firefox добавляют поддержку WebRTC. Появляются первые коммерческие продукты. Стандартизация идёт через W3C и IETF.

2017 год. Apple добавляет WebRTC в Safari. Теперь технология работает во всех основных браузерах.

2021 год. WebRTC 1.0 получает статус W3C Recommendation — официальный веб-стандарт.

2023-2026 годы. Развитие WebRTC NV (Next Version): поддержка AV1/AV2 кодеков, улучшенный SVC (Scalable Video Coding), WebTransport, WebCodecs API для низкоуровневого контроля. Качество приближается к «кинематографическому» даже на слабых каналах.

Как устанавливается соединение

Давайте проследим, что происходит от нажатия кнопки «Позвонить» до появления видео собеседника. Весь процесс занимает 1-3 секунды, но внутри — сложная последовательность действий.

Шаг 1: Signaling (сигнализация)

WebRTC не определяет протокол сигнализации — это задача приложения. Мессенджер использует WebSocket-соединение с сервером для обмена метаданными между участниками.

Алиса нажимает «Позвонить Борису». Мессенджер отправляет на сервер сигнал: «Алиса хочет начать звонок с Борисом». Сервер передаёт этот сигнал Борису. Борис видит входящий звонок и принимает его.

На этом этапе никакие медиаданные ещё не передаются. Только метаданные: кто звонит, кому, какие кодеки поддерживает каждая сторона.

Шаг 2: SDP Offer/Answer

SDP (Session Description Protocol) — формат описания медиасессии. Содержит:

Алиса создаёт SDP Offer (предложение) и отправляет его Борису через signaling-сервер. Борис создаёт SDP Answer (ответ) с информацией о своих возможностях. Стороны договариваются о параметрах сессии: какой кодек использовать, какое разрешение, какой битрейт.

Шаг 3: ICE (Interactive Connectivity Establishment)

Самый сложный этап. Задача — найти путь для прямого соединения между Алисой и Борисом. Проблема в том, что оба сидят за NAT (Network Address Translation) — их реальные IP-адреса скрыты за маршрутизатором.

ICE-агент на каждой стороне собирает «кандидатов» — адреса, по которым к нему можно подключиться:

ICE проверяет все пары кандидатов и выбирает лучшую. Приоритет: прямое P2P-соединение. Если не получается — через TURN-сервер.

Шаг 4: DTLS Handshake

Соединение установлено, но данные ещё нужно зашифровать. WebRTC использует DTLS (Datagram Transport Layer Security) — это TLS, адаптированный для UDP. Стороны обмениваются сертификатами и устанавливают зашифрованный канал.

Важный момент: шифрование в WebRTC обязательно. Нельзя отключить. Каждый звонок зашифрован — это требование стандарта, а не опция.

Шаг 5: SRTP — передача медиа

Наконец, начинается передача аудио и видео. WebRTC использует SRTP (Secure Real-time Transport Protocol) — зашифрованную версию RTP. Видеопоток кодируется выбранным кодеком, разбивается на пакеты, шифруется и отправляется по установленному каналу.

Весь процесс: Signaling → SDP → ICE → DTLS → SRTP. 1-3 секунды. Пользователь видит только анимацию ожидания.

STUN и TURN: обход NAT

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

STUN (Session Traversal Utilities for NAT)

STUN-сервер — простой сервер, который отвечает на один вопрос: «Какой у меня внешний адрес?» Ваш браузер отправляет запрос на STUN-сервер, тот видит, с какого IP пришёл запрос, и возвращает этот IP.

Теперь браузер знает свой внешний адрес и может сообщить его собеседнику. Если оба абонента за простым NAT (например, домашний роутер) — P2P-соединение устанавливается успешно. STUN-сервер почти не потребляет ресурсов — он отвечает на одиночные запросы и не обрабатывает медиатрафик.

Статистика: STUN успешно устанавливает P2P-соединение в 85-90% случаев для домашних пользователей.

TURN (Traversal Using Relays around NAT)

Иногда STUN не помогает. Это бывает при:

В этих случаях подключается TURN-сервер. Он работает как ретранслятор: принимает поток от Алисы и передаёт Борису. P2P не получилось, но звонок всё равно работает.

TURN-сервер — дорогой компонент. Он обрабатывает весь медиатрафик, а это гигабайты для видеозвонков. Для корпоративного использования TURN-сервер развёртывается внутри инфраструктуры компании, что одновременно снижает задержки и обеспечивает безопасность — трафик не покидает корпоративную сеть.

ICE в цифрах

Типичная статистика для корпоративных звонков:

Кодеки: VP8, VP9, H.264, AV1

Кодек определяет, как видеопоток сжимается для передачи по сети. Выбор кодека влияет на качество картинки, потребление трафика и нагрузку на процессор.

VP8

Первый видеокодек WebRTC. Open-source, разработан Google (On2 Technologies). Поддерживается всеми браузерами. Качество: хорошее для SD и 720p. Для 1080p требует высокий битрейт (2-4 Mbps). Нагрузка на CPU: средняя.

Когда использовать: legacy-совместимость, слабые устройства.

VP9

Наследник VP8. На 30-50% эффективнее по компрессии — то же качество при меньшем битрейте. Поддерживает SVC (Scalable Video Coding) — ключевая функция для групповых звонков. Нагрузка на CPU: выше, чем VP8.

Когда использовать: основной кодек для групповых звонков. 1080p при 1.5-2.5 Mbps.

H.264 (AVC)

Проприетарный кодек (Cisco предоставляет бесплатную реализацию OpenH264 для WebRTC). Аппаратное ускорение на большинстве устройств — низкая нагрузка на CPU. Качество сопоставимо с VP8.

Когда использовать: мобильные устройства с аппаратным ускорением H.264, низкий CPU-бюджет.

AV1

Новейший открытый кодек от Alliance for Open Media (Google, Mozilla, Microsoft, Apple). На 30% эффективнее VP9. Поддерживается в Chrome и Firefox с 2024 года. Аппаратная поддержка появляется в новых чипах (Apple M3+, Intel 14th gen+).

Когда использовать: максимальное качество при ограниченной пропускной способности. 1080p при 1-1.5 Mbps. Идеален для 4K-видеоконференций.

Opus — аудиокодек

Единый аудиокодек WebRTC. Поддерживает речь и музыку, адаптируется к пропускной способности от 6 kbps до 510 kbps. Задержка: 5-66 мс (настраивается). Качество при 32 kbps — сопоставимо с телефонной линией. При 64 kbps — как FM-радио. При 128 kbps — как CD.

Качество: от чего зависит и как управлять

Bandwidth Estimation

WebRTC непрерывно оценивает доступную пропускную способность и адаптирует качество видео. Механизм называется Bandwidth Estimation (BWE) и работает через GCC (Google Congestion Control).

Как это выглядит на практике: вы разговариваете в HD, и вдруг сосед по Wi-Fi начинает качать фильм. Пропускная способность падает. WebRTC за 2-3 секунды обнаруживает это (по задержкам пакетов и потерям) и автоматически снижает разрешение и битрейт. Вы видите, что картинка стала чуть менее чёткой, но звонок не прервался и звук не прерывается.

Приоритеты адаптации: сначала снижается разрешение видео (с 1080p до 720p, затем до 480p), затем снижается фреймрейт (с 30 до 15 fps), и только в крайнем случае отключается видео, оставляя аудио.

Jitter Buffer

Пакеты в интернете приходят не равномерно — с разной задержкой (jitter). Для видео и аудио это критично: если пакет пришёл с опозданием на 200 мс, появится заикание.

Jitter Buffer — буфер, который накапливает несколько пакетов и воспроизводит их равномерно. Размер буфера — компромисс между плавностью (больше буфер) и задержкой (меньше буфер). WebRTC управляет им автоматически, адаптируя размер к текущему состоянию сети.

FEC и NACK

Что делать, если пакет потерялся? Два механизма:

FEC (Forward Error Correction). К данным добавляется избыточная информация. Если один пакет из группы потерян — его можно восстановить по оставшимся. Увеличивает трафик на 10-30%, но устраняет эффект потерь до 5-10%.

NACK (Negative Acknowledgment). Получатель обнаруживает потерю и запрашивает повторную отправку. Работает для видео (один потерянный I-frame может испортить всю картинку), не подходит для аудио (к моменту повторной отправки звук уже неактуален).

Simulcast

Simulcast — отправка нескольких версий видеопотока с разным качеством одновременно. Например: 1080p, 720p и 360p. Медиасервер (SFU) выбирает для каждого получателя подходящий поток в зависимости от его пропускной способности.

Это особенно полезно для групповых звонков: участник с быстрым каналом получает HD, участник с мобильного интернета — 360p. Никто не страдает.

P2P vs SFU vs MCU: архитектуры звонков

Три архитектуры для видеозвонков, каждая для своего сценария.

P2P (Peer-to-Peer)

Каждый участник соединён напрямую с каждым. Сервер не участвует в передаче медиа.

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

Минусы: каждый участник отправляет свой видеопоток всем остальным. При 5 участниках — 4 исходящих потока с каждого устройства. При 10 участниках — 9 потоков. Канал и CPU перегружаются.

Оптимально: звонки 1-на-1 и небольшие группы до 4-5 человек.

SFU (Selective Forwarding Unit)

Центральный сервер (SFU) получает потоки от всех участников и пересылает каждому участнику потоки остальных. SFU не декодирует и не перекодирует видео — просто маршрутизирует зашифрованные потоки.

Плюсы: каждый участник отправляет только один исходящий поток (на SFU). SFU выбирает качество для каждого получателя (simulcast). Масштабируется до 50-100 участников.

Минусы: SFU-сервер нагружен трафиком. Задержка чуть выше, чем при P2P (на один hop).

Оптимально: групповые звонки 5-50 человек. Это стандартная архитектура для корпоративных видеоконференций.

MCU (Multipoint Control Unit)

Сервер декодирует все входящие потоки, микширует их в один «композитный» поток (все участники на одном экране) и отправляет каждому участнику одну картинку.

Плюсы: минимальная нагрузка на клиентские устройства (получают один поток). Работает даже на очень слабых устройствах.

Минусы: колоссальная нагрузка на сервер (декодирование + микширование + кодирование). Все видят одинаковую раскладку — нельзя выбрать, кого смотреть крупнее. Задержка выше (обработка на сервере добавляет 100-300 мс).

Оптимально: специфические сценарии (вебинары с записью, легаси-оборудование).

Что использует b8q

Гибридная архитектура: P2P для звонков 1-на-1 (минимальная задержка, максимальная приватность) и SFU для групповых звонков (масштабируемость до десятков участников). Переключение автоматическое — пользователь не замечает разницы. Подробнее о технологиях — на странице технологий b8q.

Безопасность WebRTC

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

Обязательное шифрование

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

End-to-End шифрование в групповых звонках

При использовании SFU медиапоток проходит через сервер. Стандартный SRTP защищает от перехвата на уровне сети, но SFU-сервер теоретически мог бы получить доступ к медиа (хотя на практике он не декодирует поток).

Для максимальной безопасности существует Insertable Streams API — расширение, позволяющее шифровать медиаданные ещё до отправки на SFU. Сервер видит только зашифрованные фреймы и не может их декодировать. Расшифровка происходит только в браузерах участников.

Защита от атак

WebRTC vs проприетарные протоколы

Zoom использует собственный протокол. Teams — тоже. Чем WebRTC лучше?

Открытый стандарт vs чёрный ящик

WebRTC — открытый код. Любой эксперт может проверить реализацию, найти уязвимости, предложить улучшения. Проприетарные протоколы — чёрный ящик. Вы не знаете, как именно шифруются данные, нет ли бэкдоров, какие уязвимости существуют.

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

Нет зависимости от вендора

Zoom закрыл API для российских пользователей? С WebRTC такая ситуация невозможна — это открытый стандарт, реализованный в каждом браузере. Браузер не отзовут. Стандарт не заблокируют. Серверы, которые стоят на вашей территории, не отключат.

Нет клиентского приложения

WebRTC работает в браузере. Не нужно устанавливать Zoom Client (350 МБ), не нужно ждать обновлений, не нужно решать проблемы совместимости с корпоративными политиками установки ПО. Открыл ссылку — позвонил. Это критически важно для BYOD-сценариев.

Сравнительная таблица

Параметр WebRTC Zoom (проприетарный)
Код Открытый Закрытый
Клиент Браузер (0 МБ) Приложение (350 МБ)
Шифрование Обязательное (DTLS+SRTP) Опциональное E2EE
P2P Да Нет (всё через серверы)
Self-hosted Да Нет
Задержка (P2P) 5-30 мс 50-150 мс
Аудит кода Любой может Невозможен

WebRTC в корпоративной среде

WebRTC в офисе — это не то же самое, что WebRTC дома. Корпоративная сеть вносит свои особенности и ограничения.

Файрволы и прокси

Корпоративный файрвол может блокировать UDP-трафик (основной транспорт WebRTC). Решения:

QoS (Quality of Service)

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

Решение: настроить QoS на сетевом оборудовании. WebRTC-трафик маркируется DSCP-метками (Differentiated Services Code Point) и получает приоритет. Видео — EF (Expedited Forwarding), аудио — EF, данные — AF41. Большинство корпоративных роутеров и коммутаторов поддерживают DSCP.

Запись звонков

В корпоративной среде часто нужно записывать звонки: для обучения, для compliance, для решения спорных ситуаций. С WebRTC это делается через SFU: сервер параллельно записывает потоки, которые пересылает участникам. Запись хранится на сервере компании, защищена теми же политиками безопасности.

Демонстрация экрана

getDisplayMedia API — расширение WebRTC для захвата экрана. Работает в браузере без плагинов. Можно расшарить весь экран, отдельное окно или вкладку браузера. Качество — до 1080p при 30fps. Нагрузка ниже, чем у видео с камеры (статичная картинка требует меньше битрейта).

Проблемы и их решения

«Собеседник меня не видит»

Причина: ICE не смог установить соединение. Обычно — строгий файрвол.

Решение: проверить доступность TURN-сервера. Открыть порт 443/TCP для TURN over TLS.

«Видео дёргается»

Причина: недостаточная пропускная способность или высокий jitter.

Решение: снизить разрешение (720p вместо 1080p), настроить QoS, проверить нагрузку на канал другими приложениями.

«Эхо при звонке»

Причина: звук из динамика попадает обратно в микрофон.

Решение: WebRTC включает AEC (Acoustic Echo Cancellation) автоматически. Если не помогает — используйте гарнитуру вместо встроенных динамиков.

«Задержка 500+ мс»

Причина: соединение через TURN-сервер, расположенный далеко.

Решение: развернуть TURN-сервер ближе к пользователям. Для компании с офисами в Москве и Новосибирске — TURN в обоих городах.

«Высокая нагрузка на CPU»

Причина: программное кодирование VP9/AV1 на слабом устройстве.

Решение: переключиться на H.264 (аппаратное ускорение) или снизить разрешение.

Будущее WebRTC

WebRTC NV (Next Version)

Работа над следующей версией стандарта уже идёт. Ключевые направления:

AI и WebRTC

Интеграция AI с видеозвонками уже реальность:

b8q использует WebRTC для всех видео и аудиозвонков и интегрирует AI-функции прямо в звонки. Подробнее — на странице возможностей.

Заключение

WebRTC — не просто «ещё один способ сделать звонок». Это открытый стандарт, который даёт компаниям три вещи, недоступные при использовании проприетарных решений:

  1. Независимость. Никакой вендор не может отключить вам WebRTC. Технология встроена в каждый браузер и не зависит от чьей-то политики.
  2. Проверяемая безопасность. Открытый код = аудируемое шифрование. Для компаний, работающих с конфиденциальной информацией, это не опция, а требование.
  3. Гибкость. P2P для приватных звонков, SFU для конференций, запись, screen sharing — всё на одной технологии. Self-hosted для полного контроля.

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

Попробуйте WebRTC-звонки в b8q

P2P для приватности, SFU для конференций. Шифрование из коробки. Работает в браузере.

Запросить демо Подробнее о технологиях