Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

Общие сведения

Технология WebRTC при работе с сетью опирается на три основных спецификации:

...

Убедитесь, что весь трафик, который участвует в установке WebRTC сессии и в передаче медиа данных беспрепятственно проходит между участниками звонка. Медиа порты WCS сервера в диапазоне [31000-32000] по умолчанию, должны быть открыты для приема входящего UDP трафика. Если WCS-сервер находится за NAT и имеет внешний IP-адрес, убедитесь что UDP пакеты, отправленные на этот внешний адрес будут корректно маршрутизированы на соответствующие порты WCS сервера, который находится за NAT.

ICE и STUN трафик

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

Image Added

DTLS Трафик

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

Image Added

SRTP Трафик

Определение SRTP пакетов

При передаче данных по SRTP, Wireshark может не распознать SRTP пакеты. Найти эти пакеты достаточно просто. WCS по умолчанию использует диапазон портов [31000-32000] для передачи медиа трафика, в том чилсе и WebRTC. В дампе ниже мы нашли два неопознанных UDP-пакета, один из которых отправлен с порта 31030, а второй принят на этом порту. Для таких пакетов нужно явно указать используемый протокол.

Image Added

Декодирование SRTP-пакетов

Wireshark сможет разобрать найденные UDP пакеты, если мы укажем ему протокол. В свойствах пакета выберите 'Decode As..' и далее выберите RTP протокол для всех пакетов, которые идут между браузером на порту 31030 и WCS сервером на порту 58732. Эти порты выделяются динамически и вашем случае будут использоватся другие значения.

Image Added

Разобранный SRTP-трафик

В результате декодирования протокола, Wireshark отобразит разобранный SRTP трафик:

Image Added

Заголовки SRTP-пакета

SRTP трафик зашифрован. Это означает что если попытаться его проиграть, вместо нормальной речи будут шумы. Но зашифровано только содержание трафика. Основные RTP-заголовки не зашифрованы и их видно в RTP пакете. Это удобно для анализа характеристик SRTP трафика. В примере ниже показан SRTP пакет с Payload Type, Sequence Number, Timestamp, SSRC.

Image Added

Список SRTP и RTP потоков, участвующих в WebRTC сессии

SRTP и RTP потоки можно проанализировать с помощью Wireshark. Для этого нужно использовать меню 'Telephony - RTP - Show All Streams'.

Image Added


В данном случае потоки с SSRC 0x3B359CA0 и 0x1EC9BA4B являются SRTP-потоками между Web-браузером и WCS, т.к. их источником и адресом назначения является IP-адрес веб-клиента (он нам заранее известен). Остальные два потока - первый и третий сверху это RTP потоки между WCS и SIP сервером (адреса WCS сервера и SIP сервера нам также известны заранее).

Анализ SRTP-потока

Как описывалось выше, заголовки SRTP-пакета не шифруются и поэтому SRTP поток полностью доступен для анализа качества, потерь, джиттера и задержок, как обычный RTP поток:

Image Added