Как стать автором
Обновить

Комментарии 11

Статья про командную строку докера + немного рекламы?

Не совсем так. Статья про WebRTC в докере. И да, на примере WebCallServer, хотя с той же Wowza проблемы с настройкой сети в докере будут ровно теми же, так что рекомендации можно применить к любому медиасерверу с поддержкой этого протокола.
ну если совсем по правде — то докеру нет разницы какой протокол идет поверху tcp/ip
Для WebRTC транспорт по умолчанию — UDP (хотя и TCP можно, но это дает задержку и сводит на нет преимущества протокола), причем, в отличие от однопортовых RTMP и RTSP, заранее неизвестно, на какой именно порт подключится клиент. Отсюда и танцы сложности в настройке.

Я бы добавил все таки в статью пометку - предостережение о том что в виртуальных сетях докера не стоит поднимать RTC продакшн решения и использовать их только в для dev.

Это разумно. Но бывают и те, кто любит микросервисы, и, соответственно, используют докер для WebRTC и в продакшне. Для того и сделана пометка: одна чат-комната — один контейнер.
Так тут не в архитектуре построения приложений дело. Тут ведь проблема в том как работает докер. Не важно ведь сколько там будет комнат, тайминги при обработке RTP могут поехать и в 1 комнате с 2 участниками очень легко.
Тут нужно либо тонко ядро хост системы настраивать либо использовать сеть хоста.
тайминги при обработке RTP могут поехать

Вот получили SRTP пакет от Chrome, например с timestamp 111222333. Далее передали этот пакет дальше по сети. Это тот тайминг, про который идет речь? Может ли он куда-то поехать?

Возможно вы имеете ввиду проблему видео энкодера, который при 30 FPS обязан выдавать не менее 30 фреймов в секунду и при просадках в производительности CPU/GPU начинает не успевать. Но это опять же не проблема Докера, а проблема производительности железа и ее надо обязательно мониторить чтобы не допускать таких просадок на каждом отдельном стриме.

Еще, что касается RTP пакетов, они не обязательно идут четко по времени энкодера, т.к. сеть не идеальна. Это все нормально отрабатывается буферами в WebRTC. Опять же, не важно в Докере или нет.
Нет
Проблема кроется в том как работает Docker: в том как он синхронизируется CPU и как выделяются рессурсы.

Чтобы не повторяться оставлю ссылку на kamailio.ru/kamailio-conf от 2019 года. Тут отлично освещена эта проблема и очень хорошо подана.

Смотрите с 4:06:50
https://www.youtube.com/watch?v=D3OJvNQ4-uI

В вашем случае это не Asterisk/freeswitch а другое ПО но сути это не меняет

Разницы в SRTP или RTP тут нет

Ну и в целом нет смысла тащить Network в докер для Reatime Communitation просто по той причине что для нескольких инстансов так или иначе придется мапить диапазон портов на рызные диапазоны портов хоста
профита в виде еще одного NAT нет.

был кстати на этой лекции, вывод который можно сделать это то, что не надо бездумно поднимать N докер контейнеров с дефолтными ран-тайм настройками на одном хосте и расчитывать, что все будет летать. И это не только к RTP/RTCP/SRTP относится.

На одном сервере только с одним контейнером можно спокойно предположить, что практически все cpu время будет выделено для этого работающего контенера, конечно с условием, что никаких других cpu-intensive задач там нет. И никакие тайминги никуда не поедут.

Если же контейнеров несколько, то планировщик можно настривать штатными докер опциями: cpu-period, cpu-quota. Лучше предварительно почитать о том как они работают в документации scheduler/sched-bwc.txt

Спасибо за ссылку.

Там обозначены две проблемы:

1. При разделении ресурсов CPU между контейнерами через cgroups, софт внутри контейнера может выбирать квоту, установленную планировщиком,
в результате чего возникает jitter, который негативно влияет на воспроизведение RTP потока.

2. Проблема с таймингами. В нашем случае не актуальна, т.к. RTP поток у нас не привязан к времени сервера.

Проблема с разделением CPU и Jitter действительно существует и не только в докерах. Гипервизоры также могут влиять.

Поэтому при запуске Docker-контейнера, мы назначаем контейнеру конкретные ядра CPU. В этом случае контейнеры не конфликтуют, нет упоминаемых квот. Сейчас проводим серию нагрузочных тестов докер контейнеров и они показывают хорошие результаты. Планируем выложить статью с результатами тестов. Судя по ним, докер вполне подходит для продакшена.

Jitter бывает и на железных машинах. В случае WebRTC он гасится адаптивным jitter-буфером, который работает на клиенте достаточно в широком диапазоне (до 1000 мс).

По поводу NAT. Можно просто выделить каждому контейнеру свой IP адрес. Тогда проблема с маппингом портов отпадает.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий