Видеозвонки через браузер — как заставить технологию работать на свою компанию

Ну очень интересно было разобраться, как совершать видеозвонки через браузер внутри компании и насколько это полезно. Тем более, что skype — «прослушивается» и пересылаемые пароли парсятся роботами…

Вроде есть Google+ Hangouts и им нередко пользуются — но это все таки не WebRTC и проприетарная облачная технология. Кто знает — не просматривают ли наше совещание по бизнес-планированию коллеги из другой компании-конкурента с блокнотами и неподдельными улыбками на сияющих лицах?

В общем, согласитесь, тема своих, приватных надежных видеопереговоров внутри компании — актуальна как никогда. Многим это нужно, но как организовать-то? У нас — получилось. Это можно сделать достаточно просто, если знать как :-) (изучив десяток RFC, стандартов w3c и их реализаций и докопавшись до причин).

Ниже я постараюсь провести по основным технологическим рискам реализации, на которые пришлось наступить нам и придется наступить скорее всего и вам — а на закуску: краткая технологическая выжимка и бизнесовый TODO, без взрывающих мозг ненужных деталей.

Технология

Одна из прорывных технологий HTML5 — это, несомненно, WebRTC, развиваемая w3c при поддержке Google, Mozilla и Opera.

Суть ее в том, что имея камеру, микрофон и браузер на компьютере, я могу совершить видеозвонок другому человеку с браузером, камерой и микрофоном, находящемся где угодно — как коллеге за соседним столом, так и боссу, загорающему на пляже с ноутбуком в окружении прекрасных женских тел. При этом соединение будет зашифрованным, раз, и только между вами — peer-to-peer — два. Круто же? Но это еще не все.

Действо происходит с использованием сильной черной магии происходит практически прозрачно, «внутри» браузера — вы и ваши программисты не забивают себе голову кодеками, файерволами, согласованиями, sip и т.п. — в самом простейшем случае задача видеозвонков с первого взгляда решается десятком строк js-кода и вот оно, счастье — приватные видеопереговоры у вас в компании работают.

Не вникайте в эту схему, иначе может взорваться мозг. Внутрь браузера засунули десятилетиями развиваемые медиа-технологии и протоколы: телестудию, радиостанцию и телефонную АТС

Но, как известно, дьявол скрывается в мелочах. О них и поговорим…

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 сами — зачем вам тогда зведолет межгалактического уровня с фотонными ракетами SIP?

Нестыковочка стала порождать монстров типа создания js-библиотек (на языке ассемблера), которые понимают и SIP и могут состыковать браузеры по WebRTC. И asterisk стал поддерживать websockets для интеграции с браузерами, желающими пообщаться по WebRTC… Но очевидная невпиКуемость технологий одна в другую и сложность технологического стека ставит использование SIP в собственных WebRTC звонках внутри компании под вопрос...(полетели помидоры, я понимаю, но согласитесь — js+sip в данном случае перебор, хотя может быть).

SIP — это то, что в WebRTC делает signaling, но более серьезно, сложно и распределенно.

Альтернативный способ решения вышеуказанной проблемы — использовать услуги специализирующейся на таких звонках компании. Вы не погружаетесь в детали и просто используете специальную js-библиотеку и… можете позвонить на любой городской и мобильный номер через специальный веб-сервис компании.

Таким образом, задача позвонить из браузера на телефонный номер — тоже решается.

Подытожим

Давайте теперь подытожим факты и взвесим возможности и риски. Можно самостоятельно и в разумные сроки развернуть защищенные видеозвонки в компании. Технологии открыты, описаны, в дебри можно не лезть — т.к. я попытался описать все риски объективно и дать технологическую выжимку хардкора выше.

Для запуска видеозвонков по WebRTC внутри компании, получается, нужно:

1. написать signaling учитывающий специфику бизнес-процессов в компании, имеющий доступ к спискам сотрудников в AD и т.п.
2. поднять 1-2 STUN/TURN сервера вне локальной сети компании для состыковки видеозвонков из разных офисов компании и с мобильных устройств. В некоторых случаях через эти сервера пойдет, правда зашифрованный, видеотрафик
3. попробовать интегрироваться с очень пока сырыми либо довольно сложными продуктами для организации видеоконфенций на несколько человек, либо написать свою WebRTC реализацию видеоконференций
4. интегрироваться со «шлюзами» для возможности совершения звонков на обычные телефонные номер из/в компанию

Технологически задачи — решаемые. Но если у вас нет времени всем этим заниматься, можно использовать, например наш продукт или облачный сервис (бесплатная регистрация и 100 руб. на счету на любые звонки куда угодно — можно потестить технологию и понять, нужна она вам или нет), поддерживающий все вышеперечисленные технологии видеозвонков из коробки и использующий наш кластер видео-серверов с поддержкой STUN/TURN протоколов.

Эксплуатация технологии

Вы выбрали вариант реализации и начали использовать видеозвонки из браузера внутри компании. Есть один момент, который как-то то ли умалчивается, то ли о нем не знают — возможны редкие случаи, когда дозвониться невозможно. Это происходит из-за того, что браузеры не смогли найти друг друга напрямую (установить peer-to-peer по ICE) и пытаются использовать последнюю возможность — установить соединение через внешний relay-сервер но… системные администраторы заблокировали исходящий UDP-трафик в подсети сотрудника. Но TURN поддерживает relay-режим ТОЛЬКО по UDP (подробности в RFC). Достаточно его разрешить — и видеозвонки снова заработают.

Еще частый вопрос — трафик и размер видео. В режиме relay на TURN-сервере одно соединение пожирает сотни килобайт в секунду — трафик напрямую зависит от размера видео в браузере. Т.е. если у вас ожидаются плотные видеоконференции в relay-режиме — подумайте об этом заранее.

Вот наверно и все, что хотелось рассказать интересного и полезного. Всем желаю удачи в скоро наступающем Новом Году, работающих проектов и довольных сотрудников!

Автор: AlexSerbul

Источник