В 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, о котором он рассказывал в эту пятницу. Нам обоим можно задавать вопросы в комментах!
Картинка до ката взята отсюда.
Комментарии (14)
mitinsvyat
17.07.2017 12:59+2WebRTC будет работать только для страниц, загруженных по HTTP (можно отключить для локальной отладки).
таки HTTPS?
IchigoWalker
17.07.2017 13:31-3Что за бред про хромом и скриншэринг? При скриншэринге не нужны никакие плагины на хром и на CEF. Нужна лишь правильная реализация. У нас целый сервис на этом построен, инфа какая-то непроверенная
IchigoWalker
17.07.2017 14:04-4Конечно есть необходимость запустить хром с флагами на юзермедиа. Но это не «танцы с бубнами» в виде плагинов =)
irbisadm
17.07.2017 14:08Можно вообще пересобрать хромиум без этих проверок и распространять своим клиентам, когда их немного. ;)
eyeofhell
17.07.2017 14:11+2Эмм… Вы будете предлагать клиентам запускать хром с аргументами командной строки? рили? :)
irbisadm
17.07.2017 14:10Единственный способ сделать это без расширения — это открытие флагом (да и из консоли это тоже флаг). Это откроет доступ к рабочему столу пользователя, для любого сайта. Расширение, в котором указывается список доверенных url и которое ставится из доверенного магазина, как-то безопаснее.
eyeofhell
17.07.2017 14:12+2Сервис публичный? Ссылку в студию. Нам тут уже всем интересно стало КАК :)
IchigoWalker
17.07.2017 14:37Да не, наш сервис использует CEF (под macos), там как-то попроще с запуском его с флагами. Для веб-сервисов в браузере естественно запуск клиентского Google Chrome с аргументами бредовая идея. Однако стоило бы отобразить в статье такую возможность без 3d party плагинов.
KonstantinSpb
Так есть же Jitsi, которых купил Atlassian, опен-сорсный кстати. У них как раз на WebRTC сделан один из клиентов
eyeofhell
Да, оч много решений со своими плюсами и минусами. Voximplant — про реалтайм JavaScript в облаке, все готовое из коробки и надежную интеграцию с телекомами.