Медийни пътища за видеообаждане
Преглед на пътищата на медийната мрежа, използвани от Video Call - за ИТ персонал
Адрес на сървъра за предаване на видео разговори: vcct.healthdirect.org.au
Постигане на най-качествена връзка
1. За повечето мрежови пътища договарянето вероятно ще доведе до валидна медийна връзка.
- Директната peer-to-peer чрез 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: Директен peer-to-peer UDP, със STUN сървърно подпомагано NAT преминаване Всяка крайна точка ще открие своя външен интернет адрес с помощта на предоставения STUN сървър. Този адрес се предоставя на другата крайна точка и се използва за настройка на връзката чрез преобразуване на мрежови адреси. Мултимедията протича през произволно избрани портове през голям диапазон от UDP портове 49152 - 65535. |
3478 (UDP) |
|
2: Чрез сървър за предаване на видеообаждания, използвайки UDP-маршрутизиран изход Ако връзката не може да бъде установена чрез горния директен peer to peer, тогава конфигурираният TURN сървър UDP порт 3478 ще се опита да установи препредаване към отдалечената крайна точка. Този адрес на релето се предоставя на другата крайна точка и се използва за настройка на връзката през релето, обратно през връзката на локалната крайна точка към 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) |
За повече информация вижте сървъри за предаване на видео разговори .