Материал: Передача потоковых данных на основе WebRTC

          После завершения работы над WebRTC-приложением было написано браузерное расширение. В манифесте расширения было указано, с какими доменами ему будет разрешено работать:

"permissions": ["#"733939.files/image014.gif">

            Рисунок 14 - Редирект

Когда пользователь заходит на страницу сайта, в базу данных сохраняется информация о том, что пользователь находится в режиме онлайн. При закрытии вкладки браузера эта информация будет удалена. Для работы приложения была необходима информация о пользователе: имя, id, фотография. Для получения этой информации отправляется асинхронный запрос на адрес vk.com/id0, с которого автоматически производится редирект на страницу пользователя. При помощи парсинга по селекторам классов из содержимого страницы вытаскивается все необходимое.

            Рисунок 15 - Парсинг полученной страницы

После получения данных на директорию пользователя в базе данных вешается обработчик получения новых сообщений о входящем видеовызове. При вызове создается всплывающее окно с кнопками для принятия и отклонения вызова. Одновременно с этим проверяется адрес текущей страницы. Это необходимо для того, чтобы проверить, находится ли пользователь на личной странице другого пользователя. Если это так, то из содержимого данной страницы будет получена информация об этом пользователе, чтобы проверить, имеет ли этот пользователь установленное расширение. На странице пользователя, который тоже имеет расширение, будет отображена кнопка для совершения видеовызова. При нажатии на нее в базу данных отправляется сообщение о вызове, а на странице загружается iframe с WebRTC-приложением, в который отправляется POST-сообщение.

            Рисунок 16 - Отправка POST-сообщения

Вторым параметром функции postMessage должен быть указан домен, на который разрешено отправлять POST-сообщение, в примере выше же указан символ * для того, чтобы разрешить отправку на  любой домен, так как iframe в данном приложении будет подгружаться со стороннего сервера.

Когда пользователь будет подключен к конференции, это отобразится на его странице Вконтакте. Другим пользователям приложения в этом случае вместо кнопки вызова будет отображена кнопка подключения к конференции. При подключении, как и при принятии, вызова будет загружен iframe и произойдет попытка подключения к сокету методом joinRoom библиотеки RTCPeerBroadcasting.

Помимо уведомления о вызове в виде всплывающего окна необходимо было также добавить звуковое уведомление, которое пользователь смог бы настраивать сам. Это было реализовано средствами Audio API. Оно позволяет воспроизводить звуковые файлы как полученные в виде ссылки на файл в Интернете, так и в виде файла формата MP3. Для реализации возможности установки аудиозаписи в качестве мелодии вызова был задействован парсинг для того, чтобы обнаружить на странице Вконтакте элементы аудиозаписей. Поиск производится по селектору audio. При нахождении элементов аудио в них добавляются кнопки установки мелодии вызова.

            Рисунок 17 - Поиск аудио-элементов

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

          После завершения написания всего программного кода и тестирования был сверстан пользовательский интерфейс всех элементов приложения на HTML. Общий вид элементов завершенного приложения показан на скриншотах (рисунки 18, 19, 20 и 21).

            Рисунок 18 - Кнопка видеовызова

            Рисунок 19 - Входящий вызов

            Рисунок 20 - Iframe с приложением. Конференция с тремя участниками

            Рисунок 21 - Установка аудио в качестве сигнала вызова

          Данная практическая часть этого дипломного проекта была попыткой проверить, возможно ли уже сейчас, даже несмотря на недостаточную стандартизированностьWebRTC, реализовать полноценное переносимое WebRTC-приложение, которое могло бы быть встроено на Интернет-ресурс со  стороны клиента при помощи браузерного расширения. Поставленная задача была успешно выполнена. Так как приложение предполагалось запускать при помощи расширения для браузера GoogleChrome, не было необходимости в реализации кроссбраузерной поддержки, что существенно упростило разработку.

2.2 WebRTC-сервис

          Второй практической реализацией был web-сервис, использование которого возможно в разных браузерах, поддерживающих WebRTC. Исходный код находится в приложении Г данной дипломной работы. Сервис, так же как и первая практическая реализация данной дипломной работы, основывается на библиотеке RTCPeerBroadcasting. Для того, чтобы реализовать возможность использования в различных браузерах, необходимо было переписать функции, взаимодействующие с функциями Web API WebRTC и добавить в них необходимые префиксы. Это касается объекта window.URL, функций getUserMedia, PeerConnection, SessionDescription. Чтобы сделать выбор нужного префикса автоматическим, используется конструкция с условным ИЛИ, перебирающая методы с разными префиксами.[2]

            Рисунок 22 - Перебор префиксов

То же самое сделано для функций PeerConnection и SessionDescription.

          Процесс прикрепления медиа потока к HTML-элементу video также различается в браузерах на движке Webkit и Gecko. Так, в Mozilla поток прикрепляется через свойство mozSrcObject, а в Chome - через свойство src.[9] Чтобы сделать процесс прикрепления потока универсальным, в начало библиотеки добавлена проверка браузера, от которой зависит процесс добавления потока.

            Рисунок 23 - Проверка User-Agent

            Рисунок 24 - Прикрепление потока к видео-элементу

Некоторые сложности при реализации кроссбраузерности вызвало недекларированное различие в реализации метода onaddstreamобъекта RTCPeerConnection в браузерах на движках Webkit и Gecko. В браузере GoogleChrome (Webkit) из объекта stream можно получить набор полей, в том числе id и label, по которым можно однозначно установить связь между клиентом и потоком, который исходит от него. В браузере MozillaFirefox (Gecko) объект stream не содержит таких полей. Об этом не говорится в документации, поэтому это вызвало определенные проблемы на этапе тестирования библиотеки. Данная проблема была решена путем переопределения объекта stream и добавления в него уникального ключа.

            Рисунок 25 - Добавление ключа к потоку

Вышеописанные изменения добавили поддержку основными браузерами, такими как Mozilla, Chrome, Opera.

Второй задачей данной реализации было упростить процесс создания видеоконференций и реализовать дополнительный функционал, такой как, например, блокирование пользователей, выключение камеры и микрофона, сохранение дополнительной информации о пользователе. Для этого был написан класс Conference, выполняющий роль слоя абстракции над библиотекой RTCPeerBroadcasting и упрощающий работу с ней. Исходный код класса Conference находится в приложении В.

Конструктор Conference принимает в качестве параметров два аргумента: адрес базы данных Firebase и имя конференции. На новом объекте Conference вызывается метод startConnection для подключения или создания новой конференции. Этот метод принимает в параметрах имя пользователя и функции обратных вызовов. Имя пользователя проверяется на наличие и корректность методом checkLoginAlreadyInUse.

            Рисунок 26 - Метод checkLoginAlreadyInUse

Если имя может быть использовано, то производится проверка количества пользователей в данной конференции. В зависимости от количества пользователей будет произведено либо подключение к конференции, либо создание новой (если пользователей нет). Для проверки количества проверяется значение в соответствующей директории базы данных.

            Рисунок 27 - Проверка количества пользователей

          Для отключения от конференции реализован метод disconnect, который вызывает метод leaveRoom библиотеки RTCPeerBroadcasting и производит отключение от базы данных с удалением директории пользователя. Этот метод может быть использован как для самостоятельного отключения, так и для автоматического, когда пользователь будет выгнан из конференции.

          Для реализации функции отключения других пользователей добавлен метод kickUser, принимающий в качестве параметра имя пользователя. При вызове этого метода в директорию указанного пользователя записывается значение “kicked”. При подключении к конференции на директорию пользователя вешается событие появления значения “kicked”, при срабатывании которого производится вызов метода disconnect.

          Для реализации функций отключения камеры и микрофона добавлены методы switchAudio и switchVideo, принимающие параметром логическое значение (true или false). Чтобы переключать вещание видео или аудио потоков задействованы методы Stream API, а именно: необходимым исходящим потокам задается свойство enabled.

            Рисунок 28 - Реализация метода switchVideo

          Процесс получения потоков от других пользователей реализован в виде события. После создания объекта Conference необходимо задать обработчик события onUserConnected, при срабатывании которого будет получено имя пользователя, идентификатор потока и HTML-видео. Обработчик события вызывается из функции onRemoteStream объекта RTCPeerBroadcasting как это показано на рисунке 29.

            Рисунок 29 - Событие onRemoteStream

Помимо этого объект Conference имеет еще три события: onUserDisconnected, onKicked и onUserCount.

          Класс Conference, помимо реализации базового функционала, необходимого для создания видеоконференций, имеет функцию слоя абстракции над RTCPeerBroadcasting, упрощающего работу с ним, автоматизируя процессы работы с сигнальным сокетом, чтения и записи служебных данных, проверки корректности данных, проверки наличия сокетов. Так, для того, чтобы создать подключение, даже если пользователи находятся на разных web-страницах или приложениях, достаточно импортировать три библиотеки (Firebase, RTCPeerBroadcasting и Conference) и вызвать три метода класса Conference (рисунок 30).

            Рисунок 30 - Вызов трех основных методов для создания подключения

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

          После того как была закончена разработка класса Conference, был сверстан интерфейс для WebRTC-сервиса, который был связан с методами класса Conference. Помимо страницы конференции, была добавлена стартовая страница, чат, возможность добавления тегов для присвоения конференции статуса публичной и страница со списком публичных конференций. В конечном итоге, сервис имел вид, показанный на рисунках 31 и 32.

            Рисунок 31 - Интерфейс приложения с запущенной конференцией с тремя пользователями

            Рисунок 32 - Список публичных конференций

ЗАКЛЮЧЕНИЕ

          В рамках данной дипломной работы была изучена технология WebRTC и возможности ее применения.

Ключевым фактором успеха развития Интернета в целом было то, что технологии, используемые в нем были изначально открытыми и свободными для реализации. WebRTC стал первым набором технологий, имеющим такую же открытость и дающим при этом возможности высококачественной полнодуплексной потоковой передачи данных. Основная идея проекта WebRTC была в том, чтобы сделать технологии подключений реального времени открытыми и простыми для использования. До появления WebRTC технологии, дающие аналогичные возможности, были закрытыми и требовали от разработчика наличия лицензии.

В целях изучения возможностей применения WebRTC было изучено Web API, архитектура которого была описана в разделе 1. На основе полученных знаний об API было создано два web-приложения. Ход проделанной работы и основные нюансы разработки были описаны в разделе 2 данной дипломной работы.

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

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. BasicsofWebRTCpeerconnection. [Электронный ресурс]. Режим доступа: https://medium.com/programming-ideas-tutorial-and-experience/basics-of-webrtc-peer-connections-c1ed743de2f6 [Дата обращения: 20.04.2014 г.].

2. Daniel Davis. Cross-browser camera capture with getUserMedia. [Электронный ресурс]. Режим доступа: https://hacks.mozilla.org/2013/02/cross-browser-camera-capture-with-getusermediawebrtc/ [Дата обращения: 10.02.2014 г.].

3. Eric Rescorla. WebRTC security architecture. [Электронный ресурс]. Режим доступа: #"_GoBack"> Режим доступа: http://w3c.org.ru/ [Дата обращения: 21.05.2014 г.].