Технологиям для звонков из браузера уже много лет: Java, ActiveX, Adobe Flash... В последние несколько лет стало ясно, что плагины и левые виртуальные машины не блещут удобством (зачем мне вообще что-то устанавливать?) и, самое главное, безопасностью. Что же делать? Выход есть!
До последнего времени в IP-сетях использовалось несколько протоколов для IP-телефонии или видео: SIP, наиболее распространенный протокол, сходящие со сцены H.323 и MGCP, Jabber/Jingle (используемый в Gtalk), полуоткрытые Adobe RTMP* и, конечно, закрытый Skype. Проект WebRTC, инициированный Google, пытается перевернуть положение дел в мире IP- и веб-телефонии, сделав ненужными все программные телефоны, включая Skype. WebRTC не просто реализует все коммуникационные возможности непосредственно внутри браузера, установленного сейчас практически на каждом устройстве, но пытается одновременно решить более общую задачу коммуникаций между пользователями браузеров (обмен различными данными, трансляция экранов, совместная работа с документами и многое другое).
WebRTC со стороны веб-разработчикаС точки зрения веб-разработчика WebRTC состоит из двух основных частей:
- управление медиапотоками от локальных ресурсов (камеры, микрофона или экрана локального компьютера) реализуется методом navigator.getUserMedia, возвращающим объект MediaStream;
- peer-to-peer коммуникации между устройствами, генерирующими медиапотоки, включая определение способов связи и непосредственно их передачу - объекты RTCPeerConnection (для отправки и получения аудио- и видеопотоков) и RTCDataChannel (для отправки и получения данных из браузера).
Мы разберемся, как организовать простейший многопользовательский видеочат между браузерами на основе WebRTC с использованием веб-сокетов. Экспериментировать начнем в Chrome/Chromium, как наиболее продвинутых в плане WebRTC браузерах, хотя вышедший 24 июня Firefox 22 почти их догнал. Нужно сказать, что стандарт еще не принят, и от версии к версии API может меняться. Все примеры проверялись в Chromium 28. Для простоты не будем следить за чистотой кода и кросс-браузерностью.
MediaStreamПервый и самый простой компонент WebRTC - MediaStream. Он предоставляет браузеру доступ к медиапотокам с камеры и микрофона локального компьютера. В Chrome для этого необходимо вызвать функцию navigator.webkitGetUserMedia() (так как стандарт еще не завершен, все функции идут с префиксом, и в Firefox эта же функция называется navigator.mozGetUserMedia()). При ее вызове пользователю будет выведен запрос о разрешении доступа к камере и микрофону. Продолжить звонок можно будет только после того, как пользователь даст свое согласие. В качестве параметров этой функции передаются параметры требуемого медиапотока и две callback-функции: первая будет вызвана в случае успешного получения доступа к камере/микрофону, вторая - в случае ошибки. Для начала создадим HTML-файл rtctest1.html с кнопкой и элементом :
WebRTC - первое знакомство
video { height: 240px; width: 320px; border: 1px solid grey; }
getUserMedia
Microsoft не была бы Microsoft, если бы в ответ на инициативу Google не выпустила немедленно свой собственный несовместимый нестандартный вариант под названием CU-RTC-Web (html5labs.interoperabilitybridges.com/cu-rtc-web/cu-rtc-web.htm). Хотя доля IE, и так небольшая, продолжает сокращаться, количество пользователей Skype дает Microsoft надежду потеснить Google, и можно предположить, что именно этот стандарт будет использоваться в браузерной версии Skype. Стандарт Google ориентирован в первую очередь на коммуникации между браузерами; в то же время основная часть голосового трафика по-прежнему остается в обычной телефонной сети, и шлюзы между ней и IP-сетями необходимы не только для удобства использования или более быстрого распространения, но и в качестве средства монетизации, которое позволит большему числу игроков их развивать. Появление еще одного стандарта может не только привести к неприятной необходимости разработчикам поддерживать сразу две несовместимых технологии, но и в перспективе дать пользователю более широкий выбор возможного функционала и доступных технических решений. Поживем - увидим.
Включение локального потокаВнутри тегов нашего HTML-файла объявим глобальную переменную для медиапотока:
Var localStream = null;
Первым параметром методу getUserMedia необходимо указать параметры запрашиваемого медиапотока - например просто включить аудио или видео:
Var streamConstraints = { "audio": true, "video": true }; // Запрашиваем доступ и к аудио, и к видео
Либо указать дополнительные параметры:
Var streamConstraints = { "audio": true, "video": { "mandatory": { "maxWidth": "320", "maxHeight": "240", "maxFrameRate": "5" }, "optional": } };
Вторым параметром методу getUserMedia необходимо передать callback-функцию, которая будет вызвана в случае его успешного выполнения:
Function getUserMedia_success(stream) { console.log("getUserMedia_success():", stream); localVideo1.src = URL.createObjectURL(stream); // Подключаем медиапоток к HTML-элементу localStream = stream; // и сохраняем в глобальной переменной для дальнейшего использования }
Третий параметр - callback-функция обработчик ошибки, который будет вызван в случае ошибки
Function getUserMedia_error(error) { console.log("getUserMedia_error():", error); }
Собственно вызов метода getUserMedia - запрос доступа к микрофону и камере при нажатии на первую кнопку
Function getUserMedia_click() { console.log("getUserMedia_click()"); navigator.webkitGetUserMedia(streamConstraints, getUserMedia_success, getUserMedia_error); }
Получить доступ к медиапотоку из файла, открытого локально, невозможно. Если попытаться так сделать, получим ошибку:
NavigatorUserMediaError {code: 1, PERMISSION_DENIED: 1}"
Выложим получившийся файл на сервер, откроем в браузере и в ответ на появившийся запрос разрешим доступ к камере и микрофону.
Выбрать устройства, к которым получит доступ Chrome, можно в Settings («Настройки»), линк Show advanced settings («Показать дополнительные настройки»), раздел Privacy («Личные данные»), кнопка Content («Настройки контента»). В браузерах Firefox и Opera выбор устройств осуществляется из выпадающего списка непосредственно при разрешении доступа.
При использовании протокола HTTP разрешение будет запрашиваться каждый раз при получении доступа к медиапотоку после загрузки страницы. Переход на HTTPS позволит выводить запрос однократно, только при самом первом доступе к медиапотоку.
Обрати внимание на пульсирующий кружок в иконке на закладке и значок камеры в правой части адресной строки:
RTCMediaConnectionRTCMediaConnection - объект, предназначенный для установления и передачи медиапотоков по сети между участниками. Кроме того, этот объект отвечает за формирование описания медиасессии (SDP), получение информации об ICE-кандидатах для прохождения через NAT или сетевые экраны (локальные и с помощью STUN) и взаимодействие с TURN-сервером. У каждого участника должно быть по одному RTCMediaConnection на каждое соединение. Медиапотоки передаются по шифрованному протоколу SRTP.
TURN-серверыICE-кандидаты бывают трех типов: host, srflx и relay. Host содержат информацию, полученную локально, srflx - то, как узел выглядит для внешнего сервера (STUN), и relay - информация для проксирования трафика через TURN-сервер. Если наш узел находится за NAT’ом, то host-кандидаты будут содержать локальные адреса и будут бесполезны, кандидаты srflx помогут только при определенных видах NAT и relay будут последней надеждой пропустить трафик через промежуточный сервер.
Пример ICE-кандидата типа host, с адресом 192.168.1.37 и портом udp/34022:
A=candidate:337499441 2 udp 2113937151 192.168.1.37 34022 typ host generation 0
Общий формат для задания STUN/TURN-серверов:
Var servers = { "iceServers": [ { "url": "stun:stun.stunprotocol.org:3478" }, { "url": "turn:user@host:port", "credential": "password" } ]};
Публичных STUN-серверов в интернете много. Большой список, например, есть . К сожалению, решают они слишком малую часть проблем. Публичных же TURN-серверов, в отличие от STUN, практически нет. Связано это с тем, что TURN-сервер пропускает через себя медиапотоки, которые могут значительно загружать и сетевой канал, и сам сервер. Поэтому самый простой способ подключиться к TURN-серверам - установить его самому (понятно, что потребуется публичный IP). Из всех серверов, на мой взгляд, наилучший rfc5766-turn-server . Под него есть даже готовый образ для Amazon EC2.
С TURN пока не все так хорошо, как хотелось бы, но идет активная разработка, и хочется надеяться, через какое-то время WebRTC если не сравняется со Skype по качеству прохождения через трансляцию адресов (NAT) и сетевые экраны, то по крайней мере заметно приблизится.
Для RTCMediaConnection необходим дополнительный механизм обмена управляющей информацией для установления соединения - хотя он и формирует эти данные, но не передает их, и передачу другим участниками необходимо реализовывать отдельно.
Выбор способа передачи возлагается на разработчика - хоть вручную. Как только обмен необходимыми данными пройдет, RTCMediaConnection установит медиапотоки автоматически (если получится, конечно).
Модель offer-answerДля установления и изменения медиапотоков используется модель offer/answer (предложение/ответ; описана в RFC3264) и протокол SDP (Session Description Protocol). Они же используются и протоколом SIP. В этой модели выделяется два агента: Offerer - тот, кто генерирует SDP-описание сессии для создания новой или модификации существующей (Offer SDP), и Answerer - тот, кто получает SDP-описание сессии от другого агента и отвечает ему собственным описанием сессии (Answer SDP). При этом в спецификации требуется наличие протокола более высокого уровня (например, SIP или собственного поверх веб-сокетов, как в нашем случае), отвечающего за передачу SDP между агентами.
Какие данные необходимо передать между двумя RTCMediaConnection, чтобы они смогли успешно установить медиапотоки:
- Первый участник, инициирующий соединение, формирует Offer, в котором передает структуру данных SDP (этот же протокол для той же цели используется в SIP), описывающую возможные характеристики медиапотока, который он собирается начать передавать. Этот блок данных необходимо передать второму участнику. Второй участник формирует Answer, со своим SDP и пересылает его первому.
- И первый и второй участники выполняют процедуру определения возможных ICE-кандидатов, с помощью которых к ним сможет передать медиапоток второй участник. По мере определения кандидатов информация о них должна передаваться другому участнику.
Формирование Offer
Для формирования Offer нам понадобятся две функции. Первая будет вызываться в случае его успешного формирования. Второй параметр метода createOffer() - callback-функция, вызываемая в случае ошибки при его выполнении (при условии, что локальный поток уже доступен).
Дополнительно понадобятся два обработчика событий: onicecandidate при определении нового ICE-кандидата и onaddstream при подключении медиапотока от дальней стороны. Вернемся к нашему файлу. Добавим в HTML после строк с элементами еще одну:
createOffer
И после строки с элементом (на будущее):
Также в начале JavaScript-кода объявим глобальную переменную для RTCPeerConnection:
Var pc1;
При вызове конструктора RTCPeerConnection необходимо указать STUN/TURN-серверы. Подробнее о них см. врезку; пока все участники находятся в одной сети, они не требуются.
Var servers = null;
Параметры для подготовки Offer SDP
Var offerConstraints = {};
Первый параметр метода createOffer() - callback-функция, вызываемая при успешном формировании Offer
Function pc1_createOffer_success(desc) { console.log("pc1_createOffer_success(): \ndesc.sdp:\n"+desc.sdp+"desc:", desc); pc1.setLocalDescription(desc); // Зададим RTCPeerConnection, сформированный Offer SDP методом setLocalDescription. // Когда дальняя сторона пришлет свой Answer SDP, его нужно будет задать методом setRemoteDescription // Пока вторая сторона не реализована, ничего не делаем // pc2_receivedOffer(desc); }
Второй параметр - callback-функция, которая будет вызвана в случае ошибки
Function pc1_createOffer_error(error){ console.log("pc1_createOffer_success_error(): error:", error); }
И объявим callback-функцию, которой будут передаваться ICE-кандидаты по мере их определения:
Function pc1_onicecandidate(event){ if (event.candidate) { console.log("pc1_onicecandidate():\n"+ event.candidate.candidate.replace("\r\n", ""), event.candidate); // Пока вторая сторона не реализована, ничего не делаем // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); } }
А также callback-функцию для добавления медиапотока от дальней стороны (на будущее, так как пока у нас только один RTCPeerConnection):
Function pc1_onaddstream(event) { console.log("pc_onaddstream()"); remoteVideo1.src = URL.createObjectURL(event.stream); }
При нажатии на кнопку «createOffer» создадим RTCPeerConnection, зададим методы onicecandidate и onaddstream и запросим формирование Offer SDP, вызвав метод createOffer():
Function createOffer_click() { console.log("createOffer_click()"); pc1 = new webkitRTCPeerConnection(servers); // Создаем RTCPeerConnection pc1.onicecandidate = pc1_onicecandidate; // Callback-функция для обработки ICE-кандидатов pc1.onaddstream = pc1_onaddstream; // Callback-функция, вызываемая при появлении медиапотока от дальней стороны. Пока что его нет pc1.addStream(localStream); // Передадим локальный медиапоток (предполагаем, что он уже получен) pc1.createOffer(// И собственно запрашиваем формирование Offer pc1_createOffer_success, pc1_createOffer_error, offerConstraints); }
Сохраним файл как rtctest2.html, выложим его на сервер, откроем в браузере и посмотрим в консоли, какие данные формируются во время его работы. Второе видео пока не появится, так как участник всего один. Напомним, SDP - описание параметров медиасессии, доступные кодеки, медиапотоки, а ICE-кандидаты - возможные варианты подключения к данному участнику.
Формирование Answer SDP и обмен ICE-кандидатамиИ Offer SDP, и каждого из ICE-кандидатов необходимо передать другой стороне и там после их получения у RTCPeerConnection вызвать методы setRemoteDescription для Offer SDP и addIceCandidate для каждого ICE-кандидата, полученного от дальней стороны; аналогично в обратную сторону для Answer SDP и удаленных ICE-кандидатов. Сам Answer SDP формируется аналогично Offer; разница в том, что вызывается не метод createOffer, а метод createAnswer и перед этим RTCPeerConnection методом setRemoteDescription передается Offer SDP, полученный от вызывающей стороны.
Добавим еще один видеоэлемент в HTML:
И глобальную переменную для второго RTCPeerConnection под объявлением первой:
Var pc2;
Обработка Offer и Answer SDPФормирование Answer SDP очень похоже на Offer. В callback-функции, вызываемой при успешном формировании Answer, аналогично Offer, отдадим локальное описание и передадим полученный Answer SDP первому участнику:
Function pc2_createAnswer_success(desc) { pc2.setLocalDescription(desc); console.log("pc2_createAnswer_success()", desc.sdp); pc1.setRemoteDescription(desc); }
Callback-функция, вызываемая в случае ошибки при формировании Answer, полностью аналогична Offer:
Function pc2_createAnswer_error(error) { console.log("pc2_createAnswer_error():", error); }
Параметры для формирования Answer SDP:
Var answerConstraints = { "mandatory": { "OfferToReceiveAudio":true, "OfferToReceiveVideo":true } };
При получении Offer вторым участником создадим RTCPeerConnection и сформируем Answer аналогично Offer:
Function pc2_receivedOffer(desc) { console.log("pc2_receiveOffer()", desc); // Создаем объект RTCPeerConnection для второго участника аналогично первому pc2 = new webkitRTCPeerConnection(servers); pc2.onicecandidate = pc2_onicecandidate; // Задаем обработчик события при появлении ICE-кандидата pc2.onaddstream = pc_onaddstream; // При появлении потока подключим его к HTML pc2.addStream(localStream); // Передадим локальный медиапоток (в нашем примере у второго участника он тот же, что и у первого) // Теперь, когда второй RTCPeerConnection готов, передадим ему полученный Offer SDP (первому мы передавали локальный поток) pc2.setRemoteDescription(new RTCSessionDescription(desc)); // Запросим у второго соединения формирование данных для сообщения Answer pc2.createAnswer(pc2_createAnswer_success, pc2_createAnswer_error, answerConstraints); }
Для того чтобы в рамках нашего примера передать Offer SDP от первого участника ко второму, раскомментируем в функции pc1createOffer success() строку вызова:
Pc2_receivedOffer(desc);
Чтобы реализовать обработку ICE-кандидатов, раскомментируем в обработчике события готовности ICE-кандидатов первого участника pc1_onicecandidate() его передачу второму:
Pc2.addIceCandidate(new RTCIceCandidate(event.candidate));
Обработчик события готовности ICE-кандидатов второго участника зеркально подобен первому:
Function pc2_onicecandidate(event) { if (event.candidate) { console.log("pc2_onicecandidate():", event.candidate.candidate); pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); } }
Сallback-функцию для добавления медиапотока от первого участника:
Function pc2_onaddstream(event) { console.log("pc_onaddstream()"); remoteVideo2.src = URL.createObjectURL(event.stream); }
Завершение соединенияДобавим еще одну кнопку в HTML
Hang Up
И функцию для завершения соединения
Function btnHangupClick() { // Отключаем локальное видео от HTML-элементов , останавливаем локальный медиапоток, устанавливаем = null localVideo1.src = ""; localStream.stop(); localStream = null; // Для каждого из участников отключаем видео от HTML-элементов , закрываем соединение, устанавливаем указатель = null remoteVideo1.src = ""; pc1.close(); pc1 = null; remoteVideo2.src = ""; pc2.close(); pc2 = null; }
Сохраним как rtctest3.html, выложим на сервер и откроем в браузере. В этом примере реализована двусторонняя передача медиапотоков между двумя RTCPeerConnection в рамках одной закладки браузера. Чтобы организовать через сеть обмен Offer и Answer SDP, ICE-кандидатами между участниками и другой информацией, потребуется вместо прямого вызова процедур реализовать обмен между участниками с помощью какого-либо транспорта, в нашем случае - веб-сокетов.
Трансляция экранаФункцией getUserMedia можно также захватить экран и транслировать как MediaStream, указав следующие параметры:
Var mediaStreamConstraints = { audio: false, video: { mandatory: { chromeMediaSource: "screen" }, optional: } };
Для успешного доступа к экрану должно выполняться несколько условий:
- включить флаг снимка экрана в getUserMedia() в chrome://flags/,chrome://flags/;
- исходный файл должен быть загружен по HTTPS (SSL origin);
- аудиопоток не должен запрашиваться;
- не должно выполняться несколько запросов в одной закладке браузера.
Хотя WebRTC еще и не закончен, уже появилось несколько базирующихся на нем библиотек. JsSIP предназначена для создания браузерных софтфонов, работающих с SIP-коммутаторами, такими как Asterisk и Camalio. PeerJS упростит создание P2P-сетей для обмена данными, а Holla сократит объем разработки, необходимый для P2P-связи из браузеров.
Node.js и socket.ioДля того чтобы организовать обмен SDP и ICE-кандидатами между двумя RTCPeerConnection через сеть, используем Node.js с модулем socket.io.
Установка последней стабильной версии Node.js (для Debian/Ubuntu) описана
$ sudo apt-get install python-software-properties python g++ make $ sudo add-apt-repository ppa:chris-lea/node.js $ sudo apt-get update $ sudo apt-get install nodejs
Установка под другие операционные системы описана
Проверим:
$ echo "sys=require("util"); sys.puts("Test message");" > nodetest1.js $ nodejs nodetest1.js
С помощью npm (Node Package Manager) установим socket.io и дополнительный модуль express:
$ npm install socket.io express
Проверим, создав файл nodetest2.js для серверной части:
$ nano nodetest2.js var app = require("express")() , server = require("http").createServer(app) , io = require("socket.io").listen(server); server.listen(80); // Если порт 80 свободен app.get("/", function (req, res) { // При обращении к корневой странице res.sendfile(__dirname + "/nodetest2.html"); // отдадим HTML-файл }); io.sockets.on("connection", function (socket) { // При подключении socket.emit("server event", { hello: "world" }); // отправим сообщение socket.on("client event", function (data) { // и объявим обработчик события при поступлении сообщения от клиента console.log(data); }); });
И nodetest2.html для клиентской части:
$ nano nodetest2.html var socket = io.connect("/"); // URL сервера веб-сокетов (корневая страница сервера, с которого была загружена страница) socket.on("server event", function (data) { console.log(data); socket.emit("client event", { "name": "value" }); });
Запустим сервер:
$ sudo nodejs nodetest2.js
и откроем страницу http://localhost:80 (если запущен локально на 80-м порту) в браузере. Если все успешно, в консоли JavaScript браузера мы увидим обмен событиями между браузером и сервером при подключении.
Обмен информацией между RTCPeerConnection через веб-сокеты Клиентская частьСохраним наш основной пример (rtcdemo3.html) под новым именем rtcdemo4.html. Подключим в элементе библиотеку socket.io:
И в начале сценария JavaScript - подключение к веб-сокетам:
Var socket = io.connect("http://localhost");
Заменим прямой вызов функций другого участника отправкой ему сообщения через веб-сокеты:
Function createOffer_success(desc) { ... // pc2_receivedOffer(desc); socket.emit("offer", desc); ... } function pc2_createAnswer_success(desc) { ... // pc1.setRemoteDescription(desc); socket.emit("answer", desc); } function pc1_onicecandidate(event) { ... // pc2.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice1", event.candidate); ... } function pc2_onicecandidate(event) { ... // pc1.addIceCandidate(new RTCIceCandidate(event.candidate)); socket.emit("ice2", event.candidate); ... }
В функции hangup() вместо прямого вызова функций второго участника передадим сообщение через веб-сокеты:
Function btnHangupClick() { ... // remoteVideo2.src = ""; pc2.close(); pc2 = null; socket.emit("hangup", {}); }
И добавим обработчики получения сообщения:
Socket.on("offer", function (data) { console.log("socket.on("offer"):", data); pc2_receivedOffer(data); }); socket.on("answer", function (data) {е console.log("socket.on("answer"):", data); pc1.setRemoteDescription(new RTCSessionDescription(data)); }); socket.on("ice1", function (data) { console.log("socket.on("ice1"):", data); pc2.addIceCandidate(new RTCIceCandidate(data)); }); socket.on("ice2", function (data) { console.log("socket.on("ice2"):", data); pc1.addIceCandidate(new RTCIceCandidate(data)); }); socket.on("hangup", function (data) { console.log("socket.on("hangup"):", data); remoteVideo2.src = ""; pc2.close(); pc2 = null; });
Серверная частьНа серверной стороне сохраним файл nodetest2 под новым именем rtctest4.js и внутри функции io.sockets.on("connection", function (socket) { ... } добавим прием и отправку сообщений клиентов:
Socket.on("offer", function (data) { // При получении сообщения "offer", // так как клиентское соединение в данном примере всего одно, // отправим сообщение обратно через тот же сокет socket.emit("offer", data); // Если бы было необходимо переслать сообщение по всем соединениям, // кроме отправителя: // soket.broadcast.emit("offer", data); }); socket.on("answer", function (data) { socket.emit("answer", data); }); socket.on("ice1", function (data) { socket.emit("ice1", data); }); socket.on("ice2", function (data) { socket.emit("ice2", data); }); socket.on("hangup", function (data) { socket.emit("hangup", data); });
Кроме этого, изменим имя HTML-файла:
// res.sendfile(__dirname + "/nodetest2.html"); // Отдадим HTML-файл res.sendfile(__dirname + "/rtctest4.html");
Запуск сервера:
$ sudo nodejs nodetest2.js
Несмотря на то что код обоих клиентов выполняется в пределах одной и той же закладки браузера, все взаимодействие между участниками в нашем примере полностью осуществляется через сеть и «разнести» участников уже не требует особых сложностей. Впрочем, то, что мы делали, тоже было очень простым - эти технологии и хороши своей простотой в использовании. Пусть иногда и обманчивой. В частности, не будем забывать, что без STUN/TURN-серверов наш пример не сможет работать в присутствии трансляции адресов и сетевых экранов.
ЗаключениеПолучившийся пример очень условен, но если немного универсализировать обработчики событий, чтобы они не различались у вызывающей и вызываемой стороны, вместо двух объектов pc1 и pc2 сделать массив RTCPeerConnection и реализовать динамическое создание и удаление элементов ,то получится вполне пригодный для использования видеочат. В этом уже нет особой специфики, связанной с WebRTC, и пример простейшего видеочата на несколько участников (как и тексты всех примеров статьи) есть на диске, идущем с журналом. Впрочем, и в интернете можно найти уже немало хороших примеров. В частности, при подготовке статьи использовались: simpl.info getUserMedia , simpl.info RTCPeerConnection ,WebRTC Reference App .
Можно предположить, что совсем скоро благодаря WebRTC произойдет переворот не только в нашем представлении о голосовой и видеосвязи, но и в том, как мы воспринимаем интернет в целом. WebRTC позиционируется не только как технология для звонков из браузера в браузер, но и как технология коммуникаций реального времени. Видеосвязь, которую мы разобрали, лишь небольшая часть возможных вариантов его использования. Уже есть примеры трансляции экрана (скриншаринга) , и совместной работы , и даже P2P-сеть доставки контента на основе браузеров с помощью RTCDataChannel.
На сегодняшний день WebRTC является «горячей» технологией для потокового аудио и видео в браузерах. Консервативные технологии, такие как HTTP Streaming и Flash, больше подходят для раздачи записанного контента (video on demand) и существенно уступают WebRTC в плане реалтайма и онлайн трансляций, т.е. там, где требуется минимальная задержка видео, позволяющая зрителям видеть то, что происходит «в прямом эфире».
Возможность качественной коммуникации в реальном времени происходит от самой архитектуры WebRTC, где для транспорта видеопотоков используется UDP протокол, являющийся стандартной основой для передачи видео с минимальными задержками и широко использующийся в коммуникационных системах реального времени.
Коммуникационная задержка важна в системах онлайн трансляций, вебинарах и других приложениях, где требуется интерактивная связь с источником видео, конечных пользователей и требует решения.
Другая весомая причина попробовать WebRTC — это, безусловно, тренд. Сегодня каждый Android Chrome браузер поддерживает эту технологию, что гарантирует миллионы устройств, готовых к просмотру трансляции без установки какого-либо дополнительного ПО и конфигураций.
Для того, чтобы проверить технологию WebRTC в деле и запустить на ней простую онлайн трансляцию, мы использовали серверное ПО Flashphoner WebRTC Media & Broadcasting Server. В фичах заявлена возможность транслировать WebRTC потоки в режиме «один ко многим» (one-to-many), а так же поддержка IP камер и систем видеонаблюдения через RTSP протокол; в настоящем обзоре мы сосредоточимся на web-web трансляциях и их особенностях.
Установка WebRTC Media & Broadcasting ServerПоскольку для Windows системы версии сервера не оказалось, а устанавливать виртуалку типа VMWare+Linux не хотелось, протестировать онлайн трансляции на домашнем Windows компьютере не получилось. Чтобы сэкономить время решили взять инстанс на облачном хостинге вроде такого:
Это был Centos x86_64 версии 6.5 без какого- либо предустановленного ПО в датацентре Амстердама. Таким образом, все, что мы получили в распоряжение, — это сервер и ssh доступ к нему. Для тех, кто знаком с консольными командами Linux, установка WebRTC сервера обещает пройти просто и безболезненно. Итак, что мы сделали:
1. Скачать архив:
$wget https://сайт/download-wcs5-server.tar.gz
2. Распаковать:
$tar -xzf download-wcs5-server.tar.gz
3. Установить:
$cd FlashphonerWebCallServer
Во время инсталляции ввевсти IP адрес сервера: XXX.XXX.XXX.XXX
4. Активировать лицензию:
$cd /usr/local/FlashphonerWebCallServer/bin
$./activation.sh
5. Запустить WCS сервер:
$service webcallserver start
6. Проверить лог:
$tail - f /usr/local/FlashphonerWebCallServer/logs/flashphoner_manager.log
7. Проверить, что два процесса на месте:
$ps aux | grep Flashphoner
Процесс установки закончен.
Тестирование WebRTC онлайн-трансляцийТестирование трансляций оказалось делом нехитрым. В дополнение к серверу есть web-клиент, который состоит из десятка Javascript, HTML и CSS файлов и был развернут нами в папку /var/www/html на этапе установки. Единственное, что пришлось сделать, это вписать IP адрес сервера в конфиг flashphoner.xml, чтобы web-клиент мог установить соединение с сервером по HTML5 Websockets. Опишем процесс тестирования.
1. Открываем страницу тестового клиента index.html в Chrome браузере:
2.
Для того чтобы начать трансляцию, нужно нажать кнопку «Start» посередине экрана.
Перед тем как это сделать, необходимо убедиться что веб-камера подключена и готова к работе. Особых требований к вебкамере нет, мы, например, использовали стандартную встроенную в ноутбук камеру с разрешением 1280×800.
Chrome браузер обязательно попросит доступ к камере и микрофону для того чтобы пользователь понимал, что его видео будет отправлено на Интернет-сервер и разрешил это сделать.
3. Интерфейс представляет собой успешную трансляцию видеопотока с камеры на WebRTC сервер. В правом верхнем углу индикатор указывает, что поток уходит на сервер, в нижнем углу кнопка «Стоп» для остановки отправки видео.
Обратите внимание на ссылку в поле снизу. Она содержит уникальный идентификатор этого потока, так любой желающий может присоединиться к просмотру. Достаточно открыть эту ссылку в браузере. Чтобы ее скопировать в буфер обмена нужно кликнуть по кнопке «Copy».
В реальных приложениях вроде вебинаров, лекций, онлайн видео трансляций или интерактивного TV разработчикам придется реализовывать раздачу этого идентификатора определенным группам зрителей для того, чтобы они смогли подключиться к нужным потокам, но это уже логика работы приложения. WebRTC Media & Broadcasting Server ее не затрагивает, а занимается только раздачей видео.
5. Соединение установлено и зритель видит поток на экране. Теперь он может отправить ссылку кому-то другому, остановить воспроизведение потока либо включить полноэкранный режим, пользуясь контролами в правом нижем углу.
Во время тестов задержка выглядела идеальной. Пинг до датацентра составил около 100 миллисекунд и задержка была не различима глазом. Отсюда, можно предположить, что реальная задержка составляет те же 100 плюс минус несколько десятков миллисекунд на время буферизации. Если сравнивать с Flash видео: в подобных тестах Flash ведет себя не так хорошо, как WebRTC. Так, если на схожей сети шевельнуть рукой, то движение на экране можно увидеть только через одну/две секунды.
Относительно качества отметим, что на движениях иногда можно различить кубики. Это соответствует природе кодека VP8 и его основной задаче — обеспечить видео связь в реальном времени с приемлемым качеством и без задержек в коммуникации.
Сервер достаточно прост в установке и настройке, для его запуска не требуется каких-либо серьезных навыков кроме знания Linux на уровне продвинутого пользователя, умеющего выполнять команды из консоли через ssh и пользоваться текстовым редактором. В итоге нам удалось наладить онлайн трансляцию one-to-many между браузерами. Подключение дополнительных зрителей к потоку также не вызвало проблем.
Качество трансляции оказалось вполне приемлемым для вебинаров и онлайн вещаний. Единственное, что вызвало некоторые вопросы, — это разрешение видео. Камера поддерживает 1280×800, но разрешение на тестовой картинке очень похоже на 640×480. Видимо, этот вопрос нужно уточнять у разработчиков.
Видео по тестированию трансляции с веб-камерычерез WebRTC-сервер
Цель этой статьи - на демонстрационном образце пирингового видеочата (p2p видеочата) ознакомиться с его структурой и принципом работы. Для этой цели воспользуемся многопользовательским демонстрационным образцом пирингового видеочата webrtc.io-demo. Его можно скачать по ссылке: https://github.com/webRTC/webrtc.io-demo/tree/master/site .
Необходимо отметить, что GitHub - это сайт или веб-сервис для совместной разработки Web-проектов. На нем разработчики могут размещать коды своих разработок, обсуждать их и общаться друг с другом. Кроме того, некоторые крупные IT-компании размещают свои официальные репозитории на этом сайте. Сервис является бесплатным для проектов с открытым исходным кодом. GitHub - это хранилище библиотек открытого, свободного исходного кода.
Итак, скачанный с GitHub демонстрационный образец пирингового видеочата, разместим на диске C персонального компьютера в созданной директории для нашего приложения "webrtc_demo".
Рис. 1
Как следует из структуры (рис.1) пиринговый видеочат состоит из клиентского script.js и серверного server.js скриптов, реализованных на языке программирования JavaScript. Скрипт (библиотека) webrtc.io.js (CLIENT) - обеспечивает организацию коммуникаций в реальном времени между браузерами по одноранговой схеме: "клиент-клиент", а webrtc.io.js (CLIENT) и webrtc.io.js (SERVER), используя протокол WebSocket, обеспечивают дуплексную связь между браузером и веб-сервером по архитектуре "клиент-сервер".
Скрипт webrtc.io.js (SERVER) входит в библиотеку webrtc.io и находится в директории node_modules\webrtc.io\lib. Интерфейс видеочата index.html реализован на HTML5 и CSS3. Содержимое файлов приложения webrtc_demo можно посмотреть одним из html-редакторов, например "Notepad++".
Принцип работы видеочата будем проверять в файловой системе ПК. Для запуска сервера (server.js) на ПК необходимо установить среду выполнения node.js. Node.js позволяет запускать JavaScript-код вне браузера. Скачать node.js можно по ссылке: http://nodejs.org/ (версия v0.10.13 на 15.07.13). На главной страничке сайта node.org щелкаем на кнопке download и переходим на http://nodejs.org/download/. Для пользователей windows сначала скачиваем win.installer (.msi), затем запускаем win.installer (.msi) на ПК, и устанавливаем nodejs и "npm package manager" в директорию Program Files.
Рис. 2
Таким образом, node.js состоит из среды разработки и выполнения JavaScript кода, а также из набора внутренних модулей, которые можно установить с помощью менеджера или диспетчера пакетов npm.
Для установки модулей необходимо в командной строке из директории приложения (например, "webrtc_demo") выполнить команду: npm install имя_модуля . В процессе установки модулей npm-менеджер создает папку node_modules в директории, из которой была выполнена установка. В процессе работы nodejs автоматически подключает модули из директории node_modules.
Итак, после установки node.js, открываем командную строку и обновим модуль express в папке node_modules директории webrtc_demo с помощью менеджера пакетов npm:
C:\webrtc_demo>npm install express
Модуль express - это веб-фреймворк для node.js или веб-платформа для разработки приложений. Чтобы иметь глобальный доступ к express, можно установить его таким образом: npm install -g express .
Затем обновим модуль webrtc.io:
C:\webrtc_demo>npm install webrtc.io
Затем в командной строке запускаем сервер: server.js:
C:\webrtc_demo>node server.js
Рис. 3
Все, сервер работает успешно (рисунок 3). Теперь с помощью веб-браузера можно обратиться к серверу по ip-адресу и загрузить веб-страницу index.html, с которой веб-браузер будет извлекать код клиентского скрипта - script.js и код скрипта webrtc.io.js, и выполнять их. Для работы пирингового видеочата (для установки соединения между двумя браузерами) необходимо с двух браузеров, поддерживающих webrtc, обратиться по ip-адресу к сигнальному серверу, работающему на node.js.
В результате откроется интерфейс клиентской части коммуникационного приложения (видеочата) с запросом на разрешение доступа к камере и микрофону (рис. 4).
Рис. 4
После щелчка на кнопке "Разрешить" подключаются камера и микрофон для мультимедийное общения. Кроме того, через интерфейс видеочата можно общаться текстовыми данными (рис. 5).
Рис. 5
Необходимо отметить, что . Сервер является сигнальным, и в основном предназначен для установки соединения между браузерами пользователей. Для работы серверного скрипта server.js, обеспечивающего WebRTC-сигнализацию, используется Node.js.
Преамбула. P2P видеочат на базе WebRTC - это альтернатива Skype и другим средствам связи. Основными элементами p2p видеочата на базе WebRTC является браузер и контактный сервер. P2P видеочаты - это пиринговые видеочаты, в которых сервер не принимает участия в передаче информационных потоков. Информация передается непосредственно между браузерами пользователей (пирингами) без каких-либо дополнительных программ. Кроме браузеров в p2p видеочатах используются контактные серверы, которые предназначены для регистрации пользователей, хранения данных о них и обеспечения коммутации между пользователями. Браузеры, которые поддерживают новейшие технологии WebRTC и HTML5, обеспечивают передачу мгновенных текстовых сообщений и файлов, а также обеспечивают голосовое и видео общение в IP сетях.
Итак, чаты, веб чаты, голосовые и видеочаты в веб интерфейсе, IMS, VoIP - это сервисы, которые обеспечивают коммуникации в режиме онлайн через составные сети с пакетной коммутацией. Как правило, коммуникационные сервисы требуют или установки клиентских приложений на пользовательские устройства (ПК, смартфоны и т.д.), или установки плагинов и расширений в браузеры. Сервисы имеют свои коммуникационные сети, большинство из которых построены по архитектуре "клиент-сервер".
Коммуникационные сервисы являются приложениями, за исключением IMS, в которых каналы передачи голоса, видео, данных и текста не интегрированы. В сетях каждого сервиса применяются . Необходимо отметить, что указанные приложения не могут одновременно работать в нескольких коммуникационных сетях, т.е. приложения, как правило, не могут взаимодействовать между собой, в результате чего для каждой коммуникационной сети необходимо устанавливать отдельное приложение.
Проблему интеграции коммуникационных услуг реального времени (чата, телефонии, видеоконференции), т.е. интеграцию каналов передачи голоса, видео, данных и доступ к ним с помощью одного приложения (браузера) можно решить в одноранговых или p2p видеочатах (пиринговых, point - to - point) на основе протокола WebRTC . По сути, браузер, поддерживающий WebRTC, становится единым интерфейсом для всех пользовательских устройств (ПК, смартфонов, айпадов, IP-телефонов, мобильных телефонов и т.д.), которые работают с коммуникационными сервисами.
Именно WebRTC обеспечивает реализацию в браузере всех технологий, обеспечивающих коммуникации реального времени. Суть p2p видеочатов заключается в том, что мультимедийные и текстовые данные передаются непосредственно между браузерами пользователей (удаленными пирингами) без участия сервера и дополнительных программ. Таким образом, браузеры не только обеспечивают доступ практически ко всем информационным ресурсам Интернет, которые хранятся на серверах, но и становятся средством доступа ко всем коммуникационным услугам реального времени и к почтовым услугам (голосовой почте, электронной почте, SMS и т.д.)
Серверы (контактные серверы) p2p видеочатов предназначены только для регистрации пользователей, хранения данных о пользователях и установки соединения (коммутации) между браузерами пользователей. Первые p2p видеочаты были реализованы с применением flash технологий. Flash p2p видеочаты применяются, например, в социальных сетях. Flash p2p видеочаты не обеспечивают высокое качество передачи мультимедийных данных. Кроме того, для вывода голоса и видеопотока из микрофона и видеокамеры в p2p flash видеочатах необходима установка flash плагина в веб-браузер.
Но к телекоммуникационным сервисам нового поколения относятся веб-коммуникации , которые для общения через Интернет используют только браузеры и контактные серверы , поддерживающие протоколы WebRTC и спецификацию HTML5 . Любое пользовательское устройство (ПК, iPad, смартфоны и т.д.), снабженное таким браузером, может обеспечить качественные голосовые и видеозвонки, а также передачу мгновенных текстовых сообщений и файлов.
Итак, новой технологией веб-коммуникаций (p2p чатов, видеочатов) является протокол WebRTC. WebRTC совместно с HTML5, CSS3 и JavaScript позволяют создавать различные веб приложения. WebRT предназначен для организации веб-коммуникаций (пиринговых сетей) в реальном времени по одноранговой архитектуре. P2P чаты на основе WebRTC обеспечивают передачу файлов, а также текстовые, голосовые и видео общения пользователей через Интернет с использованием только веб-браузеров без применения внешних дополнений и плагинов в браузере.
В p2p чатах сервер используется только для установки p2p соединения между двумя браузерами. Для создания клиентской части p2p чата на базе протокола WebRTC используют HTML5, CSS3 и JavaScript. Клиентское приложение взаимодействует с браузерами через API WebRTC.
WebRTC реализуются тремя JavaScript API:
- RTCPeerConnection;
- MediaStream (getUserMedia);
- RTCDataChannel.
Браузеры передают мультимедийные данные по протоколу SRTP, который работает поверх UDP. Поскольку NAT создает проблемы для браузеров (клиентов), находящихся за маршрутизаторами NAT, которые используют p2p соединения через сеть Интернет, то для обхода NAT трансляторов используется STUN. STUN - это клиент-серверный протокол, который работает поверх транспортного протокола UDP. В p2p чатах, как правило, применяется публичный STUN-сервер, а полученная с него информация используется для UDP-соединения между двумя браузерами, если они находятся за NAT.
Примеры реализации WebRTC приложений (p2p чатов, голосовых и видео веб чатов):
1. P2P видеочат Bistri (one-click video chat, p2p чат), выполненный на основе WebRTC, можно открыть на Bistri. Bistri работает в браузере без установки дополнительных программ и плагинов. Суть работы состоит в следующем: откройте p2p видеочат по указанной ссылке, после регистрации в открывшемся интерфейсе пригласите партнеров, затем из списка peer-клиентов выберите того партнера, который находится в сети и щелкните на кнопке "видеовызов".
В результате MediaStream (getUserMedia) выполнит захват микрофона + веб-камеры, а сервер выполнит обмен сигнальными сообщениями с выбранным партнером. После обмена сигнальными сообщениями PeerConnection API создает каналы для передачи голосового и видео потоков. Кроме того, Bistri осуществляет передачу мгновенных текстовых сообщений и файлов. На рис. 1 представлен скриншот интерфейса p2p видеочата Bistri.
Рис. 1. P2P видеочат Bistri
2. Twelephone (p2p видеочат, p2p чат, SIP Twelephone) - это клиентское приложение построено на базе HTML5 и WebRTC, которое позволяет совершать голосовые и видеозвонки, а также осуществлять передачу мгновенных текстовых сообщений, т.е. Twelephone включает тестовый p2p чат, видеочат и SIP Twelephone. Необходимо отметить, что Twelephone поддерживает протокол SIP и теперь можно совершать и принимать голосовые и видеозвонки с SIP-телефонов, используя свой аккаунт в Twitter, как номер телефона. Кроме того, текстовые сообщения можно вводить голосом через микрофон, а программа распознавания голоса вводит текст в строку "Send a message".
Twelephone - это веб телефония, которая функционирует на основе браузера Google Chrome, начиная с версии 25, без дополнительного программного обеспечения. Twelephone был разработан Chris Matthieu. Серверная часть Twelephone построена на основе Node.js. Сервер (контактный сервер) используется только для установки p2p соединения между двумя браузерами или WebRTC клиентами. Приложение Twelephone не имеет собственных средств авторизации, а ориентировано на подключение к аккаунту (учетной записи) в Twitter.
На рис. 2 представлен скриншот интерфейса p2p видеочата Twelephone.
Рис. 2. P2P Twelephone
3. Групповой p2p видеочат Conversat.io построен на основе новейших технологий WebRTC и HTML5. Видеочат Conversat разработан на основе библиотеки SimpleWebRTC и предназначен для общения до 6 peer-клиентов в одной комнате (для общения укажите название общей комнаты для peer-клиентов в строке "Name the conversation"). P2P видеочат Conversat предоставляет коммуникационные услуги пользователям без регистрации на контактном сервере. На рис. 3 представлен скриншот интерфейса p2p видеочата Conversat.
Рис. 3. Групповой P2P видеочат Conversat.io
Для участия в P2P видеочатах на базе WebRTC необходимо чтобы у пользователей был установлен браузер, поддерживающий протокол WebRTC и спецификацию HTML5. В настоящее время браузеры Google Chrome, начиная с версии 25, и Mozilla Firefox Nightly поддерживают протокол WebRTC и спецификацию HTML5. WebRTC приложения по качеству передачи изображения и звука превосходят Flash приложения.
WebRTC (Web Real-Time Communications) - это технология, которая позволяет Web-приложениям и сайтам захватывать и выборочно передавать аудио и/или видео медиа-потоки, а также обмениваться произвольными данными между браузерами, без обязательного использования посредников. Набор стандартов, которые включает в себя технология WebRTC, позволяет обмениваться данными и проводить пиринговые телеконференции, без необходимости пользователю устанавливать плагины или любое другое стороннее программное обеспечение.
WebRTC состоит из нескольких взаимосвязанных программных интерфейсов (API) и протоколов, которые работают вместе. Документация, которую вы здесь найдете, поможет вам понять основы WebRTC, как настроить и использовать соединение для передачи данных и медиа-потока, и многое другое.
СовместимостьПоскольку, реализация WebRTC находиться в процессе становления и каждый браузер имеет и WebRTC функций, настоятельно рекомендуем использовать полифил-библиотеку Adapter.js , от Google, до начала работы над вашим кодом.
Adapter.js использует клинья и полифилы для гладкой стыковки различий в реализациях WebRTC среди контекстов, его поддерживающих. Adapter.js также обрабатывает префиксы производителей, и иные различия именования свойств, облегчая процесс разработки на WebRTC, с наиболее совместимым результатом. Библиотека так же доступна как NPM пакет .
Для дальнейшего изучения библиотеки Adapter.js, смотрим .
Понятия и использование WebRTCWebRTC является многоцелевым и вместе с , предоставляют мощные мультимедийные возможности для 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. Это руководство описывает как вы можете использовать соединение узел-узел и связанный