Mediebaner for videosamtaler
En oversikt over medienettverksveiene som brukes av Video Call – for IT-ansatte
Adresse for reléserver for videoanrop: vcct.healthdirect.org.au
Oppnå forbindelse av beste kvalitet
1. For de fleste nettverksstier vil forhandlingen sannsynligvis resultere i en gyldig medietilkobling.
- Direkte peer-to-peer via UDP gir den beste tilkoblingen , men vil ofte være utilgjengelig på tvers av institusjonelle nettverk på grunn av sikkerhetsbegrensninger i nettverkspolicyene deres.
- En sikker tunnelert TCP-tilkobling er det minst ønskelige alternativet for medieoverføring, men det støttes sannsynligvis uten endringer i nettverkssikkerheten.
Anbefalt alternativ: For mange nettverk vil det å tillate NAT-utgang til UDP-port 3478 på reléserveren (nettverksbane 2, ovenfor) gi lav latens med lite overhead. Dette burde bare kreve en mindre endring i nettverkskonfigurasjonen med lav risiko.
2. For å sikre at videosamtaletrafikk prioriteres som sanntidskommunikasjon, se på alternativene nedenfor:
- Hvis ruteren din er i stand til å prioritere trafikk med DSCP-feltverdien 34 (også kjent som Assured Forwarding 41 eller AF41), kan du konfigurere dette? All WebRTC-trafikk i sanntid er merket på denne måten, og dette vil forbedre kvaliteten på videosamtaler og andre videokonferanseløsninger.
- Hvis ruteren din ikke har funksjonaliteten ovenfor, kan du sette QoS til å prioritere UDP-pakker i portområdet 5000–40000. Dette vil bidra til å prioritere videopakker og redusere forsinkelser. WebRTC bruker RTP-protokollen for å levere mediestrømmer, og RTP bruker vanligvis UDP 5000–40000. Dette kan prioritere noen pakker som ikke trenger det, men de fleste vil være RTP-pakker. Å sette opp QoS på denne måten vil sikre at videostrømmer har minst mulig avbrudd og jitter.
Videoanropet vil forsøke å bruke den beste nettverksstien den kan finne.
Tabellen nedenfor viser nettverksstiene den vil se etter, i prioritert rekkefølge:
| Nettverkssti | STUN/Relay-serverport |
|---|---|
|
1: Direkte peer-to-peer UDP, med STUN-serverassistert NAT-traversering Hvert endepunkt vil oppdage sin eksterne Internett-adresse ved hjelp av den medfølgende STUN-serveren. Denne adressen gis til det andre endepunktet og brukes til å sette opp forbindelsen via Network Address Translation. Medieflyter over tilfeldig valgte porter over et stort utvalg av UDP-porter 49152–65535. |
3478 (UDP) |
|
2: Via reléserver for videoanrop, ved bruk av UDP-rutet utgående Hvis en tilkobling ikke kan opprettes ved hjelp av den direkte peer-to-peer-tilkoblingen ovenfor, vil den konfigurerte TURN-serverens UDP-port 3478 bli forsøkt å opprette et relé til det eksterne endepunktet. Denne reléadressen gis til det andre endepunktet og brukes til å sette opp tilkoblingen gjennom reléet, tilbake gjennom det lokale endepunktets tilkobling til TURN-serveren. Medieflyter til UDP-port 3478 på TURN-serveren. |
3478 (UDP) |
|
3: Via reléserver for videoanrop, ved bruk av TCP-rutet utgående Hvis det ikke kan opprettes en forbindelse til TURN-serveren via UDP, opprettes forbindelsen til TURN-serveren via TCP 443, ikke UDP 3478. Media flyter utover til TCP-port 443 på TURN-serveren. |
3478 (TCP) |
|
4: Via videosamtale-reléserver, ved bruk av TCP-tunneling gjennom en lokal web-proxyserver Hvis en rutet forbindelse via NAT ikke kan opprettes til TURN-serveren, vil en tunnelert forbindelse til TCP-port 443 bli forsøkt via nettleserens konfigurerte web-proxyserver. Media flyter utover gjennom webproxyen, til TCP-port 443 på TURN-serveren. |
443 (TCP) |
|
5a, 5b: Via videosamtale-reléserver, ved bruk av sikker TCP Som for 3 eller 4 ovenfor, men ved bruk av en TLS TCP-tilkobling til TURN-serveren. |
443 (TCP/TLS) |
Hvis du vil ha mer informasjon, kan du se Reléservere for videoanrop .