Vaizdo skambučių medijos keliai
Vaizdo skambučių naudojamų medijos tinklo kelių apžvalga – IT darbuotojams
Vaizdo skambučių perdavimo serverio adresas: vcct.healthdirect.org.au
Geriausios kokybės ryšio pasiekimas
1. Daugelio tinklo kelių atveju derybos greičiausiai baigsis galiojančiu medijos ryšiu.
- Tiesioginis „peer-to-peer“ ryšys per UDP užtikrina geriausią ryšį , tačiau jis dažnai nebus pasiekiamas institucijų tinkluose dėl jų tinklo politikos saugumo apribojimų.
- Saugus tunelinis TCP ryšys yra mažiausiai pageidautinas medijos perdavimo variantas , tačiau greičiausiai jis bus palaikomas be jokių tinklo saugumo pakeitimų.
Rekomenduojama parinktis: daugelyje tinklų NAT išėjimo į UDP 3478 prievadą perdavimo serveryje (2 tinklo kelias, aukščiau) leidimas užtikrins mažą delsą ir nedidelę pridėtinę vertę. Tam turėtų reikėti tik nedidelio, mažos rizikos tinklo konfigūracijos pakeitimo.
2. Norėdami užtikrinti, kad vaizdo skambučių srautas būtų teikiamas pirmenybė kaip realaus laiko bendravimas, peržiūrėkite toliau pateiktas parinktis:
- Jei jūsų maršrutizatorius gali prioritetizuoti srautą, kurio DSCP lauko reikšmė yra 34 (dar žinoma kaip „Assured Forwarding 41“ arba „AF41“), galbūt galite tai sukonfigūruoti. Visas realaus laiko „WebRTC“ srautas žymimas tokiu būdu, ir tai pagerins vaizdo skambučių ir kitų vaizdo konferencijų sprendimų kokybę.
- Jei jūsų maršrutizatorius nepalaiko aukščiau išvardytų funkcijų, galite nustatyti „QoS“, kad jis teiktų pirmenybę UDP paketams 5000–40000 prievadų diapazone. Tai padės teikti pirmenybę vaizdo paketams ir sumažinti bet kokį vėlavimą. „WebRTC“ naudoja RTP protokolą medijos srautams perduoti, o RTP paprastai naudoja UDP 5000–40000. Tai atlikus, gali būti teikiama pirmenybė kai kuriems paketams, kuriems to nereikia, tačiau dauguma jų bus RTP paketai. Nustačius „QoS“ tokiu būdu, bus užtikrinta, kad vaizdo srautai kuo mažiau trukdys ir virpės.
Vaizdo skambutis bandys naudoti geriausią tinklo kelią, kurį gali rasti.
Šioje lentelėje pateikiami tinklo keliai, kurių bus ieškoma, pirmenybės tvarka:
| Tinklo kelias | STUN/Relė serverio prievadas |
|---|---|
|
1: Tiesioginis „peer-to-peer“ UDP su STUN serverio padedamu NAT apėjimu Kiekvienas galinis įrenginys atras savo išorinį interneto adresą naudodamas pateiktą STUN serverį. Šis adresas pateikiamas kitam galiniam įrenginiui ir naudojamas ryšiui užmegzti naudojant tinklo adresų vertimą. Medijos srautai perduodami per atsitiktinai parinktus prievadus plačiame UDP prievadų diapazone nuo 49152 iki 65535. |
3478 (UDP) |
|
2: Per vaizdo skambučių perdavimo serverį, naudojant UDP maršrutizuotą išeinantįjį ryšį Jei nepavyksta užmegzti ryšio naudojant aukščiau nurodytą tiesioginį „peer-to-peer“ ryšį, bus bandoma užmegzti ryšį su nuotoliniu galiniu įrenginiu per sukonfigūruotą TURN serverio UDP prievadą 3478. Šis perdavimo adresas pateikiamas kitam galiniam įrenginiui ir naudojamas ryšiui per perdavimo įrenginį užmegzti, o vėliau – per vietinio galinio įrenginio ryšį su TURN serveriu. Medijos srautai nukreipiami į UDP prievadą 3478 TURN serveryje. |
3478 (UDP) |
|
3: Per vaizdo skambučių perdavimo serverį, naudojant TCP maršrutizuotą išeinantįjį ryšį Jei nepavyksta užmegzti ryšio su TURN serveriu naudojant UDP, ryšys su TURN serveriu užmezgamas per TCP 443, o ne per UDP 3478. Medija siunčiama į TCP 443 prievadą TURN serveryje. |
3478 (TCP) |
|
4: Per vaizdo skambučių perdavimo serverį, naudojant TCP tuneliavimą per vietinį žiniatinklio tarpinį serverį Jei nepavyksta užmegzti maršrutizuoto ryšio su TURN serveriu per NAT, bus bandoma užmegzti tunelinį ryšį su TCP 443 prievadu per naršyklės sukonfigūruotą žiniatinklio tarpinį serverį. Medija teka išorėn per žiniatinklio tarpinį serverį į TCP 443 prievadą TURN serveryje. |
443 (TCP) |
|
5a, 5b: per vaizdo skambučių perdavimo serverį, naudojant saugų TCP protokolą Kaip ir 3 arba 4 punkte, bet naudojant TLS TCP ryšį su TURN serveriu. |
443 (TCP/TLS) |
Daugiau informacijos žr. Vaizdo skambučių perdavimo serveriai .