Начало работы с WebRTC

  1. Общение в реальном времени без плагинов
  2. Быстрый старт
  3. Очень короткая история WebRTC
  4. Где мы сейчас?
  5. Мой первый WebRTC
  6. Ограничения
  7. Захват экрана и вкладок
  8. Сигнализация: управление сеансом, информация о сети и медиа
  9. RTCPeerConnection
  10. RTCPeerConnection без серверов
  11. гость
  12. вызываемый абонент
  13. RTCPeerConnection plus серверы
  14. Простой клиент видеочата
  15. Сетевые топологии
  16. RTCDataChannel
  17. Безопасность
  18. В заключение
  19. Учить больше

WebRTC - это новый фронт в долгой войне за открытую и необремененную сеть. Брендан Эйх , изобретатель JavaScript

Общение в реальном времени без плагинов

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

Хотите попробовать это? WebRTC теперь доступен в Google Chrome, Safari, Firefox и Opera, для ПК и мобильных устройств. Хорошее место для начала - простое приложение для видеочата на appr.tc :

  1. открыто appr.tc в вашем браузере.
  2. Нажмите кнопку «Присоединиться», чтобы присоединиться к чат-комнате и позволить приложению использовать вашу веб-камеру.
  3. Откройте URL-адрес, отображаемый внизу страницы, в новой вкладке или, что еще лучше, на другом компьютере.

Быстрый старт

У вас нет времени, чтобы прочитать эту статью, или просто хотите код?

  1. Получите обзор WebRTC из презентации ввода / вывода Google (слайды Вот ):

  2. Если вы не использовали getUserMedia, взгляните на HTML5 Rocks статья и посмотрите источник для простого примера на simpl.info/gum ,
  3. Познакомьтесь с API RTCPeerConnection, прочитав пример ниже и демо в simpl.info/pc , который реализует WebRTC на одной веб-странице.
  4. Узнайте больше о том, как WebRTC использует серверы для сигнализации и прохождения брандмауэра и NAT, читая код и журналы консоли из appr.tc ,
  5. Не можете дождаться и просто хотите попробовать WebRTC прямо сейчас? Попробуйте некоторые из 20+ демо которые осуществляют JavaScript API WebRTC.
  6. Возникли проблемы с вашей машиной и WebRTC? Попробуйте нашу страницу устранения неполадок test.webrtc.org ,

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

Очень короткая история WebRTC

Одной из последних серьезных проблем в Интернете является обеспечение человеческого общения с помощью голоса и видео: связь в реальном времени, RTC для краткости. RTC должен быть таким же естественным для веб-приложения, как и ввод текста при вводе текста. Без этого мы ограничены в наших возможностях вводить новшества и разрабатывать новые способы взаимодействия людей.

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

Видеочат Gmail стал популярным в 2008 году, а в 2011 году Google представила Hangouts, которые используют сервис Google Talk (как и Gmail). Google купил GIPS, компанию, которая разработала множество компонентов, необходимых для RTC, таких как кодеки и методы эхоподавления. Google open source использовал технологии, разработанные GIPS и взаимодействующие с соответствующими органами по стандартизации в IETF и W3C для обеспечения консенсуса в отрасли. В мае 2011 года Эрикссон построил первая реализация WebRTC ,

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

  • Многие веб-сервисы использовали RTC, но требовали загрузки, нативных приложений или плагинов. В их числе Skype, Facebook и Google Hangouts.
  • Загрузка, установка и обновление плагинов сложна, подвержена ошибкам и раздражает.
  • Плагины сложны в развертывании, отладке, устранении неполадок, тестировании и обслуживании, и могут потребовать лицензирования и интеграции со сложной дорогой технологией. Часто трудно убедить людей устанавливать плагины в первую очередь!

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

Где мы сейчас?

WebRTC используется в различных приложениях, таких как WhatsApp, Facebook Messenger, emerge.in и платформах, таких как TokBox. WebRTC также был интегрирован с WebKitGTK + а также Qt родные приложения.

WebRTC реализует три API:

API определены в двух спецификациях:

Все три API поддерживаются на мобильных устройствах и компьютерах Chrome, Safari, Firefox, Edge и Opera.

getUserMedia : Посмотреть демонстрации и код на webrtc.github.io/samples или попробовать Крис Уилсон удивительные примеры которые используют getUserMedia в качестве входных данных для Web Audio.

RTCPeerConnection : очень простая демонстрация на webrtc.github.io/samples и полнофункциональное приложение для видео чата на appr.tc , Это приложение использует adapter.js JavaScript, поддерживается Google с помощью Сообщество WebRTC , чтобы абстрагироваться от различий браузера и изменения спецификации.

RTCDataChannel : посмотрите одну из демонстраций канала данных на webrtc.github.io/samples чтобы увидеть это в действии.

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

Мой первый WebRTC

Приложения WebRTC должны делать несколько вещей:

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

Для получения и передачи потоковых данных WebRTC реализует следующие API:

  • MediaStream : получить доступ к потокам данных, например, с камеры пользователя и микрофона.
  • RTCPeerConnection : аудио- или видеозвонки со средствами шифрования и управления полосой пропускания.
  • RTCDataChannel : одноранговая передача общих данных.

(Подробное обсуждение сетевых и сигнальных аспектов WebRTC ниже .)

MediaStream API представляет синхронизированные потоки медиа. Например, поток, взятый с входа камеры и микрофона, имеет синхронизированные видео и аудио дорожки. (Не путайте MediaStreamTrack с элементом <track>, который является чем-то совершенно другой .)

Вероятно, самый простой способ понять MediaStream - это посмотреть на него в дикой природе:

  1. В вашем браузере откройте демо на webrtc.github.io/samples/src/content/getusermedia/gum ,
  2. Откройте консоль.
  3. Проверьте переменную потока, которая находится в глобальной области видимости.

Каждый MediaStream имеет вход, который может быть MediaStream, сгенерированным getUserMedia (), и выход, который может быть передан элементу видео или RTCPeerConnection.

Метод getUserMedia () принимает MediaStreamConstraints объект параметр и возвращает Promise, который разрешается в объект MediaStream.

Каждый MediaStream имеет метку, например «Xk7EuLhsuHKbnjLWkW4yYGNJJ8ONsgwHBvLQ». Массив MediaStreamTracks возвращается методами getAudioTracks () и getVideoTracks ().

Для webrtc.github.io/samples/src/content/getusermedia/gum Например, stream.getAudioTracks () возвращает пустой массив (потому что нет звука) и, предполагая, что подключена рабочая веб-камера, stream.getVideoTracks () возвращает массив из одного MediaStreamTrack, представляющего поток с веб-камеры. Каждый MediaStreamTrack имеет вид («видео» или «аудио») и метку (что-то вроде «HD-камера FaceTime (встроенная)») и представляет один или несколько каналов аудио или видео. В этом случае есть только одна видеодорожка и нет звука, но легко представить себе случаи, когда их больше: например, приложение чата, которое получает потоки с передней камеры, задней камеры, микрофона и общего экрана. ' приложение.

MediaStream может быть присоединен к элементу видео, установив атрибут srcObject. , Ранее это было сделано путем установки атрибута src для URL объекта, созданного с помощью URL.createObjectURL (), но это устарело ,

MediaStreamTrack активно использует камеру, которая берет ресурсы и держит камеру открытой (и свет камеры включен). Если вы больше не используете трек, обязательно вызовите track.stop (), чтобы камеру можно было закрыть.

getUserMedia также может быть использован в качестве узла ввода для API Web Audio :

// справляемся с различиями браузера let audioContext; if (typeof AudioContext === 'function') {audioContext = new AudioContext (); } else if (typeof webkitAudioContext === 'function') {audioContext = new webkitAudioContext (); // eslint-disable-line new-cap} else {console.log ('Извините! Веб-аудио не поддерживается.'); } // создаем узел фильтра var filterNode = audioContext.createBiquadFilter (); // см. https://dvcs.w3.org/hg/audio/raw-file/tip/webaudio/specification.html#BiquadFilterNode-section filterNode.type = 'highpass'; // частота среза: для верхних частот звук ослабляется ниже этой частоты filterNode.frequency.value = 10000; // создаем узел усиления (для изменения громкости звука) var gainNode = audioContext.createGain (); // по умолчанию 1 (без изменений); меньше 1 означает, что звук ослаблен // и наоборот gainNode.gain.value = 0.5; navigator.mediaDevices.getUserMedia ({audio: true}, (stream) => {// Создать AudioNode из потока const mediaStreamSource = audioContext.createMediaStreamSource (stream); mediaStreamSource.connect (filterNode); filterNode.connect (gainNode); // подключаем узел усиления к месту назначения (т.е. воспроизводим звук) gainNode.connect (audioContext.destination);});

Приложения и расширения на основе Chromium могут также включать getUserMedia. Добавление audioCapture и / или videoCapture разрешений к манифесту позволяет запрашивать разрешение и предоставлять только один раз, при установке. После этого у пользователя не запрашивается разрешение на доступ к камере или микрофону.

Разрешение должно быть предоставлено только один раз для getUserMedia (). В первый раз, кнопка Разрешить отображается в браузере Infobar , HTTP-доступ для getUserMedia () был объявлен устаревшим в Chrome в конце 2015 года, поскольку он был классифицирован как Мощная функция ,

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

getUserMedia () действительно оживает в сочетании с другими API и библиотеками JavaScript:

  • Веб-камера Игрушка это приложение для фотобудки, которое использует WebGL для добавления странных и замечательных эффектов к фотографиям, которыми можно поделиться или сохранить локально.
  • FaceKat это игра "отслеживание лица", построенная с headtrackr.js ,
  • Камера ASCII использует API Canvas для генерации ASCII-изображений.

ГУМ ASCII искусство!

Ограничения

Ограничения может использоваться для установки значений разрешения видео для getUserMedia (). Это также позволяет поддержка других ограничений такие как соотношение сторон, режим облицовки (передняя или задняя камера), частота кадров, высота и ширина, а также Метод applyConstraints () ,

Есть пример на webrtc.github.io/samples/src/content/getusermedia/resolution ,

Одна проблема: ограничения getUserMedia могут влиять на доступные конфигурации общего ресурса. Например, если камера была открыта в режиме 640x480 одной вкладкой, другая вкладка не сможет использовать ограничения, чтобы открыть ее в режиме более высокого разрешения, поскольку ее можно открыть только в одном режиме. Обратите внимание, что это деталь реализации: можно было бы позволить второй вкладке повторно открыть камеру в режиме более высокого разрешения и использовать обработку видео, чтобы уменьшить масштаб видео дорожки до 640x480 для первой вкладки, но это не было реализовано.

Установка значения запрещенного ограничения дает DOMException или OverconstrainedError, если (например) запрашиваемое разрешение недоступно. Чтобы увидеть это в действии, попробуйте демо на webrtc.github.io/samples/src/content/getusermedia/resolution ,

Захват экрана и вкладок

Приложения Chrome также позволяют обмениваться «живым» видео с одной вкладки браузера или всего рабочего стола через chrome.tabCapture а также chrome.desktopCapture API-интерфейсы. (В статье об обновлении HTML5 Rocks есть демо и дополнительная информация Совместное использование экрана с WebRTC , Несколько лет, но все еще интересно.)

Также возможно использовать снимок экрана в качестве источника MediaStream в Chrome, используя экспериментальное ограничение chromeMediaSource, как в это демо , Обратите внимание, что для захвата экрана требуется HTTPS, и его следует использовать только для разработки, поскольку он включается с помощью флага командной строки, как описано в этом Discussion-Webrtc. сообщение ,

Сигнализация: управление сеансом, информация о сети и медиа

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

Вместо этого разработчики приложений WebRTC могут выбрать любой протокол обмена сообщениями, который они предпочитают, например, SIP или XMPP, и любой подходящий дуплексный (двусторонний) канал связи. appr.tc Пример использует XHR и Channel API в качестве механизма сигнализации. codelab мы создали использование Socket.io работает на Узловой сервер ,

Сигнализация используется для обмена тремя типами информации:

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

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

Например, представьте, что Алиса хочет общаться с Бобом. Вот пример кода из W3C WebRTC спецификация , который показывает процесс сигнализации в действии. Код предполагает существование некоторого механизма сигнализации, созданного в методе createSignalingChannel (). Также обратите внимание, что в Chrome и Opera RTCPeerConnection в настоящее время имеет префикс.

// обрабатывает JSON.stringify / parse const signaling = new SignalingChannel (); константные ограничения = {audio: true, video: true}; const configuration = {iceServers: [{urls: 'stuns: stun.example.org'}]}; const pc = новый RTCPeerConnection (конфигурация); // отправляем любые ледовые кандидаты другому пиру pc.onicecandidate = ({кандидат}) => signaling.send ({кандидат}); // разрешить генерацию предложения триггера события "gotiationneeded "pc.onnegotiationneeded = async () => {try {await pc.setLocalDescription (await pc.createOffer ()); // отправить предложение другому партнёру signaling.send ({desc: pc.localDescription}); } catch (err) {console.error (err); }}; // как только получится удаленный трек, покажите его в удаленном элементе видео pc.ontrack = (event) => {// больше не устанавливайте srcObject, если он уже установлен. if (remoteView.srcObject) return; remoteView.srcObject = event.streams [0]; }; // вызываем start () для запуска асинхронной функции start () {try {// получаем локальный поток, показываем его в режиме самообзора и добавляем его для отправки const stream = await navigator.mediaDevices.getUserMedia (constraints); stream.getTracks (). forEach ((track) => pc.addTrack (track, stream)); selfView.srcObject = stream; } catch (err) {console.error (err); }} signaling.onmessage = async ({desc ,андидат}) => {try {if (desc) {// если мы получим предложение, нам нужно ответить с ответом, если (desc.type === 'offer') ) {await pc.setRemoteDescription (desc); const stream = await navigator.mediaDevices.getUserMedia (ограничения); stream.getTracks (). forEach ((track) => pc.addTrack (track, stream)); await pc.setLocalDescription (await pc.createAnswer ()); signaling.send ({desc: pc.localDescription}); } else if (desc.type === 'answer') {await pc.setRemoteDescription (desc); } else {console.log ('Неподдерживаемый тип SDP.'); }} else if (кандидат) {ожидайте pc.addIceCandidate (кандидат); }} catch (err) {console.error (err); }};

Прежде всего, Алиса и Боб обмениваются информацией о сети. (Выражение «поиск кандидатов» относится к процессу поиска сетевых интерфейсов и портов с использованием ICE Framework .)

  1. Алиса создает объект RTCPeerConnection с обработчиком onicecandidate.
  2. Обработчик запускается, когда становятся доступными кандидаты в сеть.
  3. Алиса отправляет сериализованные данные кандидата Бобу через любой канал сигнализации, который они используют: WebSocket или какой-либо другой механизм.
  4. Когда Боб получает сообщение кандидата от Алисы, он вызывает addIceCandidate, чтобы добавить кандидата в описание удаленного партнера.

Клиенты WebRTC (известные как peers , также известные как Алиса и Боб) также должны выяснять и обмениваться локальной и удаленной аудио и видео информацией, такой как разрешение и возможности кодеков. Сигнализация для обмена информацией о конфигурации мультимедиа осуществляется путем обмена предложением и ответом с использованием протокола описания сеанса (SDP):

  1. Алиса запускает метод RTCPeerConnection createOffer (). Возвращение от этого этого передается RTCSessionDescription: локальное описание сеанса Алисы.
  2. В обратном вызове Алиса устанавливает локальное описание, используя setLocalDescription (), а затем отправляет это описание сеанса Бобу через их канал сигнализации. Обратите внимание, что RTCPeerConnection не начнет собирать кандидатов до тех пор, пока не будет вызвана setLocalDescription (): это кодируется в JSEP IETF проект ,
  3. Боб устанавливает описание, которое Алиса отправила ему в качестве удаленного описания, используя setRemoteDescription ().
  4. Боб запускает метод RTCPeerConnection createAnswer (), передавая ему удаленное описание, которое он получил от Алисы, чтобы можно было сгенерировать локальный сеанс, совместимый с ее. Обратному вызову createAnswer () передается RTCSessionDescription: Боб устанавливает это как локальное описание и отправляет его Алисе.
  5. Когда Алиса получает описание сеанса Боба, она устанавливает его как удаленное описание с помощью setRemoteDescription.
  6. Пинг!

Обязательно разрешите сбор мусора RTCPeerConnection, вызвав close (), когда он больше не нужен. В противном случае потоки и соединения остаются в живых. В WebRTC возможна утечка больших ресурсов!

Объекты RTCSessionDescription - это большие двоичные объекты, которые соответствуют Протокол описания сеанса , СДП. Сериализованный, объект SDP выглядит так:

v = 0 o = - 3883943731 1 IN IP4 127.0.0.1 s = t = 0 0 a = группа: BUNDLE аудио видео m = аудио 1 RTP / SAVPF 103 104 0 8 106 105 13 126 // ... a = ssrc: 2223794119 ярлык: H4fjnMzxy3dPIgQ7HxuCTLb4wLLLeRHnFxh810

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

Описанная выше архитектура предложения / ответа называется JSEP , Протокол установления сеанса JavaScript. (Там есть отличная анимация, объясняющая процесс передачи сигналов и потоков в Демо видео Эрикссон для его первой реализации WebRTC.)

)

Архитектура JSEP

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

RTCPeerConnection

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

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

Архитектура WebRTC (от webrtc.org )

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

  • сокрытие потери пакетов
  • эхоподавление
  • адаптивность полосы пропускания
  • динамическая буферизация джиттера
  • автоматическая регулировка усиления
  • шумоподавление и подавление
  • изображение «чистка».

Код W3C выше показывает упрощенный пример WebRTC с точки зрения сигнализации. Ниже приведены пошаговые инструкции двух работающих приложений WebRTC: первое - простой пример демонстрации RTCPeerConnection; второй - полностью работающий клиент видеочата.

RTCPeerConnection без серверов

Код ниже взят из демоверсии WebRTC «на одной странице» по адресу webrtc.github.io/samples/src/content/peerconnection/pc1 , который имеет локальный и удаленный RTCPeerConnection (и локальное и удаленное видео) на одной веб-странице. Это не представляет собой ничего очень полезного - вызывающий и вызываемый абоненты находятся на одной странице - но это немного упрощает работу API-интерфейса RTCPeerConnection, поскольку объекты RTCPeerConnection на странице могут напрямую обмениваться данными и сообщениями без необходимости использовать посредника. сигнальные механизмы.

В этом примере pc1 представляет локального участника (вызывающего), а pc2 представляет удаленного участника (вызываемого).

гость

  1. Создайте новый RTCPeerConnection и добавьте поток из getUserMedia ():

    // серверы - это необязательный файл конфигурации (см. обсуждение TURN и STUN ниже) pc1 = new RTCPeerConnection (servers); // ... localStream.getTracks (). forEach ((track) => {pc1.addTrack (track, localStream);});

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

    pc1.setLocalDescription (desc) .then (() => {onSetLocalSuccess (pc1);}, onSetSessionDescriptionError); trace ('pc2 setRemoteDescription start'); pc2.setRemoteDescription (desc) .then (() => {onSetRemoteSuccess (pc2);}, onSetSessionDescriptionError);

вызываемый абонент

  1. Создайте pc2 и при добавлении потока из pc1 отобразите его в элементе video:

    pc2 = новый RTCPeerConnection (серверы); pc2.ontrack = gotRemoteStream; // ... function gotRemoteStream (e) {vid2.srcObject = e.stream; }

RTCPeerConnection plus серверы

В реальном мире WebRTC нужны серверы, хотя и простые, поэтому может произойти следующее:

  • Пользователи обнаруживают друг друга и обмениваются деталями «реального мира», такими как имена.
  • Клиентские приложения (одноранговые) WebRTC обмениваются сетевой информацией.
  • Пэры обмениваются данными о медиа, таких как формат видео и разрешение.
  • Обход клиентских приложений WebRTC Шлюзы NAT и брандмауэры.

Другими словами, WebRTC требуется четыре типа серверных функций:

  • Обнаружение пользователей и общение.
  • Signaling.
  • NAT / обход брандмауэра.
  • Серверы ретрансляции в случае сбоя одноранговой связи.

Обход NAT, одноранговая сеть и требования к созданию серверного приложения для обнаружения пользователей и сигнализации выходят за рамки этой статьи. Достаточно сказать, что STUN протокол и его расширение ОЧЕРЕДЬ используются ICE фреймворк, позволяющий RTCPeerConnection справляться с обходом NAT и другими капризами сети.

ICE - это структура для соединения пиров, таких как два клиента видеочата. Первоначально ICE пытается напрямую подключиться к одноранговым узлам с минимальной задержкой через UDP. В этом процессе серверы STUN имеют единственную задачу: дать возможность узлу за NAT определить свой публичный адрес и порт. (Вы можете узнать больше о STUN и TURN из статьи HTML5 Rocks WebRTC в реальном мире .)

Поиск кандидатов на соединение

Если UDP не удается, ICE пытается TCP. В случае сбоя прямого соединения - в частности, из-за обхода NAT на предприятии и межсетевых экранов - ICE использует промежуточный (ретранслятор) сервер TURN. Другими словами, ICE сначала будет использовать STUN с UDP для прямого соединения с одноранговыми узлами и, в случае неудачи, обратится к серверу ретрансляции TURN. Выражение «поиск кандидатов» относится к процессу поиска сетевых интерфейсов и портов.

Пути передачи данных WebRTC

Инженер WebRTC Джастин Уберти предоставляет больше информации о ICE, STUN и TURN в 2013 презентация Google I / O WebRTC , (Презентация слайды привести примеры реализации серверов TURN и STUN.)

Простой клиент видеочата

Хорошее место, чтобы попробовать WebRTC, в комплекте с сигнализацией и прохождением NAT / брандмауэра с использованием сервера STUN, - это демонстрация видеочата на appr.tc , Это приложение использует adapter.js Подкладка для изоляции приложений от изменений спецификаций и префиксов. Для полной информации о взаимодействии см. webrtc.org/web-apis/interop ,

Код намеренно многословен в своем журнале: проверьте консоль, чтобы понять порядок событий. Ниже мы даем подробный обзор кода.

Сетевые топологии

WebRTC в том виде, в котором он реализован в настоящее время, поддерживает только один-к-один обмен данными, но может использоваться в более сложных сетевых сценариях: например, с несколькими одноранговыми узлами, каждый из которых общается друг с другом напрямую, одноранговым или через Многоточечный блок управления (MCU) - сервер, который может обрабатывать большое количество участников и осуществлять выборочную переадресацию потоков, а также микширование или запись аудио и видео:

WebRTC в том виде, в котором он реализован в настоящее время, поддерживает только один-к-один обмен данными, но может использоваться в более сложных сетевых сценариях: например, с несколькими одноранговыми узлами, каждый из которых общается друг с другом напрямую, одноранговым или через   Многоточечный блок управления   (MCU) - сервер, который может обрабатывать большое количество участников и осуществлять выборочную переадресацию потоков, а также микширование или запись аудио и видео:

Пример топологии многоточечного блока управления

Многие существующие приложения WebRTC демонстрируют связь только между веб-браузерами, но серверы шлюзов могут позволить приложению WebRTC, запущенному в браузере, взаимодействовать с такими устройствами, как телефоны (ака PSTN ) и с VOIP системы. В мае 2012 года компания Doubango Telecom открыла sipml5 SIP клиент , построенный с WebRTC и WebSocket, который (среди других потенциальных применений) позволяет осуществлять видеовызовы между браузерами и приложениями, работающими на iOS или Android. В Google I / O Тетр и Тропо продемонстрировали основа для связи в случае бедствий «в портфеле», используя OpenBTS ячейка включить связь между телефонами и компьютерами через WebRTC. Телефонная связь без оператора!

Tethr / Tropo: аварийная связь в портфеле

RTCDataChannel

Помимо аудио и видео, WebRTC поддерживает связь в реальном времени для других типов данных.

RTCDataChannel API обеспечивает одноранговый обмен произвольными данными с низкой задержкой и высокой пропускной способностью. Есть несколько простых «одностраничных» демонстраций на webrtc.github.io/samples/#datachannel и наш WebRTC кодовая метка показывает, как создать простое приложение для передачи файлов.

Существует множество возможных вариантов использования API, в том числе:

  • азартные игры
  • Приложения удаленного рабочего стола
  • Текстовый чат в реальном времени
  • Передача файла
  • Децентрализованные сети

API имеет несколько функций, позволяющих максимально использовать RTCPeerConnection и обеспечивающих мощную и гибкую одноранговую связь:

  • Использование настройки сеанса RTCPeerConnection.
  • Несколько одновременных каналов, с приоритезацией.
  • Надежная и ненадежная семантика доставки.
  • Встроенная защита (DTLS) и контроль перегрузки.
  • Возможность использования с или без аудио или видео.

Синтаксис намеренно похож на WebSocket с методом send () и событием сообщения:

const localConnection = новый RTCPeerConnection (серверы); const remoteConnection = новый RTCPeerConnection (серверы); const sendChannel = localConnection.createDataChannel ('sendDataChannel'); // ... remoteConnection.ondatachannel = (event) => {receiveChannel = event.channel; receiveChannel.onmessage = onReceiveMessage; receiveChannel.onopen = onReceiveChannelStateChange; receiveChannel.onclose = onReceiveChannelStateChange; }; function onReceiveMessage (event) {document.querySelector ("textarea # send"). value = event.data; } document.querySelector ("button # send"). onclick = () => {var data = document.querySelector ("textarea # send"). value; sendChannel.send (данные); };

Обмен данными происходит непосредственно между браузерами, поэтому RTCDataChannel может быть намного быстрее, чем WebSocket, даже если сервер ретрансляции (TURN) требуется, когда «дырявое перфорирование» справляется с брандмауэрами и NAT не работает.

RTCDataChannel доступен в браузерах Chrome, Safari, Firefox, Opera и Samsung. Cube Slam В игре используется API для информирования о состоянии игры: играйте с другом или играйте в медведя! Инновационная платформа Sharefest разрешил общий доступ к файлам через RTCDataChannel и peerCDN предложил проблеск того, как WebRTC может разрешить одноранговое распространение контента.

Для получения дополнительной информации о RTCDataChannel, посмотрите на IETF проект спецификации протокола ,

Безопасность

Существует несколько способов, которыми коммуникационное приложение или плагин в реальном времени могут поставить под угрозу безопасность. Например:

  • Незашифрованные носители или данные могут быть перехвачены в пути между браузерами или между браузером и сервером.
  • Приложение может записывать и распространять видео или аудио без ведома пользователя.
  • Вредоносное ПО или вирусы могут быть установлены вместе с безобидным плагином или приложением.

WebRTC имеет несколько функций, позволяющих избежать этих проблем:

  • Реализации WebRTC используют безопасные протоколы, такие как DTLS а также SRTP ,
  • Шифрование обязательно для всех компонентов WebRTC, включая механизмы сигнализации.
  • WebRTC не является плагином: его компоненты запускаются в изолированной программной среде браузера, а не в отдельном процессе, компоненты не требуют отдельной установки и обновляются при каждом обновлении браузера.
  • Доступ к камере и микрофону должен быть предоставлен в явном виде, и, когда камера или микрофон работают, это ясно видно из интерфейса пользователя.

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

В заключение

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

Технология не получает намного больше разрушительный чем это.

Мы с нетерпением ждем того, что разработчики JavaScript сделают из WebRTC, поскольку он станет широко реализованным. Как блоггер Фил Эдхолм положи это «Потенциально, WebRTC и HTML5 могли бы обеспечить такое же преобразование для связи в реальном времени, что и исходный браузер для информации».

  • Статистика WebRTC для текущего сеанса может быть найдена по адресу:
  • Кросс-браузер записки взаимодействия
  • adapter.js это JavaScript-оболочка для WebRTC, поддерживаемая Google с помощью Сообщество WebRTC , который абстрагирует префиксы вендоров, различия браузеров и изменения спецификаций
  • Чтобы узнать больше о процессах сигнализации WebRTC, проверьте appr.tc вывод журнала на консоль
  • Если это слишком много, вы можете использовать WebRTC Framework или даже полный Сервис WebRTC
  • Отчеты об ошибках и запросы функций всегда приветствуются:

Учить больше

Стандарты и протоколы

Сводка поддержки WebRTC

MediaStream и getUserMedia

  • Рабочий стол Chrome 18.0.1008+; Chrome для Android 29+
  • Опера 18+; Опера для Android 20+
  • Opera 12, Opera Mobile 12 (на базе движка Presto)
  • Firefox 17+
  • Microsoft Edge 16+
  • Safari 11.2+ на iOS; 11,1+ на Mac
  • UC 11.8+ на Android
  • Samsung Интернет 4+

RTCPeerConnection

  • Рабочий стол Chrome 20+; Chrome для Android 29+ (без флага)
  • Opera 18+ (по умолчанию включена); Opera для Android 20+ (по умолчанию включена)
  • Firefox 22+ (по умолчанию включен)
  • Microsoft Edge 16+
  • Safari 11.2+ на iOS; 11,1+ на Mac
  • Samsung Интернет 4+

RTCDataChannel

  • Экспериментальная версия в Chrome 25, более стабильная (и с совместимостью с Firefox) в Chrome 26+; Chrome для Android 29+
  • Стабильная версия (и с совместимостью с Firefox) в Opera 18+; Опера для Android 20+
  • Firefox 22+ (по умолчанию включен)

Для получения более подробной информации о межплатформенной поддержке API, таких как getUserMedia и RTCPeerConnection, см. caniuse.com а также chromestatus.com ,

Также доступны собственные API для RTCPeerConnection: документация на webrtc.org ,

Хотите попробовать это?
Возникли проблемы с вашей машиной и WebRTC?
Где мы сейчас?
Конфигурация сети: каков IP-адрес и порт моего компьютера для внешнего мира?
Медиа-возможности: с какими кодеками и разрешениями может работать мой браузер и браузер, с которым он хочет общаться?