Ну очень интересно было разобраться, как совершать видеозвонки через браузер внутри компании и насколько это полезно. Тем более, что skype — «прослушивается» и пересылаемые пароли парсятся роботами…
Вроде есть Google+ Hangouts и им нередко пользуются — но это все таки не WebRTC и проприетарная облачная технология. Кто знает — не просматривают ли наше совещание по бизнес-планированию коллеги из другой компании-конкурента с блокнотами и неподдельными улыбками на сияющих лицах?
В общем, согласитесь, тема своих, приватных надежных видеопереговоров внутри компании — актуальна как никогда. Многим это нужно, но как организовать-то? У нас — получилось. Это можно сделать достаточно просто, если знать как :-) (изучив десяток RFC, стандартов w3c и их реализаций и докопавшись до причин).
Ниже я постараюсь провести по основным технологическим рискам реализации, на которые пришлось наступить нам и придется наступить скорее всего и вам — а на закуску: краткая технологическая выжимка и бизнесовый TODO, без взрывающих мозг ненужных деталей.
Одна из прорывных технологий HTML5 — это, несомненно, WebRTC, развиваемая w3c при поддержке Google, Mozilla и Opera.
Суть ее в том, что имея камеру, микрофон и браузер на компьютере, я могу совершить видеозвонок другому человеку с браузером, камерой и микрофоном, находящемся где угодно — как коллеге за соседним столом, так и боссу, загорающему на пляже с ноутбуком в окружении прекрасных женских тел. При этом соединение будет зашифрованным, раз, и только между вами — peer-to-peer — два. Круто же? Но это еще не все.
Действопроисходит с использованием сильной черной магии происходит практически прозрачно, «внутри» браузера — вы и ваши программисты не забивают себе голову кодеками, файерволами, согласованиями, sip и т.п. — в самом простейшем случае задача видеозвонков с первого взгляда решается десятком строк js-кода и вот оно, счастье — приватные видеопереговоры у вас в компании работают.
Не вникайте в эту схему, иначе может взорваться мозг. Внутрь браузера засунули десятилетиями развиваемые медиа-технологии и протоколы: телестудию, радиостанцию и телефонную АТС
Но, как известно, дьявол скрывается в мелочах. О них и поговорим…
В описании технологии WebRTC встречаются две поразительно разные тематики — романтические истории успеха «включил и завелось» и дикий низкоуровневый хардкор из смести терминов stun, turn, ice, sdp… Т.е. либо cкопипасть и заработает, но непонятно как, либо полгода изучай исходники и RFC :-)
Одним из хардкорных терминов, вгоняющих в уныние, является «signaling». На самом деле он выполняет три простые задачи:
1) Состыковать конфигурации двух браузеров (аудио/видео потоки, кодеки, адреса и порты — в формате SDP)
SDP. Между браузерами передается вот этот кошмар, в детали которого можно не вникать. Но осадочек, даже после чтения RFC — остается
2) Обмен паролями для установки зашифрованного соединения между браузерами
3) Инициация действий — позвонить тому-то (соединить поток клиента А с потоком клиента Б на callbacks в js), положить трубку и т.п. Т.е. на js в браузере вы совершаете очень простые вещи с объектом RTCPeerConnection — но внутри объекта настоящий АДЪ.
Т.е. через signaling, который вы пишите на чем угодно и как угодно — браузеры состыковываются друг с другом и можно… совершать видеозвонки. Причем, что удивительно, можно не понимать что лежит по стеку протоколов — звонки заведутся на удивление просто.
Signaling визуально выглядит устрашающим — на самом деле просто «гоняются» SDP-описания медиапотоков в браузере через ICE… Эх, хотел написать просто — не получается
Звонить получается просто в локальной сети, но когда сотрудники в разных сетях… да еще за файерволами — браузеры не смогут установить соединение без посторонней помощи.
Технологически тут еще больший хардкор, чем в разделе выше, предупреждаю сразу, но если рассказать на пальцах получается что-то типа:
1) Для «пробивки» файерволов компании сотрудники должны обратиться по протоколам STUN/TURN к некому центральному серверу. Этот сервер либо поднимают ваши сисадмины, либо используете свободный, но с ограниченными возможностями (нет поддержки relay-режима TURN) STUN-сервер от Google.
2) Если «пробить» файерволы не удалось, остается единственная возможность — лить медиапотоки через сторонний сервер, а не peer-to-peer между браузерами. Этот режим работы TURN-сервера называется «relay». Вам такой сервер придется понимать самостоятельно — есть открытые решения, но настраивать их вам придется самостоятельно под WebRTC. Однако, по статистике — грубо всего около 10% видеозвонков идут в режиме «relay».
Еще раз кратко — чтобы видеозвонки надежно ходили внутри вашей компании, поднимайте или используйте «чужой» STUN/TURN сервер.
Примерно так ходят медиапотоки между браузерами пользователей — либо напрямую, либо через relay-сервер. Да, это ужасно и неэстетично — но лучшего способы «пробивать» файерволы пока не придумали. По данному принципу работает также skype.
Без понимания, что ICE — это не лед, а технология выбора оптимального маршрута обмена видеопотоками, закрепленная в RFC — нельзя идти дальше. Уровень осадка от излишней, некрасивой и нелогичной сложности стека протоколов STUN/TURN/ICE — возрос до критического уровня.
WebRTC — не поддерживает напрямую видеоконференции. Есть видео/аудио потоки и браузеры и комбинируй. В Skype — это платная услуга. В Google+ Hangouts (который кстати не использует WebRTC, а работает в своем плагине к Chrome и со специфическими кодеками!) — ограничение в 10-15 человек.
Поняли в чем сложность? Все видеопотоки нужно собирать где-то, превращать в один, персональный, видеопоток для конкретного участника и возвращать ему. Т.е. если у нас 10 человек, я беру кадры участников из каждого персонального видеопотока, накладываю их на кадр ведущего где нибудь внизу и сформированный кадр отдаю конкретному участнику и так для каждого. И собирать кадры нужно с поддержкой кодеков WebRTC совместимых браузеров. Представляете объем вычислений. Имеются открытые реализации подобного «MCU-сервера»:
1) licode — имхо сыроватая и там не честный MCU, а просто мультиплексирование потоков.
2) MCU video milticonference server — но он что-то сразу не завелся после перекопиляции с исходниками Chrome и последнего Asterisk, поддерживающего WebRTC через WebSockets. И как-то страшно — java на java и jav-ой погоняет :-)
Выглядит устрашающе, согласен.
Конечно, существуют коммерческие продукты и целая индустрия для организации видеоконференций — но в этой статье мы сосредоточены только на WebRTC.
В WebRTC можно поступить проще — в видеоконференции каждый браузер держит видеопоток каждого участника. Это вы должны запрограммировать внутри браузера на js самостоятельно и связать с signaling. Да, трафик тут увеличивается, но для звонков внутри компании на несколько человек — данное решение подкупает своей простотой и эффективностью.
Видеозвонки работают стабильно между Chrome — Chrome. Остальные сочетания: Chrome, Firefox, Opera — или не работают, или формально работают, а фактически нет. Но все-таки обещают с нового года надежную работу видеозвонков Chrome-Firefox.
Если посмотреть на это философски, далеко не все компании привязаны к конкретной версии браузеров — и можно посадить общающихся коллег в Chrome, возможно только на время звонка и скоро Новый Год — ну вы поняли…
А ведь правда, почему бы не позвонить из браузера на городской/мобильный телефон и наоборот? Это — возможно, но… Но тут без погружения в технологии передачи звука и видео уже не обойтись. Первый «шок» — это протокол SIP. IP телефония и SIP — ну просто неразлучные технологии, но упоминания о SIP в стандарте WebRTC — нет :-) Кого бить и чем?
А все просто — рассуждая на пальцах SIP — это разновидность мощного и гибкого signaling (см. выше). Но если вы напишите signaling сами — зачем вам тогдазведолет межгалактического уровня с фотонными ракетами SIP?
Нестыковочка стала порождать монстров типа создания js-библиотек (на языке ассемблера), которые понимают и SIP и могут состыковать браузеры по WebRTC. И asterisk стал поддерживать websockets для интеграции с браузерами, желающими пообщаться по WebRTC… Но очевидная невпиКуемость технологий одна в другую и сложность технологического стека ставит использование SIP в собственных WebRTC звонках внутри компании под вопрос...(полетели помидоры, я понимаю, но согласитесь — js+sip в данном случае перебор, хотя может быть).
SIP — это то, что в WebRTC делает signaling, но более серьезно, сложно и распределенно.
Альтернативный способ решения вышеуказанной проблемы — использовать услуги специализирующейся на таких звонках компании. Вы не погружаетесь в детали и просто используете специальную js-библиотеку и… можете позвонить на любой городской и мобильный номер через специальный веб-сервис компании.
Таким образом, задача позвонить из браузера на телефонный номер — тоже решается.
Давайте теперь подытожим факты и взвесим возможности и риски. Можно самостоятельно и в разумные сроки развернуть защищенные видеозвонки в компании. Технологии открыты, описаны, в дебри можно не лезть — т.к. я попытался описать все риски объективно и дать технологическую выжимку хардкора выше.
Для запуска видеозвонков по WebRTC внутри компании, получается, нужно:
Технологически задачи — решаемые. Но если у вас нет времени всем этим заниматься, можно использовать, например наш продукт или облачный сервис (бесплатная регистрация и 100 руб. на счету на любые звонки куда угодно — можно потестить технологию и понять, нужна она вам или нет), поддерживающий все вышеперечисленные технологии видеозвонков из коробки и использующий наш кластер видео-серверов с поддержкой STUN/TURN протоколов.
Вы выбрали вариант реализации и начали использовать видеозвонки из браузера внутри компании. Есть один момент, который как-то то ли умалчивается, то ли о нем не знают — возможны редкие случаи, когда дозвониться невозможно. Это происходит из-за того, что браузеры не смогли найти друг друга напрямую (установить peer-to-peer по ICE) и пытаются использовать последнюю возможность — установить соединение через внешний relay-сервер но… системные администраторы заблокировали исходящий UDP-трафик в подсети сотрудника. Но TURN поддерживает relay-режим ТОЛЬКО по UDP (подробности в RFC). Достаточно его разрешить — и видеозвонки снова заработают.
Еще частый вопрос — трафик и размер видео. В режиме relay на TURN-сервере одно соединение пожирает сотни килобайт в секунду — трафик напрямую зависит от размера видео в браузере. Т.е. если у вас ожидаются плотные видеоконференции в relay-режиме — подумайте об этом заранее.
Вот наверно и все, что хотелось рассказать интересного и полезного. Всем желаю удачи в скоро наступающем Новом Году, работающих проектов и довольных сотрудников!
Вроде есть Google+ Hangouts и им нередко пользуются — но это все таки не WebRTC и проприетарная облачная технология. Кто знает — не просматривают ли наше совещание по бизнес-планированию коллеги из другой компании
В общем, согласитесь, тема своих, приватных надежных видеопереговоров внутри компании — актуальна как никогда. Многим это нужно, но как организовать-то? У нас — получилось. Это можно сделать достаточно просто, если знать как :-) (изучив десяток RFC, стандартов w3c и их реализаций и докопавшись до причин).
Ниже я постараюсь провести по основным технологическим рискам реализации, на которые пришлось наступить нам и придется наступить скорее всего и вам — а на закуску: краткая технологическая выжимка и бизнесовый TODO, без взрывающих мозг ненужных деталей.
Технология
Одна из прорывных технологий HTML5 — это, несомненно, WebRTC, развиваемая w3c при поддержке Google, Mozilla и Opera.
Суть ее в том, что имея камеру, микрофон и браузер на компьютере, я могу совершить видеозвонок другому человеку с браузером, камерой и микрофоном, находящемся где угодно — как коллеге за соседним столом, так и боссу, загорающему на пляже с ноутбуком в окружении прекрасных женских тел. При этом соединение будет зашифрованным, раз, и только между вами — peer-to-peer — два. Круто же? Но это еще не все.
Действо
Не вникайте в эту схему, иначе может взорваться мозг. Внутрь браузера засунули десятилетиями развиваемые медиа-технологии и протоколы: телестудию, радиостанцию и телефонную АТС
Но, как известно, дьявол скрывается в мелочах. О них и поговорим…
Signaling
В описании технологии WebRTC встречаются две поразительно разные тематики — романтические истории успеха «включил и завелось» и дикий низкоуровневый хардкор из смести терминов stun, turn, ice, sdp… Т.е. либо cкопипасть и заработает, но непонятно как, либо полгода изучай исходники и RFC :-)
Одним из хардкорных терминов, вгоняющих в уныние, является «signaling». На самом деле он выполняет три простые задачи:
1) Состыковать конфигурации двух браузеров (аудио/видео потоки, кодеки, адреса и порты — в формате SDP)
SDP. Между браузерами передается вот этот кошмар, в детали которого можно не вникать. Но осадочек, даже после чтения RFC — остается
2) Обмен паролями для установки зашифрованного соединения между браузерами
3) Инициация действий — позвонить тому-то (соединить поток клиента А с потоком клиента Б на callbacks в js), положить трубку и т.п. Т.е. на js в браузере вы совершаете очень простые вещи с объектом RTCPeerConnection — но внутри объекта настоящий АДЪ.
Т.е. через signaling, который вы пишите на чем угодно и как угодно — браузеры состыковываются друг с другом и можно… совершать видеозвонки. Причем, что удивительно, можно не понимать что лежит по стеку протоколов — звонки заведутся на удивление просто.
Signaling визуально выглядит устрашающим — на самом деле просто «гоняются» SDP-описания медиапотоков в браузере через ICE… Эх, хотел написать просто — не получается
Браузеры ищут друг друга
Звонить получается просто в локальной сети, но когда сотрудники в разных сетях… да еще за файерволами — браузеры не смогут установить соединение без посторонней помощи.
Технологически тут еще больший хардкор, чем в разделе выше, предупреждаю сразу, но если рассказать на пальцах получается что-то типа:
1) Для «пробивки» файерволов компании сотрудники должны обратиться по протоколам STUN/TURN к некому центральному серверу. Этот сервер либо поднимают ваши сисадмины, либо используете свободный, но с ограниченными возможностями (нет поддержки relay-режима TURN) STUN-сервер от Google.
2) Если «пробить» файерволы не удалось, остается единственная возможность — лить медиапотоки через сторонний сервер, а не peer-to-peer между браузерами. Этот режим работы TURN-сервера называется «relay». Вам такой сервер придется понимать самостоятельно — есть открытые решения, но настраивать их вам придется самостоятельно под WebRTC. Однако, по статистике — грубо всего около 10% видеозвонков идут в режиме «relay».
Еще раз кратко — чтобы видеозвонки надежно ходили внутри вашей компании, поднимайте или используйте «чужой» STUN/TURN сервер.
Примерно так ходят медиапотоки между браузерами пользователей — либо напрямую, либо через relay-сервер. Да, это ужасно и неэстетично — но лучшего способы «пробивать» файерволы пока не придумали. По данному принципу работает также skype.
Без понимания, что ICE — это не лед, а технология выбора оптимального маршрута обмена видеопотоками, закрепленная в RFC — нельзя идти дальше. Уровень осадка от излишней, некрасивой и нелогичной сложности стека протоколов STUN/TURN/ICE — возрос до критического уровня.
Видеоконференции
WebRTC — не поддерживает напрямую видеоконференции. Есть видео/аудио потоки и браузеры и комбинируй. В Skype — это платная услуга. В Google+ Hangouts (который кстати не использует WebRTC, а работает в своем плагине к Chrome и со специфическими кодеками!) — ограничение в 10-15 человек.
Поняли в чем сложность? Все видеопотоки нужно собирать где-то, превращать в один, персональный, видеопоток для конкретного участника и возвращать ему. Т.е. если у нас 10 человек, я беру кадры участников из каждого персонального видеопотока, накладываю их на кадр ведущего где нибудь внизу и сформированный кадр отдаю конкретному участнику и так для каждого. И собирать кадры нужно с поддержкой кодеков WebRTC совместимых браузеров. Представляете объем вычислений. Имеются открытые реализации подобного «MCU-сервера»:
1) licode — имхо сыроватая и там не честный MCU, а просто мультиплексирование потоков.
2) MCU video milticonference server — но он что-то сразу не завелся после перекопиляции с исходниками Chrome и последнего Asterisk, поддерживающего WebRTC через WebSockets. И как-то страшно — java на java и jav-ой погоняет :-)
Выглядит устрашающе, согласен.
Конечно, существуют коммерческие продукты и целая индустрия для организации видеоконференций — но в этой статье мы сосредоточены только на WebRTC.
В WebRTC можно поступить проще — в видеоконференции каждый браузер держит видеопоток каждого участника. Это вы должны запрограммировать внутри браузера на js самостоятельно и связать с signaling. Да, трафик тут увеличивается, но для звонков внутри компании на несколько человек — данное решение подкупает своей простотой и эффективностью.
Браузеры бывают разные
Видеозвонки работают стабильно между Chrome — Chrome. Остальные сочетания: Chrome, Firefox, Opera — или не работают, или формально работают, а фактически нет. Но все-таки обещают с нового года надежную работу видеозвонков Chrome-Firefox.
Если посмотреть на это философски, далеко не все компании привязаны к конкретной версии браузеров — и можно посадить общающихся коллег в Chrome, возможно только на время звонка и скоро Новый Год — ну вы поняли…
WebRTC и телефония
А ведь правда, почему бы не позвонить из браузера на городской/мобильный телефон и наоборот? Это — возможно, но… Но тут без погружения в технологии передачи звука и видео уже не обойтись. Первый «шок» — это протокол SIP. IP телефония и SIP — ну просто неразлучные технологии, но упоминания о SIP в стандарте WebRTC — нет :-) Кого бить и чем?
А все просто — рассуждая на пальцах SIP — это разновидность мощного и гибкого signaling (см. выше). Но если вы напишите signaling сами — зачем вам тогда
Нестыковочка стала порождать монстров типа создания js-библиотек (
SIP — это то, что в WebRTC делает signaling, но более серьезно, сложно и распределенно.
Альтернативный способ решения вышеуказанной проблемы — использовать услуги специализирующейся на таких звонках компании. Вы не погружаетесь в детали и просто используете специальную js-библиотеку и… можете позвонить на любой городской и мобильный номер через специальный веб-сервис компании.
Таким образом, задача позвонить из браузера на телефонный номер — тоже решается.
Подытожим
Давайте теперь подытожим факты и взвесим возможности и риски. Можно самостоятельно и в разумные сроки развернуть защищенные видеозвонки в компании. Технологии открыты, описаны, в дебри можно не лезть — т.к. я попытался описать все риски объективно и дать технологическую выжимку хардкора выше.
Для запуска видеозвонков по WebRTC внутри компании, получается, нужно:
- написать signaling учитывающий специфику бизнес-процессов в компании, имеющий доступ к спискам сотрудников в AD и т.п.
- поднять 1-2 STUN/TURN сервера вне локальной сети компании для состыковки видеозвонков из разных офисов компании и с мобильных устройств. В некоторых случаях через эти сервера пойдет, правда зашифрованный, видеотрафик
- попробовать интегрироваться с очень пока сырыми либо довольно сложными продуктами для организации видеоконфенций на несколько человек, либо написать свою WebRTC реализацию видеоконференций
- интегрироваться со «шлюзами» для возможности совершения звонков на обычные телефонные номер из/в компанию
Технологически задачи — решаемые. Но если у вас нет времени всем этим заниматься, можно использовать, например наш продукт или облачный сервис (бесплатная регистрация и 100 руб. на счету на любые звонки куда угодно — можно потестить технологию и понять, нужна она вам или нет), поддерживающий все вышеперечисленные технологии видеозвонков из коробки и использующий наш кластер видео-серверов с поддержкой STUN/TURN протоколов.
Эксплуатация технологии
Вы выбрали вариант реализации и начали использовать видеозвонки из браузера внутри компании. Есть один момент, который как-то то ли умалчивается, то ли о нем не знают — возможны редкие случаи, когда дозвониться невозможно. Это происходит из-за того, что браузеры не смогли найти друг друга напрямую (установить peer-to-peer по ICE) и пытаются использовать последнюю возможность — установить соединение через внешний relay-сервер но… системные администраторы заблокировали исходящий UDP-трафик в подсети сотрудника. Но TURN поддерживает relay-режим ТОЛЬКО по UDP (подробности в RFC). Достаточно его разрешить — и видеозвонки снова заработают.
Еще частый вопрос — трафик и размер видео. В режиме relay на TURN-сервере одно соединение пожирает сотни килобайт в секунду — трафик напрямую зависит от размера видео в браузере. Т.е. если у вас ожидаются плотные видеоконференции в relay-режиме — подумайте об этом заранее.
Вот наверно и все, что хотелось рассказать интересного и полезного. Всем желаю удачи в скоро наступающем Новом Году, работающих проектов и довольных сотрудников!
