WebRTC, SFU і голосові кодеки: пояснення
Як WebRTC передає аудіо, як Opus стискає голос і коли груповому відео потрібен SFU. Посібник для розробників з архітектурою Voxal та посиланнями на RFC.

WebRTC передає аудіо й відео між браузерами, кодек на кшталт Opus стискає голос, щоб він поміщався в канал, а Selective Forwarding Unit (SFU) — це сервер, який у великих дзвінках пересилає відео кожного учасника всім іншим. Ці три частини пояснюють більшість того, що відбувається між мікрофоном і віддаленим динаміком.
Цей посібник призначений для розробників і допитливих читачів, які хочуть розібратися в механіці: сигналізації, ICE, STUN і TURN, RTP, Opus та компромісі між одноранговою (peer-to-peer) сіткою і SFU. Наприкінці показано, як Voxal поєднує все це: голос лишається peer-to-peer, а камера й демонстрація екрана можуть використовувати SFU. Якщо вам потрібне лише загальне уявлення, почніть зі статті що таке peer-to-peer голосовий чат.
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, а той пересилає потрібні потоки решті.
Уявіть кімнату із шістьох людей, кожна з яких надсилає потік з камери.
У повній peer-to-peer сітці кожному учаснику може знадобитися завантажувати своє відео п'ятьом іншим. У топології з пересиланням через сервер кожен учасник може надсилати один потік до SFU, який бере розподіл на себе.
Це може суттєво зменшити кількість окремих вихідних відеопотоків, які учаснику потрібно підтримувати.
Що насправді робить SFU?
SFU зазвичай приймає закодовані медіапотоки й вибірково їх пересилає. Залежно від реалізації та погоджених можливостей він може обирати, які потоки або шари якості надсилати кожному отримувачу.
Наприклад, учаснику, який дивиться на маленьку мініатюру, може не знадобитися така сама якість відео, як тому, хто показує доповідача на весь екран.
SFU допомагає керувати цими різними вимогами без того, щоб кожен відправник окремо передавав окремий потік кожному одержувачу.
Проте SFU не безкоштовний. Він потребує інфраструктури, серверної смуги пропускання, операційних витрат і додає ще один компонент на шлях медіа.
Модель приватності SFU також відрізняється від ретранслятора TURN. Оскільки SFU завершує медіатранспорт і вибірково пересилає медіа, він технічно може отримати доступ до медіа, яке приймає. Шифрування між учасником і SFU саме по собі не забезпечує наскрізної конфіденційності щодо цього SFU.
4. Peer-to-peer сітка проти SFU
Ці дві архітектури розвʼязують повʼязані, але різні задачі.

Peer-to-peer сітка
Кожен учасник встановлює медіазʼєднання з іншими учасниками.
Переваги:
- Можливі прямі медіашляхи.
- Не потрібен центральний медіасервер для повторного розподілу медіа.
- Невеликі кімнати можуть працювати без сервісу пересилання медіа.
Компроміси:
- Кожному відправнику може знадобитися завантажувати окремий потік кожному іншому учаснику.
- Кількість медіазʼєднань зростає разом із кімнатою.
- Вихідна смуга пропускання й керування зʼєднаннями можуть стати обмежувальними чинниками.
Розподіл через SFU
Кожен учасник надсилає медіа на центральний сервіс пересилання, який розподіляє їх між іншими учасниками.
Переваги:
- Ефективніший розподіл у багатьох сценаріях групового відео.
- Менша потреба, щоб кожен відправник завантажував окремі копії кожному отримувачу.
- Більше контролю над тим, які відеопотоки й шари якості отримують одержувачі.
Компроміси:
- Додаткова серверна інфраструктура та витрати на смугу пропускання.
- На шляху медіа зʼявляється посередник.
- Модель приватності й довіри відрізняється від прямого peer-to-peer звʼязку.
Головне — не вважати, що одну топологію треба застосовувати до кожного типу медіа. Аудіо й відео мають різні патерни трафіку та вимоги.
5. Чому Voxal залишає голос peer-to-peer, але може використовувати SFU для відео
Voxal розділяє голосове аудіо та відео з камери й демонстрації екрана.
Голосове аудіо завжди залишається peer-to-peer. Воно ніколи не проходить через необовʼязковий відео-SFU.
Це свідоме архітектурне рішення: голос — основна функція звʼязку, і Voxal не використовує SFU як центральний сервіс розподілу аудіо.
Відео з камери та демонстрації екрана — інша справа. У більших кімнатах повна peer-to-peer сітка може вимагати від кожного учасника завантажувати кілька відеопотоків. Що більше учасників, то важчим це стає.
Тому Voxal може використовувати Cloudflare Realtime SFU для відео та демонстрації екрана, коли це дозволяє налаштована перевага маршрутизації і кімната виходить за практичні межі сітки.
Перевага маршрутизації має значення:
- Дозволяти ретранслятор для великих кімнат: Voxal може використати SFU, коли кімната виростає за межі комфортної peer-to-peer відеотопології.
- Надавати перевагу прямому зʼєднанню: Voxal спершу пробує peer-to-peer і запитує, перш ніж дозволити ретранслятор, коли сітка стає непридатною.
- Лише пряме зʼєднання: відео й демонстрація екрана ніколи не використовують SFU, навіть якщо у великій кімнаті важко встановити всі прямі зʼєднання.
Ці налаштування стосуються відео й демонстрації екрана, а не голосового аудіо.

Чому б не пускати все через один сервер?
Бо найкраща топологія залежить від того, який трафік передається.
Голосовий потік зазвичай набагато менший за потік з камери. Спрямування голосу через центральний сервіс пересилання принесло б інший компроміс щодо інфраструктури й приватності, хоча для обраної в Voxal голосової архітектури це не потрібно.
Відео має вимогливіший профіль смуги пропускання й може суттєво виграти від серверного розподілу зі зростанням групи.
Розділення дає Voxal змогу зберегти peer-to-peer модель голосу й водночас запропонувати масштабованіший варіант для групового відео.
6. Що це означає для приватності
Мережеві терміни іноді вживають так, ніби вони автоматично гарантують певний рівень приватності. Це не так.
Peer-to-peer аудіо означає, що голосове медіа не проходить через центральний медіасервер, але сервери сигналізації все одно можуть координувати зʼєднання та обробляти повʼязані метадані.
Ретранслятор TURN пересилає зашифроване медіа, не декодуючи його. SFU ж, навпаки, завершує медіатранспорт, щоб вибірково пересилати потоки, і технічно може отримати доступ до відео, яке приймає.
Саме тому розмежування у Voxal важливе:
- Голос лишається peer-to-peer і за потреби використовує зашифрований ретранслятор TURN.
- Відео з камери та демонстрації екрана може використовувати SFU у більших кімнатах залежно від переваги маршрутизації.
- Локальна обробка віртуального фону відбувається на пристрої відправника, але це саме по собі не означає, що кожне відеозʼєднання пряме.
Розуміти реальний шлях медіа корисніше, ніж просто називати застосунок безсерверним.
7. Підсумок
Застосунок для звʼязку в реальному часі поєднує кілька незалежних рівнів:
- Сигналізація координує учасників і налаштування зʼєднання.
- ICE, STUN і TURN допомагають встановити робочий мережевий шлях.
- WebRTC і захищений транспорт RTP переносять медіа в реальному часі.
- Кодек на кшталт Opus ефективно подає аудіо.
- Мережева топологія визначає, чи тече медіа напряму між учасниками, чи через сервіс пересилання.
Дизайн Voxal застосовує ці рішення окремо до голосу й відео. Результат — архітектура з пріоритетом голосу: аудіо лишається peer-to-peer, а відео й демонстрація екрана можуть використовувати необовʼязкове серверне пересилання, коли цього потребують більші кімнати.
Ці відмінності важливі під час проєктування будь-якої системи звʼязку в реальному часі. Мета не в тому, щоб просто мінімізувати кількість серверів чи максимізувати кількість прямих зʼєднань, а в тому, щоб свідомо балансувати між затримкою, смугою пропускання, надійністю, масштабованістю та приватністю.
Спробуйте Voxal
Voxal поєднує peer-to-peer голосовий чат, push-to-talk (говоріння за натисканням), режим без рук, шумопригнічення та необовʼязкові відео й демонстрацію екрана.
Спробуйте Voxal у браузері або перегляньте реалізацію у відкритому репозиторії Voxal.
Читайте також: Що таке peer-to-peer голосовий чат? · Що таке push-to-talk? Практичний посібник · Документація Voxal з маршрутизації відео

