Webrtc vp8 codec что это

Обновлено: 06.07.2024

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

Теперь давайте разберем, WebRTC на первый взгляд состоит из одних плюсов, стоит ли ее периодически выключать?

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

При применении VPN в Opera вероятны следующие утечки:

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

Как проверить включен ли WebRTC

Вы можете воспользоваться следующими сайтами:

Если сравнить сайты, то на втором сайте вся информация предоставлена на русском языке.

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

Возможно, ли отключить WebRTC в Firefox, и как это сделать?

Отключение WebRTC в веб – браузере Firefox производится легче всего, на уровне веб – браузера.

В начале вы указываете в адресную строку команду «about:config».

Далее вы увидите предупреждающее окно, для подтверждения действия, нажмите кнопку «Я обещаю быть осторожным»

После чего появится список настроек.

Вы должны найти строку «media.peerconnection.enabled». Чтобы упростить поиск воспользуйтесь командой «поиск».

Данная строка появится при сочетании клавиш Ctrl+ F. Если же вам надо ее выключить, нужно воспользоваться значением «false»

Что означает Плагин WebRTC Control и как им воспользоваться?

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

Введите название плагина (WebRTC Control) в поисковую строку.

Для установки нажмите кнопку «добавить в firefox», которую вы увидите внизу. Если вы активировали плагин, тогда в правом верхнем углу значок плагина будет синего цвета. Но данные плагины не могут предоставить 100% защиту ваших идентифицирующих данных. Для найлучщей защиты вы можете воспользоваться плагином NoScript, он запретит все возможные скрипты в веб – браузере. Если же вы хотите создать вашу особую сеть, для того чтобы воспрепятствовать нежеланным лицам идентифицировать ваш IP –адрес, стоит использовать VPN.

Opera

Чтобы отключить WebRTC, зайдите в библиотеку (галерею) расширенный.

Второй способ отключить WebRTC – перейдите в Меню>Настройки> Безопасность, отметьте галочкой «Показать дополнительные настройки» в разделе WebRTC необходимо выбрать «Отключить непроксированный UDP».

Яндекс

Вы отключите данную функцию с помощью плагина WebRTC Control, как и в Opere значок будет синего цвета во включенном состоянии.

GoogleChrome

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

Еще одним способом для отключения WebRTC, является плагин WebRTC Control. Для того чтобы его запустить, вам необходимо перейти в «Расширения», далее перейти ниже в «Еще Расширения» где вы выберете и установите необходимое вам дополнение. Также, как и в других браузерах, если технология будет включена, иконка будет синего цвета.

При желании можете воспользоваться WEbRTC Leak Prevent, и также Easy WebRTC Block, принцип их работы такой же, как и плагина WebRTC Control.

Google CРrome на телефоне

Internet Explorer и Microsoft Edge

Браузер Internet Explorer не поддерживается WebRTC, таким образом вы будете им пользоваться, не думая об утечке данных.

Что касается браузера Microsoft Edge – вы сможете только частично блокировать технологию. Для чего вам необходимо выполнить следующие действия:

Ввести в строке about:flags
Отметить необходимую галочку
После чего необходимо перезапустить браузер

Safari на macOS

Для отключения технологии – войдите в настройки браузера, в «Дополнениях» поставите галочку о показе раздела «Разработка в меню», после чего ставим галочку на Remove Legacy WebRTC API.

Safari на iOS

Чтобы отключить WebRTC здесь – зайдите в настройки, спуститесь до пункта Safari, после чего нажмите «Дополнения», Experimental Features. Далее нажмите Remove Legacy WebRTC API, теперь вы можете быть уверенны что технология WebRTC отключена.

Для видеозвонков в Badoo мы используем стандарт WebRTC и кодек H.264. Если верить документации, этот кодек должен без проблем работать на любых устройствах Android начиная с Android 5.0. Но на практике всё оказалось не совсем так. В этой статье я расскажу про особенности реализации аппаратного кодирования для кодека H.264 в WebRTC и о том, как заставить его работать на большем количестве устройств.

Почему именно H.264?

При соединении по WebRTC все устройства, участвующие в сеансе, передают различные параметры связи, в том числе видео- и аудиокодеки. Если устройства поддерживают несколько кодеков (например, VP8 и H.264), приоритетные для платформы кодеки указываются первыми. Эти данные используются на этапе согласования в WebRTC, после которого остаются только кодеки, поддерживаемые всеми устройствами. Пример таких данных с расшифровкой можно увидеть в этом документе.

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

Поддержка H.264 на Android

Если верить описанию поддержки форматов мультимедиа, декодирование H.264 Baseline Profile должно работать на всех Android-устройствах, а кодирование — начиная с Android 3.0. В Badoo мы поддерживаем устройства начиная с Android 5.0, так что у нас не должно было возникнуть проблем. Но всё оказалось не так просто: даже в гаджетах с пятой версией мы обнаружили большое количество особенностей.

С чем это может быть связано?

Нас в этом наборе тестов интересуют мультимедиа-тесты, а конкретнее — тесты на кодирование и декодирование видео. Я решил остановиться на тестах EncodeDecodeTest, MediaCodecTest, DecoderTest и EncoderTest, так как они присутствуют на всех версиях Android начиная с 4.3. График количества строк кода в этих тестах выглядит так:

До версии 4.3 большинства из этих тестов просто не существовало, и значительный их прирост пришёлся на версии 5 и 7. Поэтому можно говорить о том, что до версии Android 4.3 Google никак не проверяла соответствие устройств своей спецификации по кодированию и декодированию видео, а в версии 5.0 значительно улучшила эту проверку.

Казалось бы, это указывает на то, что начиная с версии 5.0 с кодированием всё должно быть в порядке. Но, учитывая предыдущий мой опыт работы с декодированием потокового видео на Android, я был уверен, что это не так. Достаточно было посмотреть на количество топиков про кодирование в Google-группе discuss-webrtc.

Искать подводные камни нам помогали исходные файлы WebRTC, которые находятся в свободном доступе. Рассмотрим их подробнее.

Поддержка H.264 в WebRTC

Тут есть метод с говорящим названием isHardwareSupportedInCurrentSdkH264:

Как мы видим, поддержка аппаратного кодирования на Android реализована только для чипсетов Qualcomm и Exynos. Почему же в стандартной реализации WebRTC нет поддержки других чипсетов? Вероятнее всего, это связано с особенностями реализации аппаратных кодеков производителей. И выявить эти особенности часто можно только на продакшене, поскольку найти те или иные устройства не всегда представляется возможным.

Все описания кодеков на устройстве хранятся в файле media_codecs.xml. Вот, например, этот файл для Pixel XL и для HUAWEI P8 lite. При получении списка кодеков с помощью метода getCodecInfos() объекта MediaCodecList этот файл парсится — и возвращаются кодеки, хранящиеся в нём. Эта операция и правильность заполнения этого файла производителем покрываются в CTS тестом MediaCodecListTest, который также увеличился со 160 строк кода в Android 4.3 до 740 строк в Android 10.

В Badoo мы поменяли код метода isHardwareSupportedInCurrentSdkH264, отказавшись от «белого» списка кодеков и заменив его «чёрным» списком префиксов программных кодеков, которые перечислены в WebRTC:

Но нельзя просто так взять и реализовать поддержку всех кодеков, не обращая внимания на особенности производителей. Из названий топиков, посвящённых аппаратному кодированию на Android в группе discuss-webrtc, можно понять, что в этом случае у нас точно возникнут ошибки. В основном они появляются на этапе конфигурации кодека.

Параметры конфигурации кодека

Инициализация кодека для кодирования выглядит так:

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

— регулирует битрейт в зависимости от объёма данных, — регулирует битрейт в зависимости от частоты кадров.

Разрешение потока

После получения для кодека объекта MediaCodecInfo можно изучить кодек подробнее, получив его возможности в классе CodecCapabilities. Из них можно узнать, поддерживает ли кодек выбранные разрешение и частоту кадров. Если он поддерживает эти параметры, их можно устанавливать безопасно.

Однако иногда это правило не работает. Мы столкнулись с тем, что кодеки с префиксом “OMX.MARVELL.” кодировали неправильно, показывая зелёные полосы по краям экрана, если разрешение потока отличалось от 4:3. При этом сам кодек утверждал, что выбранные разрешение и частота кадров поддерживаются.

Режим битрейта

Стандартный режим для всех видеокодеков — постоянный битрейт. Однако однажды нам пришлось использовать переменный битрейт:

Произошло это на устройстве Lenovo A1000 с чипсетом компании Spreadtrum (теперь Unisoc), начинающимся с префикса “OMX.sprd.”. Поиск в Интернете привёл нас к посту шестилетней давности о Firefox OS, описывающему эту проблему и способ её решения.

Цветовой формат

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

Грубо говоря, всегда выбирается первый из поддерживаемых цветовых форматов.

Однако в случае с кодеками HUAWEI, начинающимися с префиксов «OMX.IMG.TOPAZ.», «OMX.hisi.» и «OMX.k3.», это не работало, и после долгих поисков мы нашли решение: вне зависимости от того, какой формат возвращают эти кодеки, необходимо использовать формат COLOR_FormatYUV420SemiPlanar. Разобраться в этом нам помог тред на одном китайском форуме.

Регулировка битрейта

Стандартный код WebRTC содержит следующее:

Как видно из этого кода, для всех чипсетов, кроме Exynos, регулировка битрейта выключена. Но это относится только к Qualcomm, так как в стандартном коде поддерживаются только Exynos и Qualcomm. Поэкспериментировав с различными значениями этой настройки, а также поискав в Интернете, мы выяснили, что для кодеков с префиксами «OMX.MTK.» её тоже нужно включить. Также необходимо сделать это для кодеков HUAWEI, начинающихся с префикса «OMX.IMG.TOPAZ.», «OMX.hisi.» или «OMX.k3.». Это связано с тем, что эти кодеки не используют временные метки кадров для регулировки битрейта, считая, что все кадры приходят с одинаковой частотой, установленной при конфигурации кодека.

В завершение приведу список кодеков, которые мы получили для устройств на Android 5.0 и 5.1. Они были нам интересны в первую очередь потому, что на более новых версиях Android ситуация улучшается и нестандартных кодеков становится всё меньше.

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

Как мы видим, у большинства устройств были чипсеты Spreadtrum, MediaTek, HUAWEI и MARVELL — поэтому наши изменения помогли включить аппаратное кодирование на этих гаджетах.

Результат

Хотя мы и предполагали, что на некоторых устройствах при работе с H.264 будут возникать проблемы, Android опять смог нас удивить. Как мы видим из статистики пользователей Badoo, на руках у пользователей ещё достаточно много устройств 2014–2016 года выпуска, которые они не хотят или не могут обновлять. И хотя ситуация с выходом обновлений Android для новых устройств уже гораздо лучше, чем несколько лет назад, доля гаджетов предыдущего поколения сокращается довольно медленно и поддерживать их придётся ещё достаточно долго.

Сейчас WebRTC активно развивается Google из-за его использования в проекте Stadia (вот видео с подробностями на эту тему), поэтому он будет становиться всё лучше и лучше и, скорее всего, станет стандартом для реализации видеосвязи. Надеюсь, что эта статья поможет вам понять особенности работы с H.264 в WebRTC и использовать это в своих проектах.

Содержание

История

В мае 2011 года Google выпустила проект с открытым кодом на основе веб-браузера в режиме реального времени общения, известной как WebRTC. После этого последовала работа по стандартизации соответствующих протоколов в IETF и браузеров интерфейсов API в W3C.

W3C проект WebRTC - работа с расширенными реализациями в браузерах Chrome и Firefox. API основан на предварительной работе, проделанной в WHATWG . Он был передан в качестве Peer Connection API, а также реализация концепции предварительных стандартов была создана в Ericsson Labs. Web Real-Time Communications ожидает, что эта спецификация значительно разовьется на основе:

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

Работа WebRTC со стороны клиента

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

Работа WebRTC со стороны сервера

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

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

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

Кодеки в WebRTC

Аудиокодеки

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

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

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

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

Видеокодеки

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

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

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

Компания Google активно продвигает кодек VP8, а Firefox и Cisco — H.264, чтобы обеспечить совместимость с обычными системами видеоконференцсвязи.

Поддержка

WebRTC поддерживается в следующих браузерах:
1. Microsoft Edge
2. Google Chrome
3. Mozilla Firefox
4. Opera
Android
1. Google Chrome
2. Mozilla Firefox
3. Opera Mobile
Chrome OS
Firefox OS
iOS
Blackberry

На данный момент Internet Explorer и Safari до сих пор не имеют встроенную поддержку WebRTC.

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

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

Недостатки

API изменяется, т.к. проект находится на стадии активной разработки. Следовательно, иногда придется менять свой код.

До утверждения аудио и видео кодеков, возможны проблемы с кроссплатформенностью.

Кроссбраузерность.

Проблемы

WebRTC – большая головная боль для всех, кто хочет обеспечить анонимность и безопасность при работе в сети. Главная проблема в том, что WebRTC очень легко и быстро раскрывает реальный IP-адрес пользователя, от чего не защищают ни прокси, ни VPN, ни Tor, ни популярные плагины типа Ghostery. Для организации аудио- или видеосвязи с помощью WebRTC два компьютера должны обменяться между собой не только публичным, но и локальным IP-адресом. Этот процесс реализован настолько открыто и прямолинейно, что запросить адрес можно с помощью простого скрипта на JavaScript. Результат – настоящая дыра в безопасности системы, закрыть которую можно только путем полного отключения WebRTC.

Как отключить WebRTC в Firefox

Откройте скрытые настройки браузера путем ввода команды about:config в адресной строке:

Теперь найдите в списке параметр media.peerconnection.enabled. Отключите его, выставив значение false.

Как отключить WebRTC в Chrome, Opera, Яндекс.Браузер

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

Поэтому для полноценной безопасности рекомендуется использовать Firefox, в котором реализовано полноценное отключение WebRTC средствами самого браузера. При этом можно дополнительно установить плагин NoScript, блокирующий исполнение всех скриптов в браузере (существует и для Chrome).

Как отключить WebRTC в ОС Android

На данный момент, нет безопасного способа отключить WebRTC в Opera для Android.

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

Краткий обзор технологии WebRTC

Стандарт WebRTC является продуктом совмещения двух различных технологий: обеспечения взаимодействия web-браузера с аппаратными мультимедийными средствами компьютера (камера, микрофон, средства захвата экрана) и создания пиринговой одноранговой сети (peer-to-peer), т.е. использование прямого обмена данными между браузерами, без использования сторонних серверов.

Структура уровней взаимодействия WebRTC

WebRTC основан на трех программных интерфейсах, реализующих его функциональность: для использования камер и микрофонов используется интерфейс navigator.mediaDevices.getUserMedia(). Для трансляции экрана используется navigator.mediaDevices.getDisplayMedia(). Создание peer-to-peer соединения управляется интерфейсом RTCPeerConnection.

WebRTC поддерживает аудио кодеки G.711 и Opus, а также видеокодеки H.264 и VP8, что позволяет обеспечить высокое качество связи между абонентами.

Схема инфраструктуры WebRTC

О безопасности WebRTC

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

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

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

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

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

Поддержка WebRTC

Для функционирования WebRTC в браузере необходима поддержка таких технологий, как JavaScript и HTML5. Эти инструменты позволяют создавать интерфейс для VoIP-приложений и использовать библиотеки интерфейсов (API) WebRTC. Непосредственная поддержка самого механизма WebRTC заявлена в браузерах Google Chrome начиная с версии 23, Firefox с версии 38, Opera с версии 12 и в Safari с версии 11. Браузеры компании Microsoft открытую реализацию WebRTC не поддерживают, Edge использует собственную реализацию под названием Object Real Time Communications (ORTC), а для IE с версии 9+ существует плагин webrtc4all, обеспечивающий поддержку необходимых кодеков и библиотек.

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

Взаимодействие клиентов WebRTC

Взаимодействие WebRTC и Asterisk

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

Еще одним необходимым условием для взаимодействия Asterisk с WebRTC-абонентами является наличие STUN-сервера, независимо от того, используют ваши абоненты NAT или нет. STUN необходим для корректной обработки заголовков SDP-пакетов, которые устанавливают сессии между абонентами и содержат в себя их ip-адреса.

Протоколы общения клиентов WebRTC

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

Здесь описаны лишь теоретические аспекты взаимодействия Asterisk с WebRTC. Подробную инструкцию по конфигурированию Asterisk для работы с абонентами WebRTC Вы можете найти на нашем сайте ознакомившись с постом «Настройка WebRTC в Asterisk 13» .

Существуют альтернативные методы поддержки абонентов WebRTC в Asterisk, такие как WebRTC-шлюзы. Примером может служить проект webrtc2sip. Это может понадобиться, если по каким-то причинам вы используете версии Asterisk ниже 11. Каких-либо специальных настроек Asterisk для использования webrtc2sip не требуется.

Особенности реализации технологии WebRTC

Для создания подключения peer-2-peer между двумя браузерами используется класс RTCPeerConnection:

В данном контейнере используются механизмы STUN и TURN для определения реальных ip-адресов абонентов и преодоления инфраструктуры NAT

Сетевая модель взаимодействия клиентов (1)

После создания подключения в него добавляются медиа-потоки, например, видео с веб-камеры:

Интерфейс GetUserMedia позволяет задавать различные параметры для передаваемого медиа-потока:

Для общения двух абонентов необходимо создать ICE-сервер, который будет обрабатывать события создания, установления и разрыва связи между пирами:

Соответственно, для сервера включаем обработку указанных событий (OFFER,ANSWER,CANDIDATE):

Со стороны вызывающего (создающего соединение) абонента последовательность создания методов выглядит следующим образом:

createOffer(offer) создание события звонка
setLocalDescropton(offer) установка локального события
SIGNALING RTC_OFFER передача события звонка серверу

Со стороны принимающего абонента используются следующая последовательность методов:

setRemoteDescription(offer) принятие события от вызывающего
createAnswer(answer) создание события ответа
setLocalAnswer(answer) установка локального события
SIGNALING RTC_ANSWER передача события серверу

Схема создания сокетов между абонентами

Читайте также: