Аудио в SFU, MCU и P2P

Кратко

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

Для аудио у SFU есть важный приём, делающий его современным выбором по умолчанию: он умеет считывать крошечное число «насколько я громкий» в каждом пакете и пересылать только тех, кто реально говорит, при этом ни разу не декодируя звук. MCU выдаёт один чистый смешанный поток, который воспроизведёт любое устройство и который легко записать, но требует много серверных ресурсов и добавляет задержку – ведь он декодирует и заново кодирует всё.

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

Почему это важно

Если вы разрабатываете сервис видеоконференций, телемедицинскую платформу, онлайн-обучение или контакт-центр, способ обработки аудио на сервере напрямую влияет на ваш месячный счёт за серверы, пределы масштабирования и качество звука – будет ли вебинар на 200 человек звучать чётко или как шумная комната. Аудиообработка обычно остаётся в тени по сравнению с видео, поэтому команды часто копируют подход, использованный в видеоархитектуре, и больше не возвращаются к этой теме – а потом, при росте нагрузки, обнаруживают, что микширование аудио съедает ресурсы CPU, или что выборочная пересылка сломала функцию записи. Эта статья предназначена для продакт-менеджера, основателя или операционного руководителя, которому важно понять, почему одна архитектура смешивает аудио, а другая его пересылает, чтобы уверенно читать архитектурные предложения, задавать инженерам правильные вопросы и осознавать цену каждого решения. Старший инженер найдёт здесь каждое утверждение с ссылкой на соответствующий IETF RFC или на опубликованное поведение mediasoup, LiveKit и Jitsi. К концу статьи вы поймёте, какой из трёх вариантов выбрать и в какой момент дешёвое решение перестаёт быть выгодным.

Один вопрос, на который должен ответить каждый групповой звонок

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

Этот единственный вопрос – объединять голоса или держать их раздельно – и есть ключевое различие между тремя архитектурами. В контексте реального времени топология – это форма линий, соединяющих участников в комнате, и правило, определяющее, что происходит с аудиосигналом по ходу его прохождения по этим линиям. Видеоверсия этого вопроса – куда направляются линии и как сервер обрабатывает изображение – подробно рассмотрена в статье SFU против MCU против Mesh: три топологии WebRTC в нашем разделе про видеостриминг. Здесь мы сосредоточимся только на аудиочасти, потому что аудио отвечает на вопрос «объединять или держать раздельно» принципиально иначе, чем видео, и именно в этой разнице и заключаются большинство сюрпризов.

Полезный образ. Представьте званый ужин. В небольшой компании из четырёх человек все слышат друг друга напрямую – посредники не нужны. На панельной дискуссии звукорежиссёр берёт микрофон у каждого спикера, объединяет сигналы на пульте и подаёт общий звук в колонки зала. В радиоредакции продюсер держит запись каждого репортёра на отдельном канале и переключается между ними, отправляя в эфир тот, что сейчас работает. Небольшая группа – это P2P, сводящий пульт – MCU (Multipoint Control Unit, устройство многоточечного управления), переключатель каналов – SFU (Selective Forwarding Unit, блок выборочной пересылки). Компромиссы в программном обеспечении почти полностью соответствуют этим трём реальным схемам.

«Замечание об именах. «P2P» и «Mesh» пересекаются. «P2P» – peer-to-peer – строго означает отсутствие сервера в медиапути. При двух участниках это настоящее прямое соединение. При трёх и более P2P превращается в Mesh: каждый устанавливает прямое соединение с каждым. В этой статье мы используем термин P2P, поскольку именно так в SEO и продуктовом мире называют сценарий без сервера, и отмечаем случаи, когда важно различать его с Mesh.»

WebRTC – семейство протоколов, с помощью которых браузеры передают аудио и видео в реальном времени, – не выбирает топологию за вас. Один и тот же JavaScript API микрофона используется во всех трёх схемах – именно поэтому выбор между ними остаётся за вами, а не за браузером.

P2P: каждый голосует за каждого

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

Проблема начинается, когда звонок растёт, и проблема эта – исходящая полоса на собственном устройстве человека. В P2P, если в звонке пять человек, ваше устройство должно отправить ваш голос четыре отдельных раза – по одному каждому из четверых – и получить в ответ четыре отдельных голосовых потока. Здесь аудио снисходительнее видео, потому что голосовой поток мал. Типичный голосовой поток WebRTC на кодеке Opus идёт примерно на 24–32 тысячах бит в секунду; даже десять таких – заметно меньше половины мегабита, что осилит любое современное соединение. Так что для одного аудио P2P выдерживает группы крупнее, чем видео-P2P.

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

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

Нажмите, чтобы увеличить

MCU: сервер объединяет все голоса в один поток

MCU размещает в центре мощный сервер и возлагает на него основную нагрузку. Каждый участник отправляет свой единственный голосовой поток на сервер. Сервер декодирует каждый поток обратно в исходный звук, объединяет их в общий микс, снова кодирует этот микс и рассылает единый общий поток каждому участнику. С точки зрения любого участника он передаёт один поток и получает один поток – независимо от количества людей в звонке. Звонок на 50 человек для вашего устройства выглядит точно так же, как звонок на двоих: один поток вверх, один вниз.

Это свойство – главная сила MCU, и о нём стоит сказать чётко. Микширование здесь не наивное. Если бы сервер просто складывал аудио всех участников и отправлял один и тот же микс каждому, вы слышали бы эхо собственного голоса. Поэтому правильный аудио- MCU выдаёт каждому участнику немного разный микс: он отправляет вам голоса всех, кроме вашего собственного. Это называется миксом N-минус-1 – для N участников каждый получает сумму голосов остальных N-1. Именно это вычитание и не даёт звонку зациклиться сам на себе.

Чего стоит MCU, в простой арифметике

Цена такого удобства – ресурсы CPU сервера, и арифметика здесь безжалостна. На каждого участника серверу приходится выполнять полное декодирование аудио, участвовать в микшировании и затем снова полностью кодировать сигнал. Чтобы проиллюстрировать это, возьмём конкретный пример. Предположим, что один цикл «декодирование плюс кодирование» на сервере требует определённой единицы работы – назовём её одной «аудиозадачей». В звонке с 50 участниками сервер декодирует 50 входящих потоков и кодирует до 50 исходящих миксов – получается около 100 аудиозадач, непрерывно, на одну комнату. SFU в той же комнате выполняет ноль аудиозадач, поскольку вообще не декодирует потоки. Это не небольшая разница – это разница между сервером, способным обслуживать несколько комнат, и сервером, который может вместить сотни.

MCU также добавляет задержку, которой избегают две другие архитектуры. Декодирование, буферизация достаточного объёма аудио для чистого микса, само микширование и повторное кодирование – всё это требует времени. Каждый проход через декодер и кодер добавляет задержку к сетевому пути, так что время «рот-до-уха» на MCU стабильно выше, чем на SFU, пересылающем то же аудио. О том, откуда берётся каждая миллисекунда задержки в аудио реального времени, читайте в Конвейер аудио WebRTC целиком.

Где MCU всё-таки выигрывает

При такой цене – зачем MCU вообще существует? Три причины, и они реальные.

Во-первых, получателю нужно декодировать всего один поток. Дешёвая ТВ-приставка, шлюз телефонной сети, старый браузер на смарт-ТВ или дозвонившаяся телефонная линия не могут декодировать и смешивать десяток отдельных аудиопотоков – но один воспроизвести могут. Всякий раз, когда среди вашей аудитории есть устройство, способное справиться лишь с одним потоком, MCU подходит естественно. Классический случай – телефонный мост: дозвонившийся по PSTN участник видеовстречи должен получить один смешанный аудиопоток, потому что телефонная линия несёт ровно один.

Во-вторых, один смешанный поток легко записать и передать дальше. Если вам нужен единый аудиофайл всей встречи – MCU уже его создал. Мы вернёмся к этому позже, потому что именно на этапе записи архитектуры SFU начинают усложняться.

В-третьих, микс одинаков для всех. Поскольку сервер управляет общим звуком, он может применить единообразную нормализацию громкости – и тогда тихий и громкий спикеры будут звучать на сопоставимых уровнях. (Громкость между спикерами – отдельная тема, см. Громкость, peak, RMS, LUFS.)

SFU: сервер пересылает голоса, не декодируя их ни разу

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

Поскольку сервер никогда не декодирует, затраты CPU SFU на комнату составляют лишь долю затрат MCU. Именно это и стало главной причиной, по которой SFU стал выбором по умолчанию для групповых звонков в 2010-х и остаётся им в 2026 году: он позволяет масштабироваться на гораздо большее число одновременных комнат при тех же аппаратных ресурсах. Затраты смещаются с сервера на клиент – теперь ваше устройство принимает и декодирует несколько аудиопотоков вместо одного. Однако, как мы видели, аудиопотоки малы, и декодировать пригоршню таких потоков легко на любом современном телефоне.

Приём, который делает аудио SFU рабочим: пересылать только тех, кто говорит

Если бы SFU наивно пересылал аудио каждого участника всем, звонок на 100 человек завалил бы каждое устройство 99 входящими голосовыми потоками, и общий шипящий фон от 99 не совсем тихих микрофонов стал бы невыносимым. Ключевая аудиофункция SFU – в том, что он так не делает. Он пересылает только важные потоки – обычно несколько самых громких участников, говорящих в данный момент, – и отбрасывает остальные.

Вот изящное решение, и это чистая аудиоинженерия. Чтобы определить, кто громче, серверу обычно пришлось бы декодировать каждый поток и измерить его уровень – именно ту ресурсоёмкую операцию, от которой SFU пытается уйти. Выход – небольшое расширение заголовка RTP, описанное в IETF RFC 6464 (Client-to-Mixer Audio Level Indication, декабрь 2011). С его помощью каждый отправитель добавляет к каждому аудиопакету одно число – уровень громкости этого пакета, выраженный значением от 0 до 127 в -dBov (децибелы ниже максимально возможного уровня сигнала, где 0 – полная шкала, а 127 – цифровая тишина). Это число находится в заголовке пакета, вне зашифрованной области, поэтому сервер может считывать громкость каждого пакета, не расшифровывая и не декодируя сам аудиосигнал. Стандарт даже предусматривает отдельный бит – бит «V» – чтобы отправитель мог указать, содержит ли пакет реальную речь.

С этим числом каждый пакет SFU может ранжировать участников по активности – то есть по тому, кто реально говорит, – и пересылать только несколько самых громких, при этом ни разу не обрабатывая сам звук. Само введение RFC 6464 формулирует цель прямо: оно позволяет серверу «пересылать только несколько самых громких аудиопотоков, не требуя декодировать и измерять каждый получаемый поток». Комплементарный стандарт, RFC 6465 (Mixer-to-Client Audio Level Indication, декабрь 2011), позволяет микшеру сообщить каждому клиенту уровни отдельных голосов, вошедших в микс, – так интерфейс клиента может подсветить активного спикера, даже когда аудио приходит уже смешанным.

Определение доминирующего спикера: как превратить данные о громкости в решение

Прочитать уровень громкости – шаг первый. Определить, кто является «активным спикером» – чтобы интерфейс подсветил его, а SFU перенаправил аудио, – шаг второй, и он не так прост, как может показаться: «кто громче прямо сейчас». Кашель, упавший телефон или один громкий слог не должны отвлекать внимание. RFC 6464 сам предупреждает, что серверам «не следует принимать решения о пересылке аудио на основе мгновенных значений уровня громкости», а вместо этого нужно сглаживать уровни во времени перед принятием решений.

Самое распространённое решение – алгоритм Иланы Волфин и Исраэля Коэна Dominant Speaker Identification for Multipoint Videoconferencing, который анализирует уровни громкости каждого участника по коротким, средним и длинным временным окнам, чтобы определить, кто в данный момент говорит. При этом используются только числовые данные о громкости из RFC 6464, без декодирования аудиопотока. Этот алгоритм реализован в mediasoup (начиная с версии 3.8.0) – за него отвечает ActiveSpeakerObserver – и лежит в основе логики определения доминирующего спикера в Jitsi. В результате формируется стабильный сигнал «активного спикера», который SFU применяет как для пересылки нужных аудио- и видеопотоков, так и для подсветки участника в интерфейсе.

Наглядный пример делает экономию очевидной. На собрании-таунхолле из 200 человек, где один выступает, а остальные слушают, MCU постоянно декодировал бы и смешивал все 200 потоков. SFU, использующий уровни RFC 6464 и определение доминирующего спикера, пересылает по сути один поток – выступающего – всем 199 слушателям, не декодируя ничего на сервере. Разница в пропускной способности и нагрузке на CPU не постепенная – это разница между жизнеспособным продуктом и нежизнеспособным.

Нажмите, чтобы увеличить

Сравнение бок о бок

Три архитектуры по-разному распределяют одни и те же четыре ресурса: отдача клиенту, нагрузка на декодирование у клиента, CPU сервера и задержка. Таблица ниже – это решение в одном кадре. «Победитель» в каждом столбце зависит от характера вашего приложения, поэтому интерпретируйте её с учётом своего продукта, а не абстрактно.

Узор становится очевидным с первого взгляда. P2P выигрывает по задержке и стоимости, но только для коротких звонков. MCU эффективен, когда получатель слабый или нужен один общий поток – но это обходится дорого с точки зрения серверных ресурсов. SFU побеждает почти во всех сценариях, поэтому он и является выбором по умолчанию. Его единственная реальная слабость – то, что MCU делает бесплатно: создание единой записи.

Частая ошибка: считать, что запись на SFU бесплатна

Вот ловушка, с которой чаще всего сталкиваются команды, – и она специфична именно для аудио. Поскольку SFU обрабатывает каждый голосовой поток отдельно, в системе не существует единого общего аудиопотока. Это отлично работает в реальном времени – каждый спикер остаётся независимым, что позволяет интерфейсу, например, приглушать одного участника, отображать уровни громкости или применять пространственное аудио. Но как только клиент спрашивает: «Можно записать встречу и прислать MP3 позже?» – у SFU просто нет того, что можно записать. Микс не создаётся. Чтобы получить одну запись, придётся запустить отдельный процесс, который подпишется на каждый поток, декодирует их, сведёт и закодирует результат – что иронично, ровно ту работу, которую всё это время выполнял MCU.

Поэтому зрелые продукты на SFU используют выделенный сервис записи, или «egress», рядом с ресивером. Например, LiveKit – это SFU, который не декодирует аудио на сервере во время живого звонка: чтобы записать, вы подписываетесь на аудиодорожки, декодируете кадры Opus, агрегируете их в сырой PCM и кодируете файл. Вывод для планирования: SFU не делает запись бесплатной – вам всё равно придётся закладывать ресурсы CPU на микширование, от которого вы, возможно, надеялись уйти. Полный путь записи и транскрипции – отдельная тема, см. Конвейеры записи и транскрипции.

Вторая, незаметная ловушка: DTX сбивает с толку наивных наблюдателей уровня. Прерывистая передача Opus (DTX) позволяет при тишине снижать нагрузку с примерно 24–32 кбит/с до около 1 кбит/с, почти не отправляя данные. Это реальная экономия полосы пропускания – но наблюдатель уровня, ожидающий пакет каждые 20 миллисекунд, может интерпретировать паузы как «спикер замолчал», потому что пакеты просто не приходят. Трекер задач самого LiveKit документирует именно такое поведение его наблюдателя уровня при работе с Opus DTX. Если в интерфейсе активного спикера появляется мерцание, когда участники замолкают, стоит проверить тайминг DTX – это первое, что нужно проверить. Подробнее о том, как работают DTX и подавление тишины, см. Детектор речевой активности (VAD) и прерывистая передача (DTX).

Как выбирают реальные продукты

К 2026 году архитектура устоялась в чёткий узор. Почти любой групповой звонок с числом участников больше четырёх работает на SFU, потому что другие подходы не масштабируются на большие комнаты при доступных вычислительных ресурсах. P2P сохраняется для звонков один на один и очень небольших групп, где важны минимальная задержка и отсутствие затрат на сервер – например, врач и один пациент, или деловой разговор на двоих. MCU отошёл на периферию, оставаясь актуальным лишь в специфических случаях, где дорогостоящее микширование оправдано: подключение встречи к телефонной сети, трансляция, требующая единого объединённого потока, или системы, в которых принимающие устройства физически не способны декодировать более одного видеопотока.

Многие продакшн-системы – гибриды. Звонок может начаться как P2P между двумя участниками, а затем перейти в режим SFU, когда подключается третий. Конференция, работающая в режиме SFU, может временно задействовать небольшой микшер в стиле MCU только для ветки подключения по PSTN, объединяя аудиопотоки комнаты в один для телефонного абонента, в то время как все остальные участники продолжают работать в независимых потоках SFU. Архитектура – не догма; это решение, которое может приниматься на уровне комнаты, а иногда и на уровне отдельного участника. Именно заголовок уровня аудио из RFC 6464 делает SFU-часть каждого такого гибрида экономически доступной.

Дерево решений, простыми словами. Двоим – запись не нужна? P2P. Получатели, способные воспроизводить только один поток, или жёсткая потребность в единой общей записи с минимальной инженерной нагрузкой? MCU. Всё остальное – а это большинство продуктов – SFU, с отдельным сервисом egress, если требуются записи. Схема ниже следует той же логике сверху вниз.

Нажмите, чтобы увеличить

Где здесь Фора Софт

Мы интегрируем аудио в реальном времени в видеоконференции, телемедицину, онлайн-обучение и контакт-центры с 2005 года, и вопрос архитектуры – один из первых, который мы решаем на каждом проекте. Телемедицинская консультация между одним врачом и одним пациентом часто лучше всего реализуется как чистый P2P-звонок; виртуальный класс с одним учителем и сорока учениками – это SFU, который транслирует поток учителя и тех немногих учеников, кто снял mute; вебинар, принимающий телефонные дозвоны, требует SFU с небольшим мостом MCU для телефонной ветки. Мы выбираем топологию, исходя из формата звонка, требований к записи и реальных устройств, которыми пользуется аудитория, – а не под моду. Когда продукту нужны и масштаб, и качественные записи, мы заранее закладываем CPU на egress-микширование, потому что видели, к чему приводит осознание этой цены за неделю до запуска.

Ключевые выводы

• Существует три аудиоархитектуры: P2P (без сервера), MCU (сервер смешивает потоки) и SFU (сервер пересылает).
• SFU пересылает только самых громких участников, определяя их по уровню громкости согласно RFC 6464, не декодируя аудиоданные.
• MCU формирует один общий аудиопоток, но требует значительных вычислительных ресурсов сервера и вносит наибольшую задержку.
• P2P подходит для звонков один на один и очень небольших групп; при четырёх и более участниках необходим сервер.
• SFU – стандартный выбор в 2026 году; его основной недостаток – сложность создания единой записи.
• Запись на SFU не бесплатна – требуется отдельный сервис микширования, который нужно предусмотреть заранее.

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

• Конвейер аудио WebRTC целиком
• Детектор речевой активности (VAD) и прерывистая передача (DTX)
• SFU против MCU против Mesh: три топологии WebRTC (видео)