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, о котором он рассказывал в эту пятницу. Нам обоим можно задавать вопросы в комментах!



Картинка до ката взята отсюда.
Поделиться с друзьями
-->

Комментарии (14)


  1. KonstantinSpb
    17.07.2017 12:58
    +1

    Так есть же Jitsi, которых купил Atlassian, опен-сорсный кстати. У них как раз на WebRTC сделан один из клиентов


    1. eyeofhell
      17.07.2017 13:08

      Да, оч много решений со своими плюсами и минусами. Voximplant — про реалтайм JavaScript в облаке, все готовое из коробки и надежную интеграцию с телекомами.


  1. mitinsvyat
    17.07.2017 12:59
    +2

    WebRTC будет работать только для страниц, загруженных по HTTP (можно отключить для локальной отладки).
    таки HTTPS?


    1. eyeofhell
      17.07.2017 13:05

      Таки да, опечатка


  1. IchigoWalker
    17.07.2017 13:31
    -3

    Что за бред про хромом и скриншэринг? При скриншэринге не нужны никакие плагины на хром и на CEF. Нужна лишь правильная реализация. У нас целый сервис на этом построен, инфа какая-то непроверенная


    1. eyeofhell
      17.07.2017 13:32

      В комменты саммонится irbisadm


    1. IchigoWalker
      17.07.2017 14:04
      -4

      Конечно есть необходимость запустить хром с флагами на юзермедиа. Но это не «танцы с бубнами» в виде плагинов =)


      1. irbisadm
        17.07.2017 14:08

        Можно вообще пересобрать хромиум без этих проверок и распространять своим клиентам, когда их немного. ;)


      1. eyeofhell
        17.07.2017 14:11
        +2

        Эмм… Вы будете предлагать клиентам запускать хром с аргументами командной строки? рили? :)


    1. irbisadm
      17.07.2017 14:10

      Единственный способ сделать это без расширения — это открытие флагом (да и из консоли это тоже флаг). Это откроет доступ к рабочему столу пользователя, для любого сайта. Расширение, в котором указывается список доверенных url и которое ставится из доверенного магазина, как-то безопаснее.


    1. eyeofhell
      17.07.2017 14:12
      +2

      Сервис публичный? Ссылку в студию. Нам тут уже всем интересно стало КАК :)


      1. IchigoWalker
        17.07.2017 14:37

        Да не, наш сервис использует CEF (под macos), там как-то попроще с запуском его с флагами. Для веб-сервисов в браузере естественно запуск клиентского Google Chrome с аргументами бредовая идея. Однако стоило бы отобразить в статье такую возможность без 3d party плагинов.


  1. kolpeex
    17.07.2017 19:02
    +1

    А как хэнгаутс работает без плагина и специальных флагов?


    1. eyeofhell
      17.07.2017 19:15
      +1

      Полагаю, google.com по умолчанию занесен в Хроме в доверенные сайты :)