WEBRTC без какого -либо сервера даже не возможно

Краткое содержание

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

1. Что такое webrtc?

WEBRTC-это набор компонентов, который позволяет разработчикам настраивать медиа-каналы в реальном времени и каналы данных между браузерами. Он был создан Google и содержит ключевые компоненты, которые поставляются в Chrome, Firefox, Opera и Microsoft Edge (ORTC).

2. Зачем вам сервис бэкэнд?

Несмотря на возможности WEBRTC, для определенных функциональных возможностей требуется бэкэнд -сервис. Например, чтобы позвонить кому -то, вам нужно знать его адрес, который обычно является динамичным. Эта информация должна храниться и управлять на сервере. Кроме того, бэкэнд -сервис может отслеживать все устройства для пользователя и уведомить их о входящих звонках.

3. Какие компоненты и оборудование участвуют в настройке WEBRTC?

WEBRTC помогает настроить физическую среду, такую ​​как камеры, динамики и микрофоны, а также другое оборудование, такие как отмена эха и оборудование отмены фона. Он также помогает настройке сети с использованием STUN (утилиты прохождения сеанса для NAT).

4. Какие аудиокодеки поддерживаются WEBRTC?

WEBRTC поддерживает различные аудиокодеки, включая G711, ILBC и Opus. Opus-это высококачественный переменный кодек, широко используемый в Webrtc.

5. Какие видеокодеки поддерживаются WEBRTC?

WEBRTC поддерживает кодеки VP8 и VP9, ​​которые являются вариациями H Google без роялти H.264/ч.265. Это также поддерживает ч.264.

6. Почему аудиокодеки важны в WEBRTC?

Аудиокодеки обрабатывают задачи, такие как потеря пакета, кодирование и декодирование аудио, коррекция ошибок, отмена шума, отмена эха и выравнивание объема. Они способствуют популярности WEBRTC на мобильных устройствах и настольных компьютерах.

7. Каков каталог, кто можно позвонить?

Чтобы инициировать звонок, вам нужно знать адрес получателя. Каталог служит динамическими белыми страницами, позволяя пользователям проверять с сервером и предоставлять контактную информацию. Это может быть реализовано с использованием XMPP, SIP или пользовательских протоколов.

8. Зачем вам сервер STUN?

Сервер STUN (утилиты обхода сеанса для NAT) помогает определить внешний IP -адрес устройства и проверять, могут ли два устройства напрямую общаться. Это играет решающую роль в установлении связей между сверстниками.

9. Что такое сервер поворота?

Если одноранговая сеанс невозможна из-за ограничений брандмауэра, необходим сервер поворота (обход с использованием реле вокруг NAT). Это помогает в передаче данных между устройствами, обходя ограничения брандмауэра.

10. Почему вы должны подумать о использовании бэкэнд -сервиса, такой как Sinch?

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

11. Webrtc только о бэкэнд?

Нет, WEBRTC включает в себя как аспекты фронта, так и бэкэнд. Например, Sinch настраивает и настраивает их Webrtc SDK, чтобы обеспечить оптимальную производительность между устройствами и условиями сети. Они реализуют такие функции, как адаптивный OPUS, для корректировки качества записи на основе качественных показателей от трафика.

12. Каковы преимущества использования Sinch?

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

13. Насколько заметна задержка сети в разговоре?

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

14. Какие функциональные возможности предоставляет услуга бэкэнд в Webrtc?

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

15. Что делает WEBRTC популярным на мобильных устройствах и настольных компьютерах?

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

WEBRTC без какого -либо сервера даже не возможно

Затем откройте две вкладки в вашем браузере (или в двух разных браузерах) и введите Localhost: 7000. Как уже упоминалось ранее, лучше всего иметь две камеры, доступные для этого примера для работы. Если все пойдет хорошо, вы должны увидеть один видео -канал на каждой из вкладок.

Webrtc и почему вам все еще нужна сервис бэкэнд

Присоединяйтесь к сообществу Dzone и получите полный опыт участника.

Эта статья первоначально появилась в блоге Sinch Christian Jensen.

Что такое webrtc?

WEBRTC – это набор компонентов, основанных на нескольких инновациях от компаний, которые Google купил в 2010 году. WEBRTC позволяет разработчику настроить каналы носителя и данных в реальном времени между двумя браузерами (или мобильными телефонами, если вы скомпилируете его для этого). Он содержит пару ключевых компонентов, и все они поставляются в Chrome, Firefox и Opera, и в Microsoft существует версия в Microsoft’S новый браузер Edge (ORTC).

Настройка потоков данных и оборудования

WEBRTC помогает настройке как физической среды (например, камеры, динамиков и микрофонов), так и другого оборудования (например, отмены Echo и оборудование отмены фона – те, которые вы найдете в основном в мобильных теле), плюс помогая выяснить сеть вместе с STUN.

Аудиокодеки и видеокодеки

Одним из основных преимуществ использования WEBRTC по сравнению с другим программным обеспечением при работе с аудио и видео в реальном времени является кодеки с открытым исходным кодом/роялти, которые Google достаточно добр, чтобы отправить.

Аудиокодеки

• G711, используется в обычных телефонных сетях
• ILBC, старая узкополосная кодировка, также используется в телефонных сетях
• Opus, высококачественная переменная и (поддержка адаптивного) кодек, который является новым в кодеке, используемой в Webrtc.

Есть больше отправленных, но это основные и наиболее широко используемые.

Видеокодеки

• VP8 и скоро VP9, ​​это Google’S вариация без роялти H.264/ч.265 Кодек
• ЧАС.264 (добавлено в 2015 году в качестве соглашения для ORTC)

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

Итак, теперь я могу построить свой собственный звонок на основе браузера в Pure JavaScript, используя (добавьте здесь свою любимую кадров JS -фреймворк)). К сожалению, это’S не так просто, чтобы настроить звонок, так как здесь отсутствуют две основные вещи.

Справочник, кто можно позвонить (или открытие сверстников)

Чтобы позвонить кому -то, вам нужно знать адрес, и, в отличие от обычных номеров телефонов, адресация в Интернете в основном динамические IP -адреса. Чтобы решить это, вы должны вести учет о том, где все. Это можно сделать несколькими способами, используя XMPP, SIP, пользовательские протоколы и т. Д., Но все сводится к тому, что любой, кто готов получить проверку вызова с сервером, так или иначе, и позволяет серверу узнать, как связаться с этим однорангом (подразумевается для дальнейшей доставки предложения/приглашения/SDP и т. Д.).

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

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

STUN SERVER

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

Сервер ретрансляционного реле (повернуть сервер)

Если одноранговая сеанс невозможна (наши собственные данные предполагают, что это учетные записи около 25% сеансов), вам понадобится сервер поворота. Сервер поворота в основном перенесет биты для вас через открытые отверстия в брандмауэре между двумя клиентами. Почему это происходит? Наиболее распространенными являются асимметричные брандмауэры и возможность пробить отверстия в разных портах в брандмауэрах.

ОК, но почему Дон’Я сам это настроил?

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

Вы, вероятно, тоже хотите иметь распределенную сеть. Если, например, у вас есть сервер поворота в U.С. И звонки происходят между клиентами в Европе, вы добавите задержку только потому, что все движение необходимо пересечь океан. Хорошим эмпирическим правилом является то, что в разговоре заметно около 250 мс (здесь больше информации о качестве обслуживания). Таким образом, не добавляя какую -либо задержку сети в клиенту и время обработки, чтобы кодировать данные, вы в основном гарантированно будете иметь слишком большую задержку между клиентами.

Это только о бэкэнд?

Это’S не только о бэкэнд. В Sinch у нас есть обширный опыт работы в реальном времени, и мы настраиваем и настраиваем нашу SDK WEBRTC, чтобы лучше всего работать на всех устройствах и в разных сетях. Несколько примеров – это реализация адаптивного OPUS, который будет корректировать качество записи на основе качественных показателей от нашего трафика. Мы также знаем, какие кодеки использовать в определенных обстоятельствах, а какие выбрать для минимизации транскодирования и задержки во всем мире.

Опубликовано в Dzone с разрешения Кристиана Дженсена . Смотрите оригинальную статью здесь.

Мнения, выраженные участниками Dzone, являются их собственными.

WEBRTC без какого -либо сервера даже не возможно?

Я пытаюсь настроить плагин Cordova для iOS, который реализует функции WEBRTC без использования какого -либо сервера, и он будет использоваться только в локальной сети. Я знаю, что есть этот плагин, который выглядит многообещающе, но у меня есть некоторые проблемы с ним. Мой план не в том, чтобы использовать Trun, STUN или какой -либо сервер сигнализации. Может ты думаешь прямо сейчас: “ОК, это невозможно. Никакая передача сигналов не равняется соединению.“Но позвольте мне сначала объяснить. Как указывалось здесь и здесь можно избежать использования сервера Trun, Stun или Ice. Я думаю, что это хороший способ начать мой проект, но все еще есть открытый вопрос. Как устройства найдут друг друга, если нет никакой передачи сигналов (в примере они используют узел.JS Server)? Прямо сейчас я играю с идеей QR-кода, который содержит всю необходимую информацию. В конце это должно выглядеть так (черные арри более важны): идея состоит в том, что каждый, кто входит в комнату, должен сканировать QR-код на RP, а затем устройство знает IP, порт и т. Д. RP и соединение WEBRTC с помощью данных DataChancel будет установлено. Я искал ответ уже несколько дней, но из -за факта (или, по крайней мере, одной из причин), что WEBRTC даже не поддерживается на iOS Nativly, не так много примеров WEBRTC, которые работают на iOS, и никого для местной сети. Итак, мой вопрос: я в правильном пути или это даже не возможно? (Я не нашел этого нигде примера, но если я размесчу все посты, которые прочитал, я думаю, что это должно быть возможно.)

спросил 10 августа 2017 года в 12:38

3257 3 3 Золотые значки 11 11 Серебряные значки 19 19 Бронзовые значки

Неважно, как вы решаете обнаружение, но для установления соединения WEBRTC вам нужно как -то получить предложение и отвечать на сообщения между сверстниками. Эти сообщения автоматически содержат кандидатов на ледя. Смотрите Stackoverflow.com/a/29056385/918910.

Webrtc: рабочий пример

Недавно мне пришлось использовать WEBRTC для простого проекта. Сама технология имеет много преимуществ и разрабатывается как открытый стандарт, без необходимости каких -либо плагинов. Тем не менее, я был совершенно новичок в WEBRTC и у меня были некоторые проблемы с тем, чтобы разобраться в основных понятиях, а также создал рабочее решение. Есть много учебных пособий (как этот, что вдохновило мое решение). Но большинство из них неполны, устарели или заставляли меня использовать некоторые сторонние услуги (E.г. Google Firebase), которая сделала лишь более сложный процесс более сложным для настройки и труднее понять.

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

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

Общее описание

Полный исходный код этого примера доступен на GitHub. Программа состоит из трех частей:

• веб приложение
• сигнальный сервер
• Повернуть сервер

А веб приложение очень просто: один файл HTML и один файл JavaScript (плюс одна зависимость: разъем.io.младший, который включен в хранилище). Он предназначен для работы только с двумя клиентами (два веб -браузера или две вкладки одного и того же браузера). После того, как вы откроете его в браузере (протестировано на Firefox 74), он попросит разрешения использовать камеру и микрофон. Как только разрешение будет предоставлено, видео и аудио с каждой из вкладок будут передаваться на другой.

Примечание: вы можете столкнуться с некоторыми проблемами, если попытаетесь получить доступ к одной и той же камере с обеих вкладок. В моем тесте я’VE использовал два устройства во время тестирования на моей машине (встроенная камера для ноутбука и веб-камера USB).

А сигнальный сервер используется приложениями WEBRTC для обмена информацией, необходимой для создания прямого соединения между сверстниками. Вы можете выбрать любую технологию для этого. В этом примере используются веб -токи (Python-Socketio на бэкэнд и разъем.io-client на фронте).

А ПОВЕРНУТЬ Сервер требуется, если вы хотите использовать этот пример в общедоступной сети. Процесс описан далее в этом посте. Для тестирования локальной сети вам не понадобится.

Сигнализация

Сервер сигнализации записан в Python3 и выглядит так:

от aiohttp import web import socketio room = 'room' sio = socketio.Asyncserver (cors_allowed_origins = '*') app = web.Application () sio.Прикрепить (приложение) @sio.Событие Async def Connect (sid, Environ): print ('подключен', sid) ждать sio.Emit ('ready', Room = Room, skip_sid = sid) sio.enter_room (sid, комната) @sio.Событие DEF DENSCONCEECT (SID): SIO.Leave_room (sid, Room) print ('Depnonded', sid) @sio.Event Async DEF DATA (SID, DATA): PRINT ('Сообщение от <>: <>'.Формат (SID, DATA)) AWAIT SIO.Emit ('Data', Data, Room = Room, Skip_SID = SID) IF __name__ == '__main__': Интернет.run_app (приложение, порт = 9999)

Каждый клиент присоединяется к одной комнате. Перед входом в комнату готовый Мероприятие отправляется всем клиентам в настоящее время в комнате. Это означает, что первое соединение WebSocket не получит никакого сообщения (комната пуста), но когда второе соединение будет установлено, первое получит готовый Событие, сигнализирующее о том, что в комнате есть как минимум два клиента, и соединение WEBRTC может начать. Кроме этого, этот сервер будет пересылать любые данные (данные событие), которое отправляется одним веб -сокетом другим.

Настройка довольно проста:

CD Signaling PIP установка AIOHTTP Python-Socketio Python Server.пирог

Это запустит сервер сигнализации на Localhost: 9999.

Webrtc

Упрощенный процесс использования WEBRTC в этом примере выглядит следующим образом:

• Оба клиента получают свои местные медиа -потока
• После получения потока каждый клиент подключается к серверу сигнализации
• Как только второй клиент подключится, первый получает готовый событие, что означает, что соединение WEBRTC можно договориться
• Первый клиент создает объект RTCpeerConnection и отправляет предложение второму клиенту
• Второй клиент получает предложение, создает объект RTCpeerConnection и отправляет ответ
• Больше информации также обменяется, как кандидаты на ледяной
• После того, как соединение будет договоренно, вызовов для получения удаленного потока называется, и этот поток используется в качестве источника видео элемент.

Если вы хотите запустить этот пример на Localhost, сигнальный сервер и веб -приложение – все, что вам нужно. Основной частью файла HTML является единственный видео элемент (какой источник будет установлен позже сценарием):

JavaScript часть немного сложнее, и я’ll объяснить это шаг за шагом. Во -первых, есть переменные конфигурации:

// конфигурационные переменные const signing_server_url = 'http: // localhost: 9999'; const pc_config = <>;

Для местного хоста, Pc_config может оставаться пустым и Signaling_server_url должен указывать на сервер сигнализации, который вы’VE начал на предыдущем шаге.

Далее у нас есть методы сигнализации:

Let Socket = io (сигнал_SERVER_URL, < autoConnect: false >); разъем.on ('data', (data) => < console.log('Data received: ',data); handleSignalingData(data); >); разъем.on ('ready', () => < console.log('Ready'); createPeerConnection(); sendOffer(); >); Пусть SendData = (data) => < socket.emit('data', data); >;

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

Пусть ПК; Пусть локалсдрем; Пусть remoteStreamElement = документ.QuerySelector ('#Remotestream');

Пусть getLocalStream = () => < navigator.mediaDevices.getUserMedia(< audio: true, video: true >) .Тогда ((поток) => < console.log('Stream found'); localStream = stream; // Connect after making sure that local stream is availble socket.connect(); >) .поймать (error => < console.error('Stream not found: ', error); >); >

Пусть CreatePeerConnection = () => < try < pc = new RTCPeerConnection(PC_CONFIG); pc.onicecandidate = onIceCandidate; pc.onaddstream = onAddStream; pc.addStream(localStream); console.log('PeerConnection created'); >поймать (ошибка) < console.error('PeerConnection failed: ', error); >>;

Пусть sendoffer = () => < console.log('Send offer'); pc.createOffer().then( setAndSendLocalDescription, (error) => < console.error('Send offer failed: ', error); >); >; Пусть sendanswer = () => < console.log('Send answer'); pc.createAnswer().then( setAndSendLocalDescription, (error) => < console.error('Send answer failed: ', error); >); >; Пусть setandsendlocaldescription = (sessiondescription) => < pc.setLocalDescription(sessionDescription); console.log('Local description set'); sendData(sessionDescription); >;

Let OniceCandidate = (Event) => < if (event.candidate) < console.log('ICE candidate'); sendData(< type: 'candidate', candidate: event.candidate >); >>; let onaddstream = (event) => < console.log('Add stream'); remoteStreamElement.srcObject = event.stream; >;

Let handleSignalingData = (data) => < switch (data.type) < case 'offer': createPeerConnection(); pc.setRemoteDescription(new RTCSessionDescription(data)); sendAnswer(); break; case 'answer': pc.setRemoteDescription(new RTCSessionDescription(data)); break; case 'candidate': pc.addIceCandidate(new RTCIceCandidate(data.candidate)); break; >>;

// начало соединения getLocalStream ();

CD Web Python -m http.сервер 7000

Sudo Apt Установка Coturn Turgerver -a -o -v -n - -no -dtls - -no -tls -u Имя пользователя: учетные данные -r realmname

const turn_server_url = ': 3478'; const turn_server_username = 'username'; const turn_server_credential = 'credential'; const pc_config = < iceServers: [ < urls: 'turn:' + TURN_SERVER_URL + '?transport=tcp', username: TURN_SERVER_USERNAME, credential: TURN_SERVER_CREDENTIAL >, < urls: 'turn:' + TURN_SERVER_URL + '?transport=udp', username: TURN_SERVER_USERNAME, credential: TURN_SERVER_CREDENTIAL >]>;