WebRTC, SFU и голосовые кодеки: объяснение
Как WebRTC передаёт звук, как Opus сжимает голос и когда групповому видео нужен SFU. Руководство для разработчиков с архитектурой Voxal и ссылками на RFC.
WebRTC передаёт аудио и видео между браузерами, кодек вроде Opus сжимает голос, чтобы он поместился в канал, а Selective Forwarding Unit (SFU) — это сервер, который в больших звонках пересылает видео каждого участника всем остальным. Эти три элемента объясняют большую часть того, что происходит между микрофоном и удалённым динамиком.
Это руководство для разработчиков и любознательных читателей, которым нужна механика: сигнализация, ICE, STUN и TURN, RTP, Opus и компромисс между пиринговой сеткой (mesh) и SFU. В конце рассказывается, как Voxal их сочетает: голос остаётся пиринговым, а камера и демонстрация экрана могут использовать SFU. Если вам нужна только общая идея, начните со статьи что такое пиринговый голосовой чат.
1. Что такое WebRTC?
WebRTC — это набор стандартов и браузерных API для обмена аудио, видео и данными в реальном времени.
Он позволяет приложениям устанавливать медиасоединения между совместимыми устройствами, не заставляя разработчиков реализовывать с нуля каждый механизм транспорта и безопасности.
WebRTC — не один протокол. Работают вместе несколько компонентов.
Сигнализация
Прежде чем два устройства смогут установить медиасоединение, им нужно обменяться информацией о сессии и своих возможностях подключения.
Этот процесс называется сигнализацией. Приложения сами выбирают механизм сигнализации; WebRTC не предписывает единый сервер или протокол сигнализации.
Voxal использует сигнализацию, чтобы согласовывать состав комнаты и установку соединений. Путь сигнализации отделён от пути медиа.
ICE, STUN и TURN
Устройства часто находятся за маршрутизаторами, межсетевыми экранами или трансляцией сетевых адресов (NAT). Поэтому найти рабочий путь соединения бывает сложнее, чем связать два публичных IP-адреса.
WebRTC использует Interactive Connectivity Establishment (ICE), чтобы собирать и проверять возможные пути соединения.
- STUN помогает устройству узнать, как оно выглядит из публичной сети.
- TURN предоставляет ретрансляционный путь, когда подходящее прямое соединение установить не удаётся.
TURN-ретранслятор пересылает зашифрованный медиатрафик. Это не то же самое, что SFU, который завершает медиасоединения и выборочно пересылает потоки.
Прямое соединение часто предпочтительнее, но ретранслятор может быть необходим для связи.
RTP и защищённая передача медиа
Медиа в реальном времени обычно передаются по протоколу Real-time Transport Protocol (RTP) вместе с RTCP для управления и отчётов.
WebRTC использует защищённый RTP (SRTP) для защиты медиа. Транспортный уровень помогает доставлять пакеты, а кодек определяет, как представлены сами звук или видео.
Это разные обязанности: кодек не устанавливает сетевое соединение, а сетевое соединение не определяет, как сжимается звук.
2. Что такое голосовой кодек?
Кодек кодирует и декодирует медиа. В голосовой связи его задача — эффективно представить речь, сохранив разборчивость и приемлемое качество звука.
Без сжатия передача необработанного аудио может занимать заметно больше полосы, чем нужно голосовому приложению.
Кодек находит компромисс между несколькими факторами:
- Качество звука и разборчивость речи.
- Битрейт и расход полосы пропускания.
- Сложность кодирования и декодирования.
- Задержка и длительность кадра.
- Поведение при меняющихся условиях сети.
Не существует одного лучшего кодека для всех приложений. У потоковой музыки, телефонных звонков, игрового чата и групповых разговоров в реальном времени разные приоритеты.
Почему Opus так широко используется
Opus — это интерактивный аудиокодек, разработанный для таких задач, как голос поверх IP, видеоконференции и внутриигровой чат.
Он поддерживает широкий диапазон битрейтов, частот дискретизации и длительностей кадра. Благодаря этой гибкости он подходит и для речи, и для более требовательных аудиозадач.
Кроме того, Opus — аудиокодек, обязательный для реализации в конечных точках WebRTC согласно требованиям WebRTC к аудиокодекам.
Это не значит, что каждое соединение WebRTC всегда использует Opus. Фактический выбор кодека зависит от возможностей, согласованных участвующими конечными точками.
В Voxal аудиоконвейер WebRTC в браузере по умолчанию использует Opus в описанной в документации архитектуре. Браузер берёт на себя значительную часть кодирования, передачи и декодирования.
Для голосового приложения реального времени кодек — лишь одна часть впечатления. Важны также качество микрофона, обработка звука, потеря пакетов, сетевая задержка, джиттер-буфер и воспроизведение на устройстве.
3. Что такое SFU?
SFU расшифровывается как Selective Forwarding Unit.
SFU — это медиасервер, который обычно применяют для групповых видеозвонков. Вместо того чтобы требовать от каждого участника отправлять отдельный видеопоток напрямую каждому другому участнику, каждый участник может отправлять медиа на SFU, а тот пересылает нужные потоки остальным.
Представьте комнату из шести человек, каждый из которых отправляет поток с камеры.
В полной пиринговой сетке каждому участнику, возможно, придётся загружать своё исходящее видео пяти другим участникам. В топологии с пересылкой через сервер каждый участник может отправить один поток на SFU, который займётся распределением.
Это может заметно сократить число отдельных исходящих видеопотоков, которые должен поддерживать участник.
Что на самом деле делает SFU?
SFU обычно принимает закодированные медиапотоки и выборочно пересылает их. В зависимости от реализации и согласованных возможностей он может выбирать, какие потоки или слои качества отправлять каждому получателю.
Например, участнику, который смотрит на маленькую миниатюру, не нужно такое же качество видео, как тому, кто выводит докладчика на весь экран.
SFU помогает справиться с этими разными требованиями, и при этом каждому отправителю не нужно независимо передавать отдельный поток каждому получателю.
Однако SFU не бесплатен. Он добавляет инфраструктуру, серверный трафик, эксплуатационные расходы и ещё один компонент на пути медиа.
У SFU также другая модель приватности, чем у TURN-ретранслятора. Поскольку SFU завершает медиатранспорт и выборочно пересылает медиа, он технически может получить доступ к принимаемым медиа. Шифрование между участником и SFU само по себе не обеспечивает сквозной конфиденциальности по отношению к этому SFU.
4. Пиринговая сетка и SFU
Эти две архитектуры решают родственные, но разные задачи.
Пиринговая сетка
Каждый участник устанавливает медиасоединения с остальными участниками.
Преимущества:
- Возможны прямые медиапути.
- Не нужен центральный медиасервер для перераспределения медиа.
- Небольшие комнаты могут работать без сервиса пересылки медиа.
Недостатки:
- Каждому отправителю, возможно, придётся загружать отдельный поток каждому другому участнику.
- Число медиасоединений растёт вместе с размером комнаты.
- Исходящая полоса и управление соединениями могут стать ограничивающими факторами.
Распределение через SFU
Каждый участник отправляет медиа в центральный сервис пересылки, который распределяет их остальным участникам.
Преимущества:
- Более эффективное распределение во многих сценариях группового видео.
- Меньше необходимости загружать отдельные копии каждому получателю.
- Больше контроля над тем, какие видеопотоки и слои качества получают получатели.
Недостатки:
- Дополнительная серверная инфраструктура и расходы на трафик.
- На пути медиа появляется посредник.
- Модель приватности и доверия отличается от прямой пиринговой связи.
Главное — не считать, что для каждого типа медиа обязательно нужна одна и та же топология. У аудио и видео разные профили трафика и требования.
5. Почему Voxal оставляет голос пиринговым, но может использовать SFU для видео
Voxal разделяет голосовое аудио и видео с камеры и демонстрации экрана.
Голосовое аудио всегда остаётся пиринговым. Оно никогда не проходит через необязательный видео-SFU.
Это осознанное архитектурное решение: голос — основная функция связи, и Voxal не использует SFU как центральный сервис распространения аудио.
Видео с камеры и демонстрации экрана — другое дело. В больших комнатах полная пиринговая сетка может требовать, чтобы каждый участник загружал несколько видеопотоков. Чем больше участников, тем тяжелее становится нагрузка.
Поэтому Voxal может использовать Realtime SFU от Cloudflare для видео и демонстрации экрана, если это позволяет настроенное предпочтение маршрутизации и комната превышает практические пределы сетки.
Предпочтение маршрутизации имеет значение:
- Allow relay for large rooms: Voxal может использовать SFU, когда комната вырастает за пределы удобной пиринговой видеотопологии.
- Prefer direct: Voxal сначала пробует пиринговое соединение и спрашивает, прежде чем разрешить ретранслятор, когда сетка становится непригодной.
- Direct only: видео и демонстрация экрана никогда не используют SFU, даже если большой комнате трудно установить все прямые соединения.
Эти настройки влияют на видео и демонстрацию экрана, но не на голосовое аудио.
Почему не пустить всё через один сервер?
Потому что лучшая топология зависит от передаваемого трафика.
Голосовой поток, как правило, намного меньше потока с камеры. Передача голоса через центральный сервис пересылки означала бы другой компромисс по инфраструктуре и приватности и при этом не была бы нужна для выбранной в Voxal голосовой архитектуры.
У видео более требовательный профиль полосы, и по мере роста группы оно может заметно выиграть от серверного распределения.
Разделение позволяет Voxal сохранить пиринговую модель голоса и при этом предложить более масштабируемый вариант для группового видео.
6. Что это значит для приватности
Сетевые термины иногда используют так, будто они автоматически гарантируют определённый уровень приватности. Это не так.
Пиринговое аудио означает, что голосовые медиа не проходят через центральный медиасервер, но серверы сигнализации по-прежнему могут координировать соединения и обрабатывать связанные метаданные.
TURN-ретранслятор пересылает зашифрованные медиа, не декодируя их. SFU же завершает медиатранспорт, чтобы выборочно пересылать потоки, и технически может получить доступ к принимаемому видео.
Вот почему различие, которое проводит Voxal, важно:
- Голос остаётся пиринговым, при необходимости через зашифрованный TURN-ретранслятор.
- Видео с камеры и демонстрации экрана в больших комнатах может использовать SFU в зависимости от предпочтения маршрутизации.
- Локальная обработка виртуального фона происходит на устройстве отправителя, но сама по себе не означает, что каждое видеосоединение прямое.
Понимать реальный путь медиа полезнее, чем просто называть приложение бессерверным.
7. Собираем всё вместе
Приложение для связи в реальном времени объединяет несколько независимых уровней:
- Сигнализация координирует участников и установку соединения.
- ICE, STUN и TURN помогают построить работоспособный сетевой путь.
- WebRTC и защищённый транспорт RTP переносят медиа в реальном времени.
- Кодек вроде Opus эффективно представляет аудио.
- Сетевая топология определяет, идут ли медиа напрямую между участниками или через сервис пересылки.
Архитектура Voxal применяет эти решения отдельно к голосу и видео. В результате получается архитектура, ориентированная на голос: аудио остаётся пиринговым, а видео и демонстрация экрана могут использовать необязательную серверную пересылку, когда этого требуют большие комнаты.
Эти различия важны при проектировании любой системы связи в реальном времени. Цель — не просто минимизировать число серверов или максимизировать число прямых соединений, а осознанно искать компромиссы между задержкой, полосой пропускания, надёжностью, масштабируемостью и приватностью.
Попробуйте Voxal
Voxal объединяет пиринговый голосовой чат, push-to-talk (передачу по нажатию кнопки), режим «свободные руки», шумоподавление, а также необязательные видео и демонстрацию экрана.
Попробуйте Voxal в браузере или изучите реализацию в открытом репозитории Voxal.
Читайте также: Что такое пиринговый голосовой чат? · Что такое push-to-talk? Практическое руководство · Документация Voxal по маршрутизации видео
