Медіашляхи для відеодзвінка
Огляд шляхів медіа-мережі, які використовує Video Call – для ІТ-персоналу
Адреса сервера ретрансляції відеодзвінків: vcct.healthdirect.org.au
Досягнення найкращої якості з'єднання
1. Для більшості мережевих шляхів узгодження, швидше за все, призведе до дійсного медіа-з’єднання.
- Прямий одноранговий зв’язок через UDP забезпечує найкраще з’єднання , але часто буде недоступним у мережах організацій через обмеження безпеки їхніх мережевих політик.
- Захищене тунельне з’єднання TCP є найменш бажаним варіантом для передачі медіафайлів, але, швидше за все, воно підтримуватиметься без змін безпеки мережі.
Рекомендований варіант: для багатьох мереж дозвіл виходу NAT на UDP-порт 3478 на сервері ретрансляції (мережевий шлях 2, вище) забезпечить низьку затримку з невеликими витратами. Для цього знадобиться лише незначна зміна конфігурації мережі з низьким рівнем ризику.
2. Щоб переконатися, що трафік відеодзвінка має пріоритет як спілкування в реальному часі, перегляньте наведені нижче параметри.
- Якщо ваш маршрутизатор здатний пріоритезувати трафік зі значенням поля DSCP 34 (він же Assured Forwarding 41 або AF41), ви можете налаштувати це. Весь трафік WebRTC у реальному часі позначається таким чином, і це покращить якість відеодзвінків та інших рішень для відеоконференцій.
- Якщо ваш маршрутизатор не підтримує зазначені вище функції, ви можете налаштувати QoS на пріоритетність пакетів UDP у діапазоні портів 5000–40000, і це допоможе визначити пріоритетність відеопакетів і зменшити затримку. WebRTC використовує протокол RTP для доставки медіа-потоків, а RTP зазвичай використовує UDP 5000-40000. Це може призвести до пріоритетності деяких пакетів, які не потребують цього, але більшість будуть RTP-пакетами. Налаштування QoS таким чином гарантує, що відеопотоки матимуть найменшу кількість переривань і тремтіння.
Відеодзвінок спробує використати найкращий мережевий шлях, який зможе знайти.
У наведеній нижче таблиці перераховано мережеві шляхи, які він шукатиме, у порядку пріоритету:
| Мережевий шлях | Порт сервера STUN/Relay |
|---|---|
|
1: Прямий одноранговий UDP з проходженням NAT за допомогою сервера STUN Кожна кінцева точка виявить свою зовнішню Інтернет-адресу за допомогою наданого сервера STUN. Ця адреса надається іншій кінцевій точці та використовується для налаштування з’єднання за допомогою трансляції мережевих адрес. Медіа потоки надходять через випадково вибрані порти через великий діапазон UDP-портів 49152–65535. |
3478 (UDP) |
|
2: через сервер ретрансляції відеодзвінків, використовуючи вихід, маршрутизований за UDP Якщо з’єднання не може бути встановлено за допомогою зазначеного вище прямого однорангового зв’язку, то налаштований UDP-порт 3478 сервера TURN спробує встановити ретрансляцію до віддаленої кінцевої точки. Ця адреса ретрансляції надається іншій кінцевій точці та використовується для встановлення з’єднання через ретрансляцію, назад через з’єднання локальної кінцевої точки з сервером TURN. Медіа надходить до UDP-порту 3478 на сервері TURN. |
3478 (UDP) |
|
3: Через сервер ретрансляції відеодзвінків із використанням вихідного каналу з маршрутизацією TCP Якщо за допомогою UDP не вдається встановити з’єднання з сервером TURN, з’єднання з сервером TURN встановлюється через TCP 443, а не через UDP 3478. Медіа потоки надходять на порт TCP 443 на сервері TURN. |
3478 (TCP) |
|
4: Через сервер ретрансляції відеодзвінків, використовуючи TCP-тунелювання через локальний веб-проксі-сервер Якщо не вдається встановити маршрутизоване з’єднання через NAT із сервером TURN, буде зроблена спроба встановити тунельне з’єднання з TCP-портом 443 через веб-проксі-сервер, налаштований у браузері. Мультимедіа надходить через веб-проксі до TCP-порту 443 на сервері TURN. |
443 (TCP) |
|
5a, 5b: Через сервер ретрансляції відеодзвінків із використанням захищеного TCP Як для 3 або 4 вище, але з використанням TLS TCP-з’єднання з сервером TURN. |
443 (TCP/TLS) |
Додаткову інформацію див. у розділі Сервери ретрансляції відеодзвінків .