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

WebRTC

Введение

WebRTC – технология, ориентированная на браузеры, которая позволяет соединить два клиента для видео-передачи данных. Основные особенности – внутренняя поддержка браузерами (не нужны сторонние внедряемые технологии типа adobe flash ) и способность соединять клиентов без использования дополнительных серверов – соединение peer-to-peer (далее, p2p ).

Установить соединение p2p – довольно трудная задача, так как компьютеры не всегда обладают публичными IP адресами, то есть адресами в интернете. Из-за небольшого количества IPv4 адресов (и для целей безопасности) был разработан механизм NAT , который позволяет создавать приватные сети, например, для домашнего использования. Многие домашние роутеры сейчас поддерживают NAT и благодаря этому все домашние устройства имеют выход в интернет, хотя провайдеры интернета обычно предоставляют один IP адрес. Публичные IP адреса - уникальны в интернете, а приватные нет. Поэтому соединиться p2p - трудно.

Для того, чтобы понять это лучше, рассмотрим три ситуации: оба узла находятся в одной сети (Рисунок 1) , оба узла находятся в разных сетях (один в приватной, другой в публичной) (Рисунок 2) и оба узла находятся в разных приватных сетях с одинаковыми IP адресами (Рисунок 3) .

Рисунок 1: Оба узла в одной сети

Рисунок 2: Узлы в разных сетях (один в приватной, другой в публичной)

Рисунок 3: Узлы в разных приватных сетях, но с численно равными адресами

На рисунках выше первая буква в дву-символьных обозначениях означает тип узла (p = peer , r = router ). На первом рисунке ситуация благоприятная: узлы в своей сети вполне идентифицируются сетевыми IP адресами и поэтому могут подключаться к друг другу напрямую. На втором рисунке имеем две разные сети, у которых похожие нумерации узлов. Здесь появляются маршрутизаторы (роутеры), у которых есть два сетевых интерфейса – внутри своей сети и вне своей сети. Поэтому у них два IP адреса. Обычные узлы имеют только один интерфейс, через который они могут общаться только в своей сети. Если они передают данные кому-то вне своей сети, то только с помощью NAT внутри маршрутизатора (роутера) и поэтому видимы для других под IP адресом роутера – это их внешний IP адрес. Таким образом, у узла p1 есть внутренний IP = 192.168.0.200 и внешний IP = 10.50.200.5 , причем последний адрес будет внешним также и для всех других узлов в его сети . Похожая ситуация и для узла p2 . Поэтому их связь невозможна, если использовать только их внутренние (свои) IP адреса. Можно воспользоваться внешними адресами, то есть адресами роутеров, но, так как у всех узлов в одной приватной сети один и тот же внешний адрес, то это довольно затруднительно. Это проблема решается с помощью механизма NAT

Что же будет, если мы все-таки решим соединить узлы через их внутренние адреса? Данные не выйдут за пределы сети. Для усиления эффекта можно представить ситуацию, изображенную на последнем рисунке – у обоих узлов совпадают внутренние адреса. Если они будут использовать их для коммуникации, то каждый узел будет общаться с самим собой.

WebRTC успешно справляется с такими проблемами, используя протокол ICE , который, правда, требует использования дополнительных серверов (STUN , TURN ). Обо всем этом ниже.

Две фазы WebRTC

Чтобы соединить два узла через протокол WebRTC (или просто RTC , если связываются два iPhone ‘a) необходимо провести некие предварительные действия для установления соединения. Это первая фаза – установка соединения. Вторая фаза – передача видео-данных.

Сразу стоит сказать, что, хоть технология WebRTC в своей работе использует множество различных способов коммуникации (TCP и UDP ) и имеет гибкое переключение между ними, эта технология не имеет протокола для передачи данных о соединении . Не удивительно, ведь подключить два узла p2p не так-то просто. Поэтому необходимо иметь некоторый дополнительный способ передачи данных, никак не связанный с WebRTC . Это может быть сокетная передача, протокол HTTP , это может быть даже протокол SMTP или Почта России . Этот механизм передачи начальных данных называется сигнальным . Передавать нужно не так много информации. Все данные передаются в виде текста и делятся на два типа – SDP и Ice Candidate . Первый тип используется для установления логического соединения, а второй для физического . Подробно обо всем этом позже, а пока лишь важно помнить, что WebRTC даст нам некую информацию, которую нужно будет передать другому узлу. Как только мы передадим всю нужную информацию, узлы смогут соединиться и больше наша помощь нужна не будет. Таким образом, сигнальный механизм, который мы должны реализовать отдельно , будет использоваться только при подключении , а при передаче видео-данных использоваться не будет.

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

• Инициатор (звонящий – caller ):
  1. Предложение начать видео-передачу данных (createOffer)
  2. Получение своего SDP SDP )
  3. Получение своих Ice candidate Ice candidate )
• Ожидающий звонка (callee ):
  1. Получение локального (своего) медиа потока и установка его для передачи (getUserMediaStream)
  2. Получение предложения начать видео-передачу данных и создание ответа (createAnswer)
  3. Получение своего SDP объекта и передача его через сигнальный механизм (SDP )
  4. Получение своих Ice candidate объектов и передача их через сигнальный механизм (Ice candidate )
  5. Получение удаленного (чужого) медиа потока и отображение его на экране (onAddStream)

Отличие лишь во втором пункте.

Несмотря на кажущуюся запутанность шагов здесь их на самом деле три: отправка своего медиа потока (п.1), установка параметров соединения (пп.2-4), получение чужого медиа потока (п.5). Самый сложный – второй шаг, потому что он состоит из двух частей: установление физического и логического соединения. Первая указывает путь , по которому должны идти пакеты, чтобы дойти от одного узла сети до другого. Вторая указывает параметры видео/аудио – какое использовать качество, какие использовать кодеки.

Мысленно этап createOffer или createAnswer следует соединить с этапами передачи SDP и Ice candidate объектов.

Основные сущности

Медиа потоки (MediaStream)

Основной сущностью является медиа поток, то есть поток видео и аудио данных, картинка и звук. Медиа потоки бывают двух типов – локальные и удаленные. Локальный получает данные от устройств входа (камера, микрофон), а удаленный по сети. Таким образом у каждого узла есть и локальный, и удаленный поток. В WebRTC для потоков существует интерфейс MediaStream и также существует подинтерфейс LocalMediaStream специально для локального потока. В JavaScript можно столкнуться только с первым, а если использовать libjingle , то можно столкнуться и со вторым.

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

Рассмотрим все по порядку. Для этого будем держать в уме некоторый пример. Допустим, что мы хотим передавать не только видео себя, но и видео нашего стола, на котором лежит листок бумаги, на котором мы собираемся что-то писать. Нам понадобится два видео (мы + стол) и одно аудио (мы). Ясно, что мы и стол стоит разделить на разные потоки, потому что эти данные, наверное, слабо зависят друг от друга. Поэтому у нас будет два MediaStream ‘a – один для нас и один для стола. Первый будет содержать и видео, и аудио данные, а второй – только видео (Рисунок 4).

Рисунок 4: Два различных медиа потока. Один для нас, один для нашего стола

Сразу ясно, что медиа поток как минимум должен включать в себя возможность содержать данные разных типов - видео и аудио. Это учтено в технологии и поэтому каждый тип данных реализуется через медиа дорожку MediaTrack . У медиа дорожки есть специальное свойство kind , которое и определяет, что перед нами – видео или аудио (Рисунок 5)

Рисунок 5: Медиа потоки состоят из медиа дорожек

Как будет всё происходить в программе? Мы создадим два медиа потока. Потом создадим две видео дорожки и одну аудио дорожку. Получим доступ к камерам и микрофону. Укажем каждой дорожке какое устройство использовать. Добавим видео и аудио дорожку в первый медиа поток и видео дорожку от другой камеры во второй медиа поток.

Но как мы различим медиа потоки на другом конце соединения? Для этого каждый медиа поток имеет свойство label – метка потока, его название (Рисунок 6). Такое же свойство имеют и медиа дорожки. Хотя на первый взгляд кажется, что видео от звука можно отличить и другими способами.

Рисунок 6: Медиа потоки и дорожки идентифицируются метками

Так, а если медиа дорожки можно идентифицировать через метку, то зачем нам для нашего примера использовать два медиа потока, вместо одного? Ведь можно передавать один медиа поток, а дорожки использовать в нем разные. Мы дошли до важного свойства медиа потоков – они синхронизируют медиа дорожки. Разные медиа потоки не синхронизируются между собой, но внутри каждого медиа потока все дорожки воспроизводятся одновременно .

Таким образом, если мы хотим, чтобы наши слова, наши эмоции на лице и наш листочек бумаги воспроизводились одновременно, то стоит использовать один медиа поток. Если это не столь важно, то выгодней использовать разные потоки – картинка будет более гладкой .

Если какую-то дорожку необходимо отключать во время передачи, то можно воспользоваться свойством enabled медиа дорожки.

В конце стоит подумать о стерео звуке. Как известно стерео звук – это два разных звука. И передавать их надо тоже отдельно. Для этого используются каналы MediaChannel . Медиа дорожка звука может иметь много каналов (например, 6, если нужен звук 5+1). Внутри медиа дорожки каналы, разумеется тоже синхронизированы . Для видео обычно используется только один канал, но могут использоваться и несколько, например, для наложения рекламы.

Резюмируя: мы используем медиа поток для передачи видео и аудио данных. Внутри каждого медиа потока данные синхронизированы. Мы можем использовать несколько медиа потоков, если синхронизация нам не нужна. Внутри каждого медиа потока есть медиа дорожки двух видов – для видео и для аудио. Дорожек обычно не больше двух, но может быть и больше, если нужно передавать несколько разных видео (собеседника и его стола). Каждая дорожка может состоять из нескольких каналов, что используется обычно только для стерео звука.

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

Дескриптор сессии (SDP)

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

Для этого используется любой сигнальный механизм. SDP можно передать хоть через сокеты, хоть человеком (сообщить его другому узлу по телефону), хоть Почтой России. Всё очень просто – Вам дадут уже готовый SDP и его нужно переслать. А при получении на другой стороне – передать в ведомство WebRTC . Дескриптор сессии хранится в виде текста и его можно изменить в своих приложениях, но, как правило, это не нужно. Как пример, при соединении десктоп↔телефон иногда требуется принудительно выбирать нужный аудио кодек.

Обычно при установке соединения необходимо указывать какой-то адрес, например URL . Здесь в этом нет необходимости, так как через сигнальный механизм Вы сами отправите данные по назначению. Чтобы указать WebRTC , что мы хотим установить p2p соединение нужно вызвать функцию createOffer . После вызова этой функции и указания ей специального callback ‘a будет создан SDP объект и передан в этот же callback . Все, что от Вас требуется – передать этот объект по сети другому узлу (собеседнику). После этого на другом конце через сигнальный механизм придут данные, а именно этот SDP объект. Этот дескриптор сессии для этого узла чужой и поэтому несет полезную информацию. Получение этого объекта – сигнал к началу соединения. Поэтому Вы должны согласиться на это и вызвать функцию createAnswer . Она – полный аналог createOffer . Снова в Ваш callback передадут локальный дескриптор сессии и его нужно будет передать по сигнальному механизму обратно.

Стоит отметить, что вызывать функцию createAnswer можно только после получения чужого SDP объекта. Почему? Потому что локальный SDP объект, который будет генерироваться при вызове createAnswer , должен опираться на удаленный SDP объект. Только в таком случае возможно скоординировать свои настройки видео с настройками собеседника. Также не стоит вызывать createAnswer и createOffer до получения локального медиа потока – им будет нечего писать в SDP объект .

Так как в WebRTC есть возможность редактирования SDP объекта, то после получения локального дескриптора его нужно установить. Это может показаться немного странным, что нужно передавать WebRTC то, что она сама нам дала, но таков протокол. При получении удаленного дескриптора его нужно тоже установить. Поэтому Вы должны на одном узле установить два дескриптора – свой и чужой (то есть локальный и удаленный).

После такого рукопожатия узлы знают о пожеланиях друг друга. Например, если узел 1 поддерживает кодеки A и B , а узел 2 поддерживает кодеки B и C , то, так как каждый узел знает свой и чужой дескрипторы, оба узла выберут кодек B (Рисунок 7). Логика соединения теперь установлена, и можно передавать медиа потоки, но есть другая проблема – узлы по-прежнему связаны лишь сигнальным механизмом.

Рисунок 7: Согласование кодеков

Кандидаты (Ice candidate)

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

Итак, соединение уже установлено (логическое соединение), но пока нет пути, по которому узлы сети могут передавать данные. Здесь не всё так просто, но начнем с простого. Пусть узлы находятся в одной приватной сети. Как мы уже знаем, они могут легко соединяться друг с другом по своим внутренним IP адресам (или быть может, по каким-то другим, если используется не TCP/IP ).

Через некоторые callback ‘и WebRTC сообщает нам Ice candidate объекты. Они тоже приходят в текстовой форме и также, как с дескрипторами сессии, их нужно просто переслать через сигнальный механизм. Если дескриптор сессии содержал информацию о наших установках на уровне камеры и микрофона, то кандидаты содержат информацию о нашем расположении в сети. Передайте их другому узлу, и тот сможет физически соединиться с нами, а так как у него уже есть и дескриптор сессии, то и логически сможет соединиться и данные «потекут». Если он не забудет отправить нам и свой объект кандидата, то есть информацию о том, где находится он сам в сети, то и мы сможем с ним соединиться. Заметим здесь еще одно отличие от классического клиент-серверного взаимодействия. Общение с HTTP сервером происходит по схеме запрос-ответ, клиент отправляет данные на сервер, тот обрабатывает их и шлет по адресу, указанному в пакете запроса . В WebRTC необходимо знать два адреса и соединять их с двух сторон.

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

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

Итак, два узла находятся в одной сети (Рисунок 8). Как их идентифицировать? С помощью IP адресов. Больше никак. Правда, еще можно использовать разные транспорты (TCP и UDP ) и разные порты. Это и есть та информация, которая содержится в объекте кандидата – IP , PORT , TRANSPORT и какая-то другая. Пусть, для примера, используется UDP транспорт и 531 порт.

Рисунок 8: Два узла находятся в одной сети

Тогда, если мы находимся в узле p1 , то WebRTC передаст нам такой объект кандидата - . Здесь приводится не точный формат, а лишь схема. Если мы в узле p2 , то кандидат таков – . Через сигнальный механизм p1 получит кандидата p2 (то есть расположение узла p2 , а именно его IP и PORT ). После чего p1 может соединиться с p2 напрямую. Более правильно, p1 будет посылать данные на адрес 10.50.150.3:531 в надежде, что они дойдут до p2 . Не важно, принадлежит ли этот адрес узлу p2 или какому-то посреднику. Важно лишь то, что через этот адрес данные будут посылаться и могут достигнуть p2 .

Пока узлы в одной сети – все просто и легко – каждый узел имеет только один объект кандидата (всегда имеется в виду свой, то есть свое расположение в сети). Но кандидатов станет гораздо больше, когда узлы будут находится в разных сетях.

Перейдем к более сложному случаю. Один узел будет находиться за роутером (точнее, за NAT), а второй узел будет находиться в одной сети с этим роутером (например, в интернете) (Рисунок 9).

Рисунок 9: Один узел за NAT, другой нет

Этот случай имеет частное решение проблемы, которое мы сейчас и рассмотрим. Домашний роутер обычно содержит таблицу NAT . Это специальных механизм, разработанный для того, чтобы узлы внутри приватной сети роутера смогли обращаться, например, к веб-сайтам.

Предположим, что веб-сервер соединен с интернетом напрямую, то есть имеет публичным IP * адрес. Пусть это будет узел p2 . Узел p1 (веб-клиент) шлет запрос на адрес 10.50.200.10 . Сначала данные попадают на роутер r1 , а точнее на его внутренний интерфейс 192.168.0.1 . После чего, роутер запоминает адрес источника (адрес p1 ) и заносит его в специальную таблицу NAT , затем изменяет адрес источника на свой(p1 → r1 ). Далее, по своему внешнему интерфейсу роутер пересылает данные непосредственно на веб‑сервер p2 . Веб-сервер обрабатывает данные, генерирует ответ и отправляет обратно. Отправляет роутеру r1 , так как именно он стоит в обратном адресе (роутер подменил адрес на свой). Роутер получает данные, смотрит в таблицу NAT и пересылает данные узлу p1 . Роутер выступает здесь как посредник.

А что если несколько узлов из внутренней сети одновременно обращаются к внешней сети? Как роутер поймет кому отправлять ответ обратно? Эта проблема решается с помощью портов . Когда роутер подменяет адрес узла на свой, он также подменяет и порт. Если два узла обращаются к интернету, то роутер подменяет их порты источников на разные . Тогда, когда пакет от веб‑сервера придет обратно к роутеру, то роутер поймет по порту, кому назначен данный пакет. Пример ниже.

Вернемся к технологии WebRTC , а точнее, к ее части, которая использует ICE протокол (отсюда и Ice кандидаты). Узел p2 имеет одного кандидата (свое расположение в сети – 10.50.200.10 ), а узел p1 , который находится за роутером с NAT, будет иметь двух кандидатов – локального (192.168.0.200 ) и кандидата роутера (10.50.200.5 ). Первый не пригодится, но он, тем не менее, генерируется, так как WebRTC еще ничего не знает об удаленном узле – он может находиться в той же сети, а может и нет. Второй кандидат пригодится, и, как мы уже знаем, важную роль будет играть порт (чтобы пройти через NAT ).

Запись в таблице NAT генерируется только когда данные выходят из внутренней сети. Поэтому узел p1 должен первым передать данные и только после этого данные узла p2 смогут добраться до узла p1 .

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

Однако, если внешние адреса известны, то соединение будет легко установлено. Если первый узел отошлет данные на роутер второго узла, то роутер их проигнорирует, так как его таблица NAT пока пуста. Однако в роутере первого узла в таблице NAT появилась нужна запись. Если теперь второй узел отправит данные на роутер первого узла, то роутер их успешно передаст первому узлу. Теперь и таблица NAT второго роутера имеет нужны данные.

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

STUN и TURN сервера

При инициализации WebRTC необходимо указать доступные STUN и TURN сервера, которые мы в дальнейшем будем называть ICE серверами. Если сервера не будут указаны, то соединиться смогут только узлы в одной сети (подключенные к ней без NAT ). Сразу стоит отметить, что для 3g -сетей обязательно использование TURN серверов.

STUN сервер – это просто сервер в интернете, который возвращает обратный адрес, то есть адрес узла отправителя. Узел, находящий за роутером, обращается к STUN серверу, чтобы пройти через NAT . Пакет, пришедший к STUN серверу, содержит адрес источника – адрес роутера, то есть внешний адрес нашего узла. Этот адрес STUN сервер и отправляет обратно. Таким образом, узел получает свой внешний IP адрес и порт, через который он доступен из сети. Далее, WebRTC с помощью этого адреса создает дополнительного кандидата (внешний адрес роутера и порт). Теперь в таблице NAT роутера есть запись, которая пропускает к нашему узлу пакеты, отправленные на роутер по нужному порту.

Рассмотрим этот процесс на примере.

Пример (работа STUN сервера)

STUN сервер будем обозначать через s1 . Роутер, как и раньше, через r1 , а узел – через p1 . Также необходимо будет следить за таблицей NAT – ее обозначим как r1_nat . Причем в этой таблице обычно содержится много записей от разный узлов подсети – они приводиться не будут.

Итак, в начале имеем пустую таблицу r1_nat .

Таблица 2: Заголовок пакета

Узел p1 отправляет этот пакет роутеру r1 (не важно каким образом, в разных подсетях могут быть использованы разные технологии). Роутеру необходимо сделать подмену адреса источника Src IP , так как указанный в пакете адрес заведомо не подойдет для внешней подсети, более того, адреса из такого диапазона зарезервированы, и ни один адрес в интернете не имеет такого адреса. Роутер делает подмену в пакете и создает новую запись в своей таблице r1_nat . Для этого ему нужно придумать номер порта. Напомним, что, так как несколько узлов внутри подсети могут обращаться к внешней сети, то в таблице NAT должна храниться дополнительная информация, чтобы роутер смог определить, кому из этих нескольких узлов предназначается обратный пакет от сервера. Пусть роутер придумал порт 888 .

Измененный заголовок пакета:

Таблица 4: Таблица NAT пополнилась новой записью

Здесь IP адрес и порт для подсети абсолютно такие же, как у исходного пакета. В самом деле, при обратной передаче мы должны иметь способ полностью их восстановить. IP адрес для внешней сети – это адрес роутера, а порт изменился на придуманный роутером.

Настоящий порт, на который узел p1 принимает подключение – это, разумеется, 35777 , но сервер шлет данные на фиктивный порт 888 , который будет изменен роутером на настоящий 35777 .

Итак, роутер подменил адрес и порт источника в заголовке пакета и добавил запись в таблицу NAT . Теперь пакет отправляется по сети серверу, то есть узлу s1 . На входе, s1 имеет такой пакет:

Src IP	Src PORT	Dest IP	Dest PORT
10.50.200.5	888	12.62.100.200	6000

Таблица 5: STUN сервер получил пакет

Итого, STUN сервер знает, что ему пришел пакет от адреса 10.50.200.5:888 . Теперь этот адрес сервер отправляет обратно. Здесь стоит остановиться и еще раз посмотреть, что мы только что рассматривали. Таблицы, приведенные выше – это кусочек из заголовка пакета, вовсе не из его содержимого . О содержимом мы не говорили, так как это не столь важно – оно как-то описывается в протоколе STUN . Теперь же мы будем рассматривать помимо заголовка еще и содержимое. Оно будет простым и содержать адрес роутера – 10.50.200.5:888 , хотя взяли мы его из заголовка пакета. Такое делается не часто, обычно протоколам не важна информация об адресах узлов, важно лишь, чтобы пакеты доставлялись по назначению. Здесь же мы рассматриваем протокол, который устанавливает путь между двумя узлами.

Итак, теперь у нас появляется второй пакет, который идет в обратном направлении:

Таблица 7: STUN сервер отправляет пакет с таким содержимым

Далее, пакет путешествует по сети, пока не окажется на внешнем интерфейсе роутера r1 . Роутер понимает, что пакет предназначен не ему. Как он это понимает? Это можно узнать только по порту. Порт 888 он не использует для своих личных целей, а использует для механизма NAT . Поэтому в эту таблицу роутер и смотрит. Смотрит на столбец External PORT и ищет строку, которая совпадет с Dest PORT из пришедшего пакета, то есть 888 .

Internal IP	Internal PORT	External IP	External PORT
192.168.0.200	35777	10.50.200.5	888

Таблица 8: Таблица NAT

Нам повезло, такая строчка существует. Если бы не повезло, то пакет бы просто отбросился. Теперь нужно понять, кому из узлов подсети надо отправлять этот пакет. Не стоит торопиться, давайте снова вспомним о важности портов в этом механизме. Одновременно два узла в подсети могли бы отправлять запросы во внешнюю сеть. Тогда, если для первого узла роутер придумал порт 888 , то для второго он бы придумал порт 889 . Предположим, что так и случилось, то есть таблица r1_nat выглядит так:

Таблица 10: Роутер подменяет адрес приемника

Src IP	Src PORT	Dest IP	Dest PORT
12.62.100.200	6000	192.168.0.200	35777

Таблица 11: Роутер подменил адрес приемника

Пакет успешно приходит к узлу p1 и, посмотрев на содержимое пакета, узел узнает о своем внешнем IP адресе, то есть об адресе роутера во внешней сети. Также он знает и порт, который роутер пропускает через NAT .

Что же дальше? Какая от этого всего польза? Польза – это запись в таблице r1_nat . Если теперь кто угодно будет отправлять на роутер r1 пакет с портом 888 , то роутер перенаправит этот пакет узлу p1 . Таким образом, создался небольшой узкий проход к спрятанному узлу p1 .

Из примера выше можно получить некоторое представление о работе NAT и сути STUN сервера. Вообще, механизм ICE и STUN/TURN сервера как раз и направлены на преодоления ограничений NAT .

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

TURN сервер – это улучшенный STUN сервер. Отсюда сразу следует извлечь, что любой TURN сервер может работать и как STUN сервер. Однако, есть и преимущества. Если p2p коммуникация невозможна (как например, в 3g сетях), то сервер переходит в режим ретранслятора (relay ), то есть работает как посредник. Разумеется, ни о каком p2p тогда речь не идет, но за рамками механизма ICE узлы думают, что общаются напрямую.

В каких случаях необходим TURN сервер? Почему не хватает STUN сервера? Дело в том, что существует несколько разновидностей NAT . Они одинаково подменяют IP адрес и порт, однако в некоторые из них встроена дополнительная защита от “фальсификации”. Например, в симметричной таблице NAT сохраняются еще 2 параметра - IP и порт удаленного узла. Пакет из внешней сети проходит через NAT во внутреннюю сеть только в том случае, если адрес и порт источника совпадают с записанными в таблице. Поэтому фокус со STUN сервером не удается - таблица NAT хранит адрес и порт STUN сервера и, когда роутер получает пакет от WebRTC собеседника, он его отбрасывает, так как он “фальсифицирован”. Он пришел не от STUN сервера.

Таким образом TURN сервер нужен в том случае, когда оба собеседника находятся за симметричным NAT (каждый за своим).

Краткая сводка

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

• Медиа поток
  • Видео и аудио данные упаковываются в медиа потоки
  • Медиа потоки синхронизируют медиа дорожки, из которых состоят
  • Различные медиа потоки не синхронизированы между собой
  • Медиа потоки могут быть локальными и удаленными, к локальному обычно подключена камера и микрофон, удаленные получают данные из сети в кодированном виде
  • Медиа дорожки бывают двух типов – для видео и для аудио
  • Медиа дорожки имеют возможность включения/выключения
  • Медиа дорожки состоят из медиа каналов
  • Медиа дорожки синхронизируют медиа каналы, из которых состоят
  • Медиа потоки и медиа дорожки имеют метки, по которым их можно различать
• Дескриптор сессии
  • Дескриптор сессии используется для логического соединения двух узлов сети
  • Дескриптор сессии хранит информацию о доступных способах кодирования видео и аудио данных
  • WebRTC использует внешний сигнальный механизм – задача пересылки дескрипторов сессии (sdp ) ложится на приложение
  • Механизм логического соединения состоит из двух этапов – предложения (offer ) и ответа (answer )
  • Генерация дескриптора сессии невозможна без использования локального медиа потока в случае предложения (offer ) и невозможна без использования удаленного дескриптора сессии в случае ответа (answer )
  • Полученный дескриптор надо отдать реализации WebRTC , причем неважно, получен ли этот дескриптор удаленно или же локально от той же реализации WebRTC
  • Имеется возможность небольшой правки дескриптора сессии
• Кандидаты
  • Кандидат (Ice candidate ) – это адрес узла в сети
  • Адрес узла может быть своим, а может быть адресом роутера или TURN сервера
  • Кандидатов всегда много
  • Кандидат состоит из IP адреса, порта и типа транспорта (TCP или UDP )
  • Кандидаты используются для установления физического соединения двух узлов в сети
  • Кандидатов также нужно пересылать через сигнальный механизм
  • Кандидатов также нужно передавать реализации WebRTC , однако только удаленных
  • В некоторых реализациях WebRTC кандидатов можно передавать только после установки дескриптора сессии
• STUN/TURN/ICE/NAT
  • NAT – механизм обеспечения доступа к внешней сети
  • Домашние роутеры поддерживают специальную таблицу NAT
  • Роутер подменяет адреса в пакетах – адрес источника на свой, в случае, если пакет идет во внешнюю сеть, и адрес приемника на адрес узла во внутренней сети, если пакет пришел из внешней сети
  • Для обеспечения многоканального доступа к внешней сети NAT использует порты
  • ICE – механизм обхода NAT
  • STUN и TURN сервера – сервера-помошники для обхода NAT
  • STUN сервер позволяет создавать необходимые записи в таблице NAT , а также возвращает внешний адрес узла
  • TURN сервер обобщает STUN механизм и делает его работающим всегда
  • В наихудших случаях TURN сервер используется как посредник (relay ), то есть p2p превращается в клиент-сервер-клиентную связь.

OpenTok, PubNub и WebRTC

Облачные платформы OpenTok и PubNub для разработки коммуникационных сервисов на основе WebRTC

2016-04-08

В настоящее время Web Video Chats становятся все более и более популярными. Web Video Chat - это веб-приложение для диалогового общения, построенное на основе Web-сервера и браузеров.

Из всех существующих технологий построения Web видеочатов (Ajax; Java; Flash-технологии; ASP.Net + Silverlight; HTML5 + JavaScript на базе WebRTC API и др.) наиболее перспективной технологией является WebRTC API. Web чаты, построенные на базе технологии WebRTC, обеспечивают качественную передачу текста, голоса, видео и данных (файлов) без установки в браузеры дополнительных плагинов или расширений. Основными элементами видеочата на WebRTC является браузер и контактный сервер.

Браузер, поддерживающий WebRTC, становится единым интерфейсом для всех пользовательских устройств (ПК, смартфонов, айпадов, IP-телефонов, мобильных телефонов и т.д.), которые работают с коммуникационными сервисами. WebRTC с WebSocket, HTML5, CSS3 и JavaScript позволяют создавать веб-коммуникационные сервисы нового поколения. Технология WebRTC реализуется тремя интерфейсами JavaScript API.

Для работы пирингового необходимо с двух браузеров, поддерживающих WebRTC, обратиться по ip-адресу к сигнальному серверу (например, WebSocket серверу), работающему на node.js. Сервер не принимает участия в передаче информационных потоков между браузерами, а является сигнальным и предназначен для установки соединения между браузерами пользователей.

В связи с тем, что поддержка WebRTC осуществляется не всеми хостингами, для реализации коммуникационных приложений на основе WebRTC API и интеграции их в веб-узлы (веб-сайты) сети Интернет можно использовать специальные платформы, поддерживающие WebRTC и предоставляющие APIs и SDKs .

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

К таким платформам относятся: OpenTok от TokBox, PubNub, VoxImplant, Twilio, SkyWay от NTT Communications, Kandy.io, SightCall и т.д. Следует отметить, что для создания контактного сервера можно развернуть Node.js для веб-коммуникационных приложений на арендованном виртуальном сервере VPS или использовать хостинги облачных платформ (PaaS), которые поддерживают проекты на базе Node.js, например, OpenShift/Red Hat, Heroku/Salesforce, AWS Elastic Beanstalk/Amazon и т.д.

Кроме того, для создания коммуникационного приложения можно приобрести платформу Flashphoner Web Call Server (серверное программное обеспечение, предназначенное для организации браузерных онлайн-трансляций аудио- и видео-потоков), которая основана на HTML5 Websockets, WebRTC и Flash технологии, и установить ее на веб-сервер под OC Linux или арендованный виртуальный сервер VPS. В настоящее время компания Flashphoner развернула свой WebRTC сервер (Web Call Server 5) на облачном хостинге Amazon Web Services.

В данном обзоре рассмотрим наиболее популярные облачные коммуникационные Web-сервисы на основе технологии WebRTC - OpenTok от TokBox и PubNub.

OpenTok от TokBox

OpenTok - это облачная платформа PaaS (платформа как услуга), которая является ведущей коммуникационной платформой WebRTC для интеграции в веб-сайты и мобильные приложения видео коммуникаций и средств обмена сообщениями. OpenTok имеет распределенную инфраструктуру, которая содержит центры обработки данных по всему миру.

Открытая платформа OpenTok от TokBox обеспечивает разработчикам возможность встраивать кроссплатформенные видеочаты на основе WebRTC API в Web приложения (веб-сайты), Java/Android и ОС IOS приложения.

Архитектура OpenTok состоит из клиентской части библиотеки WebRTC OpenTok (например, OpenTok.js), которая обеспечивает встраивание видеосвязи в клиентскую часть приложения (веб-страницу) и комплект средств (OpenTok Client SDKs) для разработки клиентских приложений (JavaScript/Web приложений, ОС Java/Android и ОС IOS).

Кроме того, составной частью архитектуры OpenTok являются серверные SDK (OpenTok Server SDKs), которые предназначены для разработки серверной инфраструктуры (для управления и аутентификации пользователей) приложения, которое обеспечивает динамическую генерацию уникальных идентификаторов сеансов ID OpenTok (sessionId) и маркеров (token) для каждого пользователя, а также работу с архивами OpenTok. Web сервер передает соответствующий идентификатор сеанса и маркер, который клиент может затем использовать для подключения к сессии.

Серверные SDKs OpenTok доступны для основных языков программирования серверной части приложений: Java, .NET, Node.js, PHP, Python, Ruby. Следует отметить, что если для серверной части приложения требуется другой язык программирования, который не входит в перечисленный список, то TokBox предоставляет OpenTok REST API для создания сессий OpenTok и работы с архивами OpenTok.

Таким образом, для создания коммуникационных приложений для узлов Интернет следует использовать серверные SDKs OpenTok в сочетании с клиентской библиотекой WebRTC OpenTok и средствами OpenTok Client SDKs.

Чтобы использовать платформу OpenTok для создания видеочата WebRTC, встроенного в узел сети Интернете, в первую очередь, необходимо создать учетную запись на TokBox.com. Бесплатная учетная запись на OpenTok действует в течение тридцати дней. Зарегистрированный пользователь имеет возможность получить ключ API (ApiKey), необходимый для разработки коммуникационного приложения OpenTok. Ключ API идентифицирует учетную запись разработчика OpenTok.

Используя руководство разработчика OpenTok (https://tokbox.com/developer/guides/) в аккаунте разработчика TokBox можно создать коммуникационное приложение (веб-страницу видеочата) с помощью OpenTok Client SDKs. Чтобы использовать платформу OpenTok для приложения, необходимо включить библиотеку OpenTok.js в веб-страницу.

https://static.opentok.com/webrtc/ .../opentok.js

Идентификатор сеанса (SESSIONID) и маркер (token) необходимые для функционирования приложения обычно создаются программно на Web сервере с одним из серверных SDKs (OpenTok Server SDKs).

Но для создания тестовой версии приложения без серверных SDKs OpenTok, можно на основе ключа API (ApiKey) получить идентификатор сеанса и маркер для этого идентификатора сессии вручную с помощью панели инструментов разработчика. Клиенту нужен маркер, который дает ему доступ к сессии.

Образцы таких переменных как ключ "apiKey", идентификатор сессии "sessionId" и маркера "token" имеют вид:

var apiKey = "17493650";
var sessionId = "2_MX40NT...tWXR-UH4";
var token = "T1==cGFyd...2RhdGE9";

После создания объекта сеанса с идентификатором сеанса (SESSIONID) и маркера (token), приложение инициализирует объект сессии.

var session = OT.initSession(apiKey, sessionId);

Затем осуществляется подключение клиента к сеансу и публикация аудио и видео потоков:

session.connect(token, function(error) {
publisher = OT.initPublisher("publisher");
session.publish(publisher);
});

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

session.on({
streamCreated: function(event) {
session.subscribe(event.stream, "subscriber");
}});

Таким образом, в соответствии с руководством разработчика можно создать основу видеочата WebRTC на базе платформы OpenTok, который можно внедрить на свой сайт. На рисунке 2 представлен интерфейс скриншота этого видеочата на WebRTC, созданного в аккаунте разработчика TokBox.

Далее необходимо создать серверную часть видеочата, используя OpenTok Server SDKs для одного из языков программирования. OpenTok Server SDKs позволяют программно создавать сеансы OpenTok, генерировать маркеры, и работать с архивацией OpenTok.

Следует отметить, что в TokBox применяются два режима передачи медиа потоков (Media Streams):

• relayed (ретрансляция), в этом режиме медиа потоки передаются непосредственно между пирингами (например, между браузерами пользователей в видеочате один-к-одному);
• routed (маршрутизация), в этом режиме используются OpenTok Media Router для маршрутизации аудио-видео потоков между клиентами (например, в многопользовательском или групповом видеочате для онлайн-совещаний).

PubNub

PubNub - это глобальная сеть потоковой передачи данных для: IoT (Internet of Things), Mobile и Web. PubNub – это облачный Web сервис обмена сообщениями в режиме реального времени, который предназначен для организации веб-коммуникаций между различными платформами: мобильными телефонами, планшетами, веб-браузерами веб-узлов и т.д. PubNub предоставляет более 70 SDKs для основных языков программирования с целью создания кроссплатформенных коммуникационных приложений и встраивания их в Web приложения (веб-сайты) и приложения мобильных устройств (Java/Android и ОС IOS).

Список поддерживаемых языков и SDKs сервисом PubNub представлен на страничке: https://github.com/pubnub/pubnub-api. Следует отметить, что кроме API-интерфейсов к конкретным программным платформам PubNub также поддерживает API REST. Например, PubNub WebRTC SDK предназначен для организации веб-коммуникаций (пиринговых сетей) в реальном времени между браузерами по одноранговой архитектуре. Архитектура взаимодействия компонентов коммуникационного приложения на основе платформы PubNub и технологии WebRTC представлена на рис. 3.

Как следует из схемы взаимодействия компонентов WebRTC видеочата (рис.3) платформа PubNub использована в качестве масштабируемого сервера сигнализации (сервера согласования) для WebRTC приложений. Кроме того, платформа PubNub обеспечивает выполнение таких дополнительных функций как присутствие (предоставление информации о доступных в сети пользователях или об актуальном списке пользователей), хранение/воспроизведение (позволяет пользователям видеть историю прошлых разговоров в течение определенного периода времени) и регистрация.

В коммуникационных WebRTC приложениях на основе платформы PubNub применяются два способа обмена сообщениями (WebSockets и AJAX) между браузером и сервером согласования. PubNub предлагает новый API для подключения WebRTC приложения к платформе PubNub. WebRTC API PubNub выполняет сигнализацию между браузерами пользователей, чтобы позволить им соединиться по одноранговой архитектуре, используя API PeerConnection WebRTC. После обмена сигнальными сообщениями между браузерами, между ними устанавливается дуплексная связь для обмена видеопотоками и произвольными данными. Связь браузеров координируется PubNub.

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

Чтобы использовать платформу PubNub для создания видеочата, в первую очередь, необходимо зарегистрироваться на PubNub с целью создания бесплатной учетной записи. Зарегистрированный пользователь имеет возможность получить API ключи subscribe_key и publish_key , необходимые для разработки коммуникационного приложения PubNub. Затем в своем аккаунте можно добавить такие функции, как security, присутствие и хранение.

После получения API ключей можно приступить к созданию коммуникационного приложения на основе платформы PubNub, используя SDKs на одном из основных языков программирования, или использовать демонстрационные приложения (шаблоны). Учебное пособие для создания коммуникационного приложения представлено на страничке: https://www.pubnub.com/docs/tutorials/pubnub-publish-subscribe. Справочное руководство по созданию видеочата на основе PubNub WebRTC SDK рассмотрено на страничке https://www.pubnub.com/docs/webrtc-javascript/pubnub-javascript-sdk.

Для создания видеочата WebRTC с нуля в соответствии с руководством необходимо применить несколько простых API для JavaScript:

• подключить библиотеку PubNub в HTML страницу, т.е. включить JavaScript PubNub SDK в код HTML страницы перед инициализацией клиента;
• init() - инициализировать клиентское API PubNub;
• subscribe() - подписаться на определенный канал (вызвать метод subscribe() PubNub API);
• publish() - отправить сообщение на конкретный канал (вызвать метод publish() PubNub API);
• unsubscribe() - отказаться от подписки на определенный канал.

Инициализация клиентского API PubNub может быть представлена в следующем виде:
var PUBNUB = PUBNUB.init({
publish_key: "Your Publish Key",
subscribe_key: "Your Subscribe Key"
});

Для создания видеочата WebRTC на основе PubNub WebRTC можно воспользоваться шаблоном с открытым исходным кодом: https://www.pubnub.com/developers/demos/webrtc/. Для проверки работы этого видеочата необходимо с двух ПК обратиться по указанному адресу, в открывшемся в браузерах интерфейсе видеочата пользователям назначаются номера телефона. Для общения пользователи должны ввести номера телефона в текстовое поле "Type Recipient"s" и щелкнуть на кнопке с изображением телефонной трубки.

В результате изображения с видеокамер предаются в браузеры и отображаются на экранах мониторов. Кроме того, этот видеочат выполняет функции чата для передачи текста. Для переписки пользователи должны ввести текст в поле "chat here" и нажать клавишу "Enter". На рисунке 4 представлен скриншот видеочата пользователя с номером телефона 164.

Рис. 4.PubNub с WebRTC

На рисунке 5 представлен скриншот видеочата пользователя с номером телефона 128.

Рис. 5.PubNub с WebRTC

Предназначенный для пользователя интерфейс Web коммуникационного приложения разработан с помощью гипертекстовой разметки HTML5 и CSS3. Код клиентской части коммуникационного приложения разработан на JS. К Web коммуникационному приложению были подключены библиотеки: JQuery, PubNub JavaScript SDK и PubNub WebRTC SDK.

WebRTC (Web Real-Time Communications) - это технология, которая позволяет Web-приложениям и сайтам захватывать и выборочно передавать аудио и/или видео медиа-потоки, а также обмениваться произвольными данными между браузерами, без обязательного использования посредников. Набор стандартов, которые включает в себя технология WebRTC, позволяет обмениваться данными и проводить пиринговые телеконференции, без необходимости пользователю устанавливать плагины или любое другое стороннее программное обеспечение.

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

Совместимость

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

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

Для дальнейшего изучения библиотеки Adapter.js, смотрим .

Понятия и использование WebRTC

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

Соединение между двумя узлами представлено как объект интерфейса RTCPeerConnection . Как только соединение установлено и открыто, используя объект RTCPeerConnection , медиапотоки ( MediaStream s) и/или каналы данных ( RTCDataChannel s) могут быть добавлены в соединение.

Медиа потоки могут состоять из любого количества треков (дорожек) медиаинформации. Эти треки, представлены объектами интерфейса MediaStreamTrack , и могут содержать один или несколько типов медиаданных, включая аудио, видео, текст (такие как субтитры или название глав). Большинство потоков состоят, как минимум, только из одного аудио трека (одной аудио дорожки), или видео дорожки, и могут быть отправлены и получены, как потоки (медиаданные в настоящим времени) или сохранены в файл.

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

more details and links to relevant guides and tutorials needed

WebRTC интерфейсы

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

Настройка соединения и управление

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

RTCPeerConnection Представляет WebRTC соединение между локальным компьютером и удаленным узлом. Используется для обработки успешной передачи данных между двумя узлами. RTCSessionDescription Представляет параметры сессии. Каждый RTCSessionDescription содержит описания типа , показывающего какую часть (предложение/ответ) процесса переговоров он описывает, и SDP -дескриптор сессии. RTCIceCandidate Представляет собой кандидата сервера установки интернет соединения (ICE) для установленовки соединения RTCPeerConnection . RTCIceTransport Представляет информацию о средстве подключения к Интернету (ICE). RTCPeerConnectionIceEvent Представляет события, которые происходят в отношении кандидатов ICE, обычно RTCPeerConnection . Один тип передается данному объекту события: icecandidate . RTCRtpSender Управляет кродированием и передачей данных через объект типа MediaStreamTrack для объекта типа RTCPeerConnection . RTCRtpReceiver Управляет получением и декодированием данных через объект типа MediaStreamTrack для объекта типа RTCPeerConnection . RTCTrackEvent Указывает на то, что новый входящий объект типа MediaStreamTrack был создан и объект типа RTCRtpReceiver был добавлен в объект RTCPeerConnection . RTCCertificate Представляет сертификат, который использует объект RTCPeerConnection . RTCDataChannel Представляет двунапрвленный канал данных между двумя узлами соединения. RTCDataChannelEvent Представляет события, которые возникают при присоединении объекта типа RTCDataChannel к объекту типа RTCPeerConnection datachannel . RTCDTMFSender Управляет кодированием и передачей двутональной мультичастотной (DTMF) сигнализацией для объекта типа RTCPeerConnection . RTCDTMFToneChangeEvent Указывает на входящее событие изменение тона двутоновой мультичастотной сигнализации (DTMF). Это событие не всплывает (если не указано иначе) и не является отменяемым (если не указано иначе). RTCStatsReport Ассинхронно сообщает статус для переданного объекта типа MediaStreamTrack . RTCIdentityProviderRegistrar Регистрирует провайдер идентификации (idP). RTCIdentityProvider Активирует возможность браузеру запросить создание или проверку обяъвления идентификации. RTCIdentityAssertion Представляет идентификатор удаленного узла текущего соединения. Если узел еще не установлен и подтвержден, ссылка на интерфейс вернет null . После установки не изменяется. RTCIdentityEvent Представляет объект события объявление идентификатора провайдером идентификации (idP). Событие объекта типа RTCPeerConnection . Один тип передается этому событию identityresult . RTCIdentityErrorEvent Представляет объект события ошибки, связанной с провайдером идентификации (idP). Событие объекта типа RTCPeerConnection . Два типа ошибки передаются этому событию: idpassertionerror и idpvalidationerror .

Руководства

Обзор архитектуры WebRTC Под API, который применяют разработчики, чтобы создавать и использовать WebRTC, расположен набор сетевых протоколов и стандартов соединения. Этот обзор - витрина этих стандартов. WebRTC позволяет вам организовать соединение в режиме узел-узел для передачи произвольных данных, аудио-, видео-потоков или любую их комбинацию в браузере. В этой статье мы взглянем на жизнь WebRTC-сессии, начиная с установки соединения и пройдем весь путь до его завершения, когда оно больше не нужно. Обзор WebRTC API WebRTC состоит из нескольких взаимосвязанных программных интерфейсов (API) и протоколов, которые работают вместе, чтобы обеспечить поддержку обмена данными и медиа-потоками между двумя и более узлами. В этой статье представлен краткий обзор каждого из этих API и какую цель он преследует. Основы WebRTC Эта статья проведет вас через создание кросс-браузерного RTC-приложения. К концу этой статьи вы должны иметь работающий дата- и медиа-канал, работающий в режиме точка-точка. Протоколы WebRTC В этой статье представлены протоколы, в дополнение к которым создан API WebRTC. Это руководство описывает как вы можете использовать соединение узел-узел и связанный

Европейские пользователи Сети разделились на две части: согласно опросу Института анализа общественного мнения в Алленбахе (Германия), Skype, чат и системы мгновенного обмена сообщениями стали неотъемлемой частью повседневной жизни для 16,5 млн. взрослых и детей, 9 млн. используют эти службы от случая к случаю, а 28 млн. к ним не прикасаются.

Ситуация может измениться, поскольку теперь в Firefox интегрирована технология коммуникаций в реальном времени (WebRTC ), а также сам клиент. Запустить аудио- и видеочат теперь ничуть не сложнее, чем открыть сайт. Такие сервисы, как   и Skype, напротив, делают ставку на решения с использованием отдельного клиента и созданием учетной записи.

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

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

Вскоре после этого Chrome и Firefox получили собственные WebRTC-движки. В настоящее время их мобильные варианты оснащены как этой технологией, так и устанавливаемым вместе с Android 5.0 движком WebView 3.6, который используется приложениями.

Для коммуникации в реальном времени в веб-просмотрщике должны быть внедрены соответствующие интерфейсы JavaScript. С помощью GetUserMedia программное обеспечение активирует захват из аудиои видеоисточников, то есть с веб-камеры и микрофона. RTCPeerConnection отвечает за установление соединения, а также за саму коммуникацию.

Параллельно с интеграцией в браузер рабочая группа Консорциума Всемирной паутины (W3C) форсировала процесс стандартизации WebRTC. Он должен завершиться уже в 2015-го году.

WebRTC довольствуется малым

Для использования службы WebRTC не требуется много ресурсов, поскольку сервер соединяет только собеседников. Установка соединения также не представляет особой сложности. Сначала браузер подает серверу WebRTC сигнал, что он планирует начать вызов. От сервера он получает HTTPS-ссылку - связь осуществляется в зашифрованном виде. Этот линк пользователь отправляет своему собеседнику. После этого браузер запрашивает у пользователя разрешение на доступ к веб-камере и микрофону.

Чтобы установить прямое потоковое соединение с собеседником, браузер получает от службы WebRTC ее IP-адрес и данные конфигурации. Веб-просмотрщик собеседника поступает таким же образом.

Чтобы потоковое соединение функционировало без сбоев и в хорошем качестве, в браузере работают три движка. Два из них оптимизируют и сжимают аудиои видеоданные, третий ответственен за их транспортировку. Он пересылает данные посредством протокола SRTP (Secure Real-time Transport Protocol), который позволяет осуществлять зашифрованную потоковую передачу в реальном времени.

Если прямое соединение установить не удается, WebRTC ищет другой путь. К примеру, это происходит в том случае, когда сетевые настройки препятствуют тому, чтобы STUN-сервер смог сообщить IP-адрес. Стандартом WebRTC предусмотрено, что в этом случае беседа состоится, но с промежуточным включением TURN-сервера (Traversal Using Relays around NAT). Так, на сайте netscan.co можно проверить, реализуется ли WebRTC на вашем компьютере и с вашим доступом к Сети.

Как осуществляется соединение

Сначала необходимо зарегистрировать беседу (1). Служба WebRTC дает ссылку, которую необходимо отправить собеседнику. Браузер с помощью STUNсервера выясняет свой собственный IP-адрес (2), отправляет его сервису и получает IP партнера для установки прямого соединения (3). Если использовать STUN не удается, беседа перенаправляется с помощью TURNсервера (4).

Общение по технологии WebRTC в браузере запускается с помощью кода JavaScript. После этого за коммуникацию отвечают три движка: голосовой и видеодвижки собирают мультимедийные данные с веб-камеры и микрофона, а транспортный движок объединяет информацию и пересылает поток в зашифрованном виде, используя протокол SRTP (Secure Real-time Protocol).

Какие браузеры работают с WebRTC

Chrome и Firefox оснащены движком WebRTC, который использует такие службы, как talky.io. Браузер от Mozilla может работать напрямую со своим собственным клиентом.

Google и Mozilla продолжают развивать идею коммуникации в реальном времени: Chrome может проводить конференцию WebRTC с несколькими участниками, а новый клиент Hello в Firefox разработан при содействии с дочерней компанией телекоммуникационного гиганта Telefonica. Apple пока что остается в стороне, в Safari WebRTC ожидать пока не стоит. Однако существует множество альтернативных приложений для iOS и плагинов для Safari.

Корпорация Microsoft идет несколько иным курсом. В качестве владельца конкурентного сервиса Skype данная компания не собирается так просто капитулировать перед WebRTC. Вместо этого Microsoft разрабатывает технологию под названием ORTC (Object Real-Time Communications) для Internet Explorer.

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

Фото: компании-производители; goodluz/Fotolia.com

WebRTC (Web Real Time Communications) — это стандарт, который описывает передачу потоковых аудиоданных, видеоданных и контента от браузера и к браузеру в режиме реального времени без установки плагинов или иных расширений. Стандарт позволяет превратить браузер в оконечный терминал видеоконференцсвязи, достаточно просто открыть веб-страницу, чтобы начать общение.

Что такое WebRTC?

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

Что нужно знать про WebRTC?

Эволюция стандартов и технологий видеосвязи

Сергей Юцайтис, Cisco, Видео+Конференция 2016

Как работает WebRTC

На стороне клиента

• Пользователь открывает страницу, содержащую HTML5 тег
• Браузер запрашивает доступ к веб-камере и микрофону пользователя.
• JavaScript код на странице пользователя контролирует параметры соединения (IP-адреса и порты сервера WebRTC или других WebRTC клиентов) для обхода NAT и Firewall.
• При получении информации о собеседнике или о потоке со смикшированной на сервере конференцией, браузер начинает согласование используемых аудио и видео кодеков.
• Начинается процесс кодирования и передача потоковых данных между WebRTC клиентами (в нашем случае, между браузером и сервером).

На стороне WebRTC сервера

Для обмена данными между двумя участниками видеосервер не требуется, но если нужно объединить в одной конференции несколько участников, сервер необходим.

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

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

Преимущества стандарта

• Не требуется установка ПО.
• Очень высокое качество связи, благодаря:
  • Использованию современных видео (VP8, H.264) и аудиокодеков (Opus).
  • Автоматическое подстраивание качества потока под условия соединения.
  • Встроенная система эхо- и шумоподавления.
  • Автоматическая регулировка уровня чувствительности микрофонов участников (АРУ).
• Высокий уровень безопасности: все соединения защищены и зашифрованы согласно протоколам TLS и SRTP.
• Есть встроенный механизм захвата контента, например, рабочего стола.
• Возможность реализации любого интерфейса управления на основе HTML5 и JavaScript.
• Возможность интеграции интерфейса с любыми back-end системами с помощью WebSockets.
• Проект с открытым исходным кодом — можно внедрить в свой продукт или сервис.
• Настоящая кросс-платформенность: одно и то же WebRTC приложение будет одинаково хорошо работать на любой операционной системе, десктопной или мобильной, при условии, что браузер поддерживает WebRTC. Это значительно экономит ресурсы на разработку ПО.

Недостатки стандарта

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

Секреты WebRTC: как вендоры извлекают пользу из прорывной веб-технологии

Цахи Левент-Леви, Bloggeek.me, Видео+Конференция 2015

WebRTC для рынка ВКС

Увеличение числа ВКС-терминалов

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

Использование в специализированных решениях

Использование различных JavaScript библиотек и API облачных сервисов с поддержкой WebRTC позволяет легко добавить поддержку видеосвязи в любые веб-проекты. Ранее для передачи данных в реальном времени разработчикам приходилось изучать принципы работы протоколов и использовать наработки других компаний, которые чаще всего требовали дополнительного лицензирования, что увеличивало расходы. Уже сейчас WebRTC активно используется в сервисах вида “Позвонить с сайта”, “Онлайн-чат поддержки”, и т.п.

Ex-пользователям Skype для Linux

В 2014 году Microsoft объявила об прекращении поддержки проекта Skype для Linux, что вызвало большое раздражение у IT-специалистов. Технология WebRTC не привязана к операционной системе, а реализована на уровне браузера, т.е. Linux пользователи смогут увидеть в продуктах и сервисах на основе WebRTC полноценную замену Skype.

Конкуренция с Flash

WebRTC и HTML5 стали смертельным ударом для технологии Flash, которая и так переживала свои далеко не лучшие годы. С 2017 года ведущие браузеры официально перестали поддерживать Flash и технология окончательно исчезла с рынка. Но нужно отдать Flash должное, ведь именно он создал рынок веб-конференций и предложил технические возможности для живого общения в браузерах.

Видеопрезентации WebRTC

Дмитрий Одинцов, TrueConf, Видео+Конференция октябрь 2017

Кодеки в WebRTC

Аудиокодеки

Для сжатия аудио-трафика в WebRTC используются кодеки Opus и G.711.

G.711 — самый старый голосовой кодек с высоким битрейтом (64 kbps), который чаще всего применяется в системах традиционной телефонии. Основным достоинством является минимальная вычислительная нагрузка из-за использования легких алгоритмов сжатия. Кодек отличается низким уровнем компрессии голосовых сигналов и не вносит дополнительной задержки звука во время общения между пользователями.

G.711 поддерживается большим количеством устройств. Системы, в которых используется этот кодек, более легкие в применении, чем те, которые основаны на других аудиокодеках (G.723, G.726, G.728 и т.д.). По качеству G.711 получил оценку 4.2 в тестировании MOS (оценка в пределах 4-5 является самой высокой и означает хорошее качество, аналогичное качеству передачи голосового трафика в ISDN и даже выше).

Opus — это кодек с низкой задержкой кодирования (от 2.5 мс до 60 мс), поддержкой переменного битрейта и высоким уровнем сжатия, что идеально подходит для передачи потокового аудиосигнала в сетях с переменной пропускной способностью. Opus - гибридное решение, сочетающее в себе лучшие характеристики кодеков SILK (компрессия голоса, устранение искажений человеческой речи) и CELT (кодирование аудиоданных). Кодек находится в свободном доступе, разработчикам, которые его используют, не нужно платить отчисления правообладателям. По сравнению с другими аудиокодеками, Opus, несомненно, выигрывает по множеству показателей. Он затмил довольно популярные кодеки с низким битрейтом, такие, как MP3, Vorbis, AAC LC. Opus восстанавливает наиболее приближенную к оригиналу “картину” звука, чем AMR-WB и Speex. За этим кодеком - будущее, именно поэтому создатели технологии WebRTC включили его в обязательный ряд поддерживаемых аудиостандартов.

Видеокодеки

Вопросы выбора видеокодека для WebRTC заняли у разработчиков несколько лет, в итоге решили использовать H.264 и VP8. Практически все современные браузеры поддерживают оба кодека. Серверам видеоконференций для работы с WebRTC достаточно поддержать только один.

VP8 — свободный видеокодек с открытой лицензией, отличается высокой скоростью декодирования видеопотока и повышенной устойчивостью к потере кадров. Кодек универсален, его легко внедрить в аппаратные платформы, поэтому очень часто разработчики систем видеоконференцсвязи используют его в своих продуктах.

Платный видеокодек H.264 стал известен намного раньше своего собрата. Это кодек с высокой степенью сжатия видеопотока при сохранении высокого качества видео. Высокая распространенность этого кодека среди аппаратных систем видеоконференцсвязи предполагает его использование в стандарте WebRTC.

Компании Google и Mozilla активно продвигают кодек VP8, а Microsoft, Apple и Cisco — H.264 (для обеспечения совместимости с традиционными системами видеоконференцсвязи). И вот тут возникакет очень большая проблема для разработчиков облачных WebRTC решений, ведь если в конференции все участники используют один браузер, то конференцию достаточно микшировать один раз одним кодеком, а если браузеры разные и среди них есть Safari / Edge, то конференцию придётся кодировать два раза разными кодеками, что в два раза повысит системные требования к медиа-серверу и как следствие, стоимость подписок на WebRTC сервисы.

WebRTC API

Технология WebRTC базируется на трех основных API:

• (отвечает за принятие веб-браузером аудио и видеосигнала от камер или рабочего стола пользователя).
• RTCPeerConnection (отвечает за соединение между браузерами для “обмена” полученными от камеры, микрофона и рабочего стола, медиаданными. Также в “обязанности” этого API входит обработка сигнала (очистка его от посторонних шумов, регулировка громкости микрофона) и контроль над используемыми аудио и видеокодеками).
• RTCData Channel (обеспечивает двустороннюю передачу данных через установленное соединение).

Прежде чем получить доступ к микрофону и камере пользователя, браузер запрашивает на это разрешение. В Google Chrome можно заранее настроить доступ в разделе “Настройки”, в Opera и Firefox выбор устройств осуществляется непосредственно в момент получения доступа, из выпадающего списка. Запрос на разрешение будет появляться всегда при использовании протокола HTTP и однократно, если использовать HTTPS:

RTCPeerConnection . Каждый браузер, участвующий в WebRTC конференции, должен иметь доступ к данному объекту. Благодаря использованию RTCPeerConnection медиаданные от одного браузера к другому могут проходить даже через NAT и сетевые экраны. Для успешной передачи медиапотоков участники должны обменяться следующими данными с помощью транспорта, например, веб-сокетов:

• участник-инициатор направляет второму участнику Offer-SDP (структура данных, с характеристиками медиапотока, которые он будет передавать);
• второй участник формирует “ответ” — Answer-SDP и пересылает его инициатору;
• затем между участниками организуется обмен ICE-кандидатами, если таковые обнаружены (если участники находятся за NAT или сетевыми экранами).

После успешного завершения данного обмена между участниками организуется непосредственно передача медиапотоков (аудио и видео).

RTCData Channel . Поддержка протокола Data Channel появилась в браузерах сравнительно недавно, поэтому данный API можно рассматривать исключительно в случаях использования WebRTC в браузерах Mozilla Firefox 22+ и Google Chrome 26+. С его помощью участники могут обмениваться текстовыми сообщениями в браузере.

Подключение по WebRTC

Поддерживаемые десктопные браузеры

• Google Chrome (17+) и все браузеры на основе движка Chromium;
• Mozilla FireFox (18+);
• Opera (12+);
• Safari (11+);

Поддерживаемые мобильные браузеры для Android

• Google Chrome (28+);
• Mozilla Firefox (24+);
• Opera Mobile (12+);
• Safari (11+).

WebRTC, Microsoft и Internet Explorer

Очень долго Microsoft хранила молчание по поводу поддержки WebRTC в Internet Explorer и в своём новым браузере Edge. Ребята из Редмонда не очень любят давать в руки пользователей технологии, которые они не контролируют, вот такая вот политика. Но постепенно дело сдвинулось с мёртвой точки, т.к. игнорировать WebRTC далее было уже нельзя, и был анонсирован проект ORTC, производный от стандарта WebRTC.

По словам разработчиков ORTC — это расширение стандарта WebRTC с улучшенным набором API на основе JavaScript и HTML5, что в переводе на обычный язык означает, что всё будет то же самое, только контролировать стандарт и его развитие будет Microsoft, а не Google. Набор кодеков расширен поддержкой H.264 и некоторым аудиокодеками серии G.7ХХ, используемыми в телефонии и аппаратных ВКС системах. Возможно появится встроенная поддержка RDP (для передачи контента) и обмена сообщениями. Кстати, пользователям Internet Explorer не повезло, поддержка ORTC будет только в Edge. Ну и, естественно, такой набор протоколов и кодеков малой кровью стыкуется со Skype for Business, что открывает для WebRTC ещё больше бизнес применений.