Почему WebRTC?

WebRTC — это трендовая технология потокового видео, которая работает в браузере пользователя без установки дополнительного ПО и использует видео кодек VP8, оптимизированный для использования в сети Интернет. Сегодня каждый Android Chrome браузер поддерживает эту технологию и тем самым мы получаем миллионы устройств, готовых к просмотру трансляции без установки какого-либо дополнительного ПО или специальных конфигураций.

Камера для этого обзора была подобрана самая простая из тех, что поддерживали протокол RTSP и кодеки H.264 и G.711 для совместимости с WebRTC Media & Broadcasting Server.

Установка

Первым делом мы установили камеру. Для этого нам не пришлось делать каких-то сложных телодвижений. Подключили питание и соединили с маршрутизатором стандартным патчкордом RJ45(интернет провод) метровой длины, который был в комплекте.
Загорелась зеленая лампочка.

Камера самостоятельно взяла IP адрес по DHCP и в web интерфейсе роутера и мы увидели Dlink 2103 IP 192.168.1.35.

Теперь нам удалось зайти в веб интерфейс с правами администратора. Пароль отсутствует.
http://192.168.1.35

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

Заходим в настройки Setup — Network и отключаем Authentication поставив его в Disabled. Тем самым мы убираем запрос пароля при попытке доступа к камере. RTSP порт, как видно из настроек, 554 — это порт, используемый в RTSP по умолчанию.

live1.sdp и live2.sdp — это профили — предопределенные конфигурации потоков, которые будут определять формат передаваемого видео. Мы используем стандартный профиль live1.sdp, т.к. он удовлетворяет нашим требованиям H.264 + G.711, 25 кадров в секунду. При необходимости можно его подредактировать.

Теперь проведем простой тест нашей камеры и заберем ее видео поток при помощи VLC плеера. Для этого в VLC открываем “Open URL” и вводим RTSP адрес камеры: rtsp://192.168.1.35/live1.sdp

Поток снова отображается и на этот раз в стороннем VLC плеере через RTSP.
Это означает, что камера протестирована и готова к вещанию через сервер.

В локальной сети нет проблем забрать поток, если ваш VLC плеер находится в одной сети с камерой. В глобальной сети могут быть проблемы с NAT и брандмауэрами. Поэтому в случае каких-либо сетевых проблем, обратитесь к администратору сети или в техподдержку Интернет-провайдера.

В нашем случае провайдером выступал Ростелеком. Все заработало сразу, т.к. или IP адрес оказался статическим, или NAT более гуманным.

Внешний IP адрес был определен за пару минут, как 177.41.122.23, с помощью одного обращения к сайту myip.ru.

Теперь осталось сказать роутеру чтобы при обращении на RTSP порт 554 он отправлял входящие запросы на IP камеру по адресу 192.168.1.35. Что и было проделано в настройках маршрутизатора.

Для того, чтобы убедиться в том, что 554 порт действительно отвечает, мы выполнили команду telnet 177.41.122.23 554 и убедились, что кто-то уже отвечает на этом порту. Осталось запустить сервер и подключиться через него к камере.

В качестве сервера использовали виртуальный сервер на Centos 64 bit от digitalocean в дата-центре Европы.

Результатом заказа сервера стал доступ к SSH консоли и мы вошли туда через SSH клиент Putty

Процесс установки медиа сервера подробно описан в документации к WebRTC Media & Broadcasting Server и сводится к выполнению нескольких команд из командной строки Linux. На всякий случай скопировали его сюда под спойлер.

1. Скачали установочный архив сервера:

$wget https://flashphoner.com/download-wcs5-server.tar.gz

2. Развернули:

$tar -xzf download-wcs5-server.tar.gz

3. Установили:

$cd FlashphonerWebCallServer

$./install.sh

В процессе установки ввели IP адрес сервера: XXX.XXX.XXX.XXX

4. Активировали лицензию:

$cd /usr/local/FlashphonerWebCallServer/bin

$./activation.sh

5. Запустили сервер:

$service webcallserver start

6. Проверили логи:

$tail - f /usr/local/FlashphonerWebCallServer/logs/flashphoner_manager.log

7. Убедились, что сервер стартовал и готов к работе:

$ps aux | grep Flashphoner

Тестирование

Процесс установки всего необходимого был закончен и мы приступаем к тестированию.
Напомним, что наш тестовый кейс будет заключаться в подключении к видеопотоку с IP камеры нескольких Web-пользователей через их браузеры.

Открываем страницу http://host:9091 Demo / Streaming Min в Chrome браузере, устанавливаем соединение и вводим rtsp-адрес rtsp://177.41.122.23/live1.sdp

177.41.122.23 — это внешний IP адрес камеры. Маршрутизатор будет перенаправлять RTSP запросы на 192.168.1.35 в соответствии с правилами трансляции сетевых адресов NAT на примере выше. Если у вас динамический IP, он может постоянно меняться, поэтому есть смысл получить бесплатный домен для динамических адресов, например с помощью сервиса no-ip.com. В этом случае адрес вашего потока будет выглядеть например так: rtsp://my-webrtc-rtsp.noip.me и будет постоянным.

Для того, чтобы началось воспроизведение потока, мы передаем как имя потока rtsp://177.41.122.23/live1.sdp — URL потока. WebRTC Media & Broadcasting Server запросит потоки с камеры, обработает их и отдаст браузеру на воспроизведение по WebRTC.

Больше пользователю никаких действий предпринимать не нужно. Подключение второго пользователя пройдет быстрее, т.к. соединение WebRTC сервера с IP камерой уже остановлено. Остается только создать WebRTC сессию и подключиться к уже существующему потоку.

После открытия ссылки в браузере нужно немного подождать. Несколько секунд требуется для того, чтобы установить соединение с сервером по Websockets, создать WebRTC сессию и забрать поток.

Соединение установлено и зритель видит поток на экране, а так же уникальную ссылку, по которой другие Интернет-пользователи смогут увидеть этот же видео поток. Теперь пользователь может отправить ссылку кому-то другому, остановить воспроизведение потока или включить полноэкранный режим, пользуясь контролами в правом нижнем углу.

Стоит отметить достаточно низкую задержку. Пинг до дата-центра составляет около 100 миллисекунд и задержка не различима глазом. Можно предположить, что реальная задержка составляет те же 100 плюс минус столько же миллисекунд на время буферизации.

В итоге нам удалось наладить онлайн трансляцию между IP камерой и web-браузерами. Подключение дополнительных зрителей к потоку по ссылке с идентификатором потока не вызвало каких-либо проблем.

Сервер достаточно прост в установке и настройке и для его запуска не требуется каких-либо серьезных навыков. Разве что необходимы знания Linux на уровне продвинутого пользователя, умеющего выполнять команды из консоли через ssh и пользоваться текстовым редактором.

Качество трансляции оказалось вполне приемлемым и почти не отличается от потока полученного с помощью VLC.
На этом тестирование было успешно завершено.

Мы рекомендуем также ознакомиться с обзором о настройках и тестировании WebRTC & Broadcasting Server для проведения онлайн-трансляций и вебинаров между браузерами.