Звонки между браузерами: подводные камни WebRTC
- вторник, 18 июля 2017 г. в 03:13:25
https://habrahabr.ru/company/Voximplant/blog/333486/
WebRTC, доступное в современных браузерах через JavaScript API, захватывает голос и видео, передает их по сети и воспроизводит в другом браузере. Еще оно умеет Peer-to-Peer между браузерами, Screen Sharing, передачу данных UDP-пакетами и подстройку битрейта под ширину канала. Очень хорошая технология. И Skype for Web на ней можно собрать, и превратить джойстик в световой меч для игры на ноутбуке, и позвонить с сотового на веб-страницу. Очень хорошая технология. Но сырая.
В Voximplant мы уже много лет развиваем множество SDK для звонков в наше облако: Android, iOS, Unity, React Native. Почетное место занимает Web SDK, использующий как раз WebRTC. С помощью него CRM принимают звонки «на веб страницу», работают кнопки «позвоните нам с веб сайта» и видео консультации с врачами. За годы мы набили множество шишек в использовании WebRTC, и под катом я кратко пройдусь по основным моментам, которые вас не обрадуют, если вы захотите использовать эту замечательную технологию.
Последние несколько лет WebRTC находится в состоянии «постоянной беты», что дает разработчикам и комитету по стандартизации возможность переделывать API, как им нравится. И они пользуются этой возможностью!
Несколько лет назад уже стабилизировавшийся API был полностью переделан: колбеки заменили на промисы, а получение потока с камеры и микрофона разделили на «треки». При этом новое API полностью реализовано не во всех браузерах. К примеру, Chrome до сих пор не умеет работать с треками.
До начала передачи голоса или видео браузерам нужно договориться между собой о разрешении, кодеках, битрейтах, – всей вот этой истории. Для этого WebRTC использует заимствованный из телекома текстовый протокол SDP (Session Description Protocol). Разработчику необходимо каким-либо способом (обычно через собственный signaling сервер) передать «offer» и «answer» SDP-пакеты между браузерами, после чего они попытаются установить Peer-to-Peer подключение и смогут передавать видео и звук, как договорились.
Проблема в том, что Chrome реализует уже много лет как устаревший «Plan B», а все остальные браузеры, включая Firefox — новый «Unified Plan». Отличаются они в кодировании нескольких потоков. А видео со звуком это, на секунду, уже два потока. Так что пока вы передаете между браузерами голос — то все хорошо. Как только начинаете передавать видео — у вас ничего не работает и нужно писать адаптер или использовать существующие полифилы.
Хотите сделать сервис онлайн-вебинаров и показывать рабочий стол? Будет работать только в Firefox. А для Chrome придется делать свой Add-on, прописывать в нем свой сайт как «доверенный» и просить пользователей этот аддон установить. Из соображений безопасности, конечно же.
Совсем недавно Apple анонсировала поддержку WebRTC в Safari, так что осенью технология будет доступна во всех основных браузерах: Chrome (desktop и Android), Safari (desktop и iOS), Firefox, Edge. Но первая версия будет содержать в себе множество ограничений, призванных защитить пользователя от попыток заглянуть в его веб-камеру через браузер:
На самом деле со всеми этими нюансами вполне можно жить. Сотни наших клиентов используют WebSDK для решения самых разных задач и у них все работает. Только у irbisadm седых волос за последний год прибавилось, как у главного по разработке WebSDK. Бонусом для Хабрапользователей — запись его внутренней лекции по нашему WebSDK, о котором он рассказывал в эту пятницу. Нам обоим можно задавать вопросы в комментах!
Картинка до ката взята отсюда.
- Разработка веб-сайтов
- Программирование
- JavaScript
- Google Chrome
- Блог компании Voximplant
WebRTC, доступное в современных браузерах через JavaScript API, захватывает голос и видео, передает их по сети и воспроизводит в другом браузере. Еще оно умеет Peer-to-Peer между браузерами, Screen Sharing, передачу данных UDP-пакетами и подстройку битрейта под ширину канала. Очень хорошая технология. И Skype for Web на ней можно собрать, и превратить джойстик в световой меч для игры на ноутбуке, и позвонить с сотового на веб-страницу. Очень хорошая технология. Но сырая.В Voximplant мы уже много лет развиваем множество SDK для звонков в наше облако: Android, iOS, Unity, React Native. Почетное место занимает Web SDK, использующий как раз WebRTC. С помощью него CRM принимают звонки «на веб страницу», работают кнопки «позвоните нам с веб сайта» и видео консультации с врачами. За годы мы набили множество шишек в использовании WebRTC, и под катом я кратко пройдусь по основным моментам, которые вас не обрадуют, если вы захотите использовать эту замечательную технологию.
Несколько разных версий API
Последние несколько лет WebRTC находится в состоянии «постоянной беты», что дает разработчикам и комитету по стандартизации возможность переделывать API, как им нравится. И они пользуются этой возможностью!
Несколько лет назад уже стабилизировавшийся API был полностью переделан: колбеки заменили на промисы, а получение потока с камеры и микрофона разделили на «треки». При этом новое API полностью реализовано не во всех браузерах. К примеру, Chrome до сих пор не умеет работать с треками.
Unified Plan и Plan B
До начала передачи голоса или видео браузерам нужно договориться между собой о разрешении, кодеках, битрейтах, – всей вот этой истории. Для этого WebRTC использует заимствованный из телекома текстовый протокол SDP (Session Description Protocol). Разработчику необходимо каким-либо способом (обычно через собственный signaling сервер) передать «offer» и «answer» SDP-пакеты между браузерами, после чего они попытаются установить Peer-to-Peer подключение и смогут передавать видео и звук, как договорились.
Проблема в том, что Chrome реализует уже много лет как устаревший «Plan B», а все остальные браузеры, включая Firefox — новый «Unified Plan». Отличаются они в кодировании нескольких потоков. А видео со звуком это, на секунду, уже два потока. Так что пока вы передаете между браузерами голос — то все хорошо. Как только начинаете передавать видео — у вас ничего не работает и нужно писать адаптер или использовать существующие полифилы.
Screen Sharing требует бубна
Хотите сделать сервис онлайн-вебинаров и показывать рабочий стол? Будет работать только в Firefox. А для Chrome придется делать свой Add-on, прописывать в нем свой сайт как «доверенный» и просить пользователей этот аддон установить. Из соображений безопасности, конечно же.
Safari защищает пользователей
Совсем недавно Apple анонсировала поддержку WebRTC в Safari, так что осенью технология будет доступна во всех основных браузерах: Chrome (desktop и Android), Safari (desktop и iOS), Firefox, Edge. Но первая версия будет содержать в себе множество ограничений, призванных защитить пользователя от попыток заглянуть в его веб-камеру через браузер:
- Доступ к камере и микрофону только из Safari, заблокировано для WebView.
- WebRTC будет работать только для страниц, загруженных по HTTPS (можно отключить для локальной отладки).
- Если WebRTC используется в iframe, то вся цепочка iframe'ов должна быть загружена с того же сайта, что и веб-страница.
- Локальный IP-адрес для Peer-to-Peer подключения используется, только если пользователь дал доступ к камере или микрофону.
- Старая версия API, без промисов, доступна только в отладочном режиме. Так что нам придется писать разный код для Chrome и «всех остальных».
- Запрет на автопроигрывание видео будет снят только в том случае, если пользователь уже дал доступ к камере или микрофону. Или если уже воспроизводится звук.
Насколько все страшно на практике?
На самом деле со всеми этими нюансами вполне можно жить. Сотни наших клиентов используют WebSDK для решения самых разных задач и у них все работает. Только у irbisadm седых волос за последний год прибавилось, как у главного по разработке WebSDK. Бонусом для Хабрапользователей — запись его внутренней лекции по нашему WebSDK, о котором он рассказывал в эту пятницу. Нам обоим можно задавать вопросы в комментах!
Картинка до ката взята отсюда.