Среди подводных камней WebRTC один особенный. Это то, как браузеры договариваются между собой о передаче медиа-потоков. Кодеки, битрейты, разрешение видео, – вся вот эта история. Кода медиа-поток один — все хорошо. Но когда их два (а видео со звуком, это, на секундочку, два медиа-потока: один для видео, другой для звука), то мнения браузеров о формате описания ситуации резко разделяются. Сделать видеозвонок из Chrome в Firefox можно довольно легко. А вот видеозвонок со звуком — уже нет. Под катом небольшая история, почему так повелось, что запилили в новой Safari и какой особый путь у Microsoft Edge.
Комбайн на поле голосовых и видеозвонков
WebRTC — это комбайн. Множество протоколов и разных JavaScript API под одним названием, который делает разные штуки:
- Захват видео с камеры и/или голоса с микрофона.
- Кодирование и декодирование разными кодеками, которые поддерживает браузер.
- Установка Peer-to-Peer подключения между браузерами с использованием подхода ICE и указанных серверов. STUN серверов для изучения топологии сети и TURN серверов, если не удалось пробить NAT и нужно подключаться через внешний сервер.
- Передача видео и аудио по сети. Кроме того, анализ ширины канала и подстройка под него битрейта кодека.
- Воспроизведение полученного.
- Передача данных в UDP или TCP стиле.
- Screen Sharing.
Самое сложное в этой истории – установить Peer-to-Peer подключение. Если это не локальное общение между вкладками, устройства не в одной сети или у них нет реальных IP-адресов с открытыми портами, то нужны какие-то промежуточные серверы, чтобы «договориться». Обычно эти сервера поднимает разработчик, который хочет воспользоваться WebRTC. За исключением STUN эхо серверов, которые отвечают на вопрос «какой у меня публичный IP» и есть публичные от Google.
В зависимости от того, что разработчик собирается передавать: голос, видео или произвольные данные, – установливается Peer-to-Peer подключение. WebRTC формирует текстовые пакеты «offer», «answer» и «ice candidate», которые разработчик должен как-то передавать между подключающимися друг к другу браузерами (обычно через собственный signaling сервер). В этих пакетах оба браузера описывают свои возможности и что будет происходить, а WebRTC пытается выбрать оптимальный способ подключения.
SDP-наследие телефонии
Пакеты, которыми WebRTC обменивается руками разработчика, используют формат SDP. Он очень старый, текстовый, пришел из телефонии (WebRTC старается минимизировать усилия разработчика при звонке из браузера в телефонные сети и обратно) и похож на HTTP. Вот так выглядит SDP-пакет «этот браузер хочет установить Peer-to-Peer подключение к другому браузеру, но пока не знает, что будет передавать по сети».
Если разработчик хочет начать/закончить передавать данные, голос или видео, то WebRTC сразу требует от него «renegotiation» – перезапуск Peer-to-Peer подключения, чтобы проверить оптимальность сетевого маршрута для передаваемых данных и передоговориться о кодеках. Вот так выглядит SDP-пакет, в котором WebRTC сообщает о желании передавать видео:
Быстро меняющийся стандарт
WebRTC с нами уже много лет и до сих пор в статусе «бета-версия». За последнее время JavaScript API было полностью переписано с коллбеков на промисы, поменялась работы с голосовыми и видео потоками, Microsoft скрафтила альтернативный API «oRTC». Много всего интересного произошло. А еще поменялся формат описания медиа потоков в SDP-пакете. Много лет использовавшийся «Plan B» с иерархической структурой был deprecated и заменен на «Unified Plan», в котором каждый поток задавался отдельной секцией в SDP пакете. Сравните.
Было:
Стало:
Chrome vs Firefox vs Edge vs Safari
Когда дело касается бета-версий веб-технологий, то их реализация в браузерах иногда сильно различается и может на годы отставать от текущей версии стандарта. Так случилось и с WebRTC. Много лет назад в Google Chrome сделали поддержку несколько медиа-треков в формате «Plan B» и до сих пор не поменяли реализацию на «Unified Plan». Соответствующий тикет открыт пару лет назад, разработчики обсуждают, насколько это важно и переназначают тикет друг другу, но воз и ныне там. В Firefox, что характерно, реализован только Unified Plan, поэтому без проблем можно коммуницировать только один медиа трек: голос или видео без звука. Нужно больше? Добро пожаловать в мир адаптеров и полифилов!
Microsoft Edge, изначально поддерживающий только свою собственную реализацию API «oRTC», в последних версиях добавил поддержку WebRTC API и Unified Plan. В Safari поддержка WebRTC будет только в следующей версии, бета которой уже доступна для разработчиков. И, что печально, Plan B. Потому что делалось на основе Chromium.
Как делать кроссбраузерные звонки?
Как мы видим, Chrome, самый популярный браузер, остался с устаревшим форматом «Plan B». Там же Safari, мобильная версия которого живет в iPhone. Firefox и новый Microsoft Edge с новым «Unified Plan».
Для передачи голоса или видео без аудио это не играет никакой роли, а вот в случае нескольких медиа-треков придется вручную модифицировать SDP или воспользоваться адаптером. Очень надеюсь, что рано или поздно все браузеры перейдут на Unified Plan. Но пока суровая реальность такова, что большинство Desktop и подавляющее большинство Mobile браузеров поддерживают «Plan B», а для совместимости с Firefox и Edge придется добавлять код. И много отлаживаться.
Картинка до ката взята отсюда.
Комментарии (0)