Medieveje til videoopkald
En oversigt over de medienetværksveje, der bruges af Video Call - for IT-personale
Adresse for videoopkaldsrelæserver: vcct.healthdirect.org.au
Opnå den bedste forbindelse
1. For de fleste netværksstier vil forhandlingen sandsynligvis resultere i en gyldig medieforbindelse.
- Direkte peer-to-peer via UDP giver den bedste forbindelse , men vil ofte ikke være tilgængelig på tværs af institutionelle netværk på grund af sikkerhedsbegrænsninger i deres netværkspolitikker.
- En sikker tunneleret TCP-forbindelse er den mindst ønskelige mulighed for medieoverførsel, men den understøttes sandsynligvis uden ændringer i netværkssikkerheden.
Anbefalet mulighed: For mange netværk vil det give lav latenstid med minimal overhead, hvis NAT-udgang tillades til UDP-port 3478 på relæserveren (netværkssti 2 ovenfor). Dette burde kun kræve en mindre ændring af din netværkskonfiguration med lav risiko.
2. For at sikre, at videoopkaldstrafik prioriteres som realtidskommunikation, bedes du se på nedenstående muligheder:
- Hvis din router er i stand til at prioritere trafik med DSCP-feltværdien 34 (også kendt som Assured Forwarding 41 eller AF41), kan du så konfigurere dette? Al WebRTC-trafik i realtid er markeret på denne måde, og dette vil forbedre kvaliteten af videoopkald og andre videokonferenceløsninger.
- Hvis din router ikke er i stand til ovenstående funktionalitet, kan du indstille QoS til at prioritere UDP-pakker i portområdet 5000-40000, hvilket vil hjælpe med at prioritere videopakker og reducere eventuel forsinkelse. WebRTC bruger RTP-protokollen til at levere mediestreams, og RTP bruger generelt UDP 5000-40000. Dette kan prioritere nogle pakker, der ikke har brug for det, men størstedelen vil være RTP-pakker. Opsætning af QoS på denne måde vil sikre, at videostreams har mindst mulig afbrydelse og jitter.
Videoopkaldet vil forsøge at bruge den bedste netværkssti, den kan finde.
Følgende tabel viser de netværksstier, der søges efter, i prioriteret rækkefølge:
| Netværkssti | STUN/Relay-serverport |
|---|---|
|
1: Direkte peer-to-peer UDP, med STUN serverassisteret NAT-traversal Hvert endepunkt finder sin eksterne internetadresse ved hjælp af den medfølgende STUN-server. Denne adresse gives til det andet endepunkt og bruges til at oprette forbindelsen via Network Address Translation. Mediestrømme over tilfældigt udvalgte porte over et stort område af UDP-porte 49152 - 65535. |
3478 (UDP) |
|
2: Via videoopkaldsrelæserver ved hjælp af UDP-rutet udgang Hvis der ikke kan oprettes en forbindelse ved hjælp af ovenstående direkte peer-to-peer, vil den konfigurerede TURN-server UDP-port 3478 blive forsøgt at etablere et relæ til det eksterne slutpunkt. Denne relæadresse gives til det andet slutpunkt og bruges til at oprette forbindelsen via relæet, tilbage gennem det lokale slutpunkts forbindelse til TURN-serveren. Mediestrømme til UDP-port 3478 på TURN-serveren. |
3478 (UDP) |
|
3: Via videoopkaldsrelæserver ved hjælp af TCP-routeret udgang Hvis der ikke kan oprettes en forbindelse til TURN-serveren via UDP, oprettes forbindelsen til TURN-serveren via TCP 443, ikke UDP 3478. Medier flyder udad til TCP-port 443 på TURN-serveren. |
3478 (TCP) |
|
4: Via videoopkaldsrelæserver ved hjælp af TCP-tunneling gennem en lokal webproxyserver Hvis en rutet forbindelse via NAT ikke kan etableres til TURN-serveren, vil en tunnelforbindelse til TCP-port 443 blive forsøgt via browserens konfigurerede webproxyserver. Medier flyder udad via webproxyen til TCP-port 443 på TURN-serveren. |
443 (TCP) |
|
5a, 5b: Via videoopkaldsrelæserver ved hjælp af sikker TCP Som i 3 eller 4 ovenfor, men ved brug af en TLS TCP-forbindelse til TURN-serveren. |
443 (TCP/TLS) |
For yderligere information, se Relay-servere for videoopkald .