Медыяшляхі для відэазванкоў
Агляд шляхоў медыя-сетак, якія выкарыстоўваюцца відэазванком - для ІТ-персаналу
Адрас сервера рэтрансляцыі відэазванкоў: 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 паміж асобнымі асобамі з падтрымкай STUN-сервера і праходжаннем NAT Кожная канцавая кропка атрымае свой знешні інтэрнэт-адрас з дапамогай прадастаўленага STUN-сервера. Гэты адрас перадаецца іншай канцавой кропцы і выкарыстоўваецца для ўстанаўлення злучэння праз трансляцыю сеткавых адрасоў. Патокі мультымедыя перадаюцца праз выпадкова выбраныя парты ў шырокім дыяпазоне UDP-партоў 49152 - 65535. |
3478 (УДП) |
|
2: Праз сервер рэтрансляцыі відэазванкоў з выкарыстаннем выходнага канала з маршрутызацыяй UDP Калі злучэнне не можа быць усталявана з дапамогай вышэйзгаданага прамога аднарангавага злучэння, то будзе зроблена спроба ўсталяваць рэтрансляцыю з аддаленай канцавой кропкай праз настроены UDP-порт 3478 сервера TURN. Гэты адрас рэтрансляцыі перадаецца іншай канцавой кропцы і выкарыстоўваецца для ўстанаўлення злучэння праз рэтрансляцыю і назад праз падключэнне лакальнай канцавой кропкі да сервера TURN. Медыяфайлы перадаюцца на UDP-порт 3478 на серверы TURN. |
3478 (УДП) |
|
3: Праз сервер рэтрансляцыі відэазванкоў, выкарыстоўваючы выходны канал па пратаколе TCP Калі падключэнне да сервера TURN не ўдаецца ўсталяваць праз UDP, яно ўсталёўваецца праз TCP 443, а не UDP 3478. Медыяфайлы перадаюцца на TCP-порт 443 на серверы TURN. |
3478 (ТКП) |
|
4: Праз сервер рэтрансляцыі відэазванкоў, выкарыстоўваючы тунэляванне TCP праз лакальны вэб-проксі-сервер Калі маршрутызаванае злучэнне праз NAT не можа быць усталявана з серверам TURN, будзе зроблена спроба тунэляванага злучэння з TCP-портам 443 праз настроены ў браўзеры вэб-проксі-сервер. Медыяфайлы перадаюцца праз вэб-проксі на TCP-порт 443 на серверы TURN. |
443 (ТКП) |
|
5a, 5b: Праз сервер рэтрансляцыі відэазванкоў з выкарыстаннем бяспечнага TCP Як і ў выпадку з пунктамі 3 ці 4 вышэй, але з выкарыстаннем TLS-злучэння з серверам TURN. |
443 (TCP/TLS) |
Больш падрабязную інфармацыю глядзіце ў раздзеле Серверы рэтрансляцыі відэазванкоў .